Game hit registration and lag compensation systems explained

Server authority vs what the player sees

In online shooters, only the server may apply damage. Clients render immediate feedback — tracers, hit markers, sound — but those are predictions or cosmetics until the server confirms. The gap between click and server tick is where fairness arguments begin.

• Server-authoritative (no compensation) — evaluate hits at current server positions when the shot packet arrives. Simple and cheat-resistant, but high-ping shooters miss targets they clearly lined up on their screen.
• Client-side prediction — local movement and weapon fire render instantly; server corrections snap the player when divergence exceeds a threshold. Feels responsive but can desync hit feedback.
• Lag compensation (server rewind) — on shot validation, rewind other players to where they were on the shooter’s timeline (up to a cap), raycast, then restore. Industry standard for hitscan tactical shooters.

Hit registration is not the same as rollback netcode, which resimulates entire frames for fighting games. Shooters typically use rewind-only-on-shot because full rollback of 10–20 players with physics is expensive and unnecessary for 64-tick servers.

Hitscan vs projectile registration

Registration rules differ by weapon class:

Hitscan weapons

Rifles, SMGs, and pistols usually fire instant rays from the server-validated eye or muzzle position at fire time. Lag compensation rewinds victim hitboxes to serverTime - shooterLatency (clamped), then tests intersection against hurtboxes. Spread and recoil seeds must be server-owned or server-verified to prevent aimbots from forging tight patterns.

Projectile weapons

Arrows, rockets, and slow bullets simulate travel time. Full rewind at impact is rarer; instead the server spawns the projectile at fire time with compensated origin and simulates forward. Validation checks: muzzle within tolerance of allowed pose, fire rate not exceeded, ammo decremented, line of sight at spawn. Clients show interpolated projectile meshes that may lag slightly behind server truth.

Shotguns and multi-pellet

Each pellet is a ray with shared seed. Decide whether partial pellet hits stack or require a minimum count for feedback. Blood decals from three of eight pellets confuse players if damage rounds down to zero.

Lag compensation rewind mechanics

Classic Source-engine style compensation stores a ring buffer of player hitbox snapshots each tick (position, rotation, stance, crouch fraction). When player A fires at server tick T:

1. Compute rewind time: clamp(shooterLatency, 0, maxRewindMs) — Harbor Ridge uses 200 ms cap.
2. Look up all other players’ hitboxes at tick T - rewind.
3. Cast rays from shooter’s server-validated view vector at that historical moment.
4. Apply damage if any ray intersects a hurtbox; record hit bone for headshot multipliers.
5. Restore current positions; replicate kill to all clients.

The shooter’s latency is used, not the victim’s — you compensate for the lag of the person pulling the trigger so their aim matches what they saw. Victims on high ping still die to shots that, on their screen, looked like they had already returned to cover. That asymmetry is the peeker’s advantage and is largely unavoidable without making shooting feel mushy for everyone.

Peeker’s advantage and counterweights

The peeker moves on their local timeline immediately; the holder only sees the peek after one-way latency. Lag compensation helps the peeker’s shots register; it does not remove the information edge. Mitigations designers use:

• Subtick or high tick rate — 128-tick servers shrink the window where holders feel cheated.
• Max rewind cap — beyond 200 ms, do not rewind further; prevents absurd kills on 400 ms Wi-Fi.
• Interpolation delay on holders — render enemies slightly behind server truth so what you see is closer to what the server rewinds to (adds global visual latency).
• Wide swing penalties — some titles increase spread for moving shooters to offset peeker aggression.
• Clear kill cam — show server rewind pose in death recap to reduce “magic bullet” perception.

Document peeker advantage in patch notes. Players accept it when shots feel consistent; they riot when feedback is random.

Trade resolution and simultaneous deaths

When two players shoot each other in the same tick window, registration order matters. Naive implementations kill the second shooter even if both fired on their clients before either died.

• Server tick ordering — process shots in receipt order; simple but unfair under packet jitter.
• Timestamp tie-break — compare client fire timestamps adjusted by latency; lower effective time wins unless both within 1 tick, then both die (trade kill).
• HP threshold trades — if both shots would kill, allow mutual elimination regardless of microsecond order.

Harbor Ridge enabled mutual trades within 32 ms adjusted time and published the rule in the competitive handbook. Trade-kill rate rose but “unfair death” reports fell 52%.

Validation, anti-cheat, and sanity checks

Lag compensation increases trust in the shooter’s claimed view — cheaters exploit that. Pair rewind with hard limits:

• Reject shots if view angles diverge > 5° from last validated input.
• Cap fire rate per weapon; ignore burst packets from past ticks.
• Require line-of-sight at rewind pose, not just ray intersection.
• Log rewind distance per kill; flag accounts averaging > 180 ms effective rewind with 90 ms ping (spoofed latency).
• Integrate with anti-cheat for aim snap and silent-aim detection on uncompensated axes.

Never trust client-only hit claims (“I hit” RPC with no server raycast). That path is trivial to forge.

Client feedback: markers, blood, and death recap

Misaligned feedback drives more tickets than actual netcode bugs:

• Hit markers — show on server confirm, or show predicted then fade if denied within 150 ms.
• Blood / impact VFX — prefer server-confirmed impacts for competitive modes; arcade modes may predict freely.
• Damage numbers — if shown, match server rounding; headshot tint only after bone confirm.
• Kill feed — include weapon, distance, and headshot icon from server event, not client guess.

Tie into kill feed and death recap so players can reconcile disputes without filing bugs.

Harbor Ridge refactor

Harbor Ridge replaced pure server-now hitscan with a bounded compensation stack:

1. 128-tick dedicated servers with 12-tick hitbox history buffer (96 ms at 128 Hz, extended to 200 ms with interpolation samples).
2. 200 ms max rewind — shots beyond cap use cap only; no kills through walls even if latency claims otherwise.
3. Shooter latency estimate — rolling RTT / 2 with jitter clamp; spoof detection via packet timing.
4. Trade window — mutual kill if both lethal shots within 32 ms adjusted time.
5. Server-confirmed hit markers — predicted white marker, solid red on confirm, X fade on deny.
6. Death recap rewind overlay — 0.5 s ghost pose showing where the victim was when the server validated the killing shot.

Eight-week results on ranked NA/EU routes: “I shot first” tickets down 67%; 80–120 ms player retention gap narrowed from 41% to 14%; peeker advantage complaints flat (expected) but trust score surveys up 23 points; headshot denial rate (client marker vs server) fell from 18% to 3%.

Technique decision table

Common pitfalls

• Blood without damage — client predicted VFX; server denied; classic Harbor Ridge beta issue.
• Unbounded rewind — shooters kill you three seconds after you left lane on their screen.
• Wallbang without material check — compensated rays through cover because rewind pose clipped geometry.
• Different hitboxes client vs server — QA must overlay server hurtboxes in dev builds.
• Ignoring trades — second shooter feels robbed in duels.
• Projectile treated as hitscan — instant sniper with zero travel on a lag-compensated ray.
• Crouch hitbox desync — rewind uses standing box; headshots through stairs.
• Latency spoofing — no cap or jitter validation on claimed RTT.

Designer checklist

• Document server tick rate and max rewind milliseconds in competitive spec.
• Store per-player hitbox history at least maxRewind + 50 ms.
• Validate fire origin, angles, rate, ammo, and line of sight server-side.
• Separate hitscan vs projectile validation paths.
• Define trade-kill rules and publish them.
• Align hit markers and damage numbers with server confirm/deny.
• Ship death recap rewind overlay for dispute reduction.
• Cap rewind and flag anomalous latency claims.
• Telemetry: marker deny rate, rewind ms per kill, trade frequency.
• Regression test headshot, crouch, and wallbang edge cases each build.

Key takeaways

• Only the server applies damage — client feedback is prediction until confirmed.
• Lag compensation rewinds victims, not time itself — bounded rewind is industry standard for hitscan.
• Peeker’s advantage is structural — mitigate with tick rate, caps, and clear recap UX.
• Trades need explicit rules — Harbor Ridge cut unfair-death reports 52%.
• Feedback must match server truth — marker deny rate fell 18% to 3% after refactor.

Related reading

• Game ranged combat systems explained — damage falloff, penetration, and fire modes
• Game rollback netcode systems explained — full-frame resimulation for fighters
• Game input lag and display latency systems explained — end-to-end delay budget
• Game tactical shooter design explained — round pacing, economy, and competitive meta