How Online Multiplayer Games Work: The Science of Netcode

In 1996, John Carmack shipped Quake with a technique that would quietly define the next three decades of online gaming: client-side prediction, a way to make a game feel instant over a 28.8k dial-up modem that could take 200 milliseconds or more to answer a single keystroke. That single engineering insight became a foundational principle every competitive multiplayer game uses today, from Counter-Strike 2 to Fortnite to Street Fighter 6. The problem Carmack was solving is, in a strict sense, still unsolved: information cannot travel faster than light, and physics has placed a hard, permanent ceiling on how responsive an online game can ever be. Everything modern netcode does is an elaborate, carefully engineered set of illusions built on top of that ceiling.

Key takeaways

• All online games must cope with latency. The physical speed of light through fiber-optic cable means a round trip between New York and London takes at minimum roughly 38 milliseconds one way accounted for, and real-world routing typically adds 50–100ms more, according to fiber latency modeling from M2 Optics.
• Client-server architecture places a trusted server as the sole authority on game state, which stops most forms of cheating while introducing unavoidable processing delay.
• Client-side prediction lets your local game respond to your input immediately while it waits for the server to confirm what really happened, hiding network latency from view.
• Lag compensation rewinds the server's copy of the game world to evaluate a shot the way the shooter actually saw it, a design documented in Valve's own Lag Compensation engineering notes.
• Rollback netcode, pioneered by Tony Cannon's GGPO library, is now the standard for fighting games: simulate forward optimistically, then rewind and replay only when a guess about the opponent's input turns out to be wrong.
• Tickrate is a budget, not a luxury. Valorant runs a genuinely uniform 128 Hz tick, while Counter-Strike 2 uses a hybrid "sub-tick" system that timestamps actions between ticks rather than simply raising the tick count, per Riot's own technical breakdown.

The fundamental problem: latency

Network latency, commonly shortened to ping (Round Trip Time, or RTT), is the time it takes a packet to travel from your machine to a server and back. It cannot be engineered away, because data in a fiber-optic cable does not travel at the speed of light in a vacuum. It travels at roughly two-thirds of that speed, around 200,000 kilometers per second, because glass has a refractive index near 1.47 that bends and slows the light signal, a figure confirmed by fiber-latency calculators built for the trading and telecom industries at M2 Optics.

That single physical fact sets a hard floor under every online game ever made. The great-circle distance from New York to London is about 5,570 kilometers. At 200,000 km/s, light in fiber needs roughly 28 milliseconds to cross that distance one way, so the theoretical round-trip minimum is around 56ms — before a single router, switch, or firewall gets involved. In practice, no cable runs in a straight line under the ocean, and every hop through an internet exchange or peering point adds processing delay. A real New York-to-London game connection typically lands somewhere between 70ms and 110ms RTT. Players in the same metro area might see 5–15ms. Players on opposite sides of the planet, say Sydney to Frankfurt, can see 280–320ms, a gap wide enough that no amount of clever coding fully erases the disadvantage.

Packet loss compounds the problem. Routers and switches drop packets under congestion, and how a game recovers from that loss matters as much as raw ping does. Nearly every real-time multiplayer game moves its traffic over UDP (User Datagram Protocol) rather than TCP (Transmission Control Protocol), because TCP's built-in guarantee that every packet arrives, in order, forces a full retransmission wait whenever anything is lost. That guarantee is exactly wrong for a fast-twitch shooter, where a stale position update from 200 milliseconds ago is worse than useless. UDP simply lets packets go missing, and each game studio builds its own thin reliability layer on top for messages that genuinely cannot be skipped, like a kill confirmation or an inventory change.

The speed-of-light floor is not a metaphor. A Sydney-to-Frankfurt player physically cannot get below roughly 190ms of one-way delay no matter what hardware either side buys, because the fiber route between those cities is around 16,500 km and light in glass caps out near 200,000 km/s.

Client-server architecture

The dominant model for competitive online games is client-server, in which a central server, or a cluster of servers, holds the single authoritative copy of the game world. Every client sends its inputs — move forward, fire, jump — to that server. The server processes those inputs, advances the simulation, and broadcasts the resulting state back out to every connected client.

This design buys three things a peer-to-peer model cannot reliably offer.

Cheat resistance. Clients never trust each other, and increasingly they do not fully trust themselves either. The server independently re-simulates the world, so if a client's report of its own position implies it teleported 100 meters or fired through a wall, the server simply rejects the claim. Position spoofing, speed hacks, and aim assistance that tries to fake input data are all defeated at the source because the server, not the player's machine, decides what actually happened.

Convergence. Because every client is ultimately following one authoritative timeline, all players eventually see the same version of events, even if their local screens briefly diverge during high-latency moments.

Scale. Modern competitive titles run dedicated servers with no player-owned machine acting as host, deployed across cloud regions chosen to sit close to population centers. Fortnite runs its matchmaking and session infrastructure on Amazon GameLift, a fact Epic Games has discussed in its own engineering posts on scaling battle royale matches, and Valorant built an entirely custom backend, described in Riot's technology blog post Peeking into VALORANT's Netcode, rather than relying on a generic hosting layer.

None of this is free. Even a player with a pristine 20ms connection pays a latency tax on every single action: the input travels to the server (roughly 10ms), the server processes it (1–2ms on a well-optimized backend), and the confirmation travels back (another 10ms). That player sees the true result of their own button press about 22ms after pressing it, and that is the best case. For games where a 50-millisecond reaction window separates a win from a loss, that gap is not trivial, which is exactly why the rest of netcode engineering exists: to hide it.

Client-side prediction: hiding the delay

Carmack's original insight, refined over the following decades into the modern standard, was this: if the client already knows the rules of the game, it does not need to wait for the server to tell it what is about to happen. It can guess, act on that guess immediately, and quietly correct itself later if the guess was wrong.

The mechanism runs in a repeating loop:

1. The player presses "move forward."
2. The client immediately moves the local player character on screen. This is the prediction.
3. The same input is sent to the server, tagged with a sequence number.
4. The server processes that input roughly one round trip later, runs its own authoritative version of the physics, and sends back the result carrying the same sequence number.
5. The client compares its own prediction against the server's authoritative answer.
6. If they match, nothing visible happens. If they diverge — a collision the client's simplified prediction missed, a slope the client mis-simulated, a hit that altered velocity — the client snaps to the corrected position and replays every input given since that point from the new, corrected baseline.

This last step is called server reconciliation, and it is the quiet workhorse that keeps competitive shooters feeling instantaneous. At typical broadband latencies, the correction is small enough, and applied smoothly enough, that most players never consciously notice it happening dozens of times per minute. It only becomes visible — as a rubber-banding snap — when connection quality genuinely degrades.

What is client-side prediction in gaming?

Client-side prediction is a technique where your game locally simulates the outcome of your own input before the server confirms it, so movement and actions feel instant. If the server's authoritative result later disagrees with the local guess, the game silently corrects your position and replays subsequent inputs from the corrected point.

Entity interpolation: smooth remote players

Prediction covers your own character. Every other player on screen is a different problem entirely, because their positions only arrive as discrete snapshots from the server, typically 20 to 128 times per second depending on the title. Rendering those snapshots the instant they arrive produces visible stutter, since a player would appear to teleport in small jumps between each update rather than move smoothly.

Entity interpolation fixes this by deliberately rendering remote players slightly in the past, usually one or two update intervals behind the most recent data received. The client holds two known snapshots and smoothly blends the displayed position between them. If updates for a given enemy arrive 50 milliseconds apart and the game renders roughly 100 milliseconds behind the newest data, there are always two real data points to interpolate between, and the resulting motion looks fluid instead of jerky.

The tradeoff is unavoidable: every enemy you see on screen is showing you their past position, not where they actually are right now. By the time you register the position, aim, and pull the trigger, the target has likely already moved somewhere else on the server's live simulation. That gap between "where I saw them" and "where they actually are" is the exact problem lag compensation was built to solve.

Lag compensation: fair hits in an unfair medium

When you fire in Counter-Strike 2 or Valorant, your decision to pull the trigger is based on an interpolated, already-stale image of the enemy. Meanwhile the server holds the enemy's true, current position. Without correction, any player with real network delay would find fast-moving targets nearly impossible to hit, since they would always be aiming at a ghost of where the enemy used to be.

Lag compensation, formalized in Valve's own engineering documentation on Lag Compensation and first shipped seriously in the GoldSrc engine that powered the original Counter-Strike, solves this by rewinding the server's copy of the world to the exact moment the shooter actually pulled the trigger:

1. The server receives a shot event from client A, timestamped T.
2. The server knows client A's current latency, say 60 milliseconds.
3. The server rewinds every other player's position to T minus 60 milliseconds — the moment client A's screen actually displayed the scene they were aiming at.
4. The server evaluates the shot against those rewound positions.
5. If the shot connects, damage is applied to the target's current, un-rewound position and health total.

This is why players sometimes report dying "behind cover" in a killcam. The shooter saw a legitimate target and fired at a real moment in their own past. From the target's perspective, they had already moved to safety locally, yet the server's rewound evaluation still counted the hit as valid because it happened at the moment the shooter's screen actually showed. Valve's own developer notes describe this openly as a deliberate design tradeoff rather than a bug: the system is calibrated to favor the shooter, because punishing the shooter for the target's own network delay would feel worse in practice. Most implementations cap the rewind window, typically at 150–200 milliseconds, specifically to stop high-ping players from gaining an unfair advantage by effectively hitting targets at very old, favorable positions.

Why does lag compensation feel unfair sometimes?

Lag compensation always favors the shooter's view of history over the target's real-time position, because the alternative — punishing shooters for the target's own network delay — feels worse in testing. A player can therefore die to a shot fired at a position they had already left, which is correct behavior by design, not a bug.

Rollback netcode: the fighting game solution

For peer-to-peer games between two players, especially fighting games where a single frame of input delay can decide a match, rollback netcode — often called GGPO-style netcode after Tony Cannon's library — solves the latency problem in a fundamentally different way than server-authoritative shooters do.

Tony Cannon, the co-founder of the fighting game community site Shoryuken and later the Evolution Championship Series, built GGPO in 2006 specifically because he was frustrated with how poorly Street Fighter II: Hyper Fighting's Xbox 360 online mode performed. GGPO went on to power beloved online fighting game experiences including Skullgirls and Killer Instinct, and Cannon eventually released it as open-source software under the MIT license in October 2019, freeing developers from any licensing fee to use it.

Both players in a rollback game run a synchronized, deterministic simulation of the exact same match. Each player's input is transmitted to the other with a sequence number attached. The old approach, called delay-based netcode, simply buffered every player's inputs by a fixed number of frames, usually three to seven, so both machines processed inputs in perfect lockstep. That kept the simulations synchronized but added constant, unavoidable input lag to every single button press, which is why older online fighting games often felt sluggish even on a strong connection.

Rollback netcode replaces that constant delay with an occasional, mostly invisible correction:

1. When your own input hasn't arrived yet on your opponent's machine for the current frame, that machine guesses — it assumes you pressed the same buttons as the previous frame.
2. It simulates forward using that guess, without waiting.
3. When your real input eventually arrives, possibly late, the machine rolls back the simulation to the last point both inputs were actually known.
4. It replays every frame since then using the correct inputs instead of the guess.
5. The corrected result is displayed to the player, usually in a single frame or two.

On a strong connection, the real input typically arrives before it is even needed, so no rollback occurs at all. On a moderately laggy connection, small rollbacks happen constantly but stay invisible because they resolve within a frame or two. Only on a genuinely bad connection do players see visible "hitches," where a character appears to snap backward to a corrected position mid-animation.

Guilty Gear Strive, Street Fighter 6, Mortal Kombat 1, and effectively every current top-tier competitive fighting game now ships with rollback netcode, and the difference in playability compared to delay-based netcode at any meaningful latency is substantial enough that its absence is now treated as a launch-day controversy by the fighting game community.

Server tickrate and its impact

Tickrate measures how many times per second a server processes accumulated inputs and pushes a state update. Counter-Strike 2 runs its servers at 64 Hz, and rather than simply raising that number, Valve introduced a sub-tick system that timestamps each individual action — a shot, a jump, a grenade throw — at the precise moment it happened between ticks, instead of snapping it to the next full tick boundary. Valorant took the more traditional route and simply built its infrastructure around a genuinely uniform 128 Hz tick, a decision Riot documented in detail in its post VALORANT's 128-Tick Servers, where the team describes server frame processing times that started around 50ms per frame in early development and were eventually optimized down to sub-2ms through code, hardware, and operating-system-level tuning.

The math behind why tickrate matters is straightforward. At 64 Hz, each tick spans about 15.6 milliseconds, meaning a shot fired just after the server has already moved past the relevant tick can be evaluated against a position that is up to 15.6ms stale. At 128 Hz, that window shrinks to roughly 7.8 milliseconds. Riot's own engineers demonstrated this concretely by comparing hitboxes on 64-tick versus 128-tick servers and found that raising the tickrate shaved off roughly 40 milliseconds, about 28 percent, of what the fighting game and shooter communities call peeker's advantage — the edge a player gets by being the one who chooses when to round a corner into an opponent's line of sight, since their client has already rendered the encounter locally before the defender's client has caught up.

Higher tickrate is not free. It multiplies CPU load and outbound bandwidth on the server roughly in proportion to the tick increase, which is exactly why many studios reserve their highest tickrate for ranked or competitive matchmaking queues while running cheaper, lower-tickrate servers for casual modes where split-second precision matters less to the player base.

Riot's engineers measured that moving VALORANT from a 64-tick to a 128-tick server cut roughly 40 milliseconds, or about 28 percent, off "peeker's advantage" — the edge a player gets from being the one who decides when to round a corner into a gunfight.

Hit registration and the hitbox problem

Netcode does not operate in isolation. Everything described so far — prediction, interpolation, lag compensation, tickrate — ultimately feeds into a single moment-of-truth calculation: did the bullet, the sword swing, or the punch actually connect? That calculation depends on hitboxes, the simplified geometric shapes (usually boxes, capsules, or spheres) that stand in for a character's actual visual model during collision checks, because testing collision against a fully detailed 3D mesh dozens of times per second, for every player, every tick, would be far too expensive computationally. As explored in more depth in How Hitboxes Work In Video Games, these simplified shapes rarely align perfectly with what a player visually sees on screen, which is part of why a shot that looks like it should have missed sometimes registers as a hit, and vice versa.

Hitboxes and netcode interact in a way that compounds uncertainty. A hitbox has to be positioned somewhere in time, and that "somewhere" is itself a product of interpolation and lag compensation choices. A generous hitbox combined with an aggressive lag-compensation rewind window can make a game feel exceptionally responsive to shooters, at the direct cost of making it feel unfair to targets, which is precisely the tension covered in Valve's own design notes and unpacked further in Why Lag Compensation Is Controversial. There is no configuration of these systems that is simultaneously perfectly fair to both parties in a duel; every competitive shooter is making an explicit, documented tradeoff, usually in favor of the shooter, because testing has shown that players tolerate "I died around a corner" far better than they tolerate "I shot first and still lost."

Anti-cheat, server authority, and why cheating persists anyway

Client-server architecture is often described as making cheating impossible, but that overstates the case. What it actually does is push cheating into narrower categories. A client cannot lie about its position, its health, or whether a bullet connected, because the server independently verifies all of that. What a client can still do is see more information than a human normally could, or act on legitimate information faster and more precisely than human reflexes allow. This is the category of cheat that dominates modern shooters: wallhacks that expose enemy positions rendered by the client's own graphics pipeline, or aimbots that translate perfectly legal mouse input with inhuman precision.

Valve's own anti-cheat system, VAC (Valve Anti-Cheat), first shipped alongside the original Counter-Strike in 2002 and works by scanning for known cheat software signatures on the client rather than trying to detect suspicious behavior on the server alone. More recent anti-cheat systems have moved deeper into the operating system to close this gap: Riot's Vanguard, which protects Valorant, runs a kernel-mode driver that starts at boot and monitors low-level system activity for the kind of memory manipulation that user-space cheats rely on. That approach is more effective, and also more controversial, because it requires players to grant a piece of anti-cheat software the deepest level of system access a Windows machine allows, a tradeoff privacy-focused players and security researchers have publicly debated since Vanguard's 2020 launch.

None of this eliminates cheating; it only raises the technical cost of building and distributing a working cheat. The arms race between anti-cheat engineering and cheat developers is now itself a permanent, resourced part of competitive game development, running in parallel with the netcode work described above rather than as an afterthought bolted onto a finished game.

What people get wrong about lag and connection quality

The single most common misconception among players is treating "ping" as the entire story. Two connections with an identical 40ms average ping can feel completely different if one has stable, consistent timing and the other has high jitter — variance in how far apart packets arrive. A game receiving packets at a steady 40ms every time can interpolate smoothly. A game receiving packets that oscillate between 15ms and 90ms has to either guess wrong constantly or add a jitter buffer, deliberately holding incoming data for a fixed window before processing it to smooth out the variance, at the direct cost of adding that buffer window as consistent additional latency. A connection with worse average ping but low jitter frequently plays better than one with better average ping but high jitter.

A second common misconception is that a fast home internet connection guarantees a fast connection to any given game server. Bandwidth, the amount of data a connection can carry per second, and latency, the delay before any of that data arrives, are almost entirely independent properties. A gigabit fiber connection to a server on the wrong continent still carries the same speed-of-light floor as a modest connection to a nearby server. This is exactly why services like Riot Direct exist: rather than relying on whatever route a player's ISP happens to choose, Riot Games operates dedicated network infrastructure that Riot itself has publicly described as effectively "their own ISP" for Valorant traffic, deliberately routing player connections along the shortest, most direct physical path to the nearest game server rather than trusting default internet routing to find it.

A third, more subtle misconception is assuming that "server-side" always means "fairer." Server authority prevents outright cheating, but the specific rules a studio chooses for lag compensation, rewind windows, and hit registration are design decisions with real winners and losers, not neutral physics. Two studios can build technically correct server-authoritative netcode and still produce games that feel meaningfully different to play, because the tuning choices inside that architecture, not the architecture itself, determine how "fair" any individual duel feels.

The takeaway

Every technique covered here — prediction, interpolation, lag compensation, rollback, tickrate tuning — exists to manage the same unmovable constraint: light takes a measurable, physical amount of time to cross a distance, and no software update will ever change that. What separates a game that feels crisp from one that feels sluggish or unfair is not whether a studio has "solved" latency, because no one ever will. It is how honestly the studio's engineering choices about prediction, rewinding, and tickrate are tuned to the specific genre they are serving, and how transparently those tradeoffs are communicated to players who are, whether they realize it or not, playing against the speed of light itself on every single shot.

---

Read next:

• Why Lag Compensation Is Controversial
• How Hitboxes Work In Video Games
• How Matchmaking Ratings Work

FAQ

Q: What is the difference between ping and latency? A: They describe the same measurement: the round-trip time for a packet to travel from your machine to the game server and back, expressed in milliseconds. "Ping" borrows its name from the network diagnostic tool that sends an ICMP echo request and times the response, but in gaming the term is used interchangeably with round-trip latency.

Q: Can better technology ever eliminate lag entirely? A: No. The speed of light in fiber-optic cable, roughly 200,000 km/s due to the glass's refractive index, sets a hard physical floor. For two players separated by 5,000 km, the minimum possible round trip is around 50 milliseconds before any router or switch is involved, and real-world routing typically adds tens of milliseconds more. The industry can shorten and straighten routes, as Riot Direct does, but it cannot break physics.

Q: Why does Valorant feel more precise than many other shooters? A: Riot invested heavily in dedicated infrastructure: a genuinely uniform 128 Hz server tickrate, a kernel-mode anti-cheat driver in Vanguard, sub-2-millisecond per-tick server compute time after extensive optimization, and a purpose-built network layer called Riot Direct that routes player traffic along the shortest path to the nearest server. The perceived precision comes from several compounding engineering decisions rather than any single feature.

Q: What is jitter, and why does it matter more than average ping sometimes? A: Jitter is the variance in how far apart packets arrive, as opposed to ping, which is just the average delay. A connection with a low average ping but wildly inconsistent packet timing can feel worse than a connection with a slightly higher but stable ping, because games rely on predictable packet timing to interpolate movement smoothly. Games use jitter buffers to absorb this variance, at the cost of adding the buffer window as extra, consistent latency.

Q: What is a killcam, and how does it demonstrate lag compensation? A: A killcam replays the moment a player died from the killer's point of view, reconstructed from server-side data. It is a direct, visible demonstration of lag compensation: the killer's shot was evaluated against your rewound position at the exact moment their screen displayed you, which can look different from what your own local screen showed you at that instant. Many "I was already behind cover" killcam moments are technically correct under the server's rules, since the rewound position used for the hit calculation was still exposed even after your local client had already moved you to safety.

Q: Why do fighting games use rollback netcode instead of the lag compensation shooters use? A: Fighting games are usually peer-to-peer between exactly two players with no dedicated server, and they require frame-perfect timing that even a few milliseconds of added delay noticeably disrupts. Rollback netcode lets both machines simulate forward optimistically without adding constant input delay, correcting only when a guess about the opponent's input turns out wrong, which suits a two-player, frame-sensitive genre better than a many-player, server-authoritative shooter model.

Q: Does having a faster internet connection guarantee lower ping in games? A: Not necessarily. Bandwidth, how much data a connection can carry per second, and latency, how long any single piece of data takes to arrive, are largely independent. A high-bandwidth connection routed through a poor path or to a distant server can still have high latency, which is why game companies like Riot build dedicated routing infrastructure rather than relying on bandwidth alone to fix responsiveness.

Q: How does tickrate affect competitive shooters specifically? A: Tickrate determines how often the server processes input and updates the world, which sets the maximum precision of hit registration. At 64 Hz, each tick spans about 15.6 milliseconds, so a shot can be evaluated against a position up to that much out of date; at 128 Hz that window shrinks to roughly 7.8 milliseconds. Riot's own engineering team measured that doubling tickrate from 64 to 128 Hz cut peeker's advantage by roughly 40 milliseconds in VALORANT.

Q: Can anti-cheat software ever fully stop cheating? A: No system has eliminated cheating outright. Server authority prevents clients from lying about game state, which stops position spoofing and speed hacks, but it cannot stop a client from acting on information it legitimately receives, such as rendered wallhack data, with inhuman precision. Kernel-level anti-cheat like Riot's Vanguard raises the technical difficulty of building undetected cheats but has not ended the arms race between cheat developers and anti-cheat engineers.