Rollback netcode: deterministic replay and controlled side effects

Run ahead, then repair

Rollback allows a game to advance while some remote inputs remain unknown. When an assumption proves wrong, the simulation returns to an earlier state and catches up with corrected input. The player should receive immediate local response, but the implementation must support revisiting work that appeared to have already happened.

The replay contract

Classic input-only rollback requires deterministic simulation from the same state and inputs; this article concerns that architecture. State-synchronizing variants have different requirements. SnapNet's architecture explanation covers input prediction, restoration, and replay. [1] GGPO's integration interface requires game-state save/load and frame-advance callbacks, making state ownership an application responsibility. [2]

Worked example

An illustrative client has completed frame 105 after predicting remote input for frame 102. The real input arrives and differs. Restore the saved state at the end of frame 101, then simulate frames 102, 103, 104, and 105 using corrected input and retained inputs for each frame. This is four replayed frames before any additional new frame.

If one saved state occupies 256 KiB, retaining 8 such states costs 2048 KiB, or 2 MiB, excluding inputs, metadata, and allocation overhead. These are hypothetical sizes, not benchmark results. The oldest saved state also bounds how far this particular buffer can restore; count whether snapshots represent frame beginnings or endings explicitly.

Implementation workflow

Inventory every value that affects future gameplay: entity creation order, timers, random-generator state, animation-dependent hit timing, and queued commands. Serialize or reconstruct it reproducibly. Do not use wall-clock time or uncontrolled asynchronous completion order as hidden simulation inputs.

Run the same input recording twice and compare canonical state hashes by frame. On the first mismatch, inspect structured state differences rather than only the final character position. Then exercise forced rollbacks even on a local connection. Profile the worst supported replay window alongside ordinary rendering and simulation work.

Side effects and limits

Give predicted effects stable event identities. An effect ledger can distinguish an already-played sound from a newly discovered event after replay. Decide which effects can be cancelled, which may finish despite a correction, and which irreversible outcomes wait for confirmation. [1]

Determinism can fail through floating-point behavior, iteration order, or missing state. Longer prediction windows increase correction exposure and replay work. Define recovery when input is older than retained history or the work budget is exhausted. Input delay can be a deliberate complementary control; rollback does not remove latency or guarantee invisible corrections.

Sources

[1] Netcode architectures: rollback — SnapNet.

[2] GGPO integration interface — Tony Cannon and GGPO contributors.