Bug Reporting for Games With Interest Management

Interest management is how a multiplayer game scales: instead of telling every client about every entity, the server replicates only what each player needs to know about, based on proximity, line of sight, or a spatial grid. It saves bandwidth and prevents wallhacks, and it produces a category of bug that is uniquely frustrating because no two players see the same thing. One player reports an enemy that appeared out of nowhere; another reports an item that vanished; a third sees a ghost that should have been culled. These are all relevancy bugs, and you cannot reproduce them without knowing what each client's interest set actually contained. This post covers how to capture that.

Why relevancy bugs are per-client

With interest management, the world the server simulates is not the world any single client sees. Each client receives a filtered slice based on its area of interest, and that slice changes every time the player moves across a cell boundary or another entity enters their radius. A bug is almost always a wrong slice: an entity that should have been included was filtered out, or one that should have been culled was sent. Because the slice is per-client, the same moment looks correct to everyone except the affected player, which makes shoulder-surfing and shared repro steps nearly useless.

This is what makes a plain description like an enemy appeared out of nowhere so hard to act on. The enemy did not teleport; it crossed into the player's area of interest and the server began replicating it, but later than it should have, so the player saw a pop instead of a smooth approach. To fix it you need to know when the entity became relevant, when the client first received it, and where the player was at each of those moments. That gap is the bug, and it only exists in one client's relevancy timeline.

Capture the relevancy set, not just the symptom

The core artifact for an interest-management bug is a snapshot of the affected client's relevancy set at the failing tick: the list of entity IDs the server considered relevant to that client, the client's position and area-of-interest radius, and the cell or grid node it occupied. Pair this with what the client had actually received, because a discrepancy between what was relevant and what was replicated is the bug itself. An entity in the relevant set but missing from the client tells a very different story than one that was never relevant.

Include the recent history of relevancy transitions for the entity in question: when it entered and left the client's interest, and any cell boundaries crossed. Pop-in bugs are usually a timing problem at a boundary, where the entity became relevant a few ticks before the server actually started sending it, or where a priority queue deferred a low-priority entity for too long. The transition log turns the vague pop into a precise interval you can replay, and it tells you whether the bug is in relevancy calculation or in replication scheduling.

Culling, line of sight, and false negatives

Many games cull entities behind walls so players cannot see through them, computing visibility from the player's position. A false negative here, culling something the player can actually see, produces the invisible-enemy report that feels like the worst kind of unfairness. The cause is often a stale or coarse visibility query: the occlusion test ran against last tick's position, or the player peeked a corner faster than the relevancy update could keep up. Capturing the visibility inputs at the failing tick is what exposes this.

False positives are the inverse and just as serious: an entity that should be hidden gets replicated, handing one player information the design intended to deny. This is both a fairness bug and a competitive-integrity bug, and it is easy to miss because nothing visibly breaks for the player benefiting from it. The only reliable way to catch it is to log, for spot checks, the full relevancy set and compare it against a ground-truth visibility computation. Reports that include the relevancy set let you audit these cases instead of waiting for a leak to be discovered.

Position, tick, and the server's view

Every relevancy bug report needs the failing tick and the positions of both the observer and the entity in question on the server at that tick, not just on the client. The whole point of interest management is that the client's view is incomplete, so the client's own report of where things were is, by definition, missing the entity that got filtered. The authoritative positions tell you whether the entity truly was within range and whether the relevancy decision was correct given the real geometry.

Also capture the relevancy update rate and any throttling in effect. Many systems update interest sets less frequently than the simulation tick to save cost, so a fast-moving entity can outrun its own relevancy update and appear to pop. If the report shows the entity moved several cells between relevancy updates, the fix is to raise the update rate for fast objects or to predict their next cell, not to touch the culling math. Without the update-rate context you would chase the wrong system entirely.

Setting it up with Bugnet

Bugnet's in-game report button captures game state the moment a player flags something, which for interest management means you can serialize the client's relevancy set right when they shout that an enemy appeared from nowhere. Wire the button to record the relevant entity IDs, the client's position and interest radius, the occupied grid cell, the failing tick, and the recent relevancy transitions for nearby entities. Add player attributes for the map and region. That snapshot captures the one client's view that no teammate could reproduce, which is exactly what a per-client bug requires.

Interest-management defects often recur at the same map locations, like a doorway or a ridgeline where the grid resolution is too coarse, so Bugnet's occurrence grouping folds those duplicate reports into one issue with a count and shows you the hotspots. Use custom fields for grid cell and entity count, then filter to find whether pop-in clusters in dense areas where your replication priority queue is saturated. One dashboard turns scattered I-saw-a-ghost reports into a map of exactly where your relevancy system is straining.

Stress-testing interest management

Relevancy bugs hide until the world is crowded, so test at population. Spawn far more entities than a normal match, cluster players at chokepoints, and have testers flag every pop, vanish, or impossible sighting with a full relevancy capture. Density is where priority queues overflow and update rates fall behind, and it is precisely the condition a quiet two-player test will never reproduce. The captures from a stress test give you the saturation behavior of your system before a launch-day crowd does it for you.

As captures accumulate, track how often the replicated set diverged from the relevant set and where those divergences cluster. A rising divergence rate under load means your scheduling needs more headroom or smarter prioritization. Treat relevancy correctness as a measurable property of the build, not a vibe, and you can ship interest management that scales smoothly instead of discovering at peak concurrency that half your players are seeing a different game than the other half.

Relevancy bugs live in one client's view. Capture that client's interest set and the server's real positions, and the invisible enemy becomes reproducible.