Bug Reporting for Games With Crafting and Recipes

Crafting looks simple from the menu, combine some materials, get an item, but underneath it is a transaction that reads from inventory, matches a recipe, consumes inputs, and writes outputs, and any slip in that sequence corrupts the player's stuff. The stakes are unusually high because crafting bugs touch the economy directly: a duplication bug can let players mint infinite resources and wreck a survival game's balance, while a consumption bug can silently eat rare materials and infuriate them. Reproducing these means capturing the exact inventory and recipe state around the craft. This post is about what state to grab so a duplicated or vanished item becomes a reproducible defect.

A craft is a transaction that can corrupt state

Think of every craft as a small transaction: it checks that the inventory holds the required materials, removes them, and adds the result. Like any transaction it can fail partway. If the code removes the inputs and then an error stops it before adding the output, the player loses materials for nothing. If it adds the output and then fails to remove the inputs, the player has duplicated value out of thin air. Both halves matter, and the bug is almost always that the consume step and the produce step are not atomic, so a failure between them leaves the inventory in an impossible state.

This is why a screenshot of the crafting menu tells you nothing useful. The bug lives in the before-and-after of the inventory, not in the menu art. What you need is the inventory state immediately before the craft and immediately after, so you can see precisely which stacks decremented and which appeared. A craft that consumed three iron but produced no tool, or one that produced a tool while the iron count never dropped, is instantly diagnosable from those two snapshots, and almost impossible to diagnose without them.

Inventory state with stack counts is the core data

The single most important thing to capture is the full inventory with exact stack counts, because crafting bugs are fundamentally about quantities changing wrongly. Item IDs alone are not enough; you need how many of each the player held, since the bugs hide in off-by-one decrements, stacks that split incorrectly, or a partial stack that the consume logic rounded the wrong way. Capture the inventory as a structured list of item IDs and counts, ideally with the slot layout if your game cares about placement, so you can reconstruct the player's bags exactly.

With that data, duplication and loss bugs reveal themselves as arithmetic. You compare the before and after counts against what the recipe specifies should change, and any discrepancy is the bug. A stack that grew by more than the recipe's output points at a duplication path; a material that dropped by more than the recipe consumed points at over-consumption. Capturing stack counts also catches the subtle stacking bugs where crafting interacts badly with a full inventory or a stack at its size limit, which is a classic place for items to silently vanish or overflow.

Recipe matching and the wrong combination

The other half of crafting is recipe matching, the logic that decides which recipe a set of materials makes. Bugs here produce the wrong output or no output at all. If two recipes share ingredients and the matcher picks by the wrong priority, the player gets the cheaper item when they wanted the better one, or a shapeless recipe matches when a shaped one should have taken precedence. Ambiguous matching is especially error-prone in grid-based crafting where placement matters, because the same items in different arrangements are supposed to mean different things.

So capture the recipe the player attempted and the one the system actually matched, along with the materials and their arrangement. When those two recipes differ, you have found a matching bug directly. Logging the candidate recipes the matcher considered helps even more, since it shows why the wrong one won. Recipe bugs are deterministic given the inputs, so once you have captured the exact materials and arrangement, you can drop them into a test and watch the matcher misfire every time, which makes the fix to the matching priority straightforward to verify.

Duplication exploits and economy damage

Duplication is the crafting bug that does real damage, because players will find it, share it, and use it until your economy is meaningless. The classic vectors are all about timing and state: crafting while a network message is in flight so the consume and produce happen on different state versions, canceling a craft at the exact frame the output is granted, or splitting a stack during the transaction so the count is read twice. These exploits are deliberate once discovered, so you want to detect them proactively rather than wait for the economy to inflate and the reports to flood in.

Instrument the invariant that crafting should conserve or reduce total value, never create it from nothing beyond the intended output. When a craft transaction ends with more value than it should, capture the full state automatically, because that is almost certainly a duplication path. Logging the timing of inputs around a craft, especially cancels and stack operations, gives you the sequence that triggers the dupe. Treating value creation as an alarm condition means you find the exploit from your own telemetry before a video tutorial finds it for you, which in a multiplayer or persistent game is the difference between a hotfix and an economy reset.

Setting it up with Bugnet

Bugnet's in-game report button is a strong fit for crafting bugs because it captures inventory and recipe state at the press, not a useless menu screenshot. Push the full inventory with stack counts before and after, the attempted and matched recipe, and the materials and arrangement into custom fields and player attributes. A report that crafting ate my materials then arrives with the two inventory snapshots already attached, so you diff them, see the consume that produced nothing, and reproduce the transaction in a debug build instead of asking the player to remember exactly what was in their bags.

Because a duplication or loss path gets exercised by many players, Bugnet's occurrence grouping folds the duplicate reports of the same broken recipe into one issue with a count, ranking which crafting bug is doing the most economic damage. Filter by the recipe ID or by the item involved and the pattern is immediate: every report on a dupe carries the same recipe and timing. For exploit hunting, the automatically captured state on your value-conservation alarms lands in the same dashboard, so you triage real duplication exploits the moment they trigger rather than after they spread.

Testing crafting as transactional logic

The teams that keep crafting economies healthy test it like the transactional system it is. Write automated tests that run every recipe against representative inventory states, full bags, partial stacks, stacks at their cap, and assert that the resulting inventory matches expectation exactly, with total value conserved aside from the intended output. Seed the suite with every duplication and loss bug you fix, so the off-by-one decrement or the non-atomic consume that once leaked value can never return silently in a later content patch. Crafting bugs are deterministic, which makes them ideal candidates for thorough automated coverage.

Make atomicity a design rule, not an afterthought. A craft should either fully complete, consuming inputs and producing outputs together, or fully roll back, leaving the inventory untouched, with no partial state ever observable, especially across a network boundary. Build that guarantee into the transaction and most loss and duplication bugs become impossible by construction rather than caught after the fact. With state-capturing reports, value-conservation alarms, and a transactional test suite, your crafting system stays the satisfying core loop it is meant to be instead of becoming the place your economy quietly falls apart.

A craft is a transaction, so capture the inventory and recipe state before and after. Duplication and loss bugs then show up as plain arithmetic you can read.