10. Movement automation

In this chapter we will discuss a few algorithms or implementations of movement automation in a typical TAS tool.

10.1. Vectorial compensation

In Strafing, we discussed various ways to “strafe” with differing objectives, most commonly maximum-acceleration strafing and speed-preserving strafing. In each of these methods, we must derive a formula or, at least, an implicit equation for the angle 𝜃 between 𝐯 and ˆ𝐚 to realise the desired strafing objective. Unfortunately, Half-Life does not allow us to realise the angles to a very high precision. This is because Half-life uses the DELTA mechanism (see DELTA rounding) to transmit information across the network from client to server and vice versa. Looking at the default delta.lst included in vanilla Half-Life, we see the following line defined under usercmd_t:

DEFINE_DELTA( viewangles[1], DT_ANGLE, 16, 1.0 ),

This shows that the yaw angle is somehow lossily compressed to 16 bits. This means that, to transmit some angle 𝑎 in degrees, it is first converted at the client side to the 16-bit integer representing

int(65536360𝑎)=int(𝑎𝑢𝑑)

where int(𝑥) is the integer part of some real number 𝑥. When the server receives this integer, it is then converted back to the floating point number

36065536(int(65536360𝑎)𝙰𝙽𝙳65535)

This expression looks familiar! Indeed, this entire operation is equivalent to the anglemod function, first described in Anglemod. Given our understanding of anglemod, we know that there are only exactly 65536 possible angles. Although this is already very precise, in the sense that any angle can be realised with only about 0.0015% absolute error, it is possible to do better by controlling the yaw angle 𝜗 in combination with 𝐹 and 𝑆.

By controlling 𝐹 and 𝑆, we can change the direction of the unit acceleration vector ˆ𝐚 (see Air and ground movements) without changing the yaw angle. To see why, recall that 𝐚 =𝐹ˆ𝐟 +𝑆ˆ𝐬, and even keeping ˆ𝐟 and ˆ𝐬 constant, we can change the “weights” 𝐹 and 𝑆 to make the vector sum point to any desired direction, and therefore realise any angle 𝜃 between 𝐯 and ˆ𝐚. Unfortunately, again, looking at the file delta.lst, we see the following lines:

DEFINE_DELTA( forwardmove, DT_SIGNED | DT_FLOAT, 12, 1.0 ),
...
DEFINE_DELTA( sidemove, DT_SIGNED | DT_FLOAT, 12, 1.0 ),
DEFINE_DELTA( upmove, DT_SIGNED | DT_FLOAT, 12, 1.0 ),

Here, the 12 indicates that the client side ˜𝐹, ˜𝑆, and ˜𝑈 (see Forwardmove, sidemove, and upmove for their definitions) will be truncated to 12 bits and integer precision. Since 212 =4096, and a signed integer transmitted across the network is not represented in two’s complement, each of these values will be clamped to [ 2047,2047].

Nevertheless, despite each of 𝜗, 𝐹, and 𝑆 being truncated, we can still combine them to obtain a more accurate angle realisation method than possible using only the yaw or the FSU.

10.1.1. Unconstrained compensation

Suppose we have computed the desired angle 𝜃 between the velocity 𝐯 and the ideal unit acceleration vector ˆ𝐚. To “realise” this angle is to strafe such that the ideal unit acceleration ˆ𝐚 is attained by changing the 𝜗, 𝐹, and 𝑆. However, due to the slight imprecision in each of these values, the ideal ˆ𝐚 can never be attained exactly. Instead, we compute the “best” approximation to it, which may be written as

˜ˆ𝐚=ˆ𝐟𝑅(𝜃)

where ˆ𝐟 is the two dimensional unit forward vector (see View vectors), and 𝑅(𝜃) is the rotation matrix. We may then define the “best” approximation such that the angle between ˆ𝐚 and ˜ˆ𝐚 is minimised. In the ideal case, the angle between the two vectors is zero, meaning the desired unit acceleration vector is attained exactly. However, in practice, there will be a small difference in angle 𝜖 such that

Π=ˆ𝐚˜ˆ𝐚=cos𝜖

Writing out the dot product and simplifying, we obtain

Π=𝑎𝑥cos(𝜗+𝜉)+𝑎𝑦sin(𝜗+𝜉)

where

𝜉=atan2(𝑆,𝐹)

Now, to minimise the angle 𝜖 is to maximise cos𝜖, and therefore maximising Π. We may compute the maximum point of Π [1] by solving

𝑑Π𝑑(𝜗+𝜉)=𝑎𝑥sin(𝜗+𝜉)+𝑎𝑦cos(𝜗+𝜉)=0

yielding

tan(𝜗+𝜉)=𝑎𝑦𝑎𝑥

Note that 𝜗 =𝑢𝑌 for some integer 𝑌 [0,65535]. Inverting the tangent function and computing the remainder when divided by 𝑢 (i.e. modulo 𝑢),

𝜉𝜉𝑢𝑢=atan2(𝑎𝑦,𝑎𝑥)1𝑢atan2(𝑎𝑦,𝑎𝑥)𝑢

Notice that the yaw 𝜗 is gone, and so is the integer yaw 𝑌. This is because the yaw is always divisible by 𝑢, and therefore its remainder is always zero. To slightly simplify implementation, write

𝜉𝑢𝜉𝑢=1𝑢atan2(𝑎𝑦,𝑎𝑥)1𝑢atan2(𝑎𝑦,𝑎𝑥)

That is, if this equality is satisfied, then the 𝜉 (and an appropriate 𝜗) will maximise Π, achieving the best approximation. In practice, however, this equality is rarely satisfied, due to the imprecision in 𝑆 and 𝐹 mentioned previously. Denote

(10.1)˜Φ=𝜉𝑢𝜉𝑢Φ=1𝑢atan2(𝑎𝑦,𝑎𝑥)1𝑢atan2(𝑎𝑦,𝑎𝑥)

Then, we want to find a ˜Φ that is the closest to Φ, subject to the constraints that 𝑆 and 𝐹 have. One way to do this is to brute force every possible combinations of 𝑆 and 𝐹 and computing the corresponding ˜Φ values. However, this is very inefficient and can take millions of iterations. Doing it once on a fast computer may not consume a noticeable amount of time, but when implemented in game, these computations need to be done every frame, and there could be thousands of frames per second.

A better approach is to build the vectorial compensation table (VCT). The details in how to compute such a table will be described in VCT generation. But here, we will assume that it contains 3-tuples (˜Φ,𝐹,𝑆), sorted by ˜Φ, where ˜Φ is computed using (10.1) using the corresponding 𝑆 and 𝐹. To find the closest ˜Φ to Φ, we may use binary search to find entries corresponding to ˜Φ1 and ˜Φ2 such that [2]

˜Φ1Φ˜Φ2

Then, the value that is closest to Φ would simply be one of ˜Φ1 and ˜Φ2. This algorithm is very fast because even if the VCT contains millions of entries, it takes at most about 20 iterations to find the two ˜Φ entries. The downside is that there will be a small but noticeable delay in generating the VCT.

As a side note, an alternative way to compute Φ exists. In practice, computing atan2(𝑎𝑦,𝑎𝑥) may be slightly less efficient, because obtaining ˆ𝐚 requires computing the rotation matrix 𝑅(𝜃), which in turn requires computing sin and cos along with multiple addition and multiplication operations. An alternative method involves observing that 𝑎𝑥 =cos(𝛽 +𝜃) and 𝑎𝑦 =sin(𝛽 +𝜃), where

𝛽=atan2(𝑣𝑦,𝑣𝑥)

Therefore,

atan2(𝑎𝑦,𝑎𝑥)=𝛽+𝜃+𝑘𝜋

for some integer 𝑘. This implies that

Φ=𝛽+𝜃+𝑘𝜋𝑢𝛽+𝜃+𝑘𝜋𝑢=𝛽+𝜃𝑢𝛽+𝜃𝑢

as 𝑢 divides 𝑘𝜋, and so the integer disappears, simplifying the expression. This method of computing Φ requires only one trigonometric computation, namely in obtaining 𝛽.

Footnotes

10.1.2. VCT generation

The algorithm described in previous sections rely on a lookup table called the vectorial compensation table (VCT). As a reminder, this is a table containing entries of 3-tuple (˜Φ,𝐹,𝑆) sorted by ˜Φ, and that each entry must have a unique 𝑌 and must satisfy 𝐹2 +𝑆2 𝑀2𝑚.

If we simply enumerate 𝐹 and 𝑆 by drawing each element from [ 2047,2047], then the resulting ˜Φ will not be unique. So see why, suppose 𝑀𝑚 =320, (𝐹1,𝑆1) =(400,800), and (𝐹2,𝑆2) =(800,1600). Then, obviously 𝐹21 +𝑆21 >𝑀2𝑚 and 𝐹22 +𝑆22 >𝑀2𝑚, but 𝜉1 =𝜉2 and therefore ˜Φ1 =˜Φ2.

To obtain a set of unique ˜Φ, we must therefore enumerate all unique coprime pairs (𝐹,𝑆), but satisfying the constraint that 2047 𝐹,𝑆 2047 and 𝐹2 +𝑆2 𝑀2𝑚. The most efficient way to enumerate this is by generating a Farey sequence. To reduce the generation time, we can exploit symmetries in (𝐹,𝑆).

Firstly, we can restrict generation in just one quadrant, namely by considering only positive 𝐹 and 𝑆. This is because for all 𝐹 and 𝑆, we know that

𝜉=atan2(𝑆,𝐹)=atan2(|𝑆|,|𝐹|)+𝜋2𝑘

for some integer 𝑘. Computing the ˜Φ,

˜Φ=𝜉𝑢𝜉𝑢=atan2(|𝑆|,|𝐹|)𝑢+16384𝑘atan2(|𝑆|,|𝐹|)𝑢+16384𝑘

Obviously 16384𝑘 , therefore this simplifies to

atan2(|𝑆|,|𝐹|)𝑢atan2(|𝑆|,|𝐹|)𝑢=atan2(𝑆,𝐹)𝑢atan2(𝑆,𝐹)𝑢

This implies that the ˜Φs computed from (𝐹,𝑆) and (|𝐹|,|𝑆|) are the same.

Within a quadrant, we only need to consider 𝜉 in [0,𝜋/4). In other words, we only need to generate values within an octant. To see this, define sets

𝑈={˜Φ(𝜉)0𝜉<𝜋4}𝑉={˜Φ(𝜉)𝜋4𝜉<𝜋2}

Then we claim that 𝑈 =𝑉, and therefore only one of them needs to be computed. Consider 𝜉 [0,𝜋/4) in the domain of 𝑈. Then clearly 𝜉 +𝜋/4 [𝜋/4,𝜋/2), which is the domain of 𝑉. Compute the corresponding ˜Φ, we have

𝜉𝑢+8192𝜉𝑢+8192=𝜉𝑢𝜉𝑢

This implies that 𝑈 𝑉. Similarly, consider 𝜉 [𝜋/4,𝜋/2) in the domain of 𝑉, then 𝜉 𝜋/4 [0,𝜋/4) is in the domain of 𝑈. It can be similarly shown that the ˜Φs computed using 𝜉 and 𝜉 𝜋/4 are the same. This shows 𝑉 𝑈, and we conclude that 𝑈 =𝑉.

One observation may be made regarding the relationship between different elements in the 𝜉-table. Define sets

𝑃={˜Φ(𝜉)0𝜉<𝜋8}𝑄={˜Φ(𝜉)𝜋8𝜉<𝜋4}

Consider some 0 𝜉 <𝜋/8. Then, we have

tan(𝜋4arctan𝑆𝐹)=1𝑆/𝐹1+𝑆/𝐹=𝐹𝑆𝐹+𝑆

Computing arctan,

𝜋4𝜉=𝜋4arctan𝑆𝐹=arctan𝐹𝑆𝐹+𝑆=arctan𝑆𝐹=𝜉

Let 𝜉 such that ˜Φ(𝜉) 𝑃. Let integers 𝑘𝑝 =𝑘𝑆 and 𝑘𝑞 =𝐹 for some 𝑘, where gcd(𝑝,𝑞) =1. Namely, 𝑝/𝑞 is the completely reduced fraction of 𝑆/𝐹. Then if 𝑞 2047 is satisfied, we have ˜Φ(𝜉) 𝑄. In addition, we also have

˜Φ(𝜉)=𝜉𝑢𝜉𝑢=𝜉𝑢𝜉𝑢

Namely, ˜Φ(𝜉) +˜Φ(𝜉) =1 if 𝜉/𝑢 is not an integer.

10.2. Line strafing

10.3. Automatic actions