Bug Tracking for Bullet Heaven Games

Bullet heaven games, the survivor-likes where one player faces an ever-growing horde, are a performance and balance stress test disguised as a casual game. By the late game there can be thousands of enemies on screen and a wall of projectiles, while item synergies stack into builds the designer never explicitly authored. The bugs that result are frame rate collapses, scaling math that overflows, and RNG that hands a player a broken or a useless build. This post covers tracking those scale, performance, and randomness bugs so a late-run disaster becomes something you can actually reproduce and fix.

Spawning and projectile density

The defining technical challenge of a bullet heaven game is sheer object count. Enemies spawn in waves that grow over time, and a maxed-out build can fill the screen with projectiles, so the spawning and pooling systems are under enormous pressure. Bugs here show up as the game choking when a wave arrives, projectiles that fail to spawn or despawn, or object pools that exhaust and start dropping entities. Because the count climbs as the run goes on, these problems are worst exactly when the player is most invested in surviving.

Track density bugs by capturing the enemy count and projectile count at the moment the problem appeared, along with how far into the run it happened. A slowdown that arrives at a specific object count tells you the spawning or pooling system has a ceiling, and the count is the number you need to reproduce it. Without it, a report that the game lagged is hopeless; with the on-screen counts and the run time, you can recreate the exact load that broke and profile it deliberately.

Performance and frame rate under load

Bullet heaven games are uniquely performance-sensitive because their fun depends on responsive movement while thousands of things update every frame. When the frame rate drops, dodging becomes impossible and the run dies to lag rather than skill, which players experience as the game cheating them. The cost is usually in the per-entity update: collision checks against every projectile, damage number rendering, or particle effects that scale linearly with a count that is anything but linear by the late game.

Track performance reports by capturing the frame rate or frame time alongside the object counts and the device. The same build that runs fine on a desktop can crawl on a handheld or a phone, so the device context is essential, and a performance bug is really a relationship between load and hardware. When reports cluster on lower-end devices at high object counts, you know where the optimization has to go, and you can set object-count budgets that keep the game playable on the weakest hardware you support.

Scaling math and the late-run overflow

A bullet heaven run is an exercise in exponential growth: damage, attack speed, area, and enemy health all scale, and that scaling is where the math breaks. Numbers that fit early in a run can overflow late, a multiplier stack can produce a value the systems cannot represent, or a percentage applied repeatedly can round into nonsense. These bugs only appear in long, successful runs, which means your own testing rarely reaches them, but your most dedicated players hit them constantly.

Track scaling bugs by capturing the run state when the math broke: the player level, the active stat multipliers, the enemy tier, and the elapsed time. A damage value that goes negative or an enemy that becomes unkillable is a scaling bug, and the multiplier stack at that moment is the cause. With the run state recorded you can reconstruct the growth curve that led to the overflow and add the clamps or wider types needed, protecting the long runs that are the genre most rewarding and most fragile moments.

RNG, item synergies, and broken builds

Randomness defines a bullet heaven run: the items offered, the order they appear, and how they combine into a build are all RNG-driven, and that is the source of both the fun and a class of bugs. A synergy can stack into a build so powerful it trivializes the game or, worse, crashes it; another combination can produce a dead build that cannot progress. An item that does not work with another, or a synergy that multiplies wrong, quietly ruins the run the player committed twenty minutes to.

Track build bugs by capturing the full active item set, their levels, and the run seed. A broken or dead build is a product of a specific combination, so you need the whole set, not just the item the player blames. The seed lets you regenerate the same item offers and reproduce how the build came together. With the item set and seed you can replay the exact synergy, find whether an item interaction multiplies incorrectly or fails to apply, and fix the combination that produced the broken outcome.

Setting it up with Bugnet

Bugnet fits bullet heaven games because the in-game report button captures state automatically the moment a run slows down, breaks, or crashes, while the run state is still live. You can attach the enemy and projectile counts, the frame rate, the active item set, the run time, and the seed as custom fields, and crashes are captured with stack traces and device context. That turns a vague the game lagged and died into a report carrying the exact load and build, so you can recreate the conditions instead of guessing what an unrepeatable twenty-minute run looked like.

Because the same late-run slowdown or the same broken synergy affects many players who reach the same point, Bugnet folds duplicate reports into one issue with an occurrence count, so a scaling overflow or a performance ceiling rises to the top of your queue. You can filter by device to find where the frame rate collapses, or by item using your custom fields to pull every report about one synergy. One dashboard with the run state and seed attached lets you reproduce and prioritize the bugs that hit your most engaged players hardest.

Testing the runs players actually finish

The studios that keep bullet heaven games healthy accept that their own short test sessions never reach the late-game conditions where the worst bugs live, so they lean on player reports and captured run state to get there. Each confirmed scaling or synergy bug, captured with its run state and seed, becomes a regression scenario that runs the build to the breaking point and asserts it holds. Performance bugs become object-count benchmarks on the weakest target devices, so a future change cannot quietly blow the budget.

Make late-run health a routine. Each release, re-run the captured high-load and high-scaling scenarios, review the top performance reports by device and object count, and replay the broken builds from their seeds to confirm the synergies behave. A bullet heaven game lives on the thrill of a build snowballing out of control, and the studios that protect that feeling are the ones that capture the run state, reproduce the late-game exactly, and lock each fix in so the next twenty-minute run reaches its triumphant end instead of a crash.

Bullet heaven bugs live in the late game your own testing never reaches. Capture the object counts, the run state, and the seed, and a twenty-minute disaster becomes reproducible.