Bug Reporting for Games With Lag Compensation

Lag compensation is the reason a shot fired on a laggy connection can still register, and the reason players sometimes get killed after diving behind cover. The server rewinds its view of the world to the moment the shooter actually pulled the trigger, validates the hit against where targets were then, and applies the result. It is the system that makes online shooters playable, and it generates some of the most contentious bug reports you will ever read. The problem is that a phantom hit looks like cheating to the victim and a missed point-blank shot looks like a broken hitbox to the shooter. Both are usually timing. This post covers what to capture so you can tell.

What lag compensation actually rewinds

When a client fires, it stamps the shot with the tick it believes it is on and the targets it saw on screen. The server receives this slightly later and rewinds every relevant entity back to the position it held at that tick, then runs the hit test against the rewound world. This favor-the-shooter model means the shooter's reality wins: if the target was in their crosshair on their screen, the hit counts even though the target has since moved. That is by design, and it is also why the victim, who has already moved, perceives an impossible hit.

The rewind is bounded by a maximum window, often a couple hundred milliseconds, to limit how far into the past a shot can reach. Bugs cluster at the edges of this window. If the server picks the wrong rewind amount, it validates against positions that never matched the shooter's screen, producing whiffs at point blank or hits through walls. Reproducing this requires knowing exactly how far back the server rewound and what the world looked like there, which no screenshot can tell you.

Phantom hits and the victim's perspective

The classic phantom hit report comes from the victim: I was clearly behind the wall and still died. From the server's point of view this may be completely correct, because the shooter fired while the victim was still exposed and the kill was validated against that earlier moment. The victim's local view had already advanced past it. To adjudicate this you need both timelines: the shooter's fire tick and the victim's position at that tick on the server, compared against where the victim believed they were.

Sometimes the victim is right and it is a real bug: the rewind reached past its window, or a hitbox lagged its visual model so the server validated against a hurtbox that no longer matched the rendered character. The only way to distinguish a correct favor-the-shooter outcome from a genuine defect is the captured rewind state. Without it you are stuck mediating between two players who each saw a different truth, and neither of them is lying about what they saw.

Hitbox and animation desync

Lag compensation rewinds positions, but it also has to rewind hitboxes, and hitboxes are often driven by animation. If the server stores rewound transforms but recomputes hitboxes from the current animation pose, the validation runs against a body in the wrong stance. A player crouching, vaulting, or in a hit reaction has a very different silhouette frame to frame, and a mismatch of a single animation frame can turn a clean headshot into a miss. Capturing the animation state at the rewound tick exposes this immediately.

Record both the rewound root position and the rewound pose or the bounding volumes the server actually tested. If the position rewound correctly but the pose did not, the report tells you the bug is in how you snapshot animation history, not in the rewind itself. This distinction saves enormous time, because the two fixes live in completely different parts of the codebase and a report that conflates them sends you hunting in the wrong file for a day.

Latency, clocks, and the rewind amount

The rewind amount is computed from the shooter's measured latency, so a bad latency estimate produces a bad rewind. Spikes, jitter, and clock drift all corrupt that estimate. Every lag-compensation report should carry the shooter's round-trip time at the moment of the shot, the rewind amount the server chose, the fire tick, and the server tick when the shot was processed. With those four numbers you can check whether the rewind matched the latency or whether the server reached too far or not far enough.

Clock synchronization deserves special attention. If the shooter's tick estimate has drifted from the server's, the fire tick points at the wrong moment and the rewind validates against a world the shooter never saw. This drifts slowly and shows up as a gradual increase in disputed hits over a long match. Logging both clocks at report time turns a slow, maddening trend into an obvious offset you can correct in the time-sync code rather than the hit-test code.

Setting it up with Bugnet

Bugnet's in-game report button is ideal for lag-compensation disputes because it captures the surrounding game state the instant a player flags a bad hit. Bind it to serialize the lag-comp context: the fire tick, the shooter's round-trip time, the rewind amount, and the rewound positions and poses the server validated against. Capture this on both the shooter and the victim so a single occurrence can carry both timelines. Add player attributes for region and ping bucket. That one snapshot replaces an unwinnable argument between two players with a reproducible record of what the server actually did.

Because the same edge case tends to fire across many matches, Bugnet's occurrence grouping folds duplicate disputes into one issue with a count, so you can see that hits through a specific doorway recur rather than treating each as a one-off. Use custom fields for rewind amount and latency bucket, then filter to find whether disputed hits cluster at high ping or on one map. One dashboard turns a flood of he-shot-me-through-a-wall reports into a prioritized list of timing defects.

Validating lag compensation over time

Lag compensation is a tuning surface as much as a feature, so treat the disputed-hit rate as a metric you watch every build. Set up internal playtests across a range of simulated latencies and have testers flag any hit that felt wrong with a full state capture. The captured rewind windows let you confirm the server validated against the right moment, and they reveal tuning issues, like a maximum window that is too generous, long before players turn them into complaints about being shot around corners.

As your captures accumulate, you can compute how often the rewind amount matched the measured latency and how often disputes correlated with clock drift. These numbers tell you whether your time synchronization, your hitbox history, or your window tuning needs attention. A shooter that feels fair is a shooter where the rewind is right far more often than it is wrong, and the only way to know that ratio is to measure it from real reports instead of guessing from the loudest forum thread.

Lag-compensation bugs are timing bugs. Capture the fire tick, the rewind amount, and the rewound world, and most disputed hits explain themselves.