Lag Compensation and Client Prediction

Implement Client-Side Prediction

Without prediction, the local player presses a movement key and sees nothing happen for 100+ milliseconds while the input travels to the server, gets processed, and the result travels back. This delay makes the game feel sluggish and unresponsive. Client-side prediction eliminates this perceived delay by running the game simulation locally for the local player's own inputs.

The concept is straightforward. When the player presses a key, the client immediately applies that input to the local player's state using the same simulation code the server uses. The player sees their character move instantly. Simultaneously, the input is sent to the server tagged with a sequence number. The server processes the input in its authoritative simulation and sends back the result, also tagged with the input's sequence number.

The client maintains a buffer of all inputs that have been sent to the server but not yet acknowledged. Each entry in the buffer contains the input data, the sequence number, and the predicted state after applying that input. When the server acknowledges an input (by sending state that references a specific sequence number), the client removes all inputs up to and including that sequence number from the buffer.

Prediction should only be applied to the local player's own entity. Predicting other players' movement is called extrapolation, and it is generally unreliable because you are guessing what input another player will send. Extrapolation causes visible errors when the other player changes direction, stops, or performs unexpected actions. Entity interpolation (covered below) is the correct technique for rendering remote players.

Add Server Reconciliation

Prediction works perfectly when the client's simulation matches the server's simulation exactly. In practice, discrepancies arise. The server might process a collision that the client did not predict (because the client did not know about a nearby entity). Another player's action might affect the local player's state in ways the client could not predict. Or subtle timing differences in simulation steps might accumulate into measurable drift.

When the server sends an authoritative state update for the local player, the client compares it to the predicted state for that same sequence number. If they match, no correction is needed. If they differ, the client must reconcile.

The reconciliation process works in three steps. First, the client sets its state to the server's authoritative state at the acknowledged sequence number. Second, it looks at all unacknowledged inputs still in the buffer (inputs the server has not processed yet). Third, it replays each of those inputs in order, re-predicting the state from the corrected starting point. This brings the client to a new predicted state that is consistent with the server's correction while preserving the feel of inputs that are still in flight.

If the correction is small (a few pixels of position difference), you can snap directly to the corrected state. If the correction is large (which happens during high lag or after a collision the client missed), a visual smoothing step prevents jarring teleportation. Store both the corrected position and the current visual position, then interpolate the visual position toward the corrected position over 100 to 200 milliseconds. The player sees a smooth adjustment rather than a harsh snap.

Implement Entity Interpolation

While the local player's movement is predicted, remote players' positions come directly from server updates. These updates arrive at the server's tick rate, typically 20 to 30 times per second. The client renders at 60+ FPS. Without interpolation, remote players would appear to teleport between positions at the tick rate, looking jerky and unnatural.

Entity interpolation solves this by rendering remote entities slightly in the past and smoothly blending between server snapshots. The client maintains a buffer of the last several state snapshots received from the server, each timestamped with the server tick. The rendering time for remote entities is set to the current server time minus one tick interval (the interpolation delay). The client finds the two snapshots that bracket this rendering time and linearly interpolates between them based on the elapsed time.

For example, if the server runs at 20 ticks per second (50 milliseconds per tick), the client renders remote entities with a 50-millisecond visual delay. At render time, it finds the two server snapshots that surround the current render time and interpolates position, rotation, and any other continuous properties between them. The result is perfectly smooth visual movement at any client frame rate.

The interpolation delay adds to the total visual latency for remote entities. The local player sees other players as they were roughly one tick interval plus the one-way network latency in the past. This is a necessary tradeoff for smooth visuals. Attempting to reduce the interpolation delay below one tick interval causes the interpolation to run out of data (the next snapshot has not arrived yet), forcing extrapolation and its associated visual errors.

Add Server-Side Lag Compensation

Lag compensation addresses a specific problem with hit detection in latent environments. When a player shoots at a moving target, they aim at where they see the target on their screen. But due to network latency and interpolation delay, the target's actual position on the server at the moment the shot is processed is different from what the shooter saw.

Without lag compensation, shots that clearly hit on the shooter's screen would miss on the server. This feels deeply unfair to the shooter. Lag compensation fixes this by rewinding the server's state to match what the shooter was seeing when they fired.

The implementation requires the server to maintain a history of world states, storing the position of every entity at each recent tick. When a player fires, their input message includes the server tick they were seeing at the time (calculated from the client's estimated relationship between local time and server time). The server looks up the world state at that historical tick, performs the hit detection against the historical positions, and applies the result to the current state.

The rewind window should be capped at a maximum value (typically 200 to 300 milliseconds) to prevent extreme exploitation. A player with 500 milliseconds of latency would need a 500-millisecond rewind, which could let them shoot around corners that the defender left 500 milliseconds ago. Capping the rewind window means very high-latency players will experience some aiming inaccuracy, which is a reasonable tradeoff for overall game fairness.

The tradeoff of lag compensation is "getting shot behind cover." A defender who ducks behind a wall may still be hit by a shot fired before they moved, because the attacker's rewound view showed them exposed. This is an unavoidable consequence of network latency, not a bug in the system. Most games accept this tradeoff because it makes shooting feel much better for the majority of players.

Measure and Tune Network Timing

All of these techniques depend on accurate timing measurements between the client and server. Three values must be measured and maintained continuously during gameplay.

Round-trip time (RTT) is the time for a message to travel from client to server and back. Measure this by sending timestamped ping messages and recording how long the pong response takes to arrive. Maintain a rolling average and track variance. The RTT determines how far ahead the client needs to predict and how large the input buffer should be.

Clock offset is the difference between the client's local clock and the server's clock. Since client clocks cannot be trusted, the client estimates the server's current tick by adding half the RTT to the tick number included in the most recent server message. This estimate is refined over multiple measurements using a smoothing algorithm that resists outliers from network jitter.

Jitter is the variation in latency over time. A connection with 100 milliseconds of steady latency is easier to compensate for than one that fluctuates between 50 and 200 milliseconds. High jitter requires larger interpolation buffers (to avoid running out of snapshots) and more aggressive prediction smoothing (to handle frequent corrections). Monitor jitter by tracking the standard deviation of RTT measurements over a sliding window.

Expose these timing values in a debug overlay during development. Seeing RTT, clock offset, jitter, and prediction correction frequency in real time while playing helps you tune buffer sizes, interpolation delays, and smoothing rates. Aim for prediction corrections to be invisible at RTTs below 100 milliseconds and barely noticeable up to 200 milliseconds.