Client-Side Prediction

Client-side prediction lets an online game respond to your movement input before the server’s answer arrives. Your computer calculates a provisional result; the server remains authoritative. Prediction hides some of the delay you feel, but does not make packets travel faster.¹

Quake’s QuakeWorld update provides a documented example. Computer Gaming World previewed John Carmack’s work in October 1996, distinguishing smaller packets from changes which made play feel faster. PC Gamer subsequently reported a free release in mid-December 1996.²³

How it works

Think of pressing forward while waiting for a network round trip. A client that waits for every server reply feels slow. A predicting client can show movement immediately, using its local movement simulation.¹

The released QuakeWorld code makes the process concrete:

1. Start from the last player state received from the server.
2. Run subsequent stored input commands through the movement simulation.
3. Use the resulting position to draw the player’s view.

CL_PredictMove performs this work, calling CL_PredictUsercmd, which in turn calls PlayerMove. When another server update arrives, it supplies a new starting point. Replaying the remaining commands brings that authoritative state towards the present.⁴

The client and server can disagree. A correction may therefore move the view away from its earlier predicted position. Valve’s Yahn Bernier describes this trade-off in his account of Half-Life networking: responsive local movement still needs correction from the server.¹

What players could adjust

In March 1997, Computer and Video Games told QuakeWorld players to set PUSHLATENCY to the negative of their ping. Its report praised the improvement in character control while noting that rockets and doors could still respond late.⁵

In the released code, pushlatency helps set the time towards which the client predicts, capped at the current time. It changes the local simulation’s timing; it does not remove network delay.⁴

Three different problems

Predicting your own movement uses inputs your computer already knows. Displaying other players is a different problem: your computer does not yet know their next input. Bernier discusses extrapolating their motion or interpolating between received positions separately.¹

Lag compensation is another operation again. In Bernier’s account, the server considers earlier world positions when resolving a delayed command such as a shot. Responsive movement on your screen does not, by itself, solve hit detection across a network.¹

See also

• Quake
• id Software
• John Carmack
• Online multiplayer

Footnotes

1. Yahn W. Bernier, Valve, “Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization”, sections on client-side prediction, other players and lag compensation. ↩ ↩² ↩³ ↩⁴ ↩⁵

2. V. Long, “Quake Aftershocks: Cheats, Hacks and Updates for Killer Quake Action”, Computer Gaming World 147, October 1996. Contemporary preview of packet-size and client-state changes. ↩

3. Edward James, “Eyewitness: QuakeWorld”, PC Gamer UK 40, February 1997, p. 18. The report dates release to mid-December; it also describes prediction of other players, which should not be conflated with local input prediction. ↩

4. id Software, released QuakeWorld source, QW/client/cl_pred.c, CL_PredictMove and CL_PredictUsercmd. This documents the released source version, not every detail of the first public executable. ↩ ↩²

5. “QuakeWorld Giblets”, Computer and Video Games 184, March 1997, “Completely lag-less!” box. The heading is more absolute than the limitations described in the text. ↩