Client-Side Prediction

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.

See also

• Quake
• id Software
• BSP Trees