When would you choose deterministic lockstep over an authoritative server, and what does each model cost you?

Short answer

Use deterministic lockstep when inputs are small and all clients can stay in sync; use an authoritative server when trust, cheating, late joins and latency compensation matter more.

Mention determinism where it changes the risk, the owner, or the next check. A useful determinism point should make the answer more testable, not merely longer.

What lockstep is actually transmitting

In a deterministic lockstep model no machine ever sends game state. Every participant runs the identical simulation from the identical starting conditions, and the only thing on the wire is player input: this player issued a move order for these unit identifiers to this coordinate on turn 412. Because the simulation is a pure function of its previous state and the input set, every machine that applies the same inputs in the same order arrives at bit-identical state without being told what that state is.

The consequence that makes the model attractive is that bandwidth is decoupled from the size of the world. A real-time strategy match with two thousand units on the field sends exactly as much data as the same match with twenty units, because the units are not being described — they are being derived. Take an illustrative eight-player game at a 10Hz command rate with a few dozen bytes of input per player per turn, and you are in the low single-digit kilobytes per second for the whole match, forever, regardless of how much is happening on screen.

A turn cannot be simulated until every participant's input for that turn has arrived. That single sentence is the whole cost model.

sequenceDiagram
  participant A as Peer A
  participant B as Peer B
  participant C as Peer C
  Note over A,C: turn 412 inputs collected
  A->>B: input for turn 414
  A->>C: input for turn 414
  B->>A: input for turn 414
  C->>A: input for turn 414
  Note over A,C: all three present, simulate 414

The interesting part of that exchange is the gap between issuing an input and simulating it. Inputs are scheduled two turns ahead, not for the current turn, which buys time for the round trip and is exactly why a lockstep game feels laggy on click rather than laggy on screen.

What the authoritative server is transmitting

The server-authoritative model inverts the flow. Clients send input to one process that owns the truth, that process advances the simulation, and it broadcasts the resulting state back out — usually as a delta against the last snapshot each client is known to have acknowledged. Clients are then rendering a description of the world rather than computing it, which means a client that falls behind or corrupts its own copy simply gets corrected on the next update instead of diverging permanently.

Bandwidth here scales with the product of entities, update rate and observers. The same two-thousand-unit strategy match becomes hostile: at an illustrative twenty bytes of delta per changed entity at 20Hz, a client watching a thousand active entities is receiving hundreds of kilobytes per second before you have compressed anything. This is why the authoritative model comes with relevance filtering as standard equipment — interest management, view distance, area-of-interest grids — while lockstep needs none of that machinery at all.

Input latency versus correction latency

Both models have to hide a round trip, and they hide it in different places. Lockstep hides it in front of the input: your command executes on a turn far enough in the future that everyone's command for that turn has arrived, so the delay is bounded below by the slowest peer's latency and is uniform for everyone. Nobody's simulation is ever wrong; everyone's controls are slightly late.

The authoritative model hides it behind the input. The client predicts the outcome of your own input immediately, and reconciles when the server's version of that frame arrives. Your controls feel instant, but the server sometimes disagrees with the prediction and you are corrected, which is visible as a snap. Latency compensation for other players' actions then becomes a separate problem with its own fairness arguments.

Determinism is a discipline, not a property

The reason lockstep is rarer than its bandwidth profile suggests is that bit-exact reproducibility across machines is genuinely hard to keep. Floating-point results can differ with compiler optimisation settings, with instruction selection, and with anything that leaves a value in a wider register than the source implied. Iteration over a hash-ordered container can vary. Reading uninitialised memory produces different values on different runs. Any use of a wall-clock or an unseeded random source is fatal. Every one of these is invisible until two machines disagree, and then the game is unplayable rather than degraded.

The only workable defence is to make divergence loud. Each machine hashes its simulation state every turn and the hashes are compared; the first turn where they differ is reported immediately rather than discovered when a unit dies on one screen and lives on another. Because the entire match is reconstructible from its input log, that turn can then be replayed offline on both builds until the diverging value is found. Teams that ship lockstep successfully treat the checksum and the replay log as core infrastructure, not diagnostics.

What decides it is the entity count, not the player count

The answer candidates most often give is "lockstep for small games, servers for large ones", and it is the wrong axis. A four-player co-op shooter has few entities and few players and is still almost always server-authoritative, because the players are adversarial-ish, latency must feel immediate, and a desync in a shooter is unrecoverable. A two-player strategy game has enormous entity counts and is a lockstep candidate precisely because two players make the latency floor tolerable.

Sort on two questions instead. How many entities does one client need to know about, which decides whether snapshot bandwidth is affordable; and can you tolerate uniform input delay, which decides whether lockstep's turn gate is acceptable to the genre. Cheat resistance then sits on top as a structural fact rather than a feature: in lockstep every client holds the whole world state, so fog of war is a rendering decision and a modified client can see through it, whereas an authoritative server can decline to send what a client should not know. That is the argument that keeps competitive shooters and MMOs on servers no matter what the bandwidth arithmetic says.

Lockstep trades latency and debuggability for bandwidth that does not grow with the world; an authoritative server trades bandwidth for trust and responsive controls. Name which of those two currencies your genre is short of and the choice follows.

© 2026 Preptima. Originally published at preptima.com.