Bug Tracking for Gacha Games

Gacha games put real money behind random outcomes, which raises the stakes on every bug. A pull that does not respect the advertised rate, a pity counter that resets when it should not, a currency balance that does not match what the player spent, or a result the client shows but the server never recorded, each of these is not just a glitch but a trust and potentially a refund issue. Because the server is the source of truth, tracking these bugs is as much about reconciling client and server records as it is about code. This post covers the bugs specific to gacha and the context that resolves them.

Pull rates and the RNG players scrutinize

Gacha players track drop rates obsessively, and any deviation from the published numbers becomes a public controversy quickly. Real bugs do occur: a banner configured with the wrong rate-up pool, a weighting table that sums to slightly more or less than one, or a featured unit that is not actually in the pool it advertises. These are not RNG variance, they are configuration and logic errors, and they affect every player who pulls on that banner until caught.

The trap is that players also report bad luck as bugs, so you need authoritative data to tell genuine bugs from variance. Capture the banner identifier, the pull request and its server-recorded result, and the rate table that was live at that moment. A player who feels cheated may simply have hit a cold streak, but if the recorded results across many reports skew from the configured table, you have a real rate bug. The server-side pull record is what lets you distinguish a true misconfiguration from a statistically normal run of bad luck.

Pity counters and guarantee logic

Pity systems promise that after a certain number of pulls a player is guaranteed a high rarity result, and they are central to how players budget their spending. The counter logic is deceptively tricky: it has to increment per pull, reset on the right trigger, sometimes carry across banners, and interact with guaranteed-featured mechanics. Bugs here are severe because they touch the explicit promise the game made. A counter that resets a pull early, fails to carry over, or grants the wrong tier at the threshold directly contradicts what the player was told.

These bugs require the pity count before and after the pull, the banner, and which pity rule was in effect. A player reporting they hit pity but got the wrong result needs their counter history checked against the server. Capturing the before-and-after pity values with each pull lets you trace the exact pull where the counter diverged from the rule. Because pity often carries across banners, the banner context matters too, since a carry-over bug only appears at the seam between one banner ending and another beginning.

Premium currency and accounting integrity

When real money is involved, currency accounting has to be exact. Players buy premium currency, spend it on pulls, and earn smaller amounts through play, and every transaction must reconcile. Bugs that lose currency are refund-generating emergencies, and bugs that grant currency are exploits that cost revenue. A pull that deducts currency but fails server-side, a double-charge from a retried request, or a balance that the client and server disagree on all undermine the financial trust the game runs on.

The essential context is the server-side transaction log: the balance before, the amount changed, the balance after, and the unique request identifier. The request ID is what catches double-charges, since a retried network call should be idempotent and only apply once. A player reporting missing currency needs their transaction history reconciled against the server ledger. Capturing the request and response IDs with the balances turns a he-said-she-said dispute into a clean audit where you can see exactly which transaction failed or applied twice.

Client and server desync

Gacha games are client-server by nature, and the gap between them is where many bugs hide. The client animates a pull and shows a result, but the server is authoritative. A flaky connection at the moment of a pull can leave the client showing one thing while the server recorded another, or nothing at all. Players see a five-star drop, the connection hiccups, and on relog the unit is gone, because the client predicted a result the server never confirmed. These desyncs are among the most upsetting bugs a gacha player can hit.

Resolving them requires both sides of the exchange: the request the client sent, the response the server returned, the connection state, and the timestamps. A report that pairs the client-displayed result with the server-recorded outcome shows the desync directly. Capturing the request and response identifiers lets you look up the authoritative server record and confirm whether the player's missing unit was ever granted. The fix is usually to make the client trust the server result on reconnect, but you can only design that correctly once you can see the desyncs clearly.

Setting it up with Bugnet

Bugnet's in-game report button captures game state automatically, and for a gacha game the most valuable thing it attaches is the transaction context. When a player reports a missing pull or wrong pity result, the report can carry the banner, the pull request and response IDs, the pity count before and after, the currency balance, and the connection state. Instead of a screenshot of an empty inventory and an angry message, you get the identifiers that let you look up the authoritative server record and resolve the dispute from data rather than guesswork.

Occurrence grouping is critical when a misconfigured banner or a bad pity rule goes live, because it affects everyone who pulls. Grouping folds the flood of reports into one issue with a climbing count, so you see the scale of a rate bug immediately rather than triaging hundreds of tickets. Custom fields let you filter by banner or by currency type, and player attributes let you separate genuine misconfigurations from individual bad luck. That single dashboard view is what lets a small team respond to a monetized bug fast enough to protect player trust.

Protecting trust through testing and transparency

The most important practice for a gacha game is to test the money-touching paths relentlessly. Automate verification that every banner's configured rate table sums correctly and contains the advertised units, that pity increments and resets follow the published rule across banner seams, and that currency transactions are idempotent under retried requests. These checks should run before any banner goes live, because a rate or pity bug that reaches players becomes a public trust crisis, not just a support ticket.

Pair rigorous testing with transparency in how you handle reports. When a captured server record shows a real bug, make the player whole quickly and visibly, and add that exact scenario as a regression test. Because players scrutinize rates and pity so closely, being able to answer a dispute with the authoritative transaction log, and to fix genuine bugs fast, is what sustains the trust the whole business model rests on. Treat every currency or pity report as a potential trust event, and your retention will reflect that care.

Gacha bugs are money bugs. Capture the server-side transaction, pity, and pull records, and disputes resolve from authoritative data instead of guesswork.