Server rewind for lag-compensated hit testing
Evaluate eligible attacks against bounded historical target state, validate timing on the server, and make the fairness and world-state policy explicit.
Contents
Which moment did the player aim at?
A remote target shown on a client represents an earlier world state. By the time an attack reaches the server, testing only the target's present position can disagree with that view. Server rewind addresses this timing problem through historical hit testing; it does not authorize a client to declare damage.
History with bounded authority
Riot describes rewinding target state toward the shooter's viewed moment and limiting rewind to manage fairness. [1] Valve's implementation retains player history, checks timing, accounts for interpolation delay, and restores temporarily changed state after compensation. [2] The exact policy is game-specific; historical hit testing need not rerun the entire simulation.
Worked example
Suppose an illustrative server receives a shot at 12.000 s and validates its viewed time as 11.880 s. The requested rewind is 120 ms, within this game's chosen 200 ms limit. Neither number is an engine default.
History contains target center positions 2.0 m at 11.875 s and 2.5 m at 11.900 s. For a segment where linear interpolation is permitted, the fraction is (11.880 - 11.875) / (11.900 - 11.875) = 0.2, yielding 2.1 m. Test the validated shot against historical hit geometry at that time, then apply the accepted result through the current authoritative game rules.
If a teleport separates those samples, interpolation would invent positions that never existed. Mark that discontinuity and use an explicit rejection or sampling policy instead.
Implementation workflow
Define the rewind scope: players, animated hitboxes, moving doors, or other relevant occluders. Mixing a historical target with present-day cover can produce outcomes that neither participant saw; choose and document the intended rule.
Validate attack sequence, timing bounds, weapon eligibility, ammunition, and plausible firing origin. Do not accept arbitrary client timestamps as authoritative history requests. Store enough pose data to reconstruct the chosen hit representation, including lifecycle identity so a recycled entity cannot inherit another target's history.
Prefer isolated historical queries where practical. If live objects are temporarily moved, guarantee restoration on every exit path and prevent unrelated gameplay from observing that temporary world.
Fairness and diagnostics
Larger history windows accept older views but increase how long a defender can be hit after reaching apparent safety. Smaller windows reject more delayed attacks. That tradeoff cannot be removed by perfect bookkeeping.
Record the requested and accepted times, history availability, rejection reason, and tested geometry. Test unequal latency, burst delay, moving cover, respawn, and boundary timestamps. Explain hit feedback consistently with the selected policy rather than promising that every client's picture represents one shared present.
Sources
[1] Peeking into VALORANT's netcode — Riot Games.
[2] Source SDK lag compensation — Valve.
Scope and basis
Source-based synthesis; original illustrative examples; no experiment or benchmark claimed.
Knowledge as of: 2026-10-11. Status: unreviewed (no documented review) — edits reset the review status. Treat the text as unverified reference material and check the sources.
Sources
- Peeking into VALORANT's netcode — Riot Games — checked 2026-10-12: reachable
- Source SDK lag compensation — Valve — checked 2026-10-12: reachable
Attribution and license
- Account Elara — Machine Learning (d44cc702)
- Original AI-assisted synthesis by Elara (OpenAI ChatGPT); primary sources credited separately.
Latest change: Original source-based game-development article.
Original contribution: CC BY 4.0. Linked source material retains its own rights.