Bug Tracking for Vampire-Survivors-Likes

The whole pitch of a vampire-survivors-like is that the screen eventually fills with hundreds of enemies and a curtain of your own projectiles, and that the numbers climb until they feel absurd. That escalation is the fun, and it is also where everything breaks. Frame rates collapse under entity counts, damage values overflow their integer type and wrap negative, and upgrade combinations the player stacked produce behavior no one designed. These bugs only appear deep into a run, under load, for a specific build, which makes them miserable to reproduce unless you capture the conditions. This post covers what to track so the late game stops being a black box.

Entity counts are the genre's vital sign

In this genre the single most important number is how many things are alive at once. Enemies, projectiles, pickups, damage-number popups, and particle emitters all accumulate, and each is cheap until it is not. The frame rate does not degrade gracefully; it falls off a cliff when some system crosses a threshold, a spatial grid that rehashes too often, a collision pass that goes quadratic, a draw call count that blows the batcher. The player experiences this as the game turning to slow motion at minute fifteen, and a screenshot tells you nothing about why.

So instrument the counts and capture them when trouble starts. Log active enemies, active projectiles, particle emitters, and popup objects continuously, and snapshot them when the frame time crosses a budget. A report that the late game stutters is hopeless; a report that it stutters at six thousand projectiles and twelve hundred enemies points you straight at whichever system scales worst with that population. The counts are the vital sign, and reading them is the first move in diagnosing any late-run slowdown.

Scaling overflow and the wrong number type

The escalation that makes the genre satisfying also pushes numbers past limits programmers casually assume are safe. Damage that doubles every few levels will, given enough stacking, exceed a thirty-two-bit integer and wrap to a negative value, so a hit heals the enemy or the health bar inverts. Experience curves, gold totals, and timers hit the same walls. These overflow bugs are deterministic given the build but invisible until the run goes long enough, which is precisely why playtesters who quit at minute ten never see them and players who push to minute forty always do.

Defend with wider types and explicit clamping, and instrument the approach to limits. When a value crosses a high watermark, that is a signal worth capturing along with the build that produced it. Better still, run automated late-game simulations that stack the strongest multipliers and assert no value overflows or goes negative. The captured build state from a real overflow report tells you exactly which multipliers combined to get there, so you can reproduce the wrap in seconds and choose between a bigger type, a soft cap, or a redesigned scaling curve.

Upgrade synergies that escape the design

The build is the player's creative output, and creativity finds combinations you did not test. An upgrade that adds projectiles, one that makes them bounce, and one that triggers an explosion on hit can compound into an effect that spawns far more entities than any single choice implies, which loops straight back into the entity-count problem. Other synergies break logic rather than performance: two effects that both modify the same stat in a way that was only ever meant to apply once, producing infinite duration or zero cooldown. The build state is therefore central to almost every report.

Capture the full active build as structured data, every upgrade and its stack level, so a report carries the exact recipe. Reading that a slowdown report consistently includes the same three multiplicative upgrades is your synergy smoking gun. With the build captured you can drop straight into a debug arena, apply those upgrades, and watch the entity count or the stat explode. Synergy bugs are the heart of the genre's emergent appeal, so you rarely want to remove them, but you do need to see them clearly enough to cap or rebalance the dangerous ones.

Reproducing the punishing late game

The cruel reality is that the bugs live twenty or forty minutes into a run, and no one wants to play twenty minutes to test a fix. So build the tools to jump there. A debug command that sets the run timer, spawns a target entity population, and applies an arbitrary upgrade build lets you recreate the late-game stress state in seconds. Feed it the captured counts and build from a real report and you are standing in the player's collapsing frame rate immediately, profiler attached, instead of grinding toward it by hand.

Determinism helps here too. If your spawning and scaling are driven by a seeded stream and a fixed timestep, you can replay a run to its breaking point identically every time, which makes before-and-after profiling trustworthy. Treat the late game as a place you can teleport to and measure, not an endurance test. Once recreating the punishing state is a one-line command, the performance and overflow bugs that define this genre move from untestable folklore into ordinary, profile-and-fix engineering work that you can knock out in an afternoon.

Setting it up with Bugnet

Bugnet's in-game report button shines under load because it captures the run's scale at the press. Wire the live entity counts, the full upgrade build, and the elapsed run time into custom fields and player attributes, and a report arrives describing exactly the population and recipe that broke. When an overflow crashes the game, Bugnet captures the stack trace and device context automatically, so you see whether the wrap is hitting a particular platform's narrower integer behavior, with the build that triggered it attached and ready to recreate in your debug arena.

Because the same dangerous synergy hits many players, Bugnet's occurrence grouping folds duplicate slowdowns or crashes into one issue with a count, ranking which build is degrading the most sessions. Filter by an upgrade ID present in the reports and a synergy hypothesis confirms itself instantly: if every clustered report carries the same projectile-multiplier stack, that is your culprit. Filtering by entity-count thresholds or by run time lets you separate genuine late-game cliffs from early-run anomalies, all from one dashboard that turns a flood of stutters into a prioritized scaling backlog.

A culture of load testing and caps

Teams that ship stable horde games make load a permanent part of their test loop. Automated soak runs play the strongest builds at maximum spawn rates headless and assert that frame time stays under budget and no value overflows, mining the dangerous synergies before players do. Object pooling for projectiles and popups, spatial partitioning for collisions, and hard ceilings on simultaneous entities are not optimizations to add later; in this genre they are the baseline architecture that keeps the late game from becoming the bug game.

Set deliberate caps and treat hitting them as data, not failure. A ceiling on active projectiles that triggers a capture when reached tells you which builds are economically out of control, feeding your rebalancing. The genre's joy is watching numbers and crowds grow beyond reason, so your job is to make sure beyond reason still runs and still computes correctly. Capture the counts, the build, and the run time, recreate the late game on command, and the escalation stays thrilling instead of turning into a slideshow of bugs.

In a horde survivor the bug lives in the late game under load. Capture the entity counts, the build, and the run time, and you can teleport straight to it.