Bug Tracking for Roguelike Card Battlers

A roguelike card battler is a combination engine. You design cards, relics, and modifiers with individual rules, then hand players a seeded run and let them assemble interactions you never explicitly imagined. That emergent depth is the genre's whole appeal, and it is also a bug factory, because the number of card combinations is far larger than anything you can test. The signature bug is the unintended interaction: two cards whose triggers chain into an infinite loop, a relic that makes a calculation go wrong, an ordering of effects that produces a result you never intended. Because runs are seeded and combos are specific, these bugs are slippery to reproduce unless you capture the right state. This post is about doing exactly that.

Bugs are emergent, not designed

In most genres you can enumerate the situations your code handles. In a card battler you cannot, because the interesting states are combinations the player builds at runtime from your card pool. You wrote each card's rule in isolation, but the player stacks five of them with three relics and a status effect, and the resulting interaction is something no one on your team ever typed out or tested. Most of the time that emergence is the fun. Sometimes it is a bug, an interaction that loops, overflows, deadlocks, or computes nonsense, and it lives in the combinatorial space between cards rather than in any single card's code.

This changes how you think about bug reports. A player who found a broken combo did something you did not anticipate, and reproducing it means recreating the exact set of cards, relics, and modifiers they had, in the exact order they played them. A description like my combo broke the game is true and useless without the components. The bug is defined by the combination, so tracking it means capturing the combination precisely. You are not debugging a feature, you are debugging an interaction that only exists because a player assembled it, and you have to assemble it again to see it.

Trigger order and infinite loops

The classic card battler bug is the trigger chain that will not stop. Card A triggers when card B resolves, B triggers when a creature takes damage, the damage triggers A again, and the loop spins forever, freezing the game or running a counter to infinity. These loops are pure emergence: each card is correct alone, but together they form a cycle. They are also a known hazard of the genre, which is why robust card systems put guardrails around trigger resolution, loop detection, iteration caps, and an explicit, documented order in which simultaneous triggers fire, because ambiguous ordering is itself a rich source of wrong results.

Trigger order matters even when nothing loops. When several effects fire at once, the order in which they resolve changes the outcome, and a player who expected one order while your engine used another reports a bug that is really an ordering ambiguity. To diagnose either the loops or the ordering disputes, you need the sequence: which cards triggered, in what order, with what state between each step. A snapshot of the final wrong result is not enough, because the bug is in the path, not the destination. Capturing the trigger sequence turns an impossible-looking outcome into a step-by-step chain you can follow.

Seeds and run state make it reproducible

Roguelikes are built on seeds: the run, the card offerings, the enemy patterns, the rewards all derive from a seed so that a run is, in principle, reproducible. That is a powerful debugging asset if you capture it. The seed plus the player's choices reconstructs the entire run, every card they were offered and took, every relic, every encounter, leading to the exact state where the bug fired. Without the seed you are trying to rebuild a specific run by hand from a vague description; with it, you can fast-forward to the precise board and watch the broken combo execute deterministically.

But the seed alone is not enough, because the run state also depends on the player's decisions along the way. You need the seed plus the deck, the relics, the current encounter, the resources, and the recent card-play and trigger sequence. Together these fully specify the moment the bug occurred. The deck and relic loadout in particular is the heart of a card-battler bug, since that is the combination that produced the emergent interaction. Capturing the full run state alongside the seed converts the genre's most unreproducible reports, the one-in-a-thousand broken combos, into deterministic test cases you can replay on demand.

Economy and reward bugs warp a run

Beyond combat, a roguelike run is also an economy: gold, card rewards, shop prices, relic drops, and the choices a player makes between fights. Bugs in that layer are quieter than a frozen combo but just as damaging to a run. A reward screen that offers the wrong rarity, a shop that misprices or fails to remove a purchased item, a relic drop that ignores its rules, all distort the run in ways players feel as unfair even when nothing visibly errors. And because the economy compounds across a run, a small error early snowballs into a run that is trivially easy or impossibly starved.

These bugs are tied to the seed and the path just like combat bugs, so the same capture serves them. To reproduce a wrong reward you need the run seed, the point in the run, the choices made so far, and the state of the player's resources. A report that the shop was broken means little without knowing which shop, at what run depth, with what gold and what offerings. Capturing the economic state alongside the combat state ensures the whole run is reproducible, so a reward or shop bug becomes as debuggable as the loops and ordering issues, rather than a vague complaint about a run that felt off.

Setting it up with Bugnet

Wire the Bugnet SDK in and the in-game report button captures the run context these bugs demand: the run seed, the full deck and relic loadout, the current encounter and resources, and the recent card-play and trigger sequence, all attached automatically when a player flags a broken combo. Instead of a useless my combo broke the game, you get the exact components and order needed to replay the interaction and watch the loop or the wrong calculation happen deterministically, so an emergent one-off becomes a fixed, debuggable scenario from a single report.

Use custom fields for the run seed, the relic set, and game version, then filter the queue to see whether a broken interaction clusters around a specific card or relic. Occurrence grouping folds many players discovering the same loop into one issue with a count, so a widely found broken combo rises above the truly rare flukes. From one dashboard you can replay the captured seed and loadout, follow the trigger sequence step by step to find the cards whose interaction misbehaves, and fix the rule or add the guardrail rather than guessing at a combination you could never have predicted.

Add guardrails and fuzz the combinations

The engineering culture that tames the genre starts in the card system itself. Build loop detection and iteration caps into trigger resolution so an infinite combo fails safely instead of freezing the game. Define and document a deterministic order for simultaneous triggers so outcomes are predictable and ordering disputes have a single correct answer. Make the whole run deterministic from the seed so that captured reports replay exactly. These guardrails do not eliminate emergent bugs, but they turn the catastrophic ones, the freezes and overflows, into handled, observable failures you can report on.

Then attack the combinatorial space before players do. Fuzz the card system by generating random decks and relic sets and auto-playing them through encounters, watching for loops, exceptions, and invariant violations. You cannot test every combination, but you can test enormously more than manual play covers, and the loops and overflows tend to surface quickly under fuzzing. Combine that with seeds captured from the field and a replay tool, and you get a loop where players who break the game in delightful or terrible ways hand you a deterministic test case, and you fix the interaction while keeping the emergent depth that makes the genre worth playing.

Card battler bugs are emergent combinations, not designed cases. Capture the seed and full loadout so a one-in-a-thousand broken combo replays deterministically as a test case.