# Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization
Source: https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization
Mirror: https://web.archive.org/web/20191214121548/https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization
Author: Yahn W. Bernier (Valve), 2001

## Overview
FPS Internet play must handle latency/loss even with broadband. Covers client/server architecture, predictive modeling, and lag compensation tradeoffs.

## Basic loops
Client: sample input → send movement command with sim time → read server packets → render. Server: read usercmds → execute → simulate server objects → send visible state per client.

## Usercmd (Half-Life)
Fields include `lerp_msec`, `msec` (frametime), `viewangles`, `forwardmove`/`sidemove`/`upmove`, `buttons`. Pure dumb client with 500ms RTT feels unusable on Internet.

## Client-side prediction
Store commands; from last server-acked state, replay unacked commands with **shared** movement code (`pm_shared/`). Server remains authoritative. Caveats: do not replay footstep/VFX every re-run (mark first-time predicted); client-only fields need sliding window of intermediate states.

## Weapon firing prediction
Share weapon logic too; replicate ammo/timers/anims as authoritative state. Avoid client-authoritative "I am at x and I headshot player 2" — cheating.

## Leading targets without lag comp
Even with movement prediction, hitscan results wait for server. High latency → must lead moving targets; Quake3 used hit confirmation tones to help players learn lead.

## Display of others: extrapolation vs interpolation
Extrapolation: ballistic forward from last state — bad under high jerk / instant turns; limit time (QW ~100ms). Interpolation: render in the past between updates; 100ms buffer at 10 Hz; 200ms survives one loss. Position **history** (search straddling timestamps) better than "always move toward latest" when update spacing varies with bandwidth choke. Detect teleports (flag or large delta) — do not interpolate across them. HL default: 20 updates/s, 100ms interp; clients may request higher rates.

## Lag compensation algorithm
Before executing usercmd: estimate latency; find world update the player had; move other players back accounting for latency **and** client's interpolation amount (`lerp_msec`); run command (traces); restore players. Also rewind ancillary state (alive/dead, ducking).

## Design implications
Enables aim-at-what-you-see for hitscan. Paradoxes: high-lag shooter can hit low-lag player who already took cover ("shot around a corner"). Valve favored local responsiveness. Head-on fights and unsighted strafers reduce perceived unfairness. **Projectiles**: HL does not lag-compensate projectile entities (open questions about whose time space they live in); firing sound still predicted.

## Conclusion
Lag compensation is a game-design choice; for HL/TFC/CS benefits outweighed inconsistencies.