Rollback Netcode Explained: How It Works and When You Need It
Rollback netcode predicts your opponent's inputs, runs the game forward instantly, and rewinds to resimulate when a prediction was wrong. Here is how it works, why it needs a deterministic simulation, how it differs from client-side prediction, and which games it is right for.
The short version
- Rollback netcode guesses what your opponent will do next, runs the game forward immediately, then rewinds and resimulates if the guess was wrong, all within a few frames you usually never see.
- It depends on a deterministic simulation that you can save, reload, and re-run, so the same inputs always produce the same result.
- It is the gold standard for fighting games and other fast, input-precise titles, popularized by the open-source GGPO SDK.
- It is a peer-to-peer, lockstep-style technique. It is not the same thing as the authoritative-server prediction model most shooters and survival games use.
"Rollback netcode explained" and "rollback netcode vs client-side prediction" are some of the most searched netcode questions, and for good reason. Rollback gets credited with making online fighting games finally feel playable, but the term is thrown around loosely and often confused with the prediction model used in shooters. This article explains what rollback actually is, the one hard requirement that makes it work, and when you should reach for it instead of a different model.
The problem rollback solves
Every networked game has to deal with the same enemy: the round-trip time between two players. The older way to handle it in fighting games is delay-based netcode. The game waits for the remote player's input to arrive before advancing the frame, and to keep both sides in sync it deliberately delays your own input by the same amount. The result is that everything you do feels slightly mushy, and the delay scales with ping. On a bad connection the game becomes unplayable, because a few frames of input lag is the difference between a clean combo and a dropped one.
Rollback netcode takes the opposite bet. Instead of waiting, it assumes the remote player will keep doing what they were just doing and runs the frame now. Your own input is never delayed. Most of the time the guess is right and nobody notices anything. When the guess is wrong, the game quietly corrects itself.
How rollback works, frame by frame
- Predict. When the remote player's input for this frame has not arrived yet, the game predicts it, usually by repeating their last known input.
- Simulate immediately. The game advances using your real input and the predicted remote input, and renders the frame. No waiting.
- Compare. When the real remote input finally arrives over the network, the game checks it against what it predicted.
- Roll back and resimulate. If the prediction was wrong, the game restores the saved state from the frame where the inputs diverged, then replays every frame from there to the present using the correct inputs. This happens in a single tick, faster than the eye can follow.
Because the correction replays multiple frames at once, the visible result is a small, brief snap rather than a stutter. The canonical deep dive on this is Infil's "Netcode and You" explainer and the Ars Technica writeup of it, both of which reached the top of Hacker News more than once because they finally made the topic click for a lot of developers.
The one hard requirement: a deterministic simulation
Rollback only works if you can save the entire game state, reload it later, and run a frame so that the same inputs always produce the exact same outputs. That property is called determinism, and it is the part that makes rollback genuinely hard to retrofit.
Three things break determinism, and all three are common in everyday game code:
- Floating-point drift. The same float math can produce slightly different results on different CPUs or compilers. Many rollback games use fixed-point math to avoid this entirely.
- Unseeded randomness. Any call to a random number generator must use a shared, replayable seed, or the two clients will diverge.
- Frame-rate-dependent logic. Physics or movement tied to wall-clock time rather than a fixed tick will not replay identically.
If your simulation is deterministic, the rollback machinery itself is almost mechanical. As GGPO's own documentation puts it, once you can save your game state, load it back, and execute a frame without rendering, the SDK can take care of the rest. The hard work is the determinism, not the rollback.
Where GGPO comes in
GGPO ("Good Game, Peace Out") is the library that popularized this approach. It was created by Tony Cannon and first released in late 2006, and it was open-sourced under the MIT License on October 9, 2019. It is peer-to-peer middleware: it handles the input prediction, the rollback, and the network transport, and it asks you to provide save-state, load-state, and advance-frame callbacks against your deterministic engine.
Games built on GGPO or GGPO-style rollback include Skullgirls, Street Fighter III: 3rd Strike Online Edition, Melty Blood: Type Lumina, and The King of Fighters XV. The shift to rollback across the fighting-game genre is the reason online matches that used to be a frustrating slideshow now feel close to offline play.
Rollback vs client-side prediction: not the same thing
This is the disambiguation people search for, so let us be precise. Both techniques predict and correct, but they sit on opposite architectures.
| Aspect | Client-side prediction + reconciliation | Rollback netcode |
|---|---|---|
| Topology | Authoritative server, clients are spectators | Peer-to-peer, each client runs the full simulation |
| What is predicted | Mostly your own local player, applied instantly | The remote player's inputs |
| Source of truth | The server | The shared deterministic simulation on both ends |
| Correction | Server sends authoritative state, client replays its own unacknowledged inputs | Local state is rewound and all players' frames are resimulated |
| Typical games | Shooters, MMOs, survival, MOBAs | Fighting games, fast 1v1 or small-N input-precise games |
| Cheating | Hard, the server validates everything | Easier, both peers see the full state and there is no referee |
The model used by most shooters and survival games is the authoritative-server one: the server owns the truth, your client predicts your own movement so it feels instant, and the server reconciles. Gabriel Gambetta's Fast-Paced Multiplayer series is the reference for that approach. Rollback is the peer-to-peer cousin where there is no server referee and both machines run the same lockstep simulation, rewinding when they disagree.
One practical consequence: because rollback peers see the entire game state and trust each other's inputs, it offers weak protection against cheating. That is acceptable in a 1v1 fighting game where a desync just ends the match, and unacceptable in a competitive shooter where money or rank is on the line.
When you should and should not use rollback
- Use it for: fighting games, platform fighters, and other fast, twitchy games with a small number of players where frame-perfect input matters more than anything.
- Think twice for: games with large or chaotic worlds where saving and resimulating state every frame is expensive, or any game where you cannot make the simulation deterministic.
- Use an authoritative server instead for: shooters, MMOs, survival and sandbox games, and anything competitive that needs server-side validation to stop cheats. The trade-offs between hosting models are covered in Listen Server vs Dedicated vs Hosted Authoritative.
If you are searching for "rollback netcode godot" or "rollback netcode unity" hoping it will smooth out a large persistent world, it is usually the wrong tool. Rollback shines in tight, deterministic, low-player-count duels. For most shared-world and shooter use cases you want a server that owns the truth.
Where Crux fits
Crux is not a rollback library, and it should not be. Rollback is a peer-to-peer pattern for deterministic duels; Crux is the backend for everything around the match. Even a fighting game needs accounts, persistent progression, ranked ladders, matchmaking to pair two players before rollback ever kicks in, and live config to tune balance without a patch. Crux ships player auth, persistent state, leaderboards, server registry, live config, economy, and matchmaking behind one API, so your networking layer can focus purely on the netcode. If your game is server-authoritative rather than peer-to-peer, Crux Realtime runs the authoritative simulation loop for you as well.
Next, read What Is an Authoritative Game Server for the server-side prediction model, or Player Reconnection and Session Resumption for keeping a match alive when a connection drops.
Netcode and realtime servers: the full series