Bug Tracking for Detective and Deduction Games

A detective game is a carefully built logic puzzle where the player gathers clues, combines them, and deduces a conclusion that unlocks the next beat. Under the hood it is a state machine: evidence flags get set as clues are found, deduction checks gate progress on the right combination, and the case advances only when the logic is satisfied. That machinery is exactly where the bugs live. A clue that fails to register, a deduction that accepts the wrong pairing, or a flag that never sets can soft-lock the player into a case with no way forward. This post is about tracking those investigation-breaking bugs.

Clue and evidence state

The foundation of a detective game is the set of flags tracking which clues the player has found, examined, and connected. These flags drive everything downstream, so a single one failing to set quietly breaks the logic that depends on it. A clue the player clearly examined but whose flag never flipped means a later deduction will reject the right answer, because as far as the game knows the player never saw the evidence. These bugs are maddening because the player did everything correctly and the game disagrees, and the only way to see the disagreement is to capture the actual evidence flag state at the moment they are stuck.

Evidence state is also rich with ordering and dependency edge cases. A clue that only registers if examined after another, a piece of evidence that can be obtained two ways with only one path setting the flag, a conversation that should unlock a topic but does not, all live in the gaps of your flag-setting logic. These rarely surface in a scripted playthrough that follows the intended path, and always surface when a player explores in an unanticipated order. Capturing the full evidence flag set, not just the current scene, is what lets you see that a critical clue is unregistered despite the player having genuinely found it.

Deduction logic and accusations

The deduction step is where the player combines clues into a conclusion, and its logic has two ways to fail. It can reject a correct deduction, leaving the player certain they are right and unable to proceed, or it can accept an incorrect one, breaking the narrative integrity of the mystery by letting a wrong theory advance the case. Both are serious. A false rejection feels like the game is broken, and a false acceptance undermines the satisfaction of the deduction the whole genre is built to deliver. To debug either, you need the exact deduction the player attempted alongside the clue state that should have validated it.

Deduction systems often involve combining specific evidence pairs or filling in a statement from a list, and the matching logic is where subtle bugs hide. An answer that should match accounts for one phrasing but not an equivalent one, a combination that is checked in one order but not its reverse, a required clue whose flag was the one that failed to set upstream. Capturing the attempted deduction and the evidence state together lets you replay the validation and see whether the logic was wrong or whether it was correctly rejecting an answer built on a clue that never registered, which points the fix back to the evidence layer.

Soft-locks and dead ends

The worst outcome in a detective game is the soft-lock: the player is stuck in a case with no available action that advances it, usually because a required clue was missed or a flag failed to set. Unlike a crash, a soft-lock leaves the game running perfectly while quietly making progress impossible, and players may spend a long time re-examining everything before they conclude they are blocked. Because the genre gates progress tightly on logic, it is especially prone to these dead ends, and a single missed flag early in a case can leave the player wandering for an hour with no feedback that anything is wrong.

Diagnosing a soft-lock requires knowing the full progression state: which clues are registered, which deductions are complete, and what the game considers the next required step. With that you can compute whether any path forward actually exists from the player's current state, and if not, trace back to the missing prerequisite. A report that says I am stuck is hopeless without this, but one that carries the complete case state lets you see that the player needs a clue whose flag failed to set three scenes ago. Treat soft-locks as the highest-severity class, because a player blocked from finishing the story is a player who stops playing entirely.

Reproducing a stuck case

Reproduction in a detective game means recreating the exact investigative state the player reached, which is far more than a save screenshot. A useful snapshot captures every evidence and clue flag, the completed and attempted deductions, the current case progression markers, and the recent sequence of player actions. With that you load the player's precise mental and mechanical position in the case and check whether a valid path forward exists. This converts a vague stuck report into a deterministic state you can analyze and, once fixed, keep as a regression test so the same dead end cannot reopen in a later build.

Categorize reports by the layer that failed, since players describe being stuck without knowing why. Tag them as unregistered clue, false deduction rejection, false deduction acceptance, or soft-lock. Once sorted the patterns emerge: unregistered-clue reports cluster around a specific evidence interaction or examination order, soft-locks cluster at a particular case transition, false acceptances point at a permissive matching rule. That structure lets a small team treat what feels like an opaque pile of I cannot progress messages as a set of distinct, locatable logic bugs, each pointing at the clue system, the deduction matcher, or the progression gate.

Setting it up with Bugnet

Bugnet's in-game report button can attach a detective game's full investigative state as custom fields: every clue and evidence flag, the completed and attempted deductions, the case progression markers, and the recent actions. Arm a guard so that detecting an unreachable state, where no valid action advances the case, flushes a report automatically with that state. If the deduction logic throws on an unexpected combination, the crash report carries a stack trace and device context. A complaint that the player is stuck becomes a snapshot showing exactly which clue went unregistered or which deduction the matcher wrongly rejected.

Occurrence grouping then ranks the logic bugs by how many players they trap. Reports of the same clue failing to register fold into one issue with a count, and soft-locks at a given case transition cluster into a high-severity issue you can filter by the progression custom field, all from one dashboard. The captured flag state lets you confirm whether the clue layer or the deduction layer failed without replaying the whole case yourself. Instead of triaging mystery-breaking bugs by intuition, you let the snapshots and the occurrence count point straight at the flag or rule that is dead-ending your players.

Testing the logic graph

Treat the case as a logic graph and test it as one. Build an automated solver that walks every intended path through a case, examining clues and submitting the correct deductions, and assert that each step sets the flags it should and that the case reaches its conclusion. Then fuzz the order of investigation, because the real bugs appear when players explore off the scripted path, and assert that no reachable state leaves the player without a valid forward action. A solvability check across the full graph catches soft-locks before a player ever wanders into one.

Pay particular attention to clues obtainable by multiple paths and deductions with equivalent phrasings, since those are where flags fail to set and matchers wrongly reject. Keep every reproduced stuck case as a permanent regression test so a fixed dead end cannot silently return when the writers add a new branch. Done with this rigor, a detective game delivers the satisfying, fair deduction the genre promises, where every clue the player finds counts and every correct conclusion advances the case, and the rare logic bug that slips through arrives with a state snapshot that names the exact flag or rule at fault.

A detective game is a logic graph, and one unset flag breaks it. Capture the clue state and the deduction so a stuck case becomes diagnosable.