How rollback netcode works in fighting games
The technique responds to local input before receiving the opponent’s data, then re-simulates the match when a prediction fails, trading constant delay for occasional corrections.
R42 / SUMMARY
Rollback netcode keeps a match responsive by executing local input immediately and temporarily predicting the remote player’s action. When the real data arrives, the game compares it with the prediction, restores an earlier state if necessary, and re-simulates the frames up to the present. The technique does not eliminate ping, jitter, or packet loss; it changes how their effects appear.
KEY POINTS
- The game does not wait for every remote input before advancing; it predicts missing input for a few frames.
- If the prediction is wrong, the simulation returns to the last correct state and replays the frames with real data.
- Determinism, fast state saving and efficient re-simulation are core requirements.
- Rollback reduces perceived input delay but does not remove ping, jitter, packet loss, or unstable Wi-Fi.
- Visual corrections may appear as small jumps, shortened animations, or effects that change after the fact.
In a local match, pressing a button and seeing an attack begin are separated by only a few milliseconds. Online, the opponent’s input must cross the network before it reaches the other console or computer. Rollback netcode does not make that trip instantaneous. It reorganizes the simulation so the player does not have to wait for a remote packet on every frame.
The central idea is straightforward: the game executes local input immediately and, when remote input has not arrived, makes a temporary prediction. In many situations, the most likely assumption is that the opponent will keep doing what they did on the previous frame. If the real data confirms the prediction, nothing has to change. If it differs, the match returns to a saved state, applies the correct input, and calculates the following frames again until it reaches the present.
Predict now, correct later
A traditional delay-only model keeps both machines synchronized by waiting for the required inputs or adding a fixed buffer before displaying each action. That can keep the visual pace stable, but it passes the cost of the connection directly to the controls: button presses feel late.
Rollback moves that cost elsewhere. Local input responds closer to the timing of an offline match, while prediction errors may appear as a character moving a few pixels, an animation skipping frames, or an effect disappearing after a correction. The technique trades constant delay for occasional adjustments. The choice is not between lag and no lag, but between different ways of managing information that has not arrived yet.
A short frame-by-frame example
Imagine a fighter walking forward. During two frames without new data, the remote game predicts that the character will keep moving in the same direction. If the actual input confirms the movement, the simulation continues. If the player pressed block instead, the system restores the earlier state, applies the block input, and replays those frames. Only the latest result needs to be displayed; the intermediate calculations can run without full rendering.
Why the technique asks so much of a game
GGPO, a library built specifically for this networking model, describes three fundamental needs: the simulation must be deterministic, the game must save and restore states quickly, and it must be able to execute gameplay frames without drawing them. Determinism means that the same initial conditions and inputs must produce the same result on every machine. If one system rounds physics, randomness, or time differently, the states can diverge even with identical controls.
Re-simulation also costs processing time. Unity’s documentation warns that higher-latency connections can require multiple ticks to be replayed inside a single frame. In a fighting game, that shapes architecture decisions: physics, effects, and supporting systems need to separate the state that defines the match from visual presentation that can be rebuilt or smoothed.
What rollback cannot fix
Rollback does not erase the physical distance between players. High ping expands the window that must be predicted; jitter makes arrival times vary; packet loss delays or removes inputs; and an unstable connection can demand corrections that are too large to hide. Good systems limit their history, may add a small amount of deliberate delay, and can end matches when network quality falls beyond what the simulation can absorb.
Rollback should also be distinguished from related techniques. Interpolation keeps remote movement visually smooth by displaying buffered data with a small delay. Lag compensation in shooters may let the server inspect an earlier state when judging a shot. These approaches share the idea of multiple timelines, but they are not synonyms for the prediction, restoration, and re-simulation loop popularized by GGPO.
How to judge the experience in practice
A good implementation cannot be judged only by a “rollback” label. Correction size, connection stability, regional matchmaking, cross-platform support, and the game’s ability to maintain its simulation rate all affect the result. A rollback-frame counter can help, but it does not replace ping, jitter, and packet-loss measurements.
Network latency is also only one part of the path between a button press and the image. The controller, game logic, render queue, and display add delays of their own. The distinction is similar to Rota42’s explanation of why more displayed frames do not automatically reduce latency. Rollback improves how a match handles remote data, but the final feel still depends on the whole chain.
Misael
Responsible for reporting and writing this story at Rota42.
R42 / FAQ
Does rollback netcode eliminate lag?
No. It mainly reduces the feeling of input delay by predicting remote inputs and correcting the simulation later. High ping, jitter, and packet loss still exist and can cause visible corrections or make a match unplayable.
Why is rollback common in fighting games?
Fighting games depend on reactions and inputs measured over a small number of frames. A deterministic simulation with few participants also makes it relatively efficient to reconstruct the match state from each player’s inputs.
What happens when the opponent prediction is wrong?
The game restores a saved state from before the error, applies the true remote input, and re-simulates the following frames. The player normally sees only the updated result, which may include a small visual jump.
Does rollback netcode require a dedicated server?
Not necessarily. GGPO was designed for peer-to-peer matches, but prediction and rollback can also exist in server-authoritative architectures. Network topology and the correction technique are related but separate design choices.
Does a wired connection still matter with rollback?
Yes. A stable connection reduces jitter and packet loss, keeping prediction windows shorter and corrections less frequent. Rollback tolerates some delay better, but it cannot turn an unstable connection into a good one.