Bug Tracking for Clicker and Tap Games

A clicker game is an economy simulator wearing a casual costume. Players tap, numbers grow, and within hours those numbers are larger than any other genre ever produces. That scale is the source of the genre's signature bugs: values that overflow or lose precision, offline progress calculations that hand out the wrong rewards because they trusted a manipulated clock, and prestige resets that wipe the wrong slice of state. Each of these quietly corrupts the economy, and because idle games are played over weeks, a small leak compounds into a broken save. This post is about tracking those failures.

Big numbers are the whole economy

In a clicker game the numbers do not just get large, they get astronomically large, and standard integer and floating types give out quickly. A counter that overflows a sixty-four bit integer wraps to a negative, and a float that grows past its precision starts incrementing in coarse jumps that make small purchases do nothing. Players notice immediately when their currency goes negative or stops responding to clicks. You must decide early on a representation, often a custom big-number type with a mantissa and exponent, and then capture the raw values in every report so a precision break shows up as concrete numbers rather than a vague complaint.

The arithmetic around those numbers is just as fragile as the storage. Multipliers stack, percentages compound, and the order of operations can lose precision or overflow an intermediate result even when the final value would have fit. A bug where a bonus is applied before a cap instead of after can hand a player orders of magnitude too much. Capturing the inputs to a reported calculation, not just the wrong output, is what lets you find which step in the multiplier chain diverged, because in a big-number economy the difference between right and broken is often a single misordered operation.

Offline progress and the untrusted clock

Offline progress is the defining feature of an idle game and its most exploitable surface. When a player returns, you compute how much they earned while away from the elapsed time, and the obvious source of that time is the device clock, which players can freely change. Set the clock forward a year and a naive game grants a year of earnings instantly. The fix is to treat the clock as untrusted: prefer a server timestamp where you have one, clamp the maximum offline duration, and capture both the device-reported delta and any trusted reference with each report so you can see when they disagree.

Even honest offline math is full of edge cases. The calculation often differs from the active loop, so a production rate that is correct while playing can be wrong when integrated over hours offline, especially when upgrades or boosts were active. Time zones, daylight saving, and a device that slept and woke with a clock jump all feed strange deltas into the formula. Capture the offline delta, the clock source, and the production state at the moment of the report. An offline reward that looks wrong is unsolvable without knowing how much time the game thought had passed and where that number came from.

Prestige resets that keep the right state

Prestige is a controlled reset: the player trades their current progress for a permanent multiplier and starts the climb again faster. The bugs are all about which state gets wiped and which survives. A reset that clears a permanent upgrade the player paid for is a disaster, and a reset that fails to clear a temporary buff hands them a permanent advantage they should not keep. Because prestige touches nearly every field in the save, it is the single most dangerous operation in the game, and every report around it needs the before and after state captured to be debuggable.

Prestige bugs are also where exploits concentrate. If the prestige calculation reads a value that a separate bug already inflated, the player banks a permanent multiplier far beyond intended, and unlike a transient glitch that multiplier is locked into their account forever. Capture the inputs to the prestige reward, the list of fields the reset cleared and kept, and the resulting multiplier. That snapshot lets you confirm the reset wiped exactly what it should and computed the reward from sane inputs, which is the only way to catch a prestige exploit before it spreads through your most engaged players.

Saves, exploits and slow corruption

Idle games are played in long stretches across weeks, so the save accumulates state and any corruption festers. The failures are rarely dramatic crashes and usually slow drift: a counter that overflows once, a bonus applied one too many times per session, a prestige that kept a field it should have cleared. None of these announce themselves, and by the time a player reports an impossible currency value or a save that will not load, the originating event is buried. The defense is to validate the save and capture the malformed state plus recent economy events whenever a check trips.

Because the numbers are enormous and the rewards desirable, clicker games attract save editing and clock manipulation. You will never stop a determined offline cheater entirely, but you can detect the impossible: a currency that exceeds what the elapsed time could produce, a multiplier with no legitimate path, a negative value from an overflow. Capture those as guarded reports so you can distinguish a genuine numeric bug from a tampered save. Treating impossible economy states as a tracked, high-priority class keeps a single overflow from quietly defining the ceiling of every player's progress.

Setting it up with Bugnet

Bugnet's in-game report button can attach the numeric and temporal context that clicker bugs require, all as custom fields: the raw big-number currency and multiplier values, the offline time delta and its clock source, and the prestige state before and after a reset. Arm guards so that a negative currency, an impossible multiplier, or an offline delta beyond your clamp flushes a report automatically the instant it occurs. If the big-number arithmetic panics, the crash arrives with a stack trace and device context. An impossible currency complaint becomes a record showing the exact overflow or the inflated offline delta that caused it.

Occurrence grouping then ranks the economy leaks by how many players they hit. Dozens of overflow reports fold into one high-severity issue with a count, and you can filter by the prestige or offline custom field to confirm a leak only appears after a certain prestige tier, all from one dashboard. The numeric values you attach let you separate a real precision bug from a tampered save at a glance. Instead of triaging idle complaints by guesswork, you triage by the captured numbers and the occurrence count that show which break is actually corroding the economy.

Testing an economy that runs for weeks

The defining challenge is that clicker bugs appear at scales and durations a normal test never reaches. Build a simulation that fast-forwards the economy through weeks of play, including prestige cycles and offline jumps, asserting invariants throughout: currency never goes negative, offline rewards never exceed the clamped maximum, prestige clears exactly the intended fields. An overflow that lives a trillion clicks away is invisible to a short test and certain to hit a dedicated player, so your tests must simulate the player who never stops.

Make clock and save manipulation part of the test plan too, feeding the offline calculation manipulated deltas to confirm the clamps hold. Watch the captured economy distributions as a live signal of whether real progression matches your balance assumptions. Keep every reproduced overflow and prestige case as a permanent regression test. Done well, a clicker game gives players a satisfying, ever-climbing economy that holds together for weeks, and the rare numeric or offline bug that slips through arrives with the raw values and time delta that lead you straight to its root.

A clicker game is a number that runs for weeks. Pick a big-number type, distrust the clock, and guard every value that can overflow.