Guide

Game networking and multiplayer netcode explained: prediction, lag, and authority

Multiplayer netcode is the software that keeps dozens of players seeing the same match while their packets cross continents at the speed of light — which is still slow enough to feel broken if you get the design wrong. A shooter where your bullets register a second late, or a platformer where you rubber-band off a ledge, usually means the networking layer fought the game loop instead of hiding latency. This guide covers topology (client-server vs peer-to-peer), who is allowed to change game state, tick rates and snapshots, client-side prediction and server reconciliation, rendering other players smoothly, lag compensation for hit detection, and the transport choices that matter in browser games.

Why networking is the hard part

Single-player games run one simulation on one machine. Multiplayer games run related simulations on many machines that only exchange messages. Light travels about 200 km per millisecond in fiber — a player in Tokyo talking to a server in Virginia might see 150–200 ms round-trip time before you add routing, Wi-Fi, or mobile tower hops. At 60 FPS each frame is ~16.7 ms; waiting two frames for server confirmation before moving your character feels sluggish. Netcode exists to make 150 ms feel like 0 ms for your inputs while still being fair to everyone else.

The core tension: responsiveness vs correctness. Let every client decide outcomes locally and the game feels instant but cheats and desync multiply. Make the server approve every action before anything moves and the game is fair but laggy. Production netcode lives in the middle — predict locally, validate remotely, correct gracefully when wrong.

Topology: client-server vs peer-to-peer

Dedicated server (client-server) is the default for competitive online games. One authoritative machine (or a cluster) runs the simulation; clients send inputs and render snapshots. Cheaters cannot silently give themselves infinite health if health only changes on the server. Cost: you pay for hosting and matchmaking infrastructure.

Listen server is a hybrid — one player’s machine hosts the match. Cheap for co-op indies, but the host has lower latency and quitting host ends the session. Fighting games and small-party co-op still use this pattern.

Peer-to-peer (P2P) connects players directly without a dedicated simulation host. Good for turn-based or lockstep RTS where every peer advances the same deterministic tick when all inputs arrive. Bad when you need continuous physics and anti-cheat — any peer can lie. Modern consoles often use P2P with relay fallback when NAT traversal fails.

Who owns the truth?

Server authority means only the server applies damage, scores goals, and resolves collisions that matter. Clients may animate optimistically, but the server snapshot wins on conflict. Client authority (rare in competitive games) trusts the client for some state — acceptable for cosmetic emotes, dangerous for inventory. Most action games are server-authoritative for gameplay and client-authoritative only for camera and local UI.

Tick rate, snapshots, and bandwidth

The server does not send a full world dump every frame. It runs at a fixed simulation tick rate — often 20–128 Hz depending on genre. A 60 Hz shooter server advances physics sixty times per second; clients may render at 144 FPS but only receive ~60 state updates per second from the server.

Each tick produces a snapshot: positions, velocities, animation states, scores. Snapshots are usually delta-compressed — only fields that changed since the last acknowledged snapshot, often quantized to 16-bit floats or integers. Interest management (or relevancy) skips entities far from the player. An open-world MMO does not stream every NPC on the continent to every client; it streams a bubble around each player.

Input packets flow upstream: “frame 1042: move stick (0.7, -0.3), jump pressed.” Small, frequent, sometimes redundant (send the same input twice in case one packet drops). Sequence numbers let the server discard stale inputs.

Client-side prediction and reconciliation

For the local player, waiting for server round-trip before moving is unacceptable. Client-side prediction applies inputs immediately on the client using the same movement code the server will run (or a close approximation). You see yourself move instantly; the server catches up later.

When the authoritative snapshot arrives, the client compares predicted position to server position. If they match, nothing happens. If they diverge — reconciliation rewinds to the last confirmed state and replays unacked inputs on top. Small errors are invisible; large errors cause the infamous rubber-banding snap. Tuning acceleration, collision margins, and how aggressively you blend corrections trades fairness against visual smoothness.

Remote players: interpolation and extrapolation

You do not predict other players’ inputs — you only know where they were 100 ms ago. Interpolation renders remote entities slightly in the past, blending between two received snapshots (e.g. display at t - 100ms). Movement looks smooth even though updates arrive discretely. Extrapolation (dead reckoning) guesses forward from last known velocity when packets stall — fine for linear motion, wrong when someone suddenly stops; cap extrapolation time to avoid characters flying into walls.

Lag compensation for hit detection

Shooters add a second layer beyond movement prediction: lag compensation (historical rewinding). When client A fires, the server rewinds other players to where they were on A’s timeline at shot time, then runs hitscan or projectile overlap tests against that historical geometry. Without it, high-ping players must lead targets by their entire ping; with it, “I was on crosshair on my screen” often registers even though the target has moved on the server’s live state.

Trade-off: you can appear shot from behind cover briefly — the server validated a past position that looked open to the shooter. Competitive players accept this as fairer than pure server-time hits. Lag compensation pairs naturally with collision detection systems that can query historical transforms per entity, not just current-frame AABBs.

Rollback netcode: fighting games and determinism

Genre matters. Rollback (popularized by GGPO) suits low-player-count, deterministic fighters. Both peers predict all inputs, including the opponent’s (often assuming “no new input” until a packet arrives). When real inputs differ, the simulation rolls back to the divergence frame and re-simulates forward — fast if the game state is small and 100% deterministic.

Rollback demands identical simulation on all peers: fixed timestep, no floating-point nondeterminism across CPUs, no random calls without synced seeds. It shines at 2–4 players; it does not scale to 100-player battle royales. See state machines for keeping combat logic modular when you must replay frames.

Transport: UDP, TCP, and the browser

Native PC and console games overwhelmingly use UDP for game data — unreliable but low-latency, with custom reliability only for critical messages (loadout changes, chat). TCP’s in-order delivery can stall an entire connection while retransmitting one lost movement packet.

Browsers cannot open arbitrary UDP sockets. Options:

WebSockets over TCP — simple, works everywhere, adds head-of-line blocking risk. Fine for turn-based, slower action, or lobby chat. See our WebSockets guide.
WebRTC data channels — UDP-like unordered delivery between peers or through a TURN relay; more setup (signaling server, ICE) but viable for browser multiplayer action.
Authoritative server + thin client — all simulation server-side, client only renders; higher latency tolerance, easier cheat prevention, common for .io-style web games.

Encrypt and authenticate every gameplay packet in production. TLS wraps WebSockets; DTLS secures WebRTC. Never trust client-reported scores without server validation.

Cheating, validation, and scope

Server authority is the primary anti-cheat. Validate movement against speed limits, cooldown timers, and line-of-sight before applying damage. Rate-limit input packets; reject physically impossible state transitions. For on-chain or wager games, separate outcome resolution (commit-reveal, server seed) from cosmetic animation — the same principle as provably fair dice: verify the result, not the particle effects.

Scope creep kills netcode projects. Ship one game mode with solid movement sync before adding vehicles, physics props, and voice chat. Profile bandwidth early: a 1 KB/s per player budget at 100 players is 100 KB/s egress per match — hosting math matters.

Key takeaways

Latency is physics — netcode hides it with prediction, interpolation, and careful authority.
Server authority for outcomes; client prediction for local responsiveness.
Remote players are rendered in the past (interpolation); your character is predicted into the future.
Lag compensation rewinds history for hits; rollback re-simulates for deterministic fighters.
Match transport to platform — UDP native, WebRTC or authoritative server in the browser.
Delta snapshots + interest management keep bandwidth bounded as player counts grow.