Rollback Netcode: How Online Fighting Games Hide Latency
The internet has unavoidable latency. Rollback netcode doesn't eliminate it — it hides it, by having both players simulate a guessed future and quietly correcting the guess when reality disagrees.
Fighting games are unusually sensitive to network latency: inputs matter down to individual frames (at 60fps, a single frame is 16.6ms), and a round-trip across the internet routinely takes far longer than that. Two broad approaches exist for handling this, and they make almost opposite trade-offs.
Delay-based netcode: wait for certainty
The straightforward approach is to simply delay local input by a few frames before applying it, buying enough time for the remote player’s input for that same frame to arrive first. This guarantees both sides simulate the exact same, fully-correct game state at every step — there’s never a wrong guess to correct — at the direct cost of added, visible input lag: every button press feels delayed by however many frames were reserved for network travel time.
Rollback: guess, simulate, correct if wrong
Rollback netcode takes the opposite trade: never wait. Each side keeps simulating every frame immediately using its own real local input and, for the remote player, its best guess at their input (typically “repeat their last known input,” a good predictor for held directions and neutral frames, which are the majority of any match).
Frame N: local input (real) + remote input (guessed) → simulate → display
Frame N+1: ...same pattern, keeps advancing without waiting...
[ a few frames later, the remote player's REAL input for frame N arrives ]
if (guessed input == real input):
nothing to do — the simulation was already correct
else:
→ roll back to frame N (reload the save state from that frame)
→ re-simulate every frame from N to now, using the REAL input this time
→ the corrected frames replace what was already shown, all in a
single instant — visible, if at all, as a brief, small correction
Because the guess (repeat the last input) is right the overwhelming majority of the time — most frames in a match aren’t the instant a player changes their input — corrections are infrequent and small, and the game feels completely lag-free even though the underlying network connection has exactly the same real latency it always did.
Why this depends entirely on save states
Rolling back requires reloading the exact game state from several frames ago, then re-simulating forward — which is precisely what a save state is for. Rollback netcode is, mechanically, “take a save state every frame, and reload one whenever a prediction turns out wrong” — which means it inherits every requirement a save state has: the simulation has to be fully deterministic (identical inputs must always produce identical output, every time, or resimulation would diverge from what was already shown) and fast enough to re-run several frames’ worth of simulation faster than real time, since all of that re-simulation has to complete within the same single frame it’s correcting.
Where this came from
GGPO — built by Tony Cannon, co-founder of the Evolution Championship Series (Evo) and the fighting-game community site Shoryuken — is the project most directly responsible for popularizing rollback in fighting games specifically. Cannon built it after being dissatisfied with the online experience of a 2006 fighting-game re-release, first releasing GGPO later that same year; it went on to be used in games including Skullgirls and Street Fighter III: 3rd Strike Online Edition. On October 9, 2019, Cannon released GGPO as open source under the MIT license, making the technique freely available to any developer rather than requiring a custom licensing arrangement — a significant factor in rollback becoming the expected standard for fighting-game netcode across the industry in the years since.
Why delay-based netcode hasn’t disappeared
Rollback isn’t strictly better in every dimension — the momentary resimulation-driven correction is a real visual artifact (a character’s position “popping” slightly when a guess was wrong), and implementing it correctly requires a fully deterministic simulation, which isn’t a given for every game engine. Delay-based netcode remains a reasonable, simpler choice when a game’s simulation isn’t (or can’t easily be made) fully deterministic, or when consistent, small, predictable delay is judged preferable to occasional visible correction — but for competitive fighting games specifically, where every frame of unnecessary delay is felt directly, rollback’s trade-off has become the clear industry consensus.