Bug Tracking for Roguelike Deck-Builders

Roguelike deck-builders are combinatorial machines. A player assembles a deck, stacks relics, and triggers chains of effects that even you, the designer, never explicitly tested together. When something breaks, it is almost never a clean crash. It is a card that doubled a buff it should have added, an infinite loop of triggers, or a run state that desynced after a particular relic fired at a particular moment. None of that reproduces from a sentence of description. This post is about capturing enough of the run, the seed, and the action history that you can replay the exact sequence and see the bug for yourself.

The combinatorial explosion of card interactions

The core difficulty of a deck-builder is that every card and relic is a small rule, and the bugs hide where two or three rules interact in an order you never anticipated. A relic that triggers on card play, a card that plays another card, and a buff that scales with cards played can together produce a number you never intended or a trigger loop that hangs the turn. The space of combinations is far too large to test exhaustively, so a meaningful fraction of your bugs will arrive from the field.

Because these are emergent, the report has to carry the full ingredient list, not just the symptom. Knowing that a player saw a damage number of forty thousand tells you nothing. Knowing the exact deck, the relics in the order acquired, the card that was played, and the targets involved lets you reconstruct the interaction. The bug is not in any one card. It is in the combination, and you can only see it if the combination travels with the report.

RNG seeds are the key to reproduction

Roguelikes are built on randomness: card rewards, shop contents, enemy patterns, and event outcomes all flow from a seed. That same seed is your most powerful debugging tool, because a run is deterministic given its seed and the player's choices. If a report captures the seed plus the sequence of decisions, you can replay the run to the exact encounter and reproduce a bug that would otherwise be a one in a million coincidence.

The catch is that a seed alone is not enough if your RNG advances based on player actions, which it should. You need the seed and the action log together, because the random stream only lands the same way if the same choices are made in the same order. Capture both and a bug that the player swears happened becomes a run you can load and watch. Capture neither and you are reduced to asking the player to remember a forty turn run, which never works.

Run state and where it desyncs

A deck-builder run accumulates a lot of state: current health, energy, the draw and discard piles, status effects on every combatant, relic counters, and ascension or difficulty modifiers. Bugs frequently come from this state desyncing, where the visible board and the underlying model disagree, or a status that should have expired persists, or a counter that should reset carries over between encounters. These are exactly the bugs that screenshots cannot capture, because the corruption is in the model, not the picture.

So the report needs a snapshot of the run model at the moment of failure, not just the screen. The contents of both piles, the active statuses with their stacks and durations, the relic counters, and the current encounter give you the state to diff against what it should be. When a player reports that an enemy took a turn it should not have, the status and intent data in that snapshot tells you whether the bug is in expiry, in turn order, or in the intent calculation, without a single round of guessing.

Triage by combo, not by symptom

Many distinct reports in a deck-builder are really the same underlying interaction seen from different angles. Three players with different decks hit the same broken relic trigger and describe three different symptoms. If you triage by symptom you treat them as three bugs. If you can group by the actual interaction, by the cards and relics involved, you see one bug with three reports and a clear pattern of what combination sets it off.

Grouping also surfaces severity honestly. An interaction that softlocks the turn for one in a thousand runs matters far less than a combo that lets a common starter relic trivialize the game, even if both generate angry posts. Occurrence counts on grouped reports tell you which combos players are actually hitting, so you spend your limited time on the interaction that affects the most runs rather than the one that happened to get the loudest forum thread.

Setting it up with Bugnet

Bugnet gives a deck-builder an in-game report button that snapshots the run when a player hits something wrong. Instead of a vague message, you receive the seed, the full deck and relic list, the current encounter, the contents of both piles, the active statuses, and the recent action log, all captured automatically as custom fields and player attributes. That is precisely the state you need to replay the run, so a combo bug arrives as something you can load rather than something you have to reconstruct from memory.

If a card interaction throws an exception or hangs a trigger loop, crash reporting captures the stack trace and the same run context together. Occurrence grouping folds the reports that share an interaction into one issue with a count, so the relic combo a thousand players hit rises above the one a single player found. You filter by seed, by relic, or by any custom field you attach, prioritize by count, ship the fix, and watch the occurrences for that combo stop arriving.

Build reproduction into your release habit

The teams that stay sane shipping deck-builders treat seed-and-log capture as a non-negotiable part of every build, because the alternative is begging players to remember runs. Make sure your report button records the seed and action history even in release builds, and test the loop by loading a captured run and confirming it reproduces the reported state. A capture pipeline you have never replayed from is a pipeline you do not actually have.

Watch the grouped occurrence list as you add content, because every new card and relic expands the interaction space and quietly creates new combos to break. A spike in reports for a particular relic right after a patch is your fastest signal that the latest card interacts badly with something old. A deck-builder that captures the seed, the run state, and the action log, and groups bugs by interaction, turns its own combinatorial chaos into a set of runs you can load, watch, and fix.

Deck-builder bugs live in combinations, not screenshots. Capture the seed, the run model, and the action log so any combo can be replayed, and group by interaction to fix what matters.