Rollback netcode lies to you for a few frames, and that is why fighting games work online

Start with the scale of the problem. A fighting game runs at sixty frames a second, so a frame lasts 16.7 milliseconds. A fast attack comes out in three to six frames, and the window to block it is one or two. A packet from Los Angeles to New York takes about forty milliseconds one way; to Tokyo, over a hundred. The network is slower than the smallest meaningful unit of the game, and nothing can be done about that. All you can choose is how to lie to the player.

The first lie: input delay

The classic solution is called delay-based. Both machines wait for the opponent's input and do not advance until it arrives. To stop network jitter from causing stutter, input delay is added: your button does not fire now but a few frames later, and that buffer is usually enough for the packet to arrive.

The advantage is that both sides see an identical match. There are two disadvantages and both are heavy. The controls go soft: three to five frames sit between the press and the punch, and precise defence simply stops working. And when a packet is lost, both players freeze — the rubbery hitching familiar from the online modes of older SNK and early Arc System Works games.

The second lie: rollback

Rollback is built the other way around. The machine waits for nothing. Having no remote input, it assumes the opponent is doing what they did on the previous frame, an assumption that is almost always right, because buttons are held rather than released every frame. The game advances immediately.

When the real input arrives and disagrees with the prediction, the engine takes the saved state from that frame, applies the correct input over it and re-runs every frame up to the present, all inside a single display frame. On screen this looks like the opponent jumping a few pixels. Your own character obeys instantly throughout, because your input was never predicted.

Delay-based lies about when you pressed. Rollback lies about what your opponent did. There is no third option.

Why you cannot simply switch it on

The interesting part is the engine requirements, the reason studios spent years saying they could not add rollback.

First, the simulation must be deterministic: identical inputs must produce an identical state, every time. No reads of the system clock, no unseeded random number generator, careful handling of floating point.

Second, the game state must be savable and restorable in full, cheaply, dozens of times a second — history is kept roughly seven or eight frames back. If state is smeared across engine objects and the rendering subsystem, there is nothing to save.

Third, simulation has to be decoupled from rendering so that seven logic steps can run inside one displayed frame. An engine whose logic lives inside the render loop has to be rewritten.

How it became the norm

GGPO was written by Tony Cannon, co-founder of the Evo tournament, around 2006, for his own use, so he could play old arcade fighters over a network. The library ran Street Fighter III: Third Strike Online Edition in 2011, Skullgirls in 2012 and Killer Instinct in 2013. On 9 October 2019 Cannon released the source under the MIT licence, and within a few years rollback went from an advantage to a requirement: the genre began rejecting games that shipped without it before release.

It is worth understanding why the method stayed inside fighting games. The cost of a rollback is directly proportional to the size of the state and the number of entities re-simulated. Two characters on one plane is a tiny state that can be copied sixty times a second. A hundred players in an open world cannot. Shooters use a related but asymmetric lie: the client predicts movement, while the server, validating a hit, rewinds hitboxes back in time to the moment you actually saw. Hence the famous death from behind cover — that is somebody else's rollback, applied to you.