Quick answer: Base defense games are about defensive structures holding against escalating waves, so the bugs are about balance and structure behavior. Track the wave that overwhelmed the player, the structures they had placed and their state, and the resource economy at that point. Capturing wave outcomes systematically tells you whether a level is genuinely unwinnable, trivially easy, or just feels unfair, which are three different fixes.
In a base defense game the player builds and upgrades structures to survive waves that grow steadily nastier, and the entire experience rests on a difficulty curve that has to feel fair. The bugs here are slippery because they hide as feelings: a level that is impossible, a wave that is cheap, a turret that does not seem to fire. Some of those are real defects in structure behavior or spawn logic, and some are balance problems where the numbers are simply tuned wrong. Telling them apart requires capturing what actually happened in the wave, not just the player's frustration. This post covers tracking wave outcomes, structures, and the economy behind them.
Defensive structures and their hidden state
The structures are the player's whole toolkit, and each carries state that is easy to get wrong: range, fire rate, target priority, cooldown, ammo, and upgrade level. A turret that quietly stopped firing because an upgrade reset its target priority, or a wall whose collision did not update after placement, breaks the defense in a way the player feels but cannot diagnose. From their side it looks like the structure is useless; from yours it could be a logic bug, a stale state after upgrading, or simply a structure they placed where its range covers nothing useful.
Capture each structure's full state when a defense fails: type, position, upgrade level, current target, cooldown, and whether it fired during the wave. A structure that never fired despite enemies in range is a loud signal of a targeting or cooldown bug, while a structure firing normally but placed badly is a player decision, not a defect. Reading the structure layout and state turns the unfire turret complaint into a clear diagnosis, and it often reveals upgrade-path bugs where leveling a structure silently disables part of its behavior.
Wave outcomes are the data you are missing
Most base defense bug reports are really wave outcomes described emotionally. The player says a level is impossible, but what you need is the structured result of the wave: which enemy types and counts spawned, in what order and timing, how far they advanced, how much damage the base took, and which enemies leaked through. With that you can see whether the wave that overwhelmed them was the one you designed or whether a spawn bug doubled the count or sent the wrong unit mix. Emotion does not reproduce; wave data does.
Logging wave outcomes consistently also lets you separate three very different problems that feel identical to players. An unwinnable level shows the base dying even with optimal play, pointing at over-tuned spawns or a structure bug. A trivial level shows the player coasting, pointing at under-tuned waves. An unfair level shows a wave that spikes suddenly out of curve, pointing at a single misplaced difficulty step. Each needs a different fix, and you can only tell which you are looking at when you have the wave outcome rather than the wave feeling.
The resource economy underneath the defense
Behind every defense is an economy: the player earns resources from surviving waves or killing enemies and spends them on structures and upgrades. Balance bugs frequently live in this loop rather than in the structures themselves. If income outpaces costs, the player buys an unstoppable wall of turrets and every level becomes trivial. If income lags, they cannot afford a viable defense and every level feels impossible no matter how well they play. The structures can be perfectly tuned and the game still feels broken because the economy is feeding them wrong.
So capture the economy state alongside the wave: resources earned, spent, and on hand at the failure point, plus the structures that money bought. A report where the player reached a hard wave with almost no resources tells you the income curve is starving them, which no amount of structure tuning will fix. Economy bugs are insidious because they shift the whole difficulty curve uniformly, so a level that tests fine for a developer with muscle memory feels unfair to a new player on the intended income. The numbers, captured, expose that gap.
Spawn timing and wave-edge bugs
A surprising share of base defense bugs live in the seams between waves and at the edges of the spawn schedule. A wave that starts before the player finishes building, a timer that skips the prep phase, or two waves whose tails and heads overlap can overwhelm a defense that was perfectly adequate for the intended pacing. The player feels ambushed by a difficulty spike that is really a scheduling defect, and because the structures and economy all look correct, this class of bug is easy to misattribute to balance when it is actually the clock misbehaving.
Capture the spawn schedule the wave actually ran against the schedule it was supposed to run, including prep-phase duration and inter-wave gaps. Logging each enemy's spawn timestamp next to its intended slot reveals when the scheduler compressed a gap or launched a wave early. These timing bugs are deterministic, so once you have the real schedule you can replay it and watch the premature assault reproduce, then fix the wave controller rather than nerfing enemies that were never too strong to begin with. The clock is part of the level, so track it like one.
Setting it up with Bugnet
Bugnet's in-game report button can fire when a player flags a level as unfair or broken, carrying the defensive state with it. Push the wave outcome, the enemy composition and timing, the full structure layout and state, and the resource economy into custom fields and player attributes. A report then arrives as the exact wave and defense that failed rather than a one-line complaint, so you can recreate the level in a debug build with those structures placed and that wave incoming, and watch whether the base dies for a real reason or a tunable one.
Because the same difficulty spike or structure bug frustrates many players, Bugnet's occurrence grouping folds the duplicate reports for one level into a single issue with a count, telling you which wave is costing you the most players. Filter by level, by the enemy type that leaked, or by structure type, and patterns emerge: if every report on a level shows the player out of resources, the economy is the culprit, not the wave. One dashboard separates the unwinnable, the trivial, and the merely unfair into distinct, prioritized fixes.
Balancing with data instead of intuition
The strongest base defense teams replace gut feeling with logged outcomes. Across all your players, the distribution of wave outcomes per level is a difficulty heatmap: a level where almost everyone loses on wave seven is either too hard or hiding a bug, and a level everyone clears without losing health is wasted tension. Build an automated simulation that plays each level with a few reference strategies and asserts the outcome lands in the intended band, so a tuning change in one place cannot silently make a distant level unwinnable.
Treat balance as something you measure continuously rather than tune once and forget. Real player wave outcomes will drift from your assumptions the moment the game meets people who play differently than your team, and capturing those outcomes is how you notice before the refunds start. Keep the structure state, wave data, and economy flowing into one place, and the difficulty curve becomes a thing you can see and steer. That is the difference between a base defense game that feels fair by accident and one that stays fair on purpose across every patch.
In base defense the complaint is usually a wave outcome described as a feeling. Capture the wave, the structures, and the economy, and the right fix becomes clear.