Lag compensation solves a fundamental problem in fast paced network games: allow client a WYSIWYG experience without being able to trust the client.
The problem is none of the machines on the network are at exactly the same tick in the game. What one client sees and base their actions on is only 100% correct for them. The classic example is detecting a precise shot at a distant object; although the client has the target directly in their crosshairs, in reality it has already moved.
- If the authoritative server base the hit detection solely on its own perception of the world, no one will ever intentionally hit anything.
- If the client is allowed authority and can tell the server what they hit, the system will be wide open to simple game-destroying exploits.
Lag compensation allow the server to, momentarily, see the world from each clients perspective and decide if they were in fact in a position to take that impossible shot. On the flipside, this means the target may be hit although they themselves felt they were safely tugged away behind a wall; however, this is much less likely to be noticeable.
Fusion keeps a history of where
HitBoxes were located in the past and knows how far behind each clients view is compared to the current server state. Using this history Fusion is able to perform lag compensation raycasts by raycasting in the past. ( Reminder: the client is ahead only of the server for the objects it has Input Authority over)
For ultra high precision, Fusion takes lag compensation one step further. The framerate of AAA games is usually higher than the tick rate of the network. What the player actually see on screen is usually not at a discrete tick, but an interpolation between two ticks. Fusion knows exactly how far between two ticks the lag compensated raycast was made and can use this for sub-tick accurate raycast.
Lag Compensated Features
For game developers using Fusion all this magic is near transparent. All that is needed is the prebuilt
HitBox component instead of or in addition to the regular Unity Colliders.
To set up a lag compensated hitboxes on a networked GameObject, the follow two steps are required:
HitBoxRootcomponent is needed on the top most node of the GameObject. The
HitBoxRootserves as a way to group all
HitBoxcomponents found on its children.
HitBoxnodes should be kept in a separate layer from regular Unity
Collidercomponents for all dynamic objects; this is the fastest and only reliable way to separate dynamic Colliders from Hitboxes when raycasting. This separation allows lag compensated raycasts to hit all static geometry while avoid to add
HitBoxcomponents to them which would be prohibitively expensive. At the same time all dynamic hits should rely exclusively on
HitBoxes, but removing dynamic Colliders entirely does not work because they are needed to allow objects to interact nicely with PhysX. The middle ground is to keep the dynamic colliders on a layer that can be ignored by lag compensated ray-casts.
N.B.: There is a limit of 31
HitBox nodes per
HitBoxRoot. If there is a need for more child nodes in a single object or prefab, the hierarchy must be broken down and distributed across several roots.
The specific structure of the hit-box hierarchy is entirely up to the needs of the specific game.
Performing lag compensated physics queries on servers is as simple as the built-in PhysX raycasts and even support overlap checks as well. Just add Fusion's pre-build
Hitbox component to the networked GameObject.
The API is identical for querying both lag compensated data and static level data kept within PhysX.
Runner.LagCompensation.Raycast(transform.position, transform.forward, 25, Object.InputAuthority, out var hit);
Object.InputAuthority tells Fusion is in control of this hitscan/Projectile. The raycast will be done against the data matching the timeframe viewed by the specific player client who was in control of it. All of this happens automatically, no need to add any complex math!