Bug Tracking for Courtroom and Debate Games

A courtroom or debate game turns a conversation into a puzzle. The player presses witnesses, presents evidence against statements, and builds an argument, while the game tracks an elaborate state of what has been said, what has been proven, and which branch the dialogue should take next. That branching machinery, driven by flags and conditions, is where the genre's bugs concentrate. A branch that fires on the wrong flag sends the trial down a path that no longer makes sense, and a flag that fails to set can dead-end the cross-examination entirely. This post is about tracking the dialogue and branching bugs that derail a trial.

Argument state and what has been said

The core of a debate game is a running model of the argument: which statements a witness has made, which the player has challenged, what evidence has been presented, and which contradictions have been exposed. This state grows over a long cross-examination and drives every branch decision. When a flag in it is wrong, the dialogue stops matching the fiction, a character references a contradiction the player never raised, or refuses to accept evidence the player clearly has. These bugs break immersion sharply because the genre depends on the conversation feeling coherent, and the only way to debug them is to capture the full argument state at the point of failure.

Argument state is especially prone to ordering bugs. A statement that can be challenged at multiple points, evidence that becomes valid only after a prior admission, a topic that should unlock after a specific line, all depend on flags being set in the right sequence. Players who probe the dialogue in an unexpected order expose conditions the writers assumed would never be reached early. Capturing the complete set of argument flags, rather than just the current line of dialogue, lets you see that a contradiction was marked resolved before the player ever addressed it, which points straight at a flag set on the wrong branch upstream.

Branching that fires on the wrong flag

Branch conditions are the logic gates of a courtroom game, and a misconfigured condition is the most common bug. A branch meant to fire only after the player proves a point fires early because it checks a flag that gets set too soon, or a key revelation is skipped because its condition checks a flag that was never set. The result is a trial that jumps to a conclusion the player has not earned or loops back over content already cleared. Because branching graphs grow large and interconnected, a single mis-wired condition can send the dialogue somewhere that quietly contradicts everything the player has established.

These bugs are hard to catch in testing because they require reaching a branch through a specific combination of prior choices, and the number of paths through a long trial is enormous. Capturing the branch the player took and the flag state that drove the condition lets you replay the decision and see exactly why the wrong branch was chosen. A report that the trial made no sense after I presented the evidence becomes tractable when you can see that presenting that evidence set a flag a later branch misread. The branch plus the flags is the evidence you need to convict the bug.

Dead ends and unwinnable trials

Like detective games, courtroom games are prone to soft-locks, but here the dead end is conversational: the player is in a cross-examination with no statement left to press and no evidence the game will accept, yet the trial will not advance. This usually traces to a required contradiction whose flag never set, so the branch that would move the trial forward can never fire. The player presses every statement and presents every piece of evidence to no effect, with no feedback that the path is broken rather than that they have the wrong idea, which is a deeply frustrating experience in a story-driven game.

Diagnosing these dead ends requires the full branching context: which statements remain, which evidence is available, and what condition the game is waiting on to advance. With that you can determine whether any valid action exists that would satisfy the next branch, and if none does, identify the flag that should have set but did not. A report carrying the complete dialogue and flag state lets you see that the player needs to present an item against a statement whose challengeable flag failed to register. Treat trial dead ends as a top-severity class, because a player stuck unable to finish a case abandons the story for good.

Reproducing a derailed trial

Reproduction in a courtroom game means recreating the exact dialogue position and argument state the player reached, which a single screenshot cannot carry. A useful snapshot captures every argument and progression flag, the current branch and the dialogue node, the available evidence, and the recent sequence of player choices. With that you load the player's precise position in the trial and step the branching from there. This turns a report about a trial that derailed on loop into a deterministic case you can analyze, fix, and keep as a regression test so the same wrong branch cannot fire again after a script change.

Categorize reports by the failure mode, since players describe confusion rather than cause. Tag them as wrong branch, missing contradiction flag, dead end, or dialogue mismatch where a character says something inconsistent with the state. Once sorted, the clusters point at specific nodes: wrong-branch reports cluster around a particular condition, dead ends cluster at a specific cross-examination, dialogue mismatches point at a flag set out of order. That structure lets a small team treat a confusing pile of the trial broke reports as a set of distinct branching bugs, each locatable to a node or condition in the dialogue graph.

Setting it up with Bugnet

Bugnet's in-game report button can attach a courtroom game's full branching state as custom fields: every argument and progression flag, the current branch and dialogue node, the available evidence, and the recent choices. Arm a guard so that detecting an unadvanceable trial, where no valid action satisfies the next branch, flushes a report automatically with that state. If the branching logic throws on an unexpected flag combination, the crash report arrives with a stack trace and device context. A complaint that the trial made no sense becomes a snapshot showing exactly which branch fired wrong or which contradiction flag never set.

Occurrence grouping then ranks branching bugs by how many players they catch. Reports of the same wrong branch firing fold into one issue with a count, and dead ends at a particular cross-examination cluster into a high-severity issue you can filter by the dialogue-node custom field, all from one dashboard. The captured flag state lets you confirm whether the argument layer or a branch condition failed without replaying the whole trial yourself. Instead of triaging story-breaking reports by guesswork, you let the snapshots and the occurrence count point straight at the condition or flag that derailed the case.

Testing the dialogue graph

Treat the trial as a branching graph and test its reachability. Build an automated walker that traverses the intended paths, making the choices and presenting the evidence a solving player would, and assert that each branch fires on the correct flags and that the trial reaches its verdict. Then fuzz the order of presses and presentations, because the real bugs appear when players act off the expected sequence, and assert that no reachable dialogue state leaves the trial unadvanceable. A reachability check across the graph catches dead ends and mis-wired branches before a player ever stumbles into one.

Pay special attention to statements challengeable from multiple points and evidence valid under several conditions, since those are where flags set out of order and branches misfire. Keep every reproduced derailed trial as a permanent regression test so a fixed branch cannot break again when the writers extend the case. Done carefully, a courtroom game delivers the tense, coherent drama of a well-built trial, where every contradiction the player exposes lands and the dialogue always makes sense, and the rare branching bug that slips through arrives with a state snapshot naming the exact node that went wrong.

A courtroom game is a branching graph with stakes. Capture the argument flags and the branch taken so a derailed trial becomes traceable.