This is a primer on the building blocks of online multiplayer netcode. Throughout, we've linked glossary definitions for each term, alongside Backend Deep Dive articles that show how each concept has been applied in well-known multiplayer games.

What Is Netcode?

Netcode is the networking code that keeps a multiplayer match consistent across machines that are milliseconds apart. It doesn't work alone. Netcode is one layer of a wider ecosystem, alongside server hosting, orchestration and matchmaking, that together deliver an online multiplayer experience. Our Call of Duty netcode article shows how those layers interact in a live game.

Netcode itself breaks down into seven parts:

• Transport: the protocol that carries packets, almost always UDP for real-time games.

• Simulation loop: how often the server advances the game world (the tick rate).

• Replication: what data gets sent to each player, and how often (the update rate).

• Authority: which machine has the final say on what happened, usually an authoritative server.

• Hosting model: where the authoritative simulation runs, whether on a player's machine (peer-to-peer), behind a relay, or on a dedicated server.

• Sync model: how machines stay in agreement, through lockstep, rollback or state replication.

• Latency hiding: client-side prediction, server reconciliation, entity interpolation and lag compensation, the techniques that make delay invisible to players.

Where Client/Server Netcode Came From

Most modern shooters trace their netcode back to one game. The original Quake (1996) used a pure client/server design: clients sent their inputs to the server, then waited for the server to tell them what happened. Every client was a terminal displaying the server's world.

On a local network, that worked. Over the internet, it did not.

John Carmack, then lead programmer at id Software, wrote in his August 1996 development log that he "was working with the wrong basic assumptions for doing a good internet game." The original design "was targeted at <200ms connection latencies," while modem players were seeing "300+ ms latencies, minimum." With pure client/server, every keypress waited a full round trip before anything moved on screen.

His fix for QuakeWorld established the model still used today. The client would now "guess at the results of the users movement until the authoritative response from the server comes through." The server stayed authoritative. The client predicted.

In sync-model terms (covered below), QuakeWorld used state replication: the server sends the state of the world, and each client predicts its own movement until the next update arrives. It is not lockstep, where every machine waits for everyone else's inputs before moving forward.

That pairing, an authoritative server plus client-side prediction, became the foundation others built on. TRIBES (1998) added synchronized 32 ms ticks, interpolation of other players, and inputs sent on three consecutive packets. Twenty years later, Overwatch still used a sliding window of inputs that its developers traced back to QuakeWorld.

What Is Ping, and How Is It Different From Lag?

Ping is a measurement. Your machine sends a small message to another machine, which replies, and the time between sending and receiving is the round-trip time (RTT). For a beginner-friendly primer, see Edgegap's guide on what latency is in gaming.

Lag is the consequence. It is the gap between what you see on your screen and what the server, and every other player, sees on theirs.

Lag is also more than a feeling. In Edgegap's latency report, 50% of gamers named lag as their #1 frustration with online games, and 34% said they quit a game completely because of it.

There is a floor that no netcode can break. Data moves through copper and fiber at a finite speed, so lag can never be lower than the travel time between two machines. Everything else adds to that floor.

The biggest addition is usually routing. Packets never travel in a straight line. They pass through a chain of routers owned by different networks, and each hop adds time. That is why distributed cloud infrastructure starts with where the server physically sits.

This is also where intuition goes wrong. In a two-player match, a direct peer-to-peer connection looks like the shortest possible path. No server in the middle, just one player to the other.

In practice, "direct" still means leaving one player's home network, crossing their ISP, crossing the other player's ISP, and arriving on a consumer connection that may be on Wi-Fi. Add more players and one of them has to host, which gives the host zero delay and everyone else a different one. A neutral server placed well between all players removes the host's advantage and often shortens the real route. The next section shows why.

Why Doesn't Distance Alone Predict Ping?

Two players 50 km apart can still have a bad connection to each other. What matters is the route their packets actually take.

Riot Games' engineering team documented this in 2015 while building its own game network. Backbone providers and ISPs, they explained, "prioritize a cheaper route over a faster route." On one San Francisco to Portland connection, "a direct trip may have taken 14ms, but the less efficient route takes a full 70ms."

Distance sets the floor. Routing decides how far above it you land.

The same logic applies to choosing a server location. Being close to one player is not the goal. The goal is the spot that gives every player in the match the best, and most even, connection.

Edgegap's 1v1 fighting game case study with a top-5 publisher measured this. By deploying each match's server on demand at the best available location, instead of using a fixed set of public cloud regions, the latency gap between opponents narrowed from 46.5 ms to 33 ms, a 28% improvement in fairness. 91% of players saw lower latency.

That is the reasoning behind more locations: the more places a server can start, the more likely one sits on a short, even route for everyone. Edgegap's network now spans 615+ locations worldwide for that reason.

Why Does One High-Ping Player Affect Everyone?

In a shooter, a high-ping player aims at where they saw the target, which is already in the past. If the server only checked hits against the present, that player would almost never land a shot.

Lag compensation solves this by rewinding. When a shot arrives, the server moves every other player back to where they were when the shooter fired, then checks the hit there.

It works. It also has a cost. Yahn Bernier, then a developer at Valve, described it in his 2001 paper on lag compensation: when "a highly lagged player shoots at a less lagged player and scores a hit, it can appear to the less lagged player that the lagged player has somehow 'shot around a corner'."

The low-ping player reached cover on their screen. The server, rewound, says they didn't.

Studios tune this trade-off differently. APEX Legends deliberately spreads the "nonsense" equally between high- and low-ping players, accepting that players at 300 ms may be shot behind cover. VALORANT estimated roughly a 141 ms head start for players peeking around corners, and built its tick rate, buffering and routing around shrinking it. Both show up as desync and rubberbanding when the gaps grow large.

No lag compensation setting fixes a large ping gap. Keeping the gap small does, which is why latency belongs in matchmaking. Edgegap's matchmaker includes latency rules for this, and our guide on improving latency through matchmaking covers the approach, along with fairness vs latency in eSports.

What Are Tick Rate and Update Rate?

Two clocks run on every game server, and they are often confused.

• Tick rate (or simulation rate) is how many times per second the server processes inputs and advances the game world.

• Update rate (or send rate) is how many times per second the server sends results to clients.

They are often equal, but many engines decouple them.

Each tick is a fixed time budget. The conversion is simple: divide 1,000 by the rate in hertz.

The tick interval adds delay on top of network latency. On average, an input waits about half a tick before the server processes it, so moving from 64 Hz to 128 Hz cuts that wait from roughly 7.8 ms to 3.9 ms.

A server that can't finish its work inside the budget falls behind. In APEX Legends, a server that misses its 50 ms window makes the whole match stutter while physics, animation and replication catch up. Players see rubberbanding, teleporting and rejected hits.

Low update rates cause a stranger artifact. Chris, the independent analyst behind the Battle(non)sense YouTube channel, explained the "super bullet" in his 2017 "Netcode 101" video. At 10 updates per second, 100 ms separates each packet, the same gap as between two bullets from a gun firing 600 rounds per minute. A gun firing 750 RPM or faster puts two or more bullets into one update, so the victim takes what looks like a single hit dealing more damage than one bullet can.

Higher tick rates reduce delay and sharpen hit registration. They also cost more CPU per match and, when the update rate rises with them, more bandwidth. For the full trade-off, see Game Server Tick Rate Explained.

Where Does the Game Run? Hosting Models

The first structural choice is where the authoritative simulation lives. There are three broad options.

Peer-to-peer (player-hosted). One player's machine acts as the host, or peers connect to each other directly. There is no server bill. In exchange:

• The host plays with zero network delay, while everyone else depends on the host's home upload speed.

• When the host leaves, the session ends or pauses while another player takes over. See Edgegap's guide on host migration in peer-to-peer or relay-based games.

• Direct connections expose each player's IP address to the others in the session.

• Authority sits on a player's machine, so that player can alter game state.

Relay. A relay server forwards packets between peers. It hides players' IP addresses and helps connections through restrictive home networks. It does not run the simulation or validate anything, so the authority questions of peer-to-peer remain.

Dedicated server. The simulation runs on a machine the developer controls. Clients send inputs, and the server decides what happened. That removes host advantage and host migration, and gives a neutral connection point for every player. The trade-off is cost and coverage: servers must be paid for, and they must sit close enough to every player to keep ping reasonable.

Many games mix models. Destiny 2 has combined peer-to-peer with authoritative servers. Orchestration platforms such as Edgegap's game server hosting exist to start dedicated servers on demand near each match, instead of keeping fleets idle in a few regions. For how the main netcode libraries support each model, see 7 netcode integrations.

How Is Game State Shared? Sync Models

The second choice is how machines stay in agreement. This is independent of the hosting model: each approach below can run peer-to-peer or through a dedicated server.

Lockstep (input delay). Machines exchange only inputs, and every machine runs the same deterministic simulation. Nobody moves forward until everyone's inputs for that step have arrived. It uses very little bandwidth, and every screen shows exactly the same thing. The costs are that input delay equals the latency, and the simulation must be perfectly deterministic across different hardware. It is common in strategy games.

Rollback. Each machine predicts the other players' inputs and simulates immediately. When the real input arrives and differs, the game rewinds to that frame and re-simulates forward. Controls feel instant, at the cost of occasional visual corrections and extra CPU. It is the standard in fighting games, and it works on dedicated servers too: Rivals of Aether 2 pairs rollback netcode with dedicated servers on Edgegap. Edgegap's comparison of input delay vs rollback and its guide to rollback netcode cover both in depth.

State replication. The server sends snapshots of the world, and clients use four techniques to hide the delay:

• Client-side prediction: the client applies its own inputs immediately, the QuakeWorld idea.

• Server reconciliation: when the server's answer arrives, the client corrects its prediction and replays any inputs the server hasn't processed yet.

• Entity interpolation: other players are drawn slightly in the past, blended smoothly between two received snapshots.

• Lag compensation: the server rewinds to judge hits, as described above.

This is the standard for shooters, from TRIBES to VALORANT. Every technique trades one artifact for another: prediction creates corrections, interpolation adds delay, and lag compensation creates the shot-behind-cover moment.

What Does Packet Loss Do to a Game?

The internet does not guarantee delivery. Packets get dropped by Wi-Fi interference, congested links, faulty hardware and overloaded routers. As our APEX Legends deep dive notes, packet loss isn't always the developer's fault.

This is why real-time games use UDP rather than TCP. TCP guarantees every packet arrives in order, so when one goes missing, everything behind it waits until it is resent. For a game, that means characters freezing mid-movement while the connection recovers. UDP lets the game decide what matters: a lost position update is simply replaced by the next one.

Loss also hurts more at low update rates, since each missing packet leaves a bigger hole. Games defend against it with redundancy. TRIBES sent each player input on three consecutive packets. Overwatch bundled every unacknowledged input into each packet, so the next one filled any gap before the server simulated.

How the Pieces Fit Together

Every concept above manages one number: the time between a player acting and every other player seeing it.

Physical distance and routing set the starting point. Tick rate and update rate add their own delay. The hosting model decides who carries the difference, and the sync model decides what that looks like on screen.

That is why the same questions come up in nearly every game in our deep dives. The answers change from game to game. The questions don't.

Many of those answers come down to where and when servers run. Automated hybrid orchestration across a distributed network, combining bare metal for steady traffic with cloud capacity for spikes, lets the same approach serve very different games, from large MMOs to lightweight mobile games running several match rooms per server. To see how it works, learn more about Edgegap's game server orchestration.

Sources

This article is based on and cites the works listed in Sources. All rights in the original content are owned by their respective owners.

• John Carmack, then lead programmer at id Software, development log (.plan), August 2, 1996.

• Riot Games engineering team, Fixing the Internet for Real-Time Applications: Part I, Riot Games Technology (2015).

• Yahn W. Bernier, then a developer at Valve, Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (2001).

• Chris, Battle(non)sense, Netcode 101 - What You Need To Know, YouTube (August 29, 2017).

• Edgegap, 1v1 Fighting Game Case Study.

• Edgegap, Latency Report.