Bug Tracking for Stealth Action Games

Stealth action games make the player a clear promise: stay hidden, manage what the guards can see and hear, and you remain undetected. The moment that contract breaks, with a guard who spots you through a wall or an alarm that never resets, the entire experience collapses because stealth depends on trusting the rules. These bugs are damaging out of all proportion to how often they happen. This post covers AI detection and awareness, line-of-sight, and sound propagation, and how capturing the complete perception state at the instant detection changed turns a betrayal players cannot describe into a perception failure you can reproduce in the editor.

Why stealth bugs are slippery

What makes stealth bugs slippery is that stealth state is a web of interacting systems: AI perception, awareness meters, line-of-sight checks, sound propagation, lighting, and cover. A detection that looks wrong might be caused by a raycast clipping a thin wall, a sound event that traveled through a closed door, or an awareness value that never decayed from a previous encounter. The player only sees the symptom, the guard turning toward them, and has no way to know which subsystem misfired, so a plain report cannot point your team at the real cause.

These bugs also hurt more than their frequency suggests, which raises the priority of catching them. A single guard who sees through geometry can make players distrust every wall in the game, second-guessing tactics that should be reliable. Because the failure is a momentary state change, reproducing it requires capturing the full perception state at the instant detection changed: every guard's awareness, the raycast results, the lighting on the player, and any sound events in flight. Reconstruct that snapshot and a betrayal becomes a bug; miss it and you are left arguing with a frustrated player about whether it really happened.

AI detection and awareness

Most stealth games model awareness as a meter that fills while a guard perceives the player and drains when perception is lost. Bugs cluster around the transitions: a meter that fills instantly when it should ramp, one that drains too slowly so guards stay alert forever, or a state machine stuck between suspicious and alarmed. Players report these as guards that are psychic or guards that are oblivious. To diagnose them you need the guard's awareness value, its current alert state, and what triggered the most recent change, all captured at the moment of the report rather than inferred afterward.

Group awareness adds complexity. When one guard is alerted, that knowledge often propagates to nearby guards or a central alarm, and the rules for who knows what and for how long are easy to get wrong. A bug might leave one guard permanently alarmed after the rest reset, or broadcast detection to guards who could not possibly have seen anything. Capturing the alert states of every nearby guard, the last known player position they share, and the alarm system status lets your team untangle whether the defect lives in the individual perception or in the propagation network that links the guards together.

Line-of-sight and sound propagation

Line-of-sight is usually raycasts from the guard's eyes to sample points on the player, modulated by distance, viewing angle, and lighting. Bugs here are some of the most damaging: a raycast that passes through a thin collision gap detects the player through a wall, while a vision cone that does not account for crouching or darkness misses a player who should be visible. To reproduce these you need the guard eye position, the player sample points, the lighting value at the player, and whether each raycast reported a hit, ideally with the positions of both endpoints so you can find the geometry the ray slipped through.

Sound propagation is the other half of perception and just as bug-prone. Footsteps, gunfire, and broken glass generate sound events that travel through the level, attenuated by distance and blocked by walls and doors. A common defect lets sound leak through closed doors or ignore walls entirely, so a guard hears a footstep two rooms away. Another lets a loud event fail to register because the propagation graph was not rebuilt after a door opened. Capturing the sound event type, its origin and volume, and which guards received it makes these otherwise invisible bugs concrete and testable.

Setting it up with Bugnet

Bugnet gives you a structured place to record the tangled perception state stealth bugs require. Wire the in-game report button so it fills custom fields with the nearest guard's awareness value and alert state, the player's lighting and crouch status, the result of the most recent line-of-sight check, and any sound event the guard received when a report is submitted. Because Bugnet stores these as searchable fields on one dashboard, you can filter for every detection-through-wall report or every stuck-alarm complaint and find the shared root cause rather than reading reports individually.

Occurrence grouping matters because a single bad raycast in a popular level produces many identical reports. Bugnet folds those into one issue with a count, so a guard that sees through a specific wall surfaces as a high-occurrence ticket you can prioritize. Player attributes such as the level and difficulty let you confirm a perception bug tied to one environment. With labels for detection, line-of-sight, sound, and awareness, a developer opening a stealth bug sees the guard's awareness, the raycast endpoints, and the sound events together, usually enough to reproduce the exact perception failure in the editor.

Building a reproduction workflow

Stealth debugging benefits enormously from visualization and determinism. Add a developer overlay that draws every line-of-sight raycast, the vision cones, the sound propagation paths, and the awareness meters in real time, so when you replay a captured report you can literally see the guard perceive the player. Pair that with deterministic AI by seeding any randomness and recording the player's path and timing, so a report can be replayed to the exact frame where detection went wrong instead of being approximated by hand, which almost never recreates the original sequence of events.

Then drive triage with the data you captured. Cluster reports by which subsystem flagged the change, line-of-sight, sound, or awareness decay, and reproduce the largest cluster first. Maintain test scenarios that exercise perception edge cases, such as crouching behind thin cover, moving through varied lighting, and making noise near closed doors, and run them every build so perception regressions surface before players hit them. With visualization, determinism, and clustering, stealth QA becomes a precise, repeatable discipline rather than a series of unwinnable arguments about fairness.

Make it part of how you ship

Stealth action games rest on a fragile contract between the player and the AI's senses, and every bug in detection, awareness, line-of-sight, or sound chips away at the player's trust. Because these systems interact, no single screenshot can explain why a guard turned around. Bake perception capture into your report button early, so by the time players are stress-testing your levels the awareness values, raycasts, and sound events arrive automatically with every flagged moment.

Treat every unfair-detection report as a window into perception edge cases your testers will never stumble into, because players approach cover, lighting, and noise in ways no script anticipates. Capture the complete perception state at the moment detection changed, route it into one dashboard with a visualization overlay on your side, and vague stealth complaints become reproducible failures. Instrument your perception systems now, and your stealth reports will become the sharpest debugging tool your team has for protecting the trust the whole genre depends on.

Stealth lives on trust in the AI's senses. Capture awareness, line-of-sight, and sound at the instant detection changed, and betrayals become bugs.