Client-Side Prediction
Making lag invisible
The networking technique pioneered in QuakeWorld (1996) that makes online games playable on high-latency connections by predicting movement locally before server confirmation.
Overview
Client-side prediction is the networking technique that makes online action games playable on high-latency connections. Pioneered by John Carmack in QuakeWorld (1996), it predicts player movement locally without waiting for server confirmation, hiding latency from players who would otherwise feel a 200 ms delay between every input. Without it, the modern internet-multiplayer FPS, MOBA, and battle-royale genres are simply not possible.
The technique reverses the trust model of the original Quake: the server is now authoritative, but the client is allowed to predict where it’ll end up while waiting for confirmation. The server later corrects the client when prediction was wrong — usually invisibly, sometimes with the dreaded “rubber-banding”.
Fast facts
- Pioneered: QuakeWorld (1996, John Carmack at id Software).
- Problem solved: High-latency play is unbearable without prediction.
- Solution: Predict locally, reconcile with server later.
- Status: Industry standard for action games; every modern shooter, MOBA, fighting game, and battle royale uses it or a variant.
The problem
Without prediction, the round-trip latency hits every input:
| Scenario | Result |
|---|---|
| Press forward | Client sends to server |
| Server processes | Updates authoritative state |
| Server sends back | Position update |
| 200 ms ping | 200 ms delay between input and visible movement |
| Player experience | Unplayable sluggishness |
The original Quake (June 1996) shipped with this naive networking and was famously hard to play across the internet. Carmack rewrote the netcode for QuakeWorld (December 1996) with prediction.
How it works
The prediction loop:
| Step | Process |
|---|---|
| 1 | Player presses forward |
| 2 | Client predicts movement locally — applies physics immediately |
| 3 | Input + sequence number sent to server |
| 4 | Server processes input authoritatively |
| 5 | Server broadcasts authoritative state to all clients |
| 6 | Client receives server state with sequence acknowledgement |
| 7 | Client compares predicted state at that sequence to server state |
| 8 | If they differ, client reconciles — re-runs prediction from server’s authoritative state |
The crucial step 8 is reconciliation — the client doesn’t snap to the server’s old state, but re-applies its more recent inputs starting from the server’s confirmed position. The result: the player sees their character move smoothly even when the server corrects.
Reconciliation
When prediction differs from server (network packet loss, mispredicted physics, hostile player input you didn’t see):
| Situation | Response |
|---|---|
| Minor difference | Smoothly interpolate over a few frames — invisible to player |
| Major difference | Snap to server position — visible “rubber-banding” |
| Consistent error | Adjust prediction model (recalibrate timing, account for high ping) |
| Lost packets | Re-send last input + buffered inputs |
The client keeps a buffer of recent inputs and predicted states, so when the server says “at sequence 42 you were at position X”, the client can replay sequences 43, 44, 45… from X to compute the new “now”.
QuakeWorld impact
Before QuakeWorld, internet Quake was:
| Aspect | Original Quake (June 1996) | QuakeWorld (December 1996) |
|---|---|---|
| Playability | 100 ms+ unplayable | Playable at 200 ms+ |
| Server model | Peer-to-peer (each client also ran simulation) | Client-server (server authoritative) |
| Player base | LAN-quality only | Internet viable; ushered in mass online FPS |
This was the enabling technique for internet multiplayer gaming. Every successful online action game since (Counter-Strike, Quake III, Halo 2, Call of Duty, Fortnite, Apex Legends) descends from QuakeWorld’s netcode pattern.
Related techniques
Client-side prediction is one piece of a larger netcode toolkit:
| Technique | Purpose |
|---|---|
| Lag compensation | Server rewinds time when validating shots; “shoot where you saw, not where they are now” |
| Client interpolation | Other players are rendered slightly behind real time, smoothly interpolating between received states |
| Server reconciliation | Resolve conflicts between predicted and actual outcomes |
| Delta compression | Send only state changes since last ack, not full state |
| Snapshot interpolation | Continuous smoothing of remote-player positions |
| Rollback netcode | Fighting-game variant — locally simulate inputs, roll back and replay if remote inputs disagree |
Implementation challenges
| Challenge | Solution |
|---|---|
| Cheating | Server is authoritative — clients can’t decide they “really hit” |
| Physics divergence | Use deterministic simulation so client and server reach same answer |
| Visual glitches | Smoothly interpolate corrections; only snap on big errors |
| Bandwidth | Send state deltas, not full state |
| Packet loss | Re-send recent inputs; buffer state on both ends |
| Adversarial latency | “Lag switching” exploits — players intentionally inducing lag |
Variants
The 28-year evolution:
| Game / engine | Year | Variation |
|---|---|---|
| QuakeWorld | 1996 | Original prediction + reconciliation |
| Half-Life (GoldSrc) | 1998 | Quake-derived; lag compensation added |
| Counter-Strike 1.6 | 2003 | Refined lag compensation; “favour the shooter” |
| Halo 2 | 2004 | First console FPS with serious netcode |
| Source engine | 2004 | Mature client-server prediction |
| Quake III Arena | 1999 | Smoother snapshot interpolation |
| Battlefield series | 2002+ | Larger player counts, more state |
| GGPO / rollback netcode | 2006 | Fighting-game alternative — rollback rather than predict |
| Modern engines | 2010s+ | All major engines (Unreal, Unity, Source 2) ship with prediction by default |
Rollback netcode (fighting games)
Fighting games have a different latency profile — every frame matters; a 100 ms ping is half a second of input lag in 60 fps gameplay. GGPO (2006, Tony Cannon) introduced rollback netcode for fighters: locally simulate as if remote inputs were “no input”; when remote inputs arrive, rollback and replay. The result: zero perceived input latency, with visual stutter only on bad connections. Now standard in Street Fighter 6, Tekken 8, Guilty Gear Strive, Mortal Kombat 11+.
Rollback is conceptually similar to client-side prediction but differs in detail — both clients are “predictors” rather than one client predicting against an authoritative server.
Legacy
Client-side prediction enabled internet gaming. Every modern online game uses this technique or its descendants — from Counter-Strike to Fortnite to Marvel Snap — making Carmack’s QuakeWorld code perhaps the most influential networking innovation in gaming history. The QuakeWorld source release (1999, GPL) made the technique studyable; the techniques propagated through every subsequent engine.
Modern netcode discussion (Glenn Fiedler’s blog, Gaffer on Games series, Valve’s Source engine documentation) all trace back to the QuakeWorld foundation.