WebTech1223411 logo WebTech1223411Web tech, read closely
Games

How Netcode Decides Who Wins in Fast Online Game Matches

Two players see each other at the same moment and both fire. On one screen, the shot clearly lands. On the other, the shooter was already behind a wall. Only one of them can be right, and the game has a few milliseconds to decide.

Abstract illustration for How Netcode Decides Who Wins in Fast Online Game Matches

Two players see each other at the same moment and both fire. On one screen, the shot clearly lands. On the other, the shooter was already behind a wall. Only one of them can be right, and the game has a few milliseconds to decide. Whatever it decides, one player will feel cheated.

That decision is made by netcode, the part of an online game that deals with the fact that every player sees a slightly different, slightly delayed version of the same match. Netcode gets blamed for every loss in a close game, often unfairly. Understanding how it works makes the trade-offs much clearer, and makes some complaints easier to judge.

The problem: nobody sees the present

Light is fast but networks are not. A message from London to New York and back takes around 70 milliseconds over fibre in ideal conditions, and real home connections add more. Add the game server's tick interval and the time to render a frame, and a typical player is seeing a world that is 50 to 150 milliseconds old.

Every player is therefore acting on outdated information. Netcode is a set of strategies for hiding that delay where possible and resolving disagreements fairly when it cannot be hidden. The underlying structure, an authoritative server sending regular snapshots, is covered in how online game servers keep many players in sync. This article focuses on the decisions made on top of it.

Client-side prediction: making your own moves instant

If your character only moved after the server confirmed it, every keypress would feel delayed by your full round-trip time. That is unplayable at anything above about 50 milliseconds.

So your client predicts. When you press a key, your game applies the movement immediately, using the same rules the server uses. It also remembers each input with a sequence number. When the server's authoritative state arrives, the client checks it against its prediction. If they agree, nothing happens. If they disagree, perhaps because another player blocked you, the client snaps to the server's version and replays the inputs that came afterwards. Done well, the correction is invisible. Done badly, you see the familiar rubber banding, where your character is pulled backwards.

Lag compensation: judging shots from the shooter's view

Prediction handles your own movement. Hit detection is harder. When you aim at an opponent, you are aiming at where they were some time ago, because that is what your screen shows. If the server checked your shot against where the target is now, you would have to lead every shot by your ping, which feels terrible.

Lag compensation solves this by rewinding. The server keeps a short history of where every player was. When your shot arrives, it estimates what you were seeing when you clicked, rolls the other players back to that moment, checks the hit, then restores the present. If it hit on your screen, it counts.

This is why the classic complaint "I was already behind the wall" exists. From the shooter's point of view, you were not. The server has decided to favour the shooter, because the alternative makes aiming impossible. Most games cap how far back they will rewind, often 200 milliseconds or so, so that players with very high ping cannot shoot people who are long gone.

Rollback: the fighting game approach

Fighting games and other one-on-one titles often use a different model called rollback netcode, popularised by the GGPO library. There is often no server deciding the outcome; both players run the full simulation.

Each client predicts the opponent's next input, usually by assuming they keep doing what they did last, and runs the game forward without waiting. When the real input arrives and differs from the guess, the client rolls the game back to that frame, applies the correct input, and quickly re-simulates up to the present, all within a single frame. Players see an occasional small correction instead of constant input delay.

Rollback only works if the game is deterministic, meaning the same inputs always produce exactly the same result, and if the simulation is cheap enough to replay several frames at once. That is why it fits fighting games well and is harder to retrofit into large open-world titles.

Is "low ping always wins" really true?

A widely repeated belief is that the player with the lower ping always has the advantage. It is partly true, but less often than people think, and sometimes the reverse.

Lower ping means you see things sooner and your inputs reach the server faster, which genuinely helps in a race to react. But lag compensation partly evens things out by judging shots from the shooter's view. In some situations a player with higher latency effectively gets to shoot at an older position, and their target, who already moved, still gets hit. This is the "peeker's advantage" debate in tactical shooters: the player moving around a corner often sees the defender a fraction of a second before the defender sees them, regardless of who has the lower ping.

What hurts most is not high ping but unstable ping. A steady 80 milliseconds is easy for netcode to handle. A connection that swings between 30 and 200 with packet loss defeats prediction and interpolation alike. We go into why players feel these swings so strongly in why online game players notice every millisecond of lag.

Things players can actually control

You cannot change the speed of light, but you can reduce the parts of the delay that are local:

  • Use a wired connection where possible. Wifi adds jitter and occasional packet loss, which netcode handles worse than raw latency.
  • Choose the nearest server region when the game lets you.
  • Stop large downloads and video streams on the same network during a match.
  • Keep frame rate high and stable. A dropped frame adds as much perceived delay as extra ping.
  • Use the game's network graph or statistics overlay to tell the difference between ping, jitter and loss.

Netcode is a set of compromises, each chosen to make an online game feel fair to as many players as possible, as often as possible. It will never please everyone in every close moment. But next time a shot seems to land behind a wall, you will know exactly which compromise you just experienced. More in our Games section.

KO
Kofi Oosterhuis

Kofi spent years keeping APIs and game servers alive through traffic spikes and the occasional bad deploy. He covers back-end design, scaling and networking, with a preference for boring systems that do not page anyone at night.

More posts by Kofi

More in Games