For twenty years, fighting games online were a compromise. Then rollback netcode became standard, and a genre that had been unplayable outside an arcade became a genre you could compete in from a sofa. It is the single most consequential technical change in competitive gaming, and almost nobody outside the genre knows what it is.
The problem
Fighting games run at sixty frames per second and are decided by differences of one or two frames. A move is punishable or safe depending on a three-frame gap. Any delay between pressing a button and seeing the result destroys the game.
Network latency is measured in tens of milliseconds, which is several frames. That is not a small problem; it is the whole problem.
Delay-based netcode
The old solution was to wait. Both clients hold their inputs for a few frames until the opponent’s input arrives, then run the frame with both. The game stays perfectly synchronised and every input you make happens slightly later than you pressed it.
It works, it is simple, and it makes the game feel like it is happening underwater. Players learned to compensate, which meant online play and offline play required different timing.
Rollback netcode
Rollback takes the opposite approach. Run the frame immediately using a prediction of what the opponent did – usually that they kept doing what they were doing. When their real input arrives, if the prediction was wrong, rewind to that frame, re-simulate with the correct input, and jump forward.
Your own inputs are never delayed. The opponent’s actions occasionally correct themselves visually, which appears as a small jitter and is far less disruptive than universal input lag.
Why it is hard to implement
- The game must be able to save and restore its complete state every frame.
- Simulation has to be fully deterministic.
- Re-simulating several frames has to fit in the time budget of one frame.
- Any system with hidden state – animation, audio, effects – has to be rollback-aware.
That first requirement is the reason so many games never added it. Retrofitting state serialisation into an engine that was not built for it is close to a rewrite.
What changed when it arrived
The competitive scene stopped being regional. A player in a small city could practise against top opposition, which had previously required travelling to where the players were.
That widened the talent pool enormously and it changed who could compete at all, which is a larger effect than any balance change in the genre’s history.
Beyond fighting games
Rollback is now used well beyond the genre – any game where input feel matters more than perfect synchronisation is a candidate. Its adoption elsewhere has been slower, largely because most genres tolerate latency better and the engineering cost is the same.
Why the genre cared first
Because fighting games are the most latency-sensitive competitive genre that exists. A shooter can hide latency with client-side prediction and hit registration tricks; a fighting game cannot, because both players are interacting with the same three-frame window.
Necessity is the whole explanation. The genre solved the hardest version of the problem because it had no alternative.
The lesson for competitive design
A technical decision made in an engine determined which players could compete in a genre for two decades. It was not a design decision, it was not visible in the game, and it mattered more than almost anything that was.
That is worth remembering when evaluating any competitive title – the things that decide a scene’s health are frequently not the things being discussed.
What a player actually notices
- Their own inputs feel immediate, always.
- The opponent occasionally teleports a short distance as a prediction corrects.
- At high latency, corrections become frequent and visible.
- At low latency, it is indistinguishable from offline play.
The trade is visual consistency for input responsiveness, and in a genre decided by frames that is the correct direction. A player can adapt to a visual correction; nobody adapts to delayed inputs.
Rollback in other genres
The technique has spread slowly. Platform fighters adopted it, some indie multiplayer games use it, and most large-scale multiplayer stays with client-side prediction and server authority – a different approach to the same latency problem.
The difference is scale. Rolling back two players is feasible; rolling back a hundred-player battle royale is not, which is why that genre uses entirely different techniques and lives with the results. The consequences at that scale are covered in the circle design piece.
Why it took so long
The technique was documented in the mid-2000s and took fifteen years to become standard. The delay was not technical ignorance – it was that retrofitting it into existing engines was expensive, and nobody could prove it would sell copies.
It eventually became standard because players started refusing to buy games without it, which is a rare case of an audience forcing an engineering decision.
Why this belongs in a design discussion
Netcode is usually filed under engineering and treated as invisible infrastructure. It is not – it determines who can compete, from where, and at what level, which makes it a design decision with a competitive outcome.
The same is true of several unglamorous production decisions in esports, including who chooses what the audience sees, which is covered in the observer piece.
Images: Street Fighter 6 store assets, Capcom. Official site: streetfighter.com.