Bug Reporting for Games With Gacha and Loot Boxes

Gacha and loot box systems combine three things that demand precision: real money, random outcomes, and a client and server that must agree on the result. When they do not agree, players report that a pull cost currency but gave nothing, that the pity counter did not move, that an item they pulled is missing. These reports carry extra weight because they involve money and player trust, and getting them wrong erodes both. Pull systems are server-authoritative state machines, so their bugs are best handled as audit records you can reconcile. This post covers what breaks in gacha systems and what to capture so a disputed pull becomes a verifiable record rather than an argument.

Pity counters and rate state

Pity systems guarantee a rare result after a number of pulls, and the pity counter is stateful, persistent, and exactly the kind of thing that desyncs. Players report that their pity did not advance, reset when it should not have, or did not trigger the guaranteed drop at the threshold. Each is a divergence between the counter the client shows and the counter the server enforces, or a bug in how the threshold is evaluated. The player sees a broken promise, which is the most damaging kind of gacha bug because pity is the thing that makes spending feel safe.

To diagnose pity bugs you need both the client and server pity counters at report time, the pull history that should have advanced them, and the threshold logic that should have fired. When the client shows a count of eighty-nine and the server shows ten, you have a clear desync and a paying player who is rightly upset. Capturing both counters and the pulls between them lets you reconcile to the authoritative truth and either fix the client display or correct a genuine server-side counting bug, rather than asking the player to trust your word about a number they were watching.

Currency desync and the money trail

Premium currency is the heart of a gacha economy, and currency bugs are the ones that generate refund requests and reviews. A pull might debit currency on the client but not register on the server, or debit twice, or the balances might simply drift after a failed network round-trip. The player reports that currency vanished or a pull was not delivered despite payment, and because real money is upstream of premium currency, you must treat these reports as financial records, not gameplay complaints. The data has to support an audit.

Capture the currency balance on both the client and the server at report time, the pull transaction with its cost and a transaction identifier, and the result the server recorded. With a transaction identifier you can match the player's report to the server-side record and determine definitively whether the pull was charged, delivered, both, or neither. This is the difference between resolving a dispute with evidence and guessing. It also protects you from the opposite case, a player who genuinely received their pull but whose client failed to render it, which the matched record resolves without a refund you did not owe.

Client and server reconciliation

The root cause of most serious gacha bugs is the reconciliation between an optimistic client and the authoritative server. The client often shows a pull result immediately for responsiveness, then the server confirms or corrects it. When the network hiccups in that window, the client and server can end up believing different things: the client showed a five-star, the server granted a three-star, or the client thinks the pull failed while the server completed it. The player reports the version they saw, which may not be the version that is real.

Capturing the full pull round-trip is what untangles this. Record the pull request the client sent, the optimistic result it displayed, the authoritative result the server returned, and whether reconciliation completed. When the displayed and authoritative results differ, you have isolated a reconciliation bug and know exactly which value the player saw versus what they actually own. This is also the data that lets you decide the right fix: tighten the reconciliation, make the client wait for authority on high-value pulls, or improve the recovery path when the confirmation is lost in flight.

Designing the gacha report payload

Assemble a pull snapshot that travels with every gacha or loot box report. Include the client and server pity counters, the client and server currency balances, the pull request with its cost and transaction identifier, the optimistic result shown, the authoritative result recorded, the reconciliation status, and the relevant drop rates or rate table version. With that you can audit any disputed pull end to end, match it to the server record, and determine the truth, which is the only acceptable basis for resolving a report that touches money and trust.

Make the snapshot a faithful capture of both sides so it stands up as an audit trail. The goal is that a player who feels cheated by a pull just hits report, and you receive a record you can reconcile against the server rather than a story you have to adjudicate. Consistent fields also let you spot systemic issues: counting reports where client and server pity disagree reveals a counting bug, and counting currency-desync reports clustered on a network condition or platform isolates where the reconciliation is failing for many players at once.

Setting it up with Bugnet

Bugnet captures your pull state automatically when a player taps the in-game report button, so the pity counters, currency balances, pull transaction, and reconciliation status arrive as custom fields with no upload code, and the transaction identifier lets you match the report to your server record. A player disputing a pull just reports it, and instead of an argument you get an auditable snapshot plus the device and platform context, including the network conditions that often explain a reconciliation failure. For money-adjacent reports, having that evidence on arrival is what lets you resolve fairly and fast.

Gacha bugs cluster around specific banners, rate tables, and network conditions, and occurrence grouping turns that into actionable priority. Bugnet folds duplicate reports into one issue with a count, and you can filter by a banner or rate_table_version custom field to find the systemic problem. When a hundred not-delivered reports share one banner, that single issue rises by occurrence count and signals a real server-side bug affecting paying players, which you escalate immediately rather than working through a hundred individual disputes one refund at a time.

Testing and auditing pull systems

Once reports carry the full pull record, you can write tests that assert the invariants money systems demand: a pull debits exactly its cost once, the pity counter advances by exactly one per pull and resets only on the guaranteed drop, and the granted item matches the authoritative roll. Each fixed gacha bug becomes a permanent assertion, which is essential because these systems touch currency and player trust, and a regression here is not a cosmetic glitch but a financial and reputational problem.

Beyond unit tests, build a reconciliation audit that periodically compares client-reported state against server records across the player base, so a desync that affects many players surfaces before the reports flood in. Keep capturing real pull records from the field, since reconciliation bugs depend on network timing you cannot fully reproduce locally. Gacha and loot boxes are often the revenue engine of a live game, and treating their bugs as auditable, testable records is what lets a small team run that engine with the precision and fairness that paying players, and increasingly regulators, expect.

A disputed pull is an audit, not an argument. Capture both sides of the state with a transaction id and a he-said complaint becomes a record you can reconcile to the truth.