In TF2, there was a rumor around a while ago that the Scout could, if given enough increases to his base movement speed, outrun the hitbox used for hitscan and/or projectile collision detection. This is completely false, but the reasons are quite interesting, so I would like to explain why I believe it to be false.

The “hitbox” of an object is, in reality, the AABB (Axis-Aligned Bounding Box) of an object. This is done by performing a linear search through the co-ordinates of an object and computing the maximum and minimum in all three axes. This yields the coordinates of a cube which is the smallest area which encompases every point in a mesh’s set of vertices.

Now, for very detailed models (such as character models), this can be an expensive process. Vertices are by no means sorted in size order (that would somewhat defeat the purpose of the search), so an entire cycle through is required each time we wish to calculate an AABB. This means that most engines either embed this information in the model itself, or they calculate it once at runtime. The reason we can do this is that we can calculate this bounding box once and then simply store it in model-local coordinates which will be translated via matrix transform with the model.

But wait! I just said that the bounding box is moved via matrix transform - the same transform that the model itself uses. Bingo. This is the key point. If the bounding box is in object local space, it is physically impossible for their positions to be misaligned.

It is at this point that I point out why I said that “I believe” it to be wrong. The Source engine is quirky. Not only is it quite old and clunky to do some tasks, it also has some design decisions that are so mind numbingly dumb that even I could do better in an afternoon for that particular purpose. A great example of this is Source’s network code. It requires you to manually specify what object properties will be sent across the network from server to client. Additional things (such as interpolation and lag prediction) make networking in Source even less deterministic. So, it is fully possible that networking bugs and/or quirky replication of model updates could be the cause of this to happen. But, this theory assumes that the hitbox and the model itself are separate entities. They are intrinsically linked, the same way a polygon and its associated material are in Source. In this way, the people who claim that the scout can “outrun” his hit box may also claim that he can outshoot his bullets. There is no way to do this other than cheating, and even that would require some kind of engine vulnerability. You may have noticed that, in Source, if you loose connection, even the local player freezes on the spot. The reasoning behind this is that the player is not controlled on the client at all. The current state of client inputs are sent to the game server each network tick for processing. This causes certain events to be processed as needed, such as movement. What does this mean? In contrast to many other game engines, this means that exploits of the local player, such as flying, noclipping or being invisible, are simply not trivially posible in Source. The downside of this is that players with bad network connections have to rely on their half-baked lag compensation and interpolation algorithms to hide the problem, rather than solve it. This architecture is great for security, not so much for performance.

In short, it is not trivially possible to outrun your hitboxes in any Valve game. The reasons why are linked with networking, AABBs and funamental engine networking design. I rest my case.