A fighting game asks for unusually exact timing. A throw break, anti-air, or one-frame link can be decided before a signal has crossed the internet and returned. That creates a basic contradiction: the game must react to a button press now, but it cannot yet know what the other player pressed now.
Rollback netcode resolves much of that contradiction by treating the first version of the next moment as a provisional guess. Rather than making both players wait for remote input, it lets each machine simulate immediately, then revises history if the real input contradicts the prediction. The result can feel strikingly close to offline play—not because latency has vanished, but because the game has chosen where players are most willing to tolerate uncertainty.
Online games can improve how delay is handled, but they cannot make distance irrelevant. A player’s input must travel through local hardware, an internet route, and usually some form of game infrastructure before another player can receive it. Even a very fast connection can have changing latency, lost packets, or brief congestion. Bandwidth helps move more data, but it is not the same thing as low or stable response time.
Traditional online play often addresses this uncertainty by adding input delay. If a match waits a few frames before acting on either player’s inputs, it has more time to receive them. The simulation stays in agreement, but the control response becomes less immediate. In a slower strategy game, that trade-off may be barely noticeable. In a fighter, where players build decisions around animation timing and muscle memory, it can make a familiar character feel strangely heavy.
Older client-server action-game techniques already used local prediction to avoid making a player wait for the server before seeing their own movement. Valve’s technical account of lag compensation describes the same underlying tension: responsiveness requires a local prediction, while authority and correction still have to exist somewhere. Rollback adapts that basic idea to a game in which both players’ exact inputs are central to every frame of play.
With delay-based netcode, a player may press punch on one frame, but the game intentionally schedules that input to take effect several frames later. Assuming both sides receive inputs before their scheduled moment, each machine can show the same result without needing to revisit it. The visible trade-off is consistent extra delay between the player’s hand and the character’s action.
Rollback takes the opposite route. When the remote player’s next input has not arrived, the local game predicts one—often that they are continuing their last held direction or pressing nothing—and advances immediately. The player sees their own button take effect without a deliberately added wait. GGPO, a rollback networking system designed for precise peer-to-peer games, describes this as speculative execution: inputs are sent while the game proceeds on a predicted version of events.
Neither approach is magical, and neither is automatically better in every genre. Delay-based systems exchange responsiveness for a stable, unsurprising timeline. Rollback exchanges some risk of visual correction for more immediate control. Fast fighting games often favor the second bargain because a delayed response can affect every decision, while a short correction may occur only when a prediction is wrong.
Consider a match running at 60 frames per second, where each frame lasts about 16.7 milliseconds. On frame 500, Player A sees that their opponent’s input for that frame has not arrived. Instead of freezing, A’s machine predicts that Player B continues holding back. It simulates frame 500, then 501, and shows the result right away.
If B really did keep holding back, nothing special happens. When the real input arrives, it matches the prediction, and the local simulation was already correct. This is why a healthy rollback connection can feel ordinary: most of its work is invisible.
If B instead pressed forward and an attack button on frame 500, A’s prediction is wrong. The game needs enough saved state to restore the match to just before frame 500, insert B’s actual input, and rapidly simulate the intervening frames again. It then displays the corrected present. The term ‘rollback’ refers to this return to an earlier state, not to the entire match visibly running backward.
That requirement explains why rollback is more than a networking switch. GGPO requires a deterministic game simulation: given the same starting state and the same inputs, it must produce the same result on both machines. It also requires the game to save and reload state efficiently. A stray difference in physics, random-number generation, frame timing, or platform behavior can turn a small correction into a desynchronization.
Imagine that Player A begins an attack while Player B appears, on A’s screen, to keep crouch-blocking. A commits to a sequence based on that image. Two frames later, B’s real input arrives: they had jumped at the earlier moment, and the predicted crouch-block was wrong.
A’s game restores the prior state, replays those two frames with the jump included, and arrives at the present again. If the rollback window is short and the correction is modest, A may simply see B move differently than expected. If the window is longer, A may see a noticeable snap, a skipped animation, or an attack outcome that seems to change abruptly. The game has not changed the input after the fact; it has replaced an earlier guess with information that was always delayed.
This example also explains an often-misunderstood point about fairness. Rollback does not promise that every player sees precisely the same provisional screen at every instant. It aims to ensure that both machines ultimately resolve the match from the same sequence of inputs. The better the connection and the closer the players are to one another in network terms, the fewer and smaller those revisions tend to be.
Modern implementations may add other layers around the core method. Riot’s explanation of 2XKO’s online architecture describes rollback alongside client-server systems and validation designed to keep matches robust. That is a useful reminder that rollback governs the moment-to-moment simulation problem; it does not, by itself, solve matchmaking, cheating, disconnects, or four-player synchronization.
Rollback has limits that marketing language can obscure. It cannot repair a persistently bad route, severe packet loss, or a large geographical separation. If real inputs arrive too late too often, the game must either roll back farther, introduce more delay, slow or pause the match, or accept increasingly disruptive corrections. There is no algorithmic escape from missing information.
It is also demanding for developers. Gameplay events may need special treatment because they are generated in a timeline that can be undone. A predicted sword slash might trigger sound, camera shake, particles, controller vibration, or a hit flash—then vanish when the simulation is corrected. Unreal Engine’s network-prediction documentation explicitly distinguishes cues that can be undone and replayed during resimulation from less exact, cheaper presentation choices. This is why a game may prioritize accurate positions and hit outcomes while allowing minor effects to be softened, delayed, or handled separately.
Finally, rollback is not automatically the right answer for every multiplayer game. A sprawling world with many independent objects, complex physics, or many players multiplies the amount of state and interaction that may need to be recreated. Epic’s current networking tools support rollback-oriented movement and resimulation, but also document alternatives such as predictive interpolation that can be more performant and less network-intensive in appropriate cases. The right system follows the game’s simulation and competitive stakes, not a fashionable label.
For players, “rollback” is best understood as a promising architectural choice rather than a guarantee of flawless online play. It suggests that the game is designed to protect immediate inputs by predicting remote ones and reconciling disagreements later. That is especially valuable in games where a few frames change whether an action is possible.
The practical test remains more specific. Does the game show a stable connection indicator? Does it match players by region or network quality? Can players decline unstable opponents? Are cross-platform matches held to the same simulation standard? And, most importantly, does the match remain readable when the connection is imperfect? A good implementation makes its corrections rare enough, short enough, and well-managed enough that players can trust what they are learning.
That is rollback’s real contribution. It does not make an online match identical to sitting beside an opponent. It makes the game spend uncertainty where it does the least damage—inside the machinery of the simulation rather than in the delay between a player’s decision and their character’s response.
Rollback netcode changes the order in which an online game learns and displays events. It shows a responsive prediction first, then quietly reconciles that prediction with the remote player’s real input.
When the assumptions are right, the correction is invisible and the match feels immediate. When the connection is poor or the simulation is too complex, the limits become visible. Understanding that trade-off makes it easier to evaluate both online fighting games and the increasingly common promise of “good netcode.”
Photo by George Becker on Pexels.
A game’s frame-rate counter can now tell two different stories. One is how often the game actually simulates the world and responds to a new button press. The other is how often…
A game can ask a player to jump with one button, sprint by holding another, aim with a trigger, rotate a camera with a stick, and open a menu with a third input. For many players,…
A game level can feel like a place someone deliberately composed for you: a doorway frames a distant landmark, an enemy arrives at the exact moment you understand a new ability,…