Netcode is the part of a game’s software that helps separate machines participate in the same match. The word is a broad label rather than one algorithm: it includes sending information, synchronising simulations and deciding what to do when messages arrive late or disagree.
It is also an easy thing to blame. A missed shot, a sudden jump in position and a delayed button response can feel similar while having different causes. Understanding the main techniques makes the diagnosis more useful than simply declaring that a game’s netcode is bad.
Who decides what really happened?
In a server-authoritative game, clients do not have the final say over the shared result. Epic’s networking overview describes an authoritative server world alongside the versions displayed by connected clients.
A dedicated server has no local player. A listen server also hosts a player on the machine acting as the server. Both are client-server arrangements; hosting a match on a player’s computer does not automatically remove authority from the design.
Keep this question separate from how messages travel. Peer-to-peer describes communication between participants, not a universal guarantee that no host has authority or that a game needs no matchmaking, relays or supporting infrastructure.
Ticks, updates and frames are not interchangeable
A simulation tick advances game state. A network update communicates information. A rendered frame produces an image. They can have different schedules. Offline games also advance simulations in steps; they do not become mathematically continuous because there is no server.
At 60 ticks per second, the nominal interval is about 16.67 milliseconds. That arithmetic does not establish the total time required for your action to reach another player’s screen. Processing, transmission, buffering and rendering can all contribute.
A higher tick rate can help particular designs, but the headline rate alone does not certify better hit registration. What the game records, timestamps and validates matters too.
Prediction makes local movement responsive
Waiting for a server response before showing every movement would make controls feel sluggish. In Riot’s account of VALORANT’s netcode, the client predicts the result of local input while the server remains authoritative. If their simulations disagree, the server corrects the client.
That reconciliation can become visible as a jump or rubber-banding. It is a mechanism for restoring agreement, but frequent corrections can still indicate a problem. A recording of a jump alone does not reveal whether the cause was lost data, a processing hitch or a simulation defect.
Interpolation makes remote movement smoother
Updates do not necessarily arrive at regular intervals. Glenn Fiedler’s snapshot interpolation demonstration shows how a receiver can buffer snapshots and draw positions between known states. This trades some delay for smoother presentation.
Interpolation is therefore different from extrapolation. The first estimates between available samples; the second projects beyond the newest known state. Neither should be described simply as the computer knowing where an opponent is right now.
Rollback corrects a predicted past
Rollback allows a game to continue before all remote inputs arrive. If a prediction proves wrong, the game restores an earlier state and simulates forward with the corrected inputs. The GGPO project is a well-known implementation of this approach.
Its developer guide requires deterministic simulation, a state that can be saved and restored, and the ability to advance simulation without rendering every intermediate step. It also documents a prediction limit: if missing information exceeds that limit, the game should not keep advancing blindly.
Rollback is not a promise of zero delay or perfect recovery. GGPO supports deliberate input delay alongside prediction, and incorrect predictions can produce visible discontinuities. The implementation has to balance responsiveness, correction length and the game’s visual feedback.
Rollback and servers can work together
It is misleading to present rollback and client-server networking as mutually exclusive choices. In its explanation of 2XKO’s online design, Riot describes using both, with the server providing authority for inputs, state and time.
That article also describes intentional input delay in both offline and online play. The example matters because it defeats two common shortcuts: rollback need not mean peer-to-peer, and a rollback game need not eliminate every intentionally delayed frame.
Why a hit can arrive after you reach cover
Players see information from different moments. Riot’s VALORANT explanation describes checking a shot against an earlier world state corresponding to what the shooter saw. It also stresses limiting how far the server will rewind.
This helps explain why a defender can see damage after apparently reaching safety. It does not prove that every such death was correct, or that lag compensation is the only possible cause. Judging one incident requires the game’s rules and timing evidence, not just the final image on one screen.
What to record when a match feels wrong
Start with the game’s own diagnostics. Note frame time, reported ping, packet-loss indicators, the server region and whether the problem occurs offline. Ping commonly reports a round-trip measurement; it is not automatically the one-way travel time of every gameplay message.
Compare a quiet connection with one carrying heavy traffic, and use a wired-network comparison where practical. A high download-speed result alone does not establish low delay, consistent delivery or adequate conditions throughout a match. Bandwidth requirements also depend on the game’s design.
If the same delayed response occurs offline, investigate the local input-to-screen path as well. If a problem occurs only in one match, preserve its time and available match identifier for a useful bug report.
Good netcode manages disagreement under constraints. It cannot remove distance or make every device operate at the same instant, but its choices can make those differences much less disruptive.
