What Is Netcode? Rollback vs Delay-Based Explained

What Players Actually Mean by Netcode

Ask someone why an online match felt awful and there is a good chance they will blame the netcode. But the word gets used loosely. Technically, netcode refers to all the programming that handles communication between players’ machines during an online game session. In practice, when a player says a game has bad netcode, they usually mean one specific experience: their inputs feel unresponsive, the action stutters, or what they see on screen does not match what they tried to do.

The core problem every online game is trying to solve is that data takes time to travel. Your internet connection introduces latency, measured in milliseconds, between when you press a button and when that information reaches another player’s machine. Two players in the same city might exchange data in under 20ms. Players on opposite coasts of the United States might see 80ms or more. Between continents, it can climb well past 150ms. The game has to decide what to do with that gap.

Delay-Based Netcode: Waiting for Everyone

The traditional solution is delay-based networking. The logic is straightforward: do not execute any player’s input until inputs from all players have arrived. The game adds a buffer, measured in frames, that equals however long it takes for the slowest connection to deliver its data. Everyone stays perfectly in sync because the game never has to guess.

The downside is immediate and physical. Every player feels an artificial pause between pressing a button and seeing the result. At low latency this might be a single frame, which most people can ignore. But as ping climbs, the delay climbs with it. At 100ms you are waiting six or seven frames before your character responds. In games where timing windows are tight, that feels like controlling your character through a thick pane of glass.

For slower genres, this is often acceptable. A turn-based strategy game or a casual sports title can absorb a few frames of delay without destroying the experience. For a fighting game where certain techniques require inputs within one or two frames, it can make entire mechanics unreachable.

Rollback Netcode: Predict and Correct

Rollback takes a different approach. Instead of waiting, the game immediately processes your local inputs and makes a prediction about what the other player is doing, typically assuming they are continuing whatever they did last. The match plays forward on your screen without any added delay.

When the actual input data from the other player arrives, the game compares reality against its prediction. If the prediction was correct, nothing visible changes. If it was wrong, the game rolls back to the last confirmed frame, replays the correct inputs, and snaps forward to the present. This correction can sometimes produce a brief visual hiccup. At low to moderate latency, predictions are usually accurate enough that the corrections are invisible.

The result is that your own inputs feel sharp and immediate regardless of your connection quality. The game’s library GGPO, developed by Tony Cannon, popularized this approach and became a standard reference for developers, particularly in the fighting game community where the difference between the two systems is most apparent.

Why This Matters Across Different Genres

Fighting game players have been the loudest advocates for rollback partly because the stakes are highest for them, but the concepts apply everywhere. First-person shooters almost universally use server-side lag compensation, a related technique where the server accounts for each client’s latency when registering hits. This is why you can sometimes see an enemy duck behind cover and still get hit by a bullet you fired slightly in the past from your own screen’s perspective.

In competitive shooters, players debate hit registration, peeker’s advantage, and tick rate, which is how frequently the server updates and processes the game state. Higher tick rates produce more precise collision and hit detection at the cost of more server resources.

Battle royale games, racing games, and MOBAs each have their own trade-offs. A 100-player battle royale cannot afford the same synchronization demands as a two-player fighting game, so developers make deliberate choices about what the server authorizes versus what the client handles locally.

Reading the Experience in Real Time

If you want to evaluate a game’s networking yourself, most titles offer a ping display or network diagnostics in the settings. Watch for consistent latency versus spiking latency, because steady high ping is often more manageable than unpredictable swings. Packet loss, when data simply fails to arrive, tends to produce the ugliest artifacts regardless of which synchronization method the game uses.

Understanding these systems does not make a bad connection tolerable, but it does explain why the same 80ms ping can feel fine in one game and completely unplayable in another. The difference is almost always in the architectural choice the developer made long before you ever pressed play.