Server-Side Hitscan vs Ballistic Projectile Registration: Edge Cases, Failure Modes, and Root-Cause Debugging

[Jake Walker]

We’ve been running our own matchmaking backend for a custom competitive title, and I keep hitting walls with how we register hitscan versus ballistic weapons server-side. For hitscan we’re doing a swept AABB against the server’s authoritative simulation, but once we introduced weapons with bullet drop and velocity falloff, we started simulating trajectory with explicit Euler integration at a fixed 30Hz tick. The problem: at range, the client’s predicted trajectory diverges from the server’s reconstruction by enough to register shots as whiffs on what feel like clean taps. How are you all handling fixed-timestep integration drift between client prediction and server reconciliation, and is explicit Euler even the right call, or should we be stepping up to RK4 or Verlet for the ballistic arc?

On the CPU budget side, per-shot trajectory sampling against every entity in range is eating our server headroom during large fights. Are you spatially culling with a coarse grid or BVH before the expensive path integration, and where have you drawn the line on sub-stepping for drop calc without blowing past a single tick’s CPU allowance? Any of you hit genuine failure modes—like shots registering through walls due to sampling gaps, or the reverse—when tuning this? Curious what production setups actually ship for the drop threshold and how you debug the edge cases where registration feels wrong.

"[Audio: Sennheiser HD 560S + FiiO K5 Pro] • [RX 7900 XTX]"

[Dean Bailey]

Here’s where most people get tripped up: hitscan and ballistic systems fail in completely different ways, so you can’t debug them with the same checklist. For hitscan, the server is doing a raycast from the weapon’s origin (or the corrected aim origin if you’re using server-side aim correction) and testing against the target’s authoritative hitboxes. The classic failure modes are: (1) the client’s predicted firing timestamp doesn’t align with the server’s authoritative snapshot, so you get “phantom hits” that register a kill but the server disagrees, or (2) hitbox/hit-translation desync where the client renders hitboxes at a different interpolation delay than the server samples them. The tell is usually timing-dependent—shots feel “sticky” at high ping but break at low ping, which points at your interpolation buffer or your cl_interp/tick alignment rather than the raycast logic itself. Always replay from the server’s authoritative trace, not the client’s prediction, because the client

"Ryzen 9 7950X3D | RTX 4070 Super | Lian Li O11 Dynamic EVO"

[Mason Roberts]

The core distinction that trips people up is that hitscan and projectiles fail in fundamentally different ways, so your debugging approach needs to change per system. For hitscan, the vast majority of “my shot connected but didn’t register” complaints are actually interpolation artifacts, not server lies. The server is authoritative and casting its raycast off the last snapshot it received—typically 40-80ms behind your live render depending on your lerp buffer. So when you see an enemy dead-on-your-screen get a kill,

[Rig: Ryzen 5 7600X & RTX 4090 24GB] • [Display: ASUS ROG PG27AQDM 240Hz OLED]

[Author]

Posts