Guide

Game netcode and multiplayer networking explained

Harbor Arena shipped its 4v4 team shooter with a naive “send position every frame” prototype. At 30 ms ping it felt fine in the office; at 120 ms across the Atlantic, players watched enemies teleport, shots registered a half-second late, and the killcam showed hits that never appeared on their screen. Refactoring to server-authoritative simulation at 64 tick, adding client-side prediction for local movement, and lag compensation for hitscan weapons cut perceived input delay from 180 ms to under 40 ms while eliminating most “I shot first” disputes. Netcode is the set of techniques that synchronize game state across machines separated by latency, packet loss, and clock drift. There is no single best approach: fighting games favor rollback, MMOs tolerate interpolation, and competitive shooters need authoritative servers with rewind. This guide explains client-server vs peer-to-peer models, tick rate and snapshots, prediction and reconciliation, rollback and lag compensation, NAT traversal, a Harbor Arena worked example, an architecture decision table, pitfalls, and a production checklist.

Why netcode is a design problem, not just engineering

Players judge fairness by what they see on their screen. Physics on two machines will diverge unless one source of truth wins. Every millisecond of round-trip time (RTT) between client and server is felt as input lag, rubber-banding, or “ghost” hits. Netcode choices constrain game design: a physics-heavy destruction sandbox needs different synchronization than a turn-based card game. Pick your model early; retrofitting rollback into a shipped authoritative shooter is a multi-month rewrite.

Three metrics matter in production:

Responsiveness — how quickly local input affects what the player sees (prediction helps).
Consistency — whether all clients agree on outcomes (authority helps).
Bandwidth and CPU — snapshot size, tick rate, and rollback simulation cost scale with player count and simulation complexity.

Client-server vs peer-to-peer

Dedicated server (client-server)

A dedicated server (or listen-server host) runs the authoritative simulation. Clients send inputs; the server advances the world and broadcasts state snapshots. Cheating is harder because clients cannot declare their own hits or inventory. Latency is asymmetric: the local player waits for server confirmation unless you predict. This is the default for competitive shooters, MOBAs, and most live-service titles.

Peer-to-peer (P2P)

Peers exchange state directly, often with one player as host. Lower hosting cost and simpler small-session setup, but the host has zero-latency advantage and anti-cheat is weak. Acceptable for co-op, sports, and some fighting games with rollback; risky for open PvP at scale.

Server authoritative rule

For any game with economy, rankings, or paid cosmetics, treat the server as authoritative for outcomes that affect progression. Clients may predict visuals; the server decides damage, loot, and match results.

Tick rate, snapshots, interpolation, and extrapolation

The simulation tick rate is how often the authoritative world advances — commonly 20–30 Hz for MMOs, 64 Hz for shooters, 120 Hz for some fighting-game rollback frames. Higher tick rates reduce quantization error but multiply CPU and bandwidth.

Snapshots

Each tick the server packages entity positions, velocities, animation states, and gameplay flags into a snapshot. Snapshots are delta-compressed against the previous acked frame to save bandwidth. Clients buffer incoming snapshots and render remote entities slightly in the past.

Interpolation

Interpolation renders other players between two received snapshots (e.g. 100 ms render delay). Movement looks smooth even at 20 Hz server tick; the trade-off is that remote players are always slightly behind reality.

Extrapolation

When the next snapshot is late, extrapolation (dead reckoning) projects entities forward from last known velocity. Works for steady movement; causes rubber-banding when the guess was wrong. Cap extrapolation time aggressively.

Client-side prediction and server reconciliation

Without prediction, every jump waits for server RTT before the local character leaves the ground. Client-side prediction applies input immediately on the client while simultaneously sending the input to the server. When the authoritative snapshot arrives, the client reconciles: if the server position differs, rewind local state to the server frame and replay unacked inputs on top.

Requirements for clean prediction:

Deterministic or near-deterministic movement on client and server (same constants, same integration step).
Input numbering so the server can replay the exact sequence.
Separation of predicted vs non-predicted systems — do not predict other players or server-spawned projectiles locally.

Mispredictions cause micro-stutters; tune movement so corrections are rare and small. For combat systems, animate local feedback instantly but let the server confirm damage.

Rollback netcode

Rollback netcode (popularized by GGPO in fighting games) assumes inputs are delayed by RTT. Instead of waiting, the game speculatively simulates frames using predicted remote inputs. When real inputs arrive late, it rolls back to the correct frame and resimulates forward. Local players feel instant response; remote mistakes cause brief visual corrections.

Rollback demands:

Fast, deterministic simulation (no heavy physics engines without fixed step).
Bounded state size — full open-world state cannot roll back cheaply.
Input delay tuning (often 2–4 frames) to absorb variance.

Ideal for 1v1 and small-player fighting, platform fighters, and some sports titles. Poor fit for 100-player battle royales. See our fighting game design guide for frame-data constraints that pair with rollback.

Lag compensation (server-side rewind)

Hitscan weapons raycast at the shooter's aim. With raw server time, a player with 80 ms ping must lead a moving target by their entire latency — unfair and unintuitive. Lag compensation rewinds other players' hitboxes to where they were on the shooter's screen at fire time (within a clamped window, e.g. 200 ms), then tests the shot against that historical pose.

Trade-offs:

Shooter feels fair; victim may see themselves around a corner when killed (the “got shot around corner” complaint).
Requires storing a ring buffer of past poses per entity.
Must clamp rewind to prevent absurd kills at 500 ms ping.

Projectile weapons usually use server-spawned entities instead of rewind; melee may use shorter windows or fully server-side hit detection.

NAT traversal, relays, and session setup

Home routers block inbound connections. Games use NAT punch-through (STUN/TURN coordinated via a matchmaking service) or relay servers when punch fails. Relays add latency but improve connect rates. Platform SDKs (Steam, EOS, PlayStation) abstract much of this; custom backends need explicit fallback paths.

Session flow typically: authenticate → matchmake → allocate server or negotiate P2P → exchange version/build hash → load assets → start simulation. Version mismatches should fail before gameplay, not mid-match. Cross-platform adds platform identity and pool complexity on top of transport.

Worked example: Harbor Arena 4v4 shooter refactor

Harbor Arena's post-launch netcode pass targeted three player complaints: movement felt mushy, hit registration disagreed with killcam, and high-ping players were unplayable in ranked.

Authority move. All damage, ability cooldowns, and objective captures moved server-side. Clients sent InputCmd structs (buttons, view angles, sequence id) at 128 Hz send rate; server simulated at 64 tick.
Prediction layer. Local strafe and jump predicted on client; weapons showed muzzle flash and tracers immediately; damage numbers waited for server ack. Reconciliation blended errors over 80 ms to hide pops.
Lag comp. Hitscan rifles rewound enemy capsules 150 ms max; shotguns used server-only pellet cones without rewind to reduce corner kills.
Snapshot budget. Delta snapshots capped at 1.2 KB per player per tick; irrelevant entities culled by relevance volumes. Low-bandwidth mode dropped to 32 tick with extra interpolation.
Telemetry. Per-match histograms of RTT, packet loss, prediction error, and lag-comp rewind distance fed into ranked matchmaking region locks.

Result: NA/EU ranked retention up 9%; “netcode” negative reviews down 34% in six weeks. APAC still needed Tokyo relay investment — netcode cannot beat speed of light without regional servers.

Netcode architecture decision table

Genre / constraint	Recommended model	Why
Competitive FPS / tactical shooter	Dedicated server + prediction + lag comp	Anti-cheat, fair hits, scalable ranked
Fighting / platform fighter	Rollback P2P or dedicated with rollback	Frame-perfect inputs; small state
MOBA / hero shooter	Server authoritative, 30–64 tick, interpolation	Many entities; ability validation on server
MMO / open world	Server shards, low tick, interest management	Bandwidth scales with AOI culling, not global state
Co-op PvE (2–4 players)	Listen server or P2P host, light prediction	Cost-efficient; cheating less critical
Turn-based / async	Server validates moves; no real-time sync	Latency irrelevant; focus on cheat-proof turn log
Battle royale (100 players)	Regional dedicated, aggressive relevance + compression	Rollback impossible at scale; prioritize stable 20–30 Hz

Common pitfalls

Testing only on LAN. Artificial zero-latency hides prediction bugs until public beta.
Non-deterministic physics. Client and server diverge every frame; reconciliation becomes constant rubber-banding.
Predicting other players. Creates ghost interactions and desynced animations.
Unbounded lag compensation. High-ping players become teleporting killers; clamp and show ping in UI.
Ignoring packet loss. TCP for real-time gameplay causes head-of-line blocking; use UDP with reliability only where needed.
Same build for P2P and dedicated. Host migration and cheat surfaces differ; separate code paths need separate tests.
Shipping without netgraph tools. Support cannot debug “lag” reports without RTT, loss, and tick stats in replays.

Production checklist

Choose authority model and tick rate before vertical slice multiplayer.
Define which systems are predicted, interpolated, or server-only.
Implement input sequencing and snapshot ack for reconciliation.
Build lag simulation tools (artificial delay/jitter/loss) in dev builds.
Playtest at 30, 80, 150, and 250 ms RTT with real packet loss profiles.
Instrument prediction error, snapshot size, and server CPU per player.
Document hit detection policy (rewind window, projectiles, melee) for players.
Plan regional server or relay footprint for launch markets.
Version-gate matchmaking; reject mismatched protocol or content hashes.
Record server replays for dispute resolution and anti-cheat review.

Key takeaways

Netcode trades responsiveness, consistency, and cost — genre dictates the right balance.
Server authority stops most cheats but needs prediction for feel.
Rollback suits small deterministic games; shooters need rewind lag comp, not full state rollback.
Interpolation smooths remote players at the cost of temporal accuracy.
Measure under real latency — LAN-perfect netcode fails in the wild.