Bug Tracking for Match and Merge Games

Match and merge games look like the simplest thing in the world: line up tiles, merge them, watch the numbers climb. That simplicity is a trap for the developer. The grid is a small state machine with a surprising number of edge cases, the merges cascade in an order that has to be exactly right, the random spawns must be reproducible if you ever want to debug them, and the rewards grow into big numbers that strain your integer math. A tiny error in any of these quietly compounds through the economy. This post is about tracking those bugs with state you can actually replay.

Grid state and merge resolution

The grid is where most match and merge bugs originate, and the good news is that it is fully serializable. A merge bug is almost always a question of resolution order: when several merges become possible in one move, which resolves first, and does resolving one invalidate another. A merge that should have chained but did not, two tiles that merged when they should not have, a board that fills and locks when it should trigger a reshuffle, all flow deterministically from the grid layout and the move. Capture the grid before the move and the move itself, and you can replay the exact resolution.

Edge cases cluster at the boundaries, literally. Tiles at the grid edge, merges that span a full row, special tiles that affect neighbors, and the moment the board is nearly full all expose assumptions in your fall and fill logic. These are precisely the configurations that never appear in a casual playtest and always appear in a report from a player who has been grinding for hours. A serialized grid lets you load that improbable configuration directly rather than trying to grind your own board into the same shape, which could take you longer than the player took to find it.

RNG that you can reproduce

Random spawns are the soul of a merge game and the bane of its debugging unless you make them reproducible. If your spawn RNG draws from an unseeded global source, then a report about an impossible board or a spawn that never gives the needed tile is unreplayable, because the sequence is gone forever. The fix is to use a seeded, per-run generator and to log the seed and the draw count with every report. With the seed you can fast-forward to the exact spawn sequence the player saw and confirm whether the distribution is genuinely broken or just unlucky.

Reproducible RNG also lets you settle the constant stream of complaints that the game is rigged. Players in merge games are acutely sensitive to droughts, and many bug reports are really probability complaints. With the seed captured you can replay the run and measure the actual distribution, which either reveals a real weighting bug or proves the spawn table is fair and the player hit a normal cold streak. Either way you answer with evidence. A merge game without reproducible RNG is a game where you can never tell a bug from variance, and that uncertainty is corrosive to a small team's time.

Big numbers and economy breaks

Merge games trend toward big numbers fast, and big numbers break naive math. A reward that fits comfortably early can overflow a thirty-two bit integer after enough merges, wrapping to a negative or a tiny value and either bricking progress or handing the player infinite resources. Floating point introduces the opposite failure, where large values lose precision and round in ways that make totals drift or display wrong. Decide early whether you need a big-integer or a carefully managed floating representation, and capture the raw numeric values in reports so an overflow shows up as a number, not a vague the count looks wrong.

Because the economy compounds, a small merge or reward error does not stay small. Over-rewarding by a few percent per merge multiplies into a player sitting on resources the game was never balanced for, which then makes every later system feel broken. These economy breaks often trace back to a single miscounted merge much earlier, so capturing the merge sequence and the resulting reward together lets you find the origin rather than just observing the bloated total. Treat any report where the numbers do not add up as a potential economy leak and trace it back to the merge that started it.

Reproducing reported boards

The whole strategy rests on being able to load a reported board exactly. A useful snapshot is compact: the serialized grid, the RNG seed and draw count, the recent merge sequence, and the current economy totals. With that you reconstruct the player's situation in a test harness and step the move. This is dramatically more reliable than a screenshot, which shows you a frozen board but not the move that broke it or the random draws that follow. A loadable snapshot becomes a permanent regression test, so a fixed merge bug cannot quietly creep back in a later build.

Sort incoming reports by their failure type rather than by the player's wording. Tag them as merge resolution, grid lock, spawn distribution, or numeric overflow. Once categorized the clusters are clear: overflow reports all appear past a certain progression milestone, grid locks cluster on near-full boards, distribution complaints spike around a specific tile tier. That structure lets a tiny team make sense of what otherwise reads as an undifferentiated pile of the numbers are wrong messages, and it points each cluster at the specific subsystem that needs the fix.

Setting it up with Bugnet

Bugnet's in-game report button can attach the merge game's full reproducible state as custom fields: the serialized grid, the RNG seed and draw count, the recent merge sequence, and the raw economy totals. Arm a guard so that a reward exceeding a sane ceiling, or a total going negative, flushes a report automatically, catching overflow the moment it happens rather than when a player notices their bricked save. If the resolution logic panics on a malformed board, the crash report carries a stack trace and device context. Rigged complaints become replayable runs with a captured seed.

Occurrence grouping then turns volume into priority. Hundreds of distribution complaints fold into one issue with a count you can investigate by replaying seeds, and overflow reports cluster into a single high-severity issue once they cross your guard. Filter by the progression or tile-tier custom field to confirm an overflow only appears past a milestone, all from one dashboard. Rather than answering every rigged accusation by hand, you let the occurrence count and the captured seeds tell you which complaints hide a real weighting or numeric bug worth fixing.

Testing the economy long

The bugs that matter in a merge game appear late, so your tests have to run long. Build a bot that plays optimal or random merges for the equivalent of many hours, asserting invariants the whole time: totals never go negative, rewards stay within the merge that justifies them, the board never locks without a reshuffle. Short tests pass happily while the thirty-two bit overflow sits a thousand merges out of reach. Seed the RNG in these runs so any failure is reproducible and can become a regression case immediately.

Watch the captured economy totals as a health signal, not just a debugging aid. If real players are accumulating resources faster than your balance assumed, the dashboard will show it before your reviews tank. Keep every reproduced board as a permanent test, and add a numeric ceiling guard to every reward path as a matter of policy. Shipped this way, a match and merge game stays satisfying and fair deep into its big-number endgame, and the rare bug that does slip through arrives with a seed and a grid that lead you straight to its cause.

A merge game is only debuggable if its randomness is reproducible. Seed the RNG, serialize the grid, and guard the big numbers.