Server-Side Hitscan vs Ballistic Projectile Registration: Advanced Implementation and Real-World Architecture

[Ella Rivera]

We’ve been stuck deciding between hitscan and ballistic projectile registration for our competitive title.

🎮 Battlestation & Rig: Ryzen 9 7950X3D | RTX 4090 ROG Strix | 64GB DDR5 6000 CL30 | Custom Water Loop | ASUS ROG Swift OLED PG27AQDM 27″ 240Hz 0.03ms | Fanatec Gran Turismo DD Pro (8Nm) + ClubSport V3 Load Cell Pedals | Audio-Technica ATH-R70x + Schiit Magni/Modi Stack

📍 Atlanta, GA (USA)

"0.03ms OLED response renders ghosting completely obsolete."

[Benjamin Campbell]

For hitscan weapons, the cleanest server-side approach is to treat every shot as an authoritative raycast: the client sends the fire event with the aim origin and forward vector, but the server re-runs the cast against its own snapshot of player hitboxes rather than trusting the client’s ray. The critical part is lag compensation — you can’t just check against current positions, or anyone on 60ms+ ping gets phantom shots. You need to replay enemy entities back to the exact server tick the shot was registered (think of how CS’s cl_showlagcompensation works), then cast against

"Rank doesn’t define skill, but tilt certainly destroys it."

[Jake Baker]

Great topic. The core architectural difference between hitscan and ballistic registration usually comes down to where the server enforces authority over the shot. On hitscan, the cleanest modern approach is server-side lag compensation with position rewinding: the client sends a fire event plus its predicted snapshot, the server traces a raycast from the weapon’s origin at the exact server tick the shot was registered, then temporarily rewinds each nearby player’s position history to that tick before validating the intersection against their hitboxes. This is what games like VALORANT and CS2 use to make your shots feel responsive while keeping the server authoritative—the catch is that rewinding has a window limit (usually ~500ms), so server-side hitscan still can’t fully solve rubberbanding for players who’ve been lagging hard. Deferred hitscan (client predicts, server validates async) trades some “hit feel” for fewer false hits, which is why many competitive titles still favor server-authoritative hitscan despite the input latency.

For ballistic projectiles, you’re dealing with a fundamentally different problem because the trajectory itself is the entity the server must simulate. The server owns the full physics sim—velocity, gravity, drag, and travel time—

"Nintendo 64 with UltraHDMI mod + EverDrive 64 X7 setup."

[Author]

Posts