# 6. Strafing¶

*Strafing* in the context of Half-Life speedrunning refers to the technique of pressing the correct movement keys (usually the WASD keys) and moving the mouse left and right in a precise way to increase the player speed beyond what the developers intended or make sharp turns without sacrificing too much speed. Strafing as a technique can be achieved similarly in the air and on the ground. If there is a need to distinguish between them, we refer to the former as “airstrafing” and the latter as “groundstrafing”. Strafing is commonly accompanied by a series of jumps intended to keep the player off the ground, as there is friction when moving on the ground. For the purpose of our discussions, the sole act of jumping repeatedly like a rabbit, regardless of whether strafing is done concurrently, is *bunnyhopping*, although the reader will find some in the community who include airstrafing when the term “bunnyhopping” is used. In this chapter, we will only discuss strafing and not bunnyhopping.

While this chapter is not the first mathematical treatment of this topic, it is the goal of the author to write the definitive analysis and optimisation of strafing in a significantly greater level of precision and thoroughness than seen in other sources. This chapter shall serve as the starting point and baseline for further discussions and analysis of strafing-related techniques and physics. Other attempts at mathematical treatments of strafing like this by injx, this by flafla2, this by Kared13, this by ZdrytchX, this by jrsala, and this by Matt’s Ramblings, are ad-hoc and suffer from flaws that make them less suited for further analyses (e.g. surfing analysis, speed-preserving strafing, curvature analysis, minimal-time paths), gaining a deeper understanding of strafing, or indeed for practical implementations.

Strafing is so fundamental to speedrunning, that a speedrunner ought to “get it out of the way” while focusing on other techniques. Strafing should be viewed as a building block that is used as a basis for other speedrunning techniques and tricks. If we do not cannot perform strafing near optimally, the entire speedrun falls apart. This applies to TASes as well: we want to optimise strafing as much as possible so that we can “forget about it” when constructing a TAS and permitting us to concentrate on the planning, the “general picture”, and executing specific tricks.

Tip

Be sure to familiarise yourself with the fundamentals of player movement described in Player movement basics. Without the prerequisite knowledge, this chapter can be hard to follow.

## 6.1. Basic intuition¶

Before delving into the mathematics, it may be helpful to have a geometric intuition of how strafing works. In Half-Life, and indeed in real-life classical mechanics, the velocity and acceleration are defined as Euclidean vectors with a length (or magnitude) and a direction, typically drawn as an arrow in the Euclidean space. In the strafing context, we are only interested in vectors drawn on a 2D space. When a body in Half-Life accelerates in a frame, the acceleration vector, scaled by frame time, is added to the velocity vector to obtain a new velocity vector,

This may be interpreted geometrically as putting the acceleration arrow after the velocity arrow to obtain a new velocity arrow. The diagram looks like a triangle, as seen in Fig. 6.1.. Now, notice that the new velocity arrow is *longer* than the previous velocity arrow. This means that the *speed* (represented by the arrow length) has been increased.

In Half-Life physics, the magnitude or length of the acceleration vector depends on the current speed and the angle between the velocity and itself, which in turn is controlled by the viewangles, as explained in Air and ground movements. The task of finding the optimal angles to achieve a certain goal is the topic of this chapter.

## 6.2. Building blocks¶

Regardless of the objective of strafing, its physics is governed by the fundamental movement equation (FME). We will construct several few mathematical building blocks to aid further analyses. Firstly, write , where is already given in Air and ground movements. Expanding each yields

This can be done because the dot product satisfies the distributive law. Very quickly, we obtained (6.1) which is sometimes called the *scalar FME*, often used in practical applications as the most general way to compute new *speeds* (as opposed to velocity vectors) given .

Tip

This is a very common and useful trick that can be used to quickly yield an expression for the magnitude of vectorial outputs without explicit vectorial computations or geometric analyses. Half-Life physicists ought to learn this technique well.

From equation (6.1), we can further write down the equations by assuming and respectively, to eliminate . These new equations can be found by expanding , again already given previously. We get

Note that when , we have . Define such that

Assuming , then if , we have . If , then . Define also such that and therefore , as

Note

Note that we permit and , but restricts . We never need to invert the cosines to obtain and in theoretical and practical computations when their absolute values are greater than 1. However, had we really done it, and would have imaginary parts.

Putting these together, we can write the more explicitly as a piecewise-defined function

The new speed can also be correspondingly written as a piecewise-defined function by substituting with (6.3). These equations will be important in the exploitative analyses of the FME shortly.

However, computing speeds is sometimes not sufficient. We sometimes want to also compute velocity *vectors* endowed with both directionality and magnitude, but without worrying about player viewangles and . We can achieve this by parametrising in terms of a rotation of by an angle of . This may be expressed as

This is a matrix multiplication of by a rotation matrix. The benefit of writing the FME in this form is that we no longer need to worry about calculating and , which, recalling from View vectors, depend on the yaw angle in the 2D case. We also no longer need to worry about , , and needed to compute . All we need to know is the angle between velocity and acceleration vectors. This can make efficient computations easier as well, because the angle is easily computed (as we will see shortly) in just a few lines of code.

Caution

Remember from Notations Used that vectors in this documentation are *row vectors*. Therefore, the order of multiplication is different from those in standard linear algebra textbooks. In fact, the components in are also ordered differently.

With this idea in mind, we can rewrite the FME as

Note that the precaution is needed so that the unit vector is well defined. In other words, the directionality of is lost when it is zero. This is therefore one downside of parametrising in terms of , where the special case of zero velocity must be handled separately by replacing (and assuming as usual) in (6.4), thereby involving the viewangles in the computations.

When written in the form of (6.4), positive gives *clockwise* rotations, while negative gives *anticlockwise* rotations. If this convention is inconvenient for a particular application, one can easily reverse the directionality by reversing the signs of the elements in the rotation matrix.

## 6.3. Maximum acceleration¶

Airstrafing to continuously gain speed beyond what the developers intended is one of the oldest speedrunning tricks. It is of no surprise that one of the earliest inquiries into Half-Life physics is related to the question of how to airstrafe with the maximum acceleration, when research began circa 2012 by the author of this documentation. In this section, we will provide precise mathematical descriptions of how maximum-acceleration strafing works in a way that will provide a baseline for further analyses and also can readily be implemented in TAS tools.

We must define our metric for “maximum acceleration” in a mathematically precise way. Specifically, we want to maximise the *average scalar acceleration* over some period of time . The average scalar acceleration may in turn be defined as

where is the speed at time and is the initial speed. We believe this is a valid metric because it reflects the intention of the speedrunner better in the field: namely, to increase the speed as much as possible over some time, which automatically also increases the distance travelled within the same period of time, since the distance travelled is simply the sum of all the speeds in every frame within the period of time in question.

### 6.3.1. Arguments of the maxima¶

Let be the current player velocity, the velocity after strafing, and the game frame time (see Frame rate). To maximise the average scalar acceleration, it is sufficient to maximise the per-frame scalar acceleration

It turns out that maximising the per-frame acceleration “greedily” also maximises the global average acceleration over the span of some time . In other words, optimising only the individual frames result in the optimal “overall” acceleration as well. This is perhaps owing to good luck, because it is by no means a universal rule that local maxima yield a global maximum in other instances. We will prove this assertion in a later section.

Now, we will assume and are independent of any other variables. Therefore, we can ignore them, and the task of maximising acceleration boils down to maximising solely the new speed . Looking at (6.2), observe that the new speed is invariant to the transformation , because both and are even functions. Without loss of generality, we will consider only .

Before we search for the global optimum, we must understand the behaviours of the piecewise . Observe that the maximum of occurs at or , if we consider the entire domain of , or

In addition, we also see that is strictly increasing in and strictly decreasing in . Indeed, the plot for against forms a semi-ellipse except in degenerate cases.

On the other hand, the maximum of , however, depends on the sign of . The symbols here have already been defined in Air and ground movements.

If , then is strictly increasing. If , then is strictly decreasing.

The relative sizes of can vary in various ways, and there are in total permutations we must consider in order to study the behaviour of the new speed and therefore the maximum point.

If and only if , , and . In , is strictly increasing with a maximum point at . In , is strictly decreasing. However, if , then for the entire range. We conclude that

If and only if , , and . In , is strictly decreasing with a maximum point at . In , . Therefore, we always have

If and only if , , and . In , is strictly increasing. In , the maximum occurs at . This implies

If and only if , , and . In , we have , which is strictly decreasing because . Therefore, the maximum point is at

If and only if , , and . In , is strictly increasing. In , is also strictly increasing. But since at , we conclude that

As we will see later, this case actually yields , which is useless. But we will include this case for the sake of completeness.

If and only if , , . The rest of the analysis and the result are exactly the same as that in the case.

Given the case-by-case study of these six permutations, we can summarise that the maximum point of occurs at

To implement (6.5), care must be taken when computing and . This is because when , we have and .

### 6.3.2. Optimality¶

We show that the angles given in (6.5) actually gives the highest average acceleration over some time , more than just the maximum speed after one frame of strafing. After one frame of strafing, the average acceleration is given by

Since the only variable is , clearly the angles in (6.5) maximises the acceleration. Now suppose the player has strafed for
some time at a *maximum* average acceleration possible so that the final speed is some , and it is required to strafe another frame. The new average acceleration after another frame is then

where is given by the FME with as the starting speed. Since the only variable is again , clearly (6.5) gives the maximum . We conclude by induction that (6.5) gives the maximum average acceleration over some time .

On top of that, we also show that (6.5) gives the highest average *speed* over some time . In other words, it admits the shortest time possible to travel any distance . Given an initial speed of , the average speed after one frame of strafing is

Clearly (6.5) gives the maximum average speed because is the only variable. Now, suppose the player has strafed for some time at the maximum possible average speed with some final speed . After another frame of strafing, the new average speed is

where is given by the FME with as the starting speed and is the only variable. Again, the angles given by (6.5) maximises .

### 6.3.3. Speed equations¶

Using (6.5) we obtain the optimal under various situations. We can proceed to eliminate and from (6.1) to obtain a clean formulae for speed after one frame. Further, we can also obtain formulae for the speed after frames, assuming all the movement variables are held constant.

For airstrafing where there is no friction (namely ), we can solve the recurrence relations easily and obtain formulae for the speed after frames of strafing as follows:

These equations can be quite useful in planning. For example, to calculate the number of frames required to airstrafe from ups to ups at default Half-Life settings and 1000 fps, we solve

In addition, under airstrafing again, we can integrate the speed equations to obtain distance-time equations. Before doing this, we must make a change of variables by assuming continuous time and writing . Then we compute

for each case.

For groundstrafing, however, the presence of friction means simple substitutions may not work. In more complex cases, it may be desirable to simply calculate the speeds frame by frame using the scalar FME.

### 6.3.4. Effects of frame rate¶

The frame rate can affect the acceleration significantly. Looking at the second case of (6.5), the acceleration per frame is

One can immediately see that the lower the (that is, the higher the game frame rate), the higher the acceleration. The first case of (6.5) and also provides greater accelerations at greater game frame rates. The other cases, however, do not admit greater accelerations at higher frame rates.

#### 6.3.4.1. When ¶

Recall in Frame rate that, on older game engines, the player frame rate is the game frame rate rounded towards zero to the nearest 0.001. This is not normally a problem, because speedruns are often run at frame rates such that , thus eliminating any slowdown. However, at the time of writing (July 2020), there exists an area of contention regarding the WON version of Blue Shift, where the default frame rate is 72 fps and some community rules forbid raising it further via console commands. Clearly, the slowdown factor at 72 fps is less than 1. There is a question of whether it is optimal to

use a lower such that (which would be or in the WON Blue Shift case), or

use and in some of the frames and switch to in other frames

We claim that it is better to always lower such that and . Precisely, we claim that the *average speed* over some real time is maximised when throughout time . To see why, recall that the average speed is simply the total distance travelled divided by the time taken. The average speed in the first frame is

Immediately, we can see that to maximise the average speed, we must have so that is as big as possible. Now suppose the player has already travelled for some distance at a *maximum* average speed , taking some real time . We need to strafe another frame. The new average speed is then given by

Recall that . Write for some . Eliminating , the new average speed may be rewritten as

Observe that to maximise , we must have which implies . By induction, we have proved our claim stated earlier.

### 6.3.5. Effects of friction¶

There is a limit to the speed achievable by maximum-acceleration groundstrafing alone. There will be a critical speed such that the increase in speed exactly cancels the friction, so that , namely the speed reaches a steady state. For the common example of default game settings, suppose the (the first case of (6.6)), (see Air and ground movements), and geometric friction (see Ground friction) is at play. Then we may write

Solving for , we obtain the maximum groundstrafe speed for this particular configuration, keeping in mind that is dependent on :

Take the case of default Half-Life settings at 1000 fps, we calculate

This is then the absolute maximum speed achievable by groundstrafing alone in vanilla Half-Life. At another common frame rate of 100 fps, we instead obtain the steady state speed of . There is nothing we can do to groundstrafe beyond this speed!

Interestingly, when there is edge friction, the game sets with the default settings, and the maximum groundstrafe speed is drastically reduced to , which is indeed devastating as previously claimed in Edgefriction, because it is not significantly more than the normal running speed of 320.

We also see that when the entity friction is less than 1, the effect on the maximum groundstrafe speed is very small. For instance, if , then . This yields the maximum groundstrafe speed of , barely larger than the normal groundstrafe speed.

Traditionally, jumping is done repeatedly to lift off from the ground to avoid the effects of ground friction. However, the presence of the bunnyhop cap (see Bunnyhop cap) compels speedrunners to opt for ducktapping (see Ducktapping) instead. Ducktapping has a downside of requiring one frame of ground contact, which introduces one frame of friction. The effect of this one frame of friction can be completely eliminated by setting the frame rate to an extremely high value in that frame alone, which forces while the player is on the ground. If this is not possible, or forbidden, then the one frame of friction is unavoidable.

It turns out that the single frame of ground friction can be devastating, especially in lower frame rates. In fact, under most circumstances and combinations of movement variables, there exists a fixed point or steady state speed which acts as a limit to the speed a player can maintain indefinitely using only ducktapping and strafing alone. Let be this steady state speed. Let be a function that gives the speed after frames of maximum-acceleration strafing from an initial speed of . Denote the ducktap “period”, or the time the player spends in the air after a ducktap. Define functions

Then gives the speed when the player lands on the ground after a ducktap and airstrafing. In general, to find the steady state speed , we solve the equation

To give some concrete examples, consider ducktapping and strafing in a typical 1000 fps TAS with default Half-Life settings. Assuming so that the geometric friction is in effect. Then (6.8) can be rewritten using (6.6) and (4.2) as

where

Assuming , we obtain . This implies that the player is able to maintain at least the default `sv_maxvelocity`

at 1000 fps by ducktapping and strafing. Consider, however, ducktapping and strafing at 100 fps, which is a restriction some in the community are in favour of imposing. Here, (6.8) may instead be rewritten as

With and solving, we instead obtain , which is substantially lower than that at 1000 fps.

### 6.3.6. Growth of speed¶

By obtaining (6.7), we can immediately make a few important observations. In the absence of friction and if , the speed over time grows sublinearly, or . This implies that the acceleration gradually decreases over time, but never reaches zero. It is notable that the acceleration at lower speeds can be substantial (more than linear acceleration) compared to that at higher speeds. To see why, write new speed , then taking the derivative with respective to to obtain acceleration, yielding

for some . Now observe that, at , the acceleration as initial speed decreases .

When , however, possibly in the first case and the fifth case of (6.5), the growth of speed is linear. Even with the presence of ground friction, the growth of speed can be linear under an arithmetic friction. For example, in the default game settings, on the ground when . In addition, the arithmetic friction is at play when . Therefore, the speed at the -th frame is

as long as .

### 6.3.7. Air-ground speed threshold¶

The acceleration of groundstrafe is usually greater than that of airstrafe. It
is for this reason that groundstrafing is used to initiate bunnyhopping.
However, once the speed increases beyond the acceleration will begin
to decrease, as the friction grows proportionally with the speed. There will be
a critical speed beyond which the acceleration of airstrafe exceeds that of
groundstrafe. This is called the *air-ground speed threshold* (AGST), admittedly
a rather non-descriptive name.

Analytic solutions for AGST are always available, but they are cumbersome to write and code. Sometimes the speed curves for airstrafe and groundstrafe intersects several times, depending even on the initial speed itself. A more practical solution in practice is to simply use Equation (6.1) to compute the new airstrafe and groundstrafe speeds then comparing them.

It is also important to note that, even if the air acceleration is greater than the ground acceleration for a given speed, it does not mean that it is optimal to actually leave the ground for air acceleration at that particular time. To illustrate, assume the default Half-Life settings and . Suppose also the player is on the ground, and the speed is very low at . After one frame of groundstrafing, the new speed would be

On the other hand, the player could also ducktap or jump to get into the air and airstrafe, which would have yielded a speed of

We have . If the player actually ducktaps to leave the ground, it would have taken the player approximately 0.25s to land back onto the ground. However, before the player could have done so, the air acceleration would have already diminished owing to the sublinear growth mentioned in Growth of speed. For example, even with , the next speed is for a speed difference of , which is lower than what would be obtained from groundstrafing.

### 6.3.8. Effects of bunnyhop cap¶

It is impossible to avoid the bunnyhop cap (see Bunnyhop cap) when jumping in later official releases of the game. To lift off the ground and avoid the effects of ground friction, one alternative would be to ducktap instead (see Ducktapping). However, each ducktap requires the player to slide on the ground for one frame. Without using very high frame rates to force the frame to be , the player will lose speed due to friction, especially at lower frame rates. In addition, the player cannot ducktap if there is insufficient clearance above the player. In such cases, jumping is the only way to maintain speed, though there are different possible ways to approach this. Regardless of the movement strategy, we must not trigger the cap itself when jumping, because that would cause an instant and significant reduction in speed.

It turns out that the answer is not as straightforward as we may have thought and would require more investigations.

## 6.4. Maximum deceleration¶

It is often the case that the player needs to rapidly decelerate in the air or on the ground without any aid using weapons, damage, or solid entities. When the player is on the ground, deceleration is easy to achieve by simply issuing the `+use`

command, which would exponentially reduce the velocity by a factor of 0.3 per frame. When the player is in the air, however, the player must rely on the pure air movement physics to decelerate as much as possible.

### 6.4.1. Arguments of the minima¶

Using the tools and partial results we built earlier in Maximum acceleration, we can perform a similar case-by-case analysis for the different permutations of . We will not repeat some of the steps in the following analyses.

If , then the minimum point is simply at since for all .

Suppose and . Then, is strictly decreasing in , so we must consider the points . We show that the global minimum is still at . Calculate the local minima at and :

Suppose the minimum point is at . This implies

Assume . Then this implies

which is a contradiction, because our supposition that implies . Assume instead that . Then we obtain

But implies and clearly , which is a contradiction. This concludes the proof.

Suppose . Then in , is strictly increasing with a minimum point at . In , is strictly decreasing with a minimum point at and a minimum value of corresponding to . In , the value stays at . We show that the global minimum is yet again at . Calculate the local minima corresponding to and . We have

Suppose the global minimum is at . This implies

Assume . Then we obtain

which is a contradiction. Assume instead that , which implies

But implies . Putting these inequalities together yields

Since and , this further implies that

But implies , which is a contradiction. This concludes the proof.

We conclude that

In , is strictly decreasing. In , we have . If , the minimum point is at because is strictly decreasing. We conclude that

Suppose and . Then for all . Since is an even function in , we have

Suppose and . Then is strictly increasing in , therefore there are also two local minima at and . We claim that the global minimum is at . Suppose the contrary, that is the global minimum is at . This implies

Assume . Then we have

But implies . Putting these inequalities together yields

This contradicts . Assume instead that . Then we have

But implies that , which is a contradiction. This concludes the proof.

Suppose and . In , . In , we simply have . We claim that the global minimum is always at . Suppose the contrary, that the global minimum is at . This implies that

This contradicts the assumption that from which we deduce that . End of proof.

Finally, suppose and . Then we again claim that the global minimum occurs at . Suppose the contrary, that the global minima occur at . Then this implies that

Assume that . Then we have

which contradicts . Assume otherwise that . Then we obtain

On the other hand, implies

But also implies

which is a contradiction. End of proof.

We conclude that

In , is strictly decreasing. In , . We conclude that

In , is strictly increasing. In , is also strictly increasing and ends with at . In , we have . We conclude that

The analysis and result is exactly the same as that in the case.

Combining the above case-by-case findings, we have the global minimum at

### 6.4.2. Effects of frame rate¶

In every case in (6.9), the frame rate has no effect on the deceleration if we ignore the effects of friction. For example, suppose in the first case. Then the speed in the next frame may be written as

Assuming , the absence of friction, and , then the deceleration in one frame is therefore

which is independent of the frame rate.

## 6.5. Speed preserving strafing¶

Speed preserving strafing can be useful when we are strafing at high . It takes only about 4.4s to reach 2000 ups from rest at . While making turns at 2000 ups, if the velocity is not parallel to the global axes the speed will exceed `sv_maxvelocity`

. Occasionally, this can prove cumbersome as the curvature decreases with increasing speed, making the player liable to collision with walls or other obstacles. Besides, as the velocity gradually becomes parallel to one of the global axes again, the speed will drop back to `sv_maxvelocity`

. This means, under certain situations, that the slight speed increase in the process of making the turn has little benefit. Therefore, it can sometimes be helpful to simply make turns at a constant `sv_maxvelocity`

. This is where the technique of *speed preserving strafing* comes into play. Another situation might be that we want to groundstrafe at a constant speed. When the speed is relatively low, constant speed groundstrafing can produce a very sharp curve, which is sometimes desirable in a very confined space.

We first consider the case where friction is absent. Setting in Equation (6.1) and solving,

If then we must have , or

At this point we can go ahead and write out the full formula for that preserves speed while strafing

On the other hand, if friction is present, then we have

By the usual line of attack, we force which implies that , giving the formula

and the necessary condition

We can check that if friction is absent, then and the condition becomes what we have obtained earlier. If this condition failed, however, then we instead have

Note that we took the negative square root, because needs to be as large as possible so that the curvature of the strafing path is maximised, which is one of the purposes of speed preserving strafing. To derive the necessary condition for the formula above, we again employ the standard strategy, yielding

Observe that we need and . Then we square the inequality to yield the converse of the condition for , as expected. Putting these results together, we obtain

Note that, regardless of whether friction is present, if then we might resort to using the optimal angle to strafe instead. This can happen when, for instance, the speed is so small that the player will always gain speed regardless of strafing direction. Or it could be that the effect of friction exceeds that of strafing, rendering it impossible to prevent the speed reduction. If is greater than the maximum groundstrafe speed, then the angle that minimises the inevitable speed loss is obviously the optimal strafing angle.

## 6.6. Curvature¶

The locus of a point obtained by strafing is a spiral. Intuitively, at any given speed there is a limit to how sharp a turn can be made without lowering acceleration. It is commonly known that this limit grows harsher with higher speed. As tight turns are common in Half-Life, this becomes an important consideration that preoccupies speedrunners at almost every moment. Learning how navigate through tight corners by strafing without losing speed is a make-or-break skill in speedrunning.

It is natural to ask exactly how this limit can be quantified for the benefit of TASing. The simplest way to do so is to consider the *radius of curvature* of the path. Obviously, this quantity is not constant with time, except for speed preserving strafing. Therefore, when we talk about the radius of curvature, precisely we are referring to the *instantaneous* radius of curvature, namely the radius at a given instant in time. But time is discrete in Half-Life, so this is approximated by the radius in a given frame.

### 6.6.1. 90 degrees turns¶

Passageways in Half-Life commonly bend perpendicularly, so we frequently make 90 degrees turns by strafing. We intuitively understand how the width of a passage limits the maximum radius of curvature one can sustain without colliding with the walls. This implies that the speed is limited as well. When planning for speedruns, it can prove useful to be able to estimate this limit for a given turn without running a simulation or strafing by hand. In particular, we want to compute the maximum speed for a given passage width.

We start by making some simplifying assumptions that will greatly reduce the
difficulty of analysis while closely modelling actual situations in practice.
Referring to Fig. 6.4., the first assumption we make is
that the width of the corridor is the same before and after the turn. This width
is denoted as , as one can see in the figure. This assumption is
justified because this is often true or approximately true in Half-Life maps.
The second assumption is that the path is circular. The centre of this circle,
also named the *centre of curvature*, is at point . As noted earlier,
the strafing path is in general a spiral with varying radius of curvature.
Nevertheless, the total time required to make such a turn is typically very
small. Within such short time frame, the radius would not have changed
significantly. Therefore it is not absurd to assume that the radius of curvature
is constant while making the turn. The third assumption is that the positions of
the player before and after making the turn coincide with the walls. This
assumption is arguably less realistic, but the resulting path is the larger
circular arc one can fit in this space.

By trivial applications of the Pythagorean theorem, it can be shown that the relationship between the radius of curvature and the width of the corridor is given by

This formula may be used to estimate the maximum radius of curvature for making such a turn without collision. However, the radius of curvature by itself is not very useful. We may wish to further estimate the maximum speed corresponding to this .

### 6.6.2. Radius-speed relationship¶

The following figure depicts the positions of the player at times , and . The initial speed is . All other symbols have their usual meaning.

Based on the figure, the radius of curvature may be approximated as the -intercept, or . Obviously, a more accurate approximation may be achieved by averaging and . However, this results in a clumsy formula with little benefit. Empirically, the approximation by calculating is sufficiently accurate in practice. In consideration of this, it can be calculated that

Note that this is the most general formula, applicable to any type of strafing. From this equation, observe that the radius of curvature grows with the square of speed. This is a fairly rapid growth. On the other hand, under maximum speed strafing, the speed grows with the square root of time. Informally, the result of these two growth rates conspiring with one another is that the radius of curvature grows linearly with time. We also observe that the radius of curvature is directly influenced by , as experienced strafers would expect. Namely, we can make sharper turns at higher frame rates.

From Equation (6.10) we can derive formulae for various types of strafing by eliminating . For instance, in Type 2 strafing we have . Substituting, we obtain a very simple expression for the radius:

Or, solving for , we obtain a more useful equation:

For Type 1 strafing, the formula is clumsier. Recall that we have and

To eliminate , we can trivially rewrite the equation in this form