Rollback Netcode
Rollback netcode predicts what remote players will do, simulates forward immediately, then rewinds and replays the simulation when their real inputs arrive. Local input never waits for the network, so play stays responsive at higher latency. Corrections become visible when predictions are wrong, which is the trade it makes.
Also called
rollback
,
How Does Rollback Netcode Work, Frame by Frame?
Online, the other player's input always arrives late. Rollback's answer to that is not to wait. On every frame, the game:
Runs your input now, on the next frame, as it would offline.
Predicts the other player's input, usually as a repeat of their last one. At 60 frames per second a frame lasts about 16.7 ms, and players change what they press far less often, so the guess is usually right.
Saves the game state for the last several frames.
Corrects when the real input arrives. If it differs from the guess, the game restores the frame the input belonged to, applies it, and re-simulates every frame since, before drawing the next one.
Players see step 4 as a correction: an attack that appears already a few frames in, or a character that snaps into place. It is not lag compensation, where a server rewinds positions only to check whether a shot hit.
How large each correction is depends on one number: how late the input arrived.
Rollback vs Delay-Based Netcode: How Much Latency Can Rollback Hide?
Delay-based netcode holds every input until the remote input for the same frame has arrived. Both screens always agree and nothing is corrected, but the controls lag, and when the delay changes mid-match, so does the timing of every move.
Rollback keeps controls at offline timing and moves the cost into corrections, and latency sets their size. An input 100 ms late belongs about six frames back at 60 fps, so the opponent's move appears six frames in. At 30 ms it is two frames, which players often never notice. Rollback hides latency. It does not remove it, and the more there is, the more shows.
Most shipped games use both: a small fixed input delay absorbs part of the latency, rollback covers the rest, and a cap limits how far prediction runs ahead. NetherRealm's rollback update for Mortal Kombat X and Injustice 2 kept three frames of input delay, with an engine built to re-simulate up to eight frames within one 16 ms frame (Michael Stallone, GDC 2018). Past the cap, extra latency usually becomes more input delay or a pause, not larger corrections.
What Does Rollback Netcode Cost to Build?
The player gets responsive controls. The developer pays for them in three places:
CPU. A rollback re-runs several frames of game logic inside one frame's budget. NetherRealm's first implementation took about 30 ms per frame against a 16.7 ms budget, and shipping it took roughly seven to eight man-years, per the same talk.
Saving and restoring state. Everything that can change must be cheap to snapshot and restore every frame. Particles and sound need their own handling, or they replay on every rewind.
Determinism, when only inputs are sent. In the classic peer-to-peer design popularised by the GGPO library, each machine runs the full simulation from shared inputs, so both must compute identical results. Any difference is a desync.
That is why rollback took hold in fighting games first: two players, a small game state and a fixed 60 fps. Each additional player is one more input that can be mispredicted, and a larger state costs more to save and re-simulate.
Does Rollback Netcode Need Peer-to-Peer?
No. GGPO-style rollback grew up on peer-to-peer connections, where players send inputs straight to each other. The same loop also works with a dedicated server as the source of truth: no host can quit or tamper with the match, and clients correct to the server's state rather than only to each other's inputs.
Rivals of Aether 2 is built this way. It runs SnapNet rollback on dedicated servers, and SnapNet "resimulates the entire game state without requiring strict determinism" (Rivals of Aether 2 breakdown, November 2024). Sending state as well as inputs is what relaxes the requirement from Part 3.
A server also changes the route, and the direct one is not always shorter. In a 2020 Edgegap analysis of 122,000 peer-to-peer matches from a 1v1 fighting game, routing each match through a server at the best available location between the two players lowered average round-trip time by 23% in 70% of matches (1v1 report). Less delay means fewer frames to roll back, so the corrections from Part 2 shrink with it.
A word from our sponsor (ourselves!)
Most lag comes from distance, not from code. Edgegap's Edge Cloud is a distributed network with up to 615+ locations available on demand, so each match runs at the best available location for its players. Independent replays of live studio traffic measured a 58% drop in average round-trip time compared with public cloud.
