Quick answer: Idle and incremental game bugs cluster around number overflow and precision, offline progress calculation, and prestige resets that must wipe some state but keep others. Capture the raw numeric values, the elapsed offline time, the prestige layer, and the save version with every report so you can reproduce an overflowed currency, lost offline gains, or a reset that kept the wrong upgrade.

Idle and incremental games are built to push numbers to absurd scales, reward players for being away, and periodically reset everything in exchange for a permanent boost. Each of those pillars is a source of bugs that no other genre faces in the same way. A currency that wraps to infinity or NaN, an offline calculation that grants nothing or far too much, or a prestige reset that wipes an upgrade it should have kept can stall progression or corrupt a save built over weeks. This post covers the bug categories unique to idle games and the context that makes them reproducible.

When the numbers stop being numbers

The signature challenge of the genre is scale. Currencies routinely climb past what a double-precision float can represent exactly, and once you exceed that range, arithmetic starts producing surprises. A value displays as a clean number but compares wrong, an addition stops registering because the increment is too small relative to the total, or a calculation produces Infinity or NaN that then poisons every downstream number. Players see their counter freeze, jump to a nonsense value, or show the word NaN where their fortune used to be.

These bugs depend entirely on the raw numeric value, which is why a screenshot of a formatted number is not enough. The display might read a tidy abbreviated figure while the underlying value is already NaN. Capturing the raw, unformatted number, the data type or big-number library state, and the operation that was running tells you whether you hit the float precision wall or a divide that produced infinity. Without the raw value you cannot tell a display formatting bug from a genuine numeric corruption.

Offline progress that pays the wrong amount

Rewarding players for time away is core to the genre and a constant source of bugs. When a player returns, the game computes how much they would have earned during the elapsed offline interval. That calculation has to handle device clock changes, very long absences, and rates that themselves change as resources accumulate. Bugs appear when a clock that jumped backward yields negative time, a multi-week absence overflows the elapsed calculation, or the rate used assumes the start-of-interval state rather than integrating over the whole period.

The essential context is the elapsed offline time the game computed, the device timestamps it used, and the rates in effect. A player reporting they got nothing for two days away might have a clock that drifted backward, producing a negative or zero interval. A player who got an impossible windfall might have hit an overflow in the elapsed seconds. Capturing both the wall-clock delta and the in-game interval the code derived from it lets you see exactly where the offline math diverged from reality.

Prestige resets that keep the wrong things

Prestige is the loop that gives idle games their longevity: reset most progress to gain a permanent multiplier, then climb faster. The reset logic has to be surgical, wiping currencies and most upgrades while preserving prestige currency, permanent unlocks, and meta-progression. The bugs are almost always about the boundary. A reset that clears a permanent upgrade the player paid prestige currency for, or one that fails to clear a temporary buff so it persists and compounds across resets, breaking the game's balance entirely.

Multi-layer prestige systems make this worse, since a higher reset must correctly fold the lower layers. To debug a bad reset you need to know which prestige layer was triggered, the state before the reset, and the state after. A player who lost a permanent unlock is reporting a reset that crossed the keep-versus-wipe boundary in the wrong place. Capturing the prestige layer and a before-and-after snapshot of the upgrade set lets you pinpoint exactly which entry was wiped or spared incorrectly.

Save format and the ever-growing state blob

Idle games persist constantly, often saving to local storage every few seconds, and the save has to encode numbers that exceed normal integer ranges. That makes serialization a recurring hazard. A big-number value stored as a plain string and parsed back with the wrong precision, an upgrade map that grows with each update and breaks old parsers, or a save written before a balance patch that loads into an economy where the numbers no longer make sense. Because saves are written so often, a serialization bug can corrupt a player's entire run in seconds.

Migration is the sharpest edge. When you rebalance, an old save's enormous numbers must still load and behave sanely, and a migration that misreads a big-number field can turn a player's fortune into zero or NaN on load. Always capture the save format version and the game version that wrote the save alongside the raw values. That pairing tells you immediately whether a corrupted economy is a fresh write failure or a migration that mishandled the genre's oversized numbers.

Setting it up with Bugnet

Bugnet's in-game report button captures game state automatically, and for an idle game the most valuable thing it can grab is the raw numeric state. When a player reports a frozen counter or a NaN currency, the report can carry the unformatted values, the big-number library state, the elapsed offline interval, the active prestige layer, and the save version. Instead of a screenshot showing a tidy abbreviated number, you get the actual underlying value, so you can tell a formatting glitch from genuine numeric corruption at a glance and load the exact state into a test build.

Occurrence grouping is built for the way idle bugs spread. A precision wall or a bad offline formula hits everyone who reaches the same scale, so instead of a flood of separate tickets you see one grouped issue with a climbing count and the shared numeric range across reporters. Custom fields let you filter by prestige layer or save version, so you can immediately tell whether an overflow only bites players past a certain milestone or whether a recent migration broke offline progress for an entire cohort at once.

Testing at the scales players will reach

The hardest idle bugs only appear at scales QA rarely reaches by hand, so the most important practice is to test there deliberately. Build debug commands that fast-forward time, multiply currencies into the ranges where precision breaks down, and trigger prestige resets across every layer. A counter that works fine in the first hour will reveal its overflow only when you push it past the float wall on purpose, and an offline formula needs to be tested with simulated absences of months, not minutes.

Reinforce that with a feedback loop from real reports. When a player's captured raw value shows where the numbers broke, turn that exact value and elapsed interval into a unit test for your big-number and offline code. Over time you accumulate a suite that exercises the genuine extremes your players hit, which is always further than a designer would think to test. That discipline is what keeps a number-pushing genre stable across the long arc of progression that defines it.

Idle bugs hide behind formatted numbers. Capture the raw value, the offline interval, and the prestige layer, and overflow and reset bugs become reproducible.