Client prediction and reconciliation with an authoritative server

Responsiveness with authority

Waiting for a server round trip before showing every movement makes local control feel delayed. Prediction lets the client act on input immediately, while the server still determines accepted game state. The difficult part is integrating a delayed answer without discarding newer input or applying it twice.

Match the acknowledged moment

Number inputs and retain unacknowledged commands. On an authoritative update, restore the corresponding state and replay remaining commands in order. [1] Compare the server result with the prediction for that same acknowledged moment, not with the client's later present. Valve's prediction implementation explicitly performs an acknowledged-state error comparison. [2]

Worked example

In an illustrative one-dimensional controller, the client has predicted commands 101, 102, and 103. A server update acknowledges 101 at position 5.0 m; the client had predicted 5.1 m after that command. Commands 102 and 103 each move 0.2 m under the restored state.

Discard command history through 101, restore 5.0 m, and replay 102 then 103. The reconciled present becomes 5.4 m, compared with the previous predicted present of 5.5 m. The relevant correction is -0.1 m; simply snapping to 5.0 m would also erase two still-pending movements.

For presentation, a separate visual offset may decay from the old appearance toward the corrected simulation position. Collision and future prediction must use the corrected state immediately. Treat a teleport as an explicit discontinuity rather than smoothing it through intervening walls.

Implementation workflow

Define exactly what one input command means: tick, duration, buttons, and any quantized values. Share movement rules where practical, and include all state required for replay, such as velocity, movement mode, and cooldowns. A position alone may not reconstruct the next result.

Make replayed effects identifiable so repeated prediction does not duplicate audio, particles, or transactions. The server validates command progression and game rules; receiving a plausible position from a client is not equivalent to simulating valid input. Bound stored history and specify recovery when an update predates available state.

Limits and validation

Prediction cannot know every remote action or newly revealed obstacle. Frequent corrections can signal mismatched stepping, incomplete replay state, differing geometry, or genuine uncertainty. Measure correction frequency, magnitude, command age, and replay cost separately.

Test loss, duplication, reordered updates, moving platforms, and input during respawn. Reject stale authoritative updates according to protocol ordering. Tune visual smoothing only after confirming simulation correctness: a smooth picture can hide persistent disagreement without fixing it.

Sources

[1] Client-side prediction and reconciliation — Gabriel Gambetta.

[2] Source SDK prediction implementation — Valve.