Netcode Without Mythology: Lockstep, Rollback and Why Two Games Feel Different

Despite all using insecure WiFi with latency and packet loss, your online matchmaking game seems faster and fluid than that yearly multiplayer rockstar live-service battle royale hit. Lag is lag, right? Except none of those architectures are the same. The rockstar game waits for all inputs in locking step, pauses everyone, waits, hesitates, before showing them developing in sync. That indie hit you enjoy is guessing everyone’s keypresses, then rewind-and-replays corrects before the stray movements become noticeable. Many mobile games are authoritative server syncs, sending frequent state updates rather than detailed input records, with players slowing down and correcting to the authoritative version when they see they have strayed.

So when a new online game hits, the "lag" isn't one thing. It could be the delay of the whole match synchronizing on offline input, the snappy guessing of your last move in a rollback simulation, or the correction to an external authority's idea of your next move - each feeling very different. Keep reading to understand how, and why, the same latency feels different when the game's networking model is totally different.

Deterministic Lockstep versus State Snapshot Synchronization

The two fundamental planes of network synchronization between a multiplayer game's clients are whether to send just the raw input or the full state, and whether the game must be deterministically laid out globally across many clients.

Deterministic lockstep sends only input records, never game state, and thus everyone runs identical simulation of the game world so long as each version receives and processes the same inputs.

This requires that every game client only advances the simulation to the minimum frame where all required inputs are available to make that simulation. So if a player joins halfway through the match, lockstep networking has to pause play for the new client's inputs to arrive.

Another cost of a deterministic lockstep model is the delay that must be introduced. On a typical 80ms round-trip time, a lockstep game must introduce 40ms of input delay to ensure that the remote input arrives on time.

Simulation determinism is the reason that lockstep works - no game simulation can be run halfway as long as later frames require prior input data that hasn't yet arrived. And so lockstep games push the clients into lockstep after each fully resolved frame.

State synchronization, on the other hand, starts with an inconsistent simulation across clients and relies on delta updates from an authoritative source to fix errors, rewind, correct movements, and confirm the authoritative state. The game simulation is to some extent out of sync even if temporarily consistent.

The reason games do authoritatively synchronize states rather than inputs is that state synchronization has lower latency and quicker responsiveness. It's also slightly more versatile in a game that isn't perfectly deterministic, or network-contentious, or heavily mid-match.

Rollback Blends State Sync with Lockstep Agility

Rollback strikes a middle ground between the two responses. It uses predictive simulation to be fast to the player, but keeps confirmed frames and a history trail of state in case it has to return to an earlier confirmed frame and re-simulate.

A game using rollback still sends the same minimalist input records across the network, but also saves its state at regular intervals so it can wind back to a previous valid frame. As an extreme example, Apollo 11 Command Module used magnetic tape to rollback, letting the computer "replay" a previous flight simulation. Apollo 11 gamely sped up rendering and animation to simulate prediction.

So in a rollback netcode architecture, the game uses a speculative simulation on an old frame which allows the player to keep moving and playing in between input arrival and verification, but winds back to a saved frame any time lag exceptions, timeouts, or differences in the simulation output appear.

Rollback doesn't avoid the 40ms delay of lockstep, but doesn't rewrite valid simulation frames the way a state-sync game must. Instead, it looks like waiting for confirmations but allows super-fast snap response.

Yes, it will make some mistakes in speculative simulation. And it requires keeping an authoritative copy of a history of frames, consistently sending inputs, and rewinding when a missed input appears. But rollback is more responsive and faster than lockstep for every player.

Virtual Simulation and Correction

Why does a competent game developer prefer rollback to lockstep or state-sync netcode?

Lockstep dominates, brakes the simulation, and waiting adds delay whether or not an individual player is suffering lag. And a state-sync recording inherently "rubber bands" clients, causing the simulation to correct to an authoritative state rather than smoothly bracing.

But rollback lets every player keep moving as fast as their connection allows, even while some will appear to "warp" back to already-confirmed simulation frames.

Say two opponents are fighting, the remote client inputs, button mashing for extra damage. The local simulation appears to inflict damage, but the remote client missed and behind a high-mid recovery rate! The rollback simulation can still correct when subsequent inputs disprove the speculative guess.

Many competitive fighting, shooter, and beat-em-up games use rollback to keep the game moving while smoothly correcting errors that would make a long, intermittent rubber band in a state-sync game.

Lockstep and rollback can still be used to ensure the same game simulation appears to all players. They do not resolve known accuracy problems. Errors in client processing, inputs transmitted or stored at slightly different times, and no way to verify an error.

An authoritative state-sync can be the definitive version of the game state. But rollback remains the smoothest way to allow players to continue playing even between verification intervals.

The player's experience is still of stuttering, hesitation, or a rubber band, but not for the same reasons. Rollback still causes barely noticeable errors, hesitation, stuttering, and rubber-band errors. It just comes across as more fluid and responsive.

That feeling of a smooth game world that instantly corrects your movement about every 30th of a second is the fastest and lowest-delay way to keep multiple players acting in sync.