Bug Tracking for Incremental and Clicker Games

Incremental and clicker games are deceptively demanding to engineer. Their entire premise, numbers that grow without bound, prestige systems that reset and multiply, progress that accumulates over weeks of play, pushes against the limits of how computers represent numbers and how save systems hold accumulating state. The bugs that result, an overflow that produces negative currency, a formatting glitch at huge magnitudes, a prestige that resets the wrong things, an offline calculation that goes wild, are specific to the genre and depend on the exact, often astronomical, numbers involved.

Numbers grow beyond what types hold

The defining feature of an incremental game, ever-growing numbers, is also its defining engineering challenge. A value that fits comfortably in a standard integer or float in the first hour can, after a dedicated player grinds for days, exceed the range or precision those types can represent. When that happens you get overflow, producing negative or nonsensical values, or precision loss, producing wrong numbers, both of which break the game.

These bugs only appear at the extreme magnitudes that committed players reach, which is exactly the range you are least likely to test by hand. A quick playtest never pushes numbers high enough to overflow, so the bug ships invisibly and then hits your most engaged players, the ones who have played long enough to reach the breaking magnitude. Tracking these bugs requires capturing the actual numbers involved, because the magnitude is the condition that triggers the bug.

Capture the resource magnitudes

For any incremental game bug, capture the current magnitudes of the key resources, the numbers the player has accumulated. A bug that produces a wrong or negative value is diagnosed by seeing the magnitude at which it occurred, which tells you whether you have hit an overflow boundary, a precision limit, or a logic error in your number handling.

If you use a big-number library to handle astronomical values, capture the magnitudes in a form that preserves their scale, and test your library at the magnitudes your most committed players reach, not just the ones in a short playtest. When several reports of a value bug cluster at a particular magnitude, you have found a boundary your number representation cannot cross, which points directly at the type or library limit responsible, the kind of bug that is obvious once you see the number and invisible until you do.

Formatting at extreme scales

Displaying astronomical numbers is its own source of bugs. Incremental games use scientific notation, named tiers, or other schemes to show enormous values readably, and these formatting systems break at the edges: a tier name that runs out, scientific notation that displays wrong, a number that overflows its display field, a formatting that produces gibberish at a magnitude the formatter did not anticipate.

Capture the raw value and the displayed value when players report a formatting bug, so you can see the mismatch between what the number is and how it was shown. A report that the number looks wrong becomes clear when you see the raw magnitude and the broken display, pointing at the formatting logic for that range of values. Formatting bugs are cosmetic but jarring, undermining player confidence in a game where the numbers are the whole point, so capturing both the value and its display is key to fixing them.

Prestige resets and offline calculation

Prestige systems, which reset progress in exchange for a permanent multiplier, are a rich source of bugs because they involve carefully resetting some state while preserving and multiplying other state. A prestige bug might reset something it should keep, keep something it should reset, or miscalculate the multiplier, and these depend on the exact state at the moment of prestige. Capture the prestige-relevant state with reports about prestige problems.

Offline calculation, computing progress accrued while the player was away, is the other genre-specific bug factory, especially interacting with the huge magnitudes incremental games reach. A long offline period multiplied by a high production rate can overflow, and clock manipulation or time-zone issues can produce wild results. Capture the offline duration and the calculated gains so an offline-calculation bug arrives with the inputs that produced it, which usually reveals the overflow or the time-handling error at fault.

Setting it up with Bugnet

Add an in-game report option and attach the key resource magnitudes, prestige state, offline duration and calculated gains, and save version as custom fields. Bugnet stores them so an incremental game bug arrives with the actual numbers and state that produced it, letting you reproduce an overflow, a formatting glitch, or a prestige error that only manifests at the magnitudes and states real players reach.

Enable automatic crash capture for the overflows that crash rather than just corrupt, and group identical issues into occurrence counts. Because incremental game bugs cluster at specific magnitudes, the occurrence view is especially revealing: a wave of the same value bug all at a similar magnitude points straight at a number-representation boundary, which you can fix once and confirm by watching whether players continue to hit it past that scale.

Test at the magnitudes players will reach

The most important proactive practice for an incremental game is testing at the extreme magnitudes your most dedicated players will reach, not the gentle numbers of a short playtest. Add developer tools to fast-forward progress or set resources to astronomical values, and verify that your number handling, formatting, prestige, and offline calculation all hold up at the scales of a player who has grinded for weeks.

This high-magnitude testing catches the genre signature bugs before they ship, because those bugs live entirely at scales casual testing never reaches. Combine it with your captured reports for the magnitudes and states you did not anticipate, and you cover the full range: the high-magnitude testing catches the predictable overflow and formatting boundaries, and the captured data catches the surprising states real players create. For a game where the numbers are the entire experience, ensuring they never break at any scale a player can reach is the core of keeping the game working over the weeks and months players invest in it.

In an incremental game the numbers are everything, and they break at scales you never test. Capture the number.