Netcode
Netcode is the collection of networking techniques a multiplayer game uses to keep every player's view of the match consistent despite the delay between them. It covers what the server sends and how often, what the client predicts in between, and how disagreements get resolved. It is the layer players feel without seeing.
,
What Is Netcode Made Of?
Most of what players call bad netcode is a symptom, and the cause usually sits in a different layer than the one being blamed. This page covers what netcode is made of, what it trades away, and how to tell which layer is at fault.
Netcode is the networking code that keeps a multiplayer match consistent across machines that are milliseconds apart. It is not one system. It breaks 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 each player receives, and how often, the update rate.
Authority: which machine has the final say, usually an authoritative server.
Hosting model: where that simulation runs.
Sync model: how machines stay in agreement.
Latency hiding: client-side prediction, interpolation and lag compensation.
No part of that stack is a complete answer. Each one decides something and leaves the rest to its neighbours. A high tick rate does nothing for a long route. Prediction does nothing for a dropped packet.
In Practices - Insights from Edgegap's Blog
Article's key insights
Latency has a floor, and everything else stacks on top of it: The physical travel time between two machines is the minimum delay any online game can have. Routing, tick rate, update rate and processing all add to it. Netcode cannot remove that delay. It can only decide where players feel it.
The shortest path is rarely the fastest: A direct peer-to-peer connection looks like the shortest route between two players, but packets still cross both players' ISPs and whatever routes those networks choose. A well-placed server between them is often both faster and fairer.
Lag compensation moves the cost, it doesn't erase it: Lag compensation rewinds the server so a high-ping player's shot counts, which means the target can be hit after reaching cover. The only real fix is keeping ping gaps small, which makes it a matchmaking and server placement problem as much as a netcode one.
Tick rate is a time budget: A server's tick rate sets how many milliseconds it has to simulate each step of the game. Higher rates cut delay and sharpen hit registration, but cost more CPU and bandwidth. A server that overruns its budget stutters for everyone in the match.
Two separate choices, not one: Where the game runs (peer-to-peer, relay or dedicated server) and how state is shared (lockstep, rollback or state replication) are independent decisions. Any sync model can run on any hosting model.
How Does Netcode Hide Latency Without Removing It?
Data moves through copper and fibre at a finite speed, so delay can never be lower than the travel time between two machines. Netcode cannot change that. What it does is choose where the delay shows up.
Each latency-hiding technique has a price:
Prediction lets the client act on its own input at once, so the game feels instant. When the server disagrees, the client is corrected.
Interpolation draws other players slightly in the past so their movement looks smooth. The cost is that you see them a little late.
Lag compensation rewinds the server to what the shooter saw, so a high-ping player's shot counts. In his 2001 paper, Yahn Bernier, then a developer at Valve, described the side effect: 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'."
Every technique trades one artifact for another. All of them work on the delay they are given.
That delay is set by more than distance, and the game developer controls none of the rest. In 2015, Riot Games' engineering team explained that backbone providers and ISPs "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, and routing decides how far above it you land. The ISP makes the routing call, not the developer. What a developer does choose is where the server sits, which decides which routes are on offer at all.
Who Hosts the Game Logic, and How Does It Stay in Sync?
These are two separate choices, and any sync model can run on any hosting model.
Who hosts the game logic (where the simulation runs):
Peer-to-peer: one player's machine hosts. That player has zero network delay, and everyone else depends on the host's connection. See peer-to-peer.
Relay: a server forwards packets between players. It does not run the simulation or validate anything. See relay server.
Dedicated server: the simulation runs on a machine the developer controls. That removes host advantage and gives every player a neutral connection point. The trade-off is cost and coverage, since servers must be paid for and must sit close enough to every player. See dedicated server.
How machines stay in agreement (the sync model):
Lockstep: machines exchange only inputs, and nobody moves until everyone's inputs have arrived. Input delay equals the latency, and the simulation must be deterministic. Common in strategy games.
Rollback: each machine predicts the others' inputs and simulates at once. When a real input differs, the game rewinds and re-simulates. Controls feel instant, at the cost of visual corrections and extra CPU. Standard in fighting games. See rollback netcode.
State replication: the server sends snapshots and clients hide the delay with prediction, interpolation and lag compensation. Standard for shooters. See state replication.
Input delay and rollback are the two answers to the same question: what should a player's screen do while another player's input is still on its way? Edgegap's comparison of input delay vs rollback covers when each one fits.
Hosting decides who absorbs the delay. Sync decides how it looks. Neither decides how large it is.
What Do Players Mean When They Say "Bad Netcode"?
Players report symptoms. They rarely name a layer. The same complaint can come from several causes, and each cause has a different fix.
What players report | The layer usually behind it | Term |
|---|---|---|
A shot lands after the target reached cover | Lag compensation working across a large ping gap | |
Teleporting and snapping back | The server correcting a client that drifted | |
The whole match stutters | The server missing its tick budget | |
Characters freeze mid-move | Dropped packets | |
One hit does more damage than a bullet should | Several shots landing in one update |
The last row is the "super bullet" that Battle(non)sense described in his 2017 "Netcode 101" video. At 10 updates per second, a gun firing 750 rounds per minute or faster puts two or more bullets into a single update.
The first row comes down to delay, and to how unevenly it falls across the players in a match. No netcode technique controls that. Server placement is the main lever a developer holds.
Edgegap tested the case that should favour a direct connection most. In a 2020 analysis of 122,000 peer-to-peer matches from a 1v1 console game, routing each match through a server placed at the best available location between the two players lowered average round-trip time by 23% in 70% of matches (1v1 case study). In the other 30%, it was no faster than a direct connection. Edgegap's netcode fundamentals article covers the full reasoning.
A word from our sponsor (ourselves!)
Most lag comes from distance, not from code. Edgegap's Edge Cloud is a distributed network with up to 615+ locations available on demand, so each match runs at the best available location for its players. Independent replays of live studio traffic measured a 58% drop in average round-trip time compared with public cloud.
Where Does Your Engine's Netcode Fit?
An engine's networking layer is the interface a developer builds against: Unity's Netcode for GameObjects, Mirror, Fish-Net, Unreal's built-in networking, Godot's multiplayer API. Each one implements part of the stack, such as a transport, a way to replicate state, and in some cases prediction.
None of them decides where the authoritative simulation runs, or how close that is to each player. Those two choices sit above the library, and they set the delay the library then has to hide.
Edgegap's Take (just our opinion, take it with a grain of salt!)
Netcode Hides Latency. Placement Decides How Much There Is to Hide.
When a playtester says the netcode is bad, the tempting move is to open the prediction code. Check four things first, in this order: the ping gap between the players in that match, packet loss on their connections, whether the server held its tick budget under load, and what the desync logs say.
Only the last check points squarely at code you wrote. The first three are about how much delay there is and how evenly it falls across players. Netcode can hide delay. It has no say in how much of it there is to hide.
Tuning prediction against a long route treats the symptom. Often the cause is where the server is hosted. A dedicated server started close to the players in a match, on a network with enough locations to choose from, shortens the delay itself. Netcode cannot do that.
,
