Bug Tracking for Score Attack Games

In a score attack game, the score is the entire point. Players replay the same content over and over chasing a higher number, and they compare that number against a leaderboard that defines the competition. This makes scoring integrity the single most important correctness property in the game. A bug that awards a few extra points in an edge case, or a leaderboard that accepts an impossible score, does not just annoy one player, it poisons the standing of everyone who played honestly. This post is about tracking scoring bugs precisely enough to keep that number, and the leaderboard built on it, trustworthy.

Scoring integrity is the product

The scoring system is where the game keeps its promise, and any inconsistency breaks it. Players who grind a score attack game develop an intuitive model of exactly how many points each action is worth, and they notice immediately when the same play yields a different score. The bugs usually live in interactions: a combo multiplier applied before a bonus instead of after, a chain that should reset but carries over, a time bonus computed from the wrong clock. Each is small in isolation and significant in aggregate, because over a full run those discrepancies compound into a total the player cannot reconcile with what they did.

To debug scoring you need the breakdown, not just the final number. A report that says my score was wrong is useless, but one that carries the per-event scoring log, including each action, its base value, the multiplier in effect, and the running total, lets you recompute the run and find the exact event where the math diverged. Capturing the scoring breakdown turns a subjective dispute into an arithmetic check. When the player and the game disagree about a total, the itemized log is the referee, and without it you are reduced to taking sides.

Edge-case scoring interactions

The hardest scoring bugs are at the boundaries where systems overlap. A multiplier that maxes out, a combo that ends on the exact frame a bonus triggers, two scoring events resolving on the same frame in an undefined order, all produce results your designers never hand-calculated. These are the cases competitive players find precisely because they are probing for the optimal route, and an exploit that doubles a multiplier in a corner case will be discovered and shared within days of launch. Capturing the inputs around a reported anomaly is the only way to reconstruct the exact interaction that produced it.

Order of operations is the recurring culprit. Whether a percentage bonus applies to the base or to the already-multiplied value, whether a cap clamps before or after a stacking bonus, whether a tie in timing favors one event or another, these decisions have to be defined and consistent. When they are not, the same nominal play scores differently depending on a frame-level coincidence, which players experience as randomness in a game that is supposed to reward precision. Logging the inputs and the resolution order at each scoring event is what lets you find and pin down these interactions before the competitive community routes around them.

Leaderboards and the cost of bad data

A leaderboard turns a private score into a public, permanent record, which raises the stakes on every scoring bug. An impossible score at the top of the board is not a cosmetic glitch, it is a declaration to every honest player that the competition is not real, and it drives away exactly the dedicated players a score attack game depends on. The defense starts with server-side validation: a submitted score should be checkable against the run that produced it, whether by replaying captured inputs or by verifying the score falls within bounds the game's own rules allow. A leaderboard that accepts any number it is sent is a leaderboard waiting to be ruined.

Exploits and submission bugs are two faces of the same problem. A scoring edge case that over-rewards, combined with a leaderboard that trusts the client, produces a record no legitimate run can beat. Capture the full scoring breakdown and the run context with each submission so a suspicious entry can be recomputed and verified rather than removed on a hunch. Treat an impossible leaderboard entry as a high-severity bug that points back to a scoring interaction, because removing the entry without finding the underlying miscount just invites the next player to rediscover the same exploit.

Reproducing and verifying disputed scores

Verification is the core discipline of a score attack game, and it rests on being able to recompute a run from captured data. A useful snapshot includes the per-event scoring log, the inputs or events that drove it, the run seed if the content is randomized, and the final breakdown by category. With that you replay the run through the scoring engine and compare the recomputed total against what the game awarded. If they match, the score is real and any complaint is a misunderstanding you can explain. If they diverge, the log shows the exact event where the engine and the rules disagreed.

Sort reports by the kind of integrity failure rather than by the player's framing. Tag them as miscount, exploit, leaderboard rejection, or display mismatch where the shown score differs from the recorded one. Once categorized, the clusters point at causes: miscounts cluster around a specific scoring interaction, exploits cluster around a route the community has found, display mismatches point at a presentation bug rather than a scoring one. This structure keeps the integrity work focused, because in a genre where the number is everything, knowing whether a complaint is about the math or merely the display saves a great deal of misdirected effort.

Setting it up with Bugnet

Bugnet's in-game report button is well suited to scoring disputes because you can attach the per-event scoring breakdown, the inputs that produced it, the run seed, and the final categorized total as custom fields. Arm a guard so a submitted score that fails server-side validation, or exceeds the maximum the rules allow, flushes a report automatically with the full breakdown. If the scoring engine panics on an edge-case interaction, the crash report carries a stack trace and device context. A my score was wrong complaint becomes a recomputable run that either confirms the total or pinpoints the diverging event.

Occurrence grouping then ranks integrity issues by how widespread they are. Many reports of the same miscount on a specific combo fold into one issue with a count, and suspicious leaderboard submissions cluster into a single high-severity issue you can filter by the scoring-route custom field, all from one dashboard. The captured breakdowns let you verify or refute a disputed score in seconds. Instead of refereeing complaints by intuition, you let the recomputed totals and the occurrence count tell you which scoring interaction is genuinely broken and threatening the integrity of your board.

Testing scoring like an auditor

Treat scoring as code that must be audited, not just played. Build a suite of golden tests where a fixed sequence of actions must produce an exact, hand-verified total, and run it on every change so a refactor of the combo system cannot silently shift a multiplier order. Add property-based tests that fuzz scoring events and assert invariants: the total is deterministic for a given input sequence, no single action exceeds its defined maximum, caps clamp consistently. Most scoring regressions are introduced invisibly by an unrelated change, and an exact-total assertion catches them before they reach the leaderboard.

Make server-side verification a non-negotiable part of the submission path, and keep every recomputed dispute as a permanent regression case. Watch the distribution of submitted scores as a live integrity signal, since a sudden cluster of identical high scores is the fingerprint of a freshly discovered exploit. Done with discipline, a score attack game offers players a number they can trust and a leaderboard worth competing on, and the rare scoring bug that does appear arrives with a breakdown that lets you correct the math and the standings before the competitive community loses faith.

In a score attack game the number is the product. Log the scoring breakdown and verify submissions so the leaderboard stays worth competing on.