2. Entities

For a more in-depth descriptions of specific entities, refer to

2.1. Basic properties

2.2. Camera

Not all entities can see, but for those that do, the eyes are the windows to the soul. In the Half-Life universe, an entity is called the camera or the view. The camera is located at a fixed position relative to the entity’s origin, at least at server side. At client side, the player’s camera position is slightly complicated by view bobbing if enabled.

2.3. Movement

All entities in Half-Life has an associated movement type, or movetype. These are all the possible movetypes in Half-Life:

MOVETYPE_NONE

The entity never moves and not subjected to gravity. Examples of entities using this movetype are triggers, RPG laser spots, env_explosion, etc. In the engine code, SV_Physics_None handles the physics of this movetype. This function simply calls the Think function associated with the entity and returns.

MOVETYPE_WALK

This movetype is only used by the player and gives rise to the familiar air and ground movement physics of the player (see Player movement basics).

MOVETYPE_STEP

This is the primary movetype used by monsters, analogous to MOVETYPE_WALK for the player. SV_Physics_Step handles this movetype, and it computes water buoyancy physics, gravity by Euler’s method (see Gravity), friction, position update, and also runs the entity’s Think function.

MOVETYPE_FLY

This movetype is used by entities that do not experience gravity, but has collision. For example, the Nihilanth (Nihilanth) uses this movetype, so does the tripmine (Tripmine), crossbow bolt, and many others. Notably, this movetype is also used by the player on a ladder (Ladders). The SV_Physics_Toss is responsible of this movetype. It runs the Think function, perform other checks, and compute position update and collisions.

MOVETYPE_TOSS

This movetype is used by gibs, dead monsters, and certain pickup items such as the battery and suit. Similar to MOVETYPE_FLY, the SV_Physics_Toss function handles this movetype, though with gravity.

MOVETYPE_PUSH

This movetype is used by entities that can push and crush other entities, but does not clip to worldspawn. These are buttons, doors, func_breakable (func_breakable, but not func_pushable), func_rotating, func_wall, func_pendulum, etc. SV_Physics_Pusher runs the physics for this movetype, which calls either SV_PushRotate or SV_PushMove at some point, and calls the Think function of the entity.

MOVETYPE_NOCLIP

Entities with this movetype does not experience gravity, and does not clip with any other entity. SV_Physics_Noclip is responsible of the physics, which consists of running the Think function, computing position and angle update, and SV_LinkEdict.

MOVETYPE_FLYMISSILE

This movetype is not found to be used by any entity in vanilla Half-Life. The SV_Physics_Toss function is responsible of its physics.

MOVETYPE_BOUNCE

This movetype is used by entities that can bounce off other entities. A prominent example is the hand grenade (Hand grenade), but satchel charges (Satchel charge), MP5 greandes, and others use this movetype as well. Similar to MOVETYPE_TOSS, SV_Physics_Toss is called for this movetype, but with the bounce coefficient (see Collision) computed by $b=2-k_e$.

MOVETYPE_BOUNCEMISSILE

Just like MOVETYPE_FLYMISSILE, this movetype does not seem to be used by any entity in the unmodded Half-Life. SV_Physics_Toss is also called for this movetype, and the bounce coefficient (see Collision) is set to be $b=2$, independent of entity gravity.

MOVETYPE_FOLLOW

Entities of this movetype tracks the movement of the entity given by pev->aiment. For example, the CBasePlayerItem class, subclassed by all player weapons, follows the player and is set to this movetype. Entities of this movetype does not experience gravity or collision. SV_Physics_Follow runs its physics code, and consists of calling Think and copying the aiment origin and angles, along with SV_LinkEdict.

MOVETYPE_PUSHSTEP

This entity seems to only be used by func_pushable. The physics of this movetype is very similar to that of MOVETYPE_PUSH, except that MOVETYPE_PUSHSTEP uses a slightly different way to collide with other entities.

TODO

MOVETYPE_COMPOUND

This movetype does not seem to be used.

2.4. Gravity

Some entities in Half-Life experience gravity. A func_pushable box, when pushed off an edge, falls to the ground. However, the game computes gravity for these entities in a way that differs from the gravity for the player (see Gravity). Entity gravity is integrated using the simplest form of the Euler’s method. Suppose an entity has vertical velocity $v$ and position $x$ at the start of a frame. Provided this entity’s movetype is set to experience gravity, the new vertical velocity and position after one frame are given by

$$v^{\prime }=v-g{\tau }_g{x}^{\prime }=x+v^{\prime }{\tau }_g=x+v{\tau }_g-g{\tau }_g^2$$

where $g$ is the effective gravitational acceleration and ${\tau }_g$ is the game frame rate (see Frame rate). Readers familiar with Newtonian mechanics will note the fact that $x^{\prime }$ differs from what one would expect. A simple rewriting yields

$$x^{\prime }=(x+v{\tau }_g-\frac{1}{2}g{\tau }_g^2)-\frac{1}{2}g{\tau }_g^2$$

where the terms in the brackets match the prediction from Newtonian mechanics. Indeed, after $n$ frames of gravity, we can write

$$x_n=(x_0+vn{\tau }_g-\frac{1}{2}g{n}^2{\tau }_g^2)-\frac{1}{2}g{\tau }_g^2$$

Let ${\tilde{x}}_n$ be the Newtonian prediction after $n$ frames of gravity. Then we first observe that ${\tilde{x}}_n>x_n$. In addition, the difference ${\tilde{x}}_n-x_n$ is directly proportional to the frame time ${\tau }_g$ and inversely proportional to the frame rate $f_g$. The lower the frame rate, the smaller $x_n$ becomes relative to ${\tilde{x}}_n$, which manifests as lower vertical positions in the game. This may be understood in many different ways. For example, a falling entity would reach the ground sooner. An MP5 grenade would travel a shorter horizontal distance before landing.

2.5. Friction

Entities of movetype MOVETYPE_STEP experience ground friction in a similar way as the player. The friction is similar to what is given in Ground friction, except with edgefriction $e_f=1$.

2.6. Collision

Many entities in Half-Life collide with one another. The velocity of the colliding entity usually changes as a result, while the position and velocity of the entity receiving the collision usually stay constant, countering real world Newtonian physics. The process of changing the velocity is usually referred to as velocity clipping. Collision is one of the most common events in Half-Life, so it is worthwhile to study its physics.

Collisions occur in the position update step of an entity. The player entity’s position update is described in Position update. A collision is detected by performing a player trace and checking if the trace strikes a plane. Let $\hat{n}$ be the plane normal and let $v$ be the velocity at the instant of collision. Let $b(C_b,k_e)$ be the bounce coefficient which, in general, depends on sv_bounce (denoted as $C_b$) and $k_e$ (see Friction). The bounce coefficient controls how the velocity is reflected akin to a light ray. If $v^{\prime }$ is the velocity resulting from the collision, then the general collision equation (GCE) can be written as

(2.1)$$v^{\prime }=v-b(C_b,k_e)(v\cdot \hat{n})\hat{n}$$

Before we proceed, we must point out that this equation may be applied multiple times per frame when computing the position update for an entity.

Fig. 2.1. Depiction of a general case of collision, where the player collides with plane $OW$ with normal $n$ at $A$ with velocity $AB$.

Collisions in the general case is depicted in Fig. 2.1.. The point at which collision occurs is $A$, and let the arrow $AB$ the velocity vector $v$. Then, the length of $A{B}^{\prime }$ represents the dot product $v\cdot \hat{n}$, and $B^{\prime }$ is a projection of $B$ onto the line $A{B}^{\prime }$, which is parallel to the plane normal. In general, this dot product is scaled by $b$, causing the final velocity vector to point out of the plane, shown by $AC$. If $b=1$ instead, then $A{C}^{\prime }$ would be the final vector.

In most cases, players have $b=1$ because $C_b=1$ in the default Half-Life settings and $k_e=1$ if there is no func_friction that modifies it (see func_friction). The value of $b$ and its dependence on $C_b$ and $k_e$ for the player is described in Position update. The case of $b\ne 1$ is more common for other entities. For example, snarks have $b=3/2$ and $k_e=1/2$. In general, if the movement type of an entity is designated as MOVETYPE_BOUNCE, then $b=2-k_e$.

Care must be taken when $b<1$. To understand why, we first observe that $v\cdot \hat{n}<0$, because otherwise there would not be any collision events. With

$$v^{\prime }\cdot \hat{n}=(1-b)v\cdot \hat{n}$$

we see that if $b<1$ then the angle between the resultant velocity and the plane normal is obtuse. As a result, collisions will occur indefinitely with an increasing $v$. To prevent this, the game utilises a safeguard immediately after the line tracing process in the respective FlyMove functions to set $v^{\prime }=0$.

Hence, assuming $b\ge 1$ we employ the following trick to quickly find $\parallel v^{\prime }\parallel$: write $\parallel v^{\prime }{\parallel }^2=v^{\prime }\cdot v^{\prime }$ and expanding each $v^{\prime }$ in the RHS to give

$$\parallel v^{\prime }\parallel =\parallel v\parallel \sqrt{1-b(2-b){\cos }^2\alpha }$$

where $\alpha$ is the smallest angle between $v$ and $\hat{n}$ confined to $[-\pi /2,\pi /2]$. Observe that the resulting speed is strictly increasing with respect to $b$ in $[1,\infty )$. In fact, the curve of resultant speed against $b$ is hyperbolic provided $\alpha \ne 0$ and $\alpha \ne \pm \pi /2$. When $\alpha$ does equal zero, the resultant speed will be linear in $b$ like so:

$$\parallel v^{\prime }\parallel =\parallel v\parallel (b-1)$$

Again, this result assumes $b\ge 1$. On the other hand, for the very common case of $b=1$ we have

$$\parallel v^{\prime }\parallel =\parallel v\parallel \left|\sin \alpha \right|$$

Observe that the resultant velocity is always parallel to the plane, as one can verify that $v^{\prime }\cdot \hat{n}=0$ is indeed true.

2.6.1. Speed preserving circular walls

In Half-Life, we can sometimes find concave walls made out of multiple planes that approximate a circular arc. Examples can be found in some Office Complex maps such as the wall shown in Fig. 2.2.. Circular walls can be a blessing for speedrunners because they allow making sharp turns without losing too much speed. In fact, if the number of planes increases, the approximation will improve, and so the speed will be better preserved.

Fig. 2.2. An example of a “speed preserving” wall in the Office Complex map of c1a2, which is made up of multiple planes to approximate an arc.

Let $n$ be the number of walls and let $\beta$ be the angle subtended by the arc joining the midpoints of every wall. For example, with $\beta =\pi /2$ the first and the last walls will be perpendicular, and with $\beta =\pi$ they will be opposite and parallel instead. Let $v_i$ be the velocity immediately after colliding with the $i$-th wall, and assuming $v_0$ is parallel to and coincident with the first wall. Assume also that $0\le \beta /(n-1)\le \pi /2$, which means that the angle between adjacent planes cannot be acute. If the velocity does not change due to other external factors throughout the collisions, then

$$\parallel v_{i+1}\parallel =\parallel v_i\parallel \cos \left(\frac{\beta }{n-1}\right)$$

The general equation at frame $n$ is simply

$$\parallel v_n\parallel =\parallel v_0\parallel {\cos }^{n-1}\left(\frac{\beta }{n-1}\right)$$

It can be verified that

$$\underset{n\to \infty }{lim}\parallel v_n\parallel =\parallel v_0\parallel$$

This demonstrates the speed preserving property of circular walls. Observe also that the final speed is completely independent of the radius of the arc. Perfectly circular walls are impossible in Half-Life due to the inherent limitations in the map format, so some amount of speed loss is unavoidable. Nevertheless, even with $n=3$ and $\beta =\pi /2$ we can still preserve half of the original speed.

This is somewhat analogous to uniform circular motion in the real world. In the real world, an object rotating around a point in a circular path experiences centripetal acceleration $a_c={\omega }^{2}r$ with constant angular speed $\omega$. The velocity of the rotating body changes its direction continuously to keep up with the circular arc, but crucially, the magnitude or speed remains constant throughout. In theory, there is no restriction on how small the radius of curvature $r$ can be.