Bug Tracking for Endless Runners

An endless runner is a game that gets harder the longer you survive, and its bugs follow the same curve. Early on everything is forgiving and nothing breaks. Deep into a run, the speed has scaled, the procedural generator has produced thousands of spawns, and the failures emerge: an obstacle pattern that cannot be cleared no matter how perfectly you play, a collision that misses at high speed and lets you phase through a wall, a difficulty ramp that crossed from hard into impossible. These bugs are tied to seed, distance and speed, none of which a screenshot captures. This post is about tracking them properly.

Procedural generation and impossible gaps

The heart of an endless runner is a generator that stitches together obstacle patterns forever, and its worst bug is the unclearable configuration. Two hazards spawn with a gap narrower than the player can physically pass, or a jump is required immediately after a landing that has not finished its recovery frames. These never appear in a short playtest because they depend on a specific sequence of random choices that only surfaces after thousands of spawns. The only way to debug them is to make the generation reproducible: log the seed and the distance, so you can fast-forward to the exact pattern the player hit.

Reproducibility also lets you validate generation systematically rather than waiting for reports. With a seeded generator you can simulate millions of meters offline and assert that every spawned pattern is clearable given the player's movement constraints at that speed. The patterns that fail the assertion are your impossible gaps, found before a player ever meets them. Without a captured seed, an unclearable pattern is a rumor you cannot confirm, and with one it becomes a deterministic test case you can fix and then guard against forever in your generation rules.

Collision at speed

Collision bugs in a runner are usually speed bugs. As the runner accelerates, the distance covered per frame grows, and a collision check that samples only the current position can step right over a thin obstacle between frames, the classic tunneling problem. The player phases through a wall that should have ended their run, which feels like a cheat to them and like a missed game-over to you. Continuous or swept collision fixes the tunneling, but you only know it is happening if you capture the speed and the frame durations around the reported pass-through, because tunneling scales directly with both.

The opposite failure is just as common: a collision that triggers when it should not, ending a run on an obstacle the player visibly cleared. This often comes from a collider that is larger than the sprite, or from the difference between where the player sees the character and where the physics thinks it is at high speed. Capturing the player and obstacle positions, the speed, and the frame timing at the moment of the collision lets you measure the discrepancy. A run that ends unfairly is the fastest way to lose a player in this genre, so collision reports deserve precise positional context, not a verbal account.

Speed scaling and difficulty cliffs

Difficulty in a runner usually scales with distance, and the bugs live where that scaling misbehaves. A speed curve that ramps too steeply turns a game that is hard at one thousand meters into one that is mathematically impossible at two thousand, where no reaction time suffices. Sometimes the speed and the spawn density scale independently and combine into a spike neither was tuned for. Players experience this as a wall where their run always ends at the same distance, which is a strong signal that the difficulty crossed a cliff rather than that the player got worse.

These cliffs are easy to miss because developers rarely play deep enough to reach them, while dedicated players live out there. Capture the distance, the current speed, and the spawn density with every report, and a cluster of runs all ending near the same distance becomes an obvious difficulty cliff in the data. The fix is usually to cap or smooth the scaling, but you cannot tune what you cannot see. Treating the distance at which runs end as a tracked metric turns the vague complaint that the game gets impossible into a precise point on the curve you can flatten.

Reproducing a run from its seed

Reproduction in an endless runner means replaying a run from its seed, which a screenshot can never support. A compact snapshot captures the generation seed, the distance at the failure, the current speed, the recent spawn pattern, and the player and obstacle positions at the incident. With the seed and distance you regenerate the exact stretch of level the player was running and step through it frame by frame at the captured speed. This converts an anecdote about an impossible gap into a deterministic case you can load, fix, and keep as a regression test so the generator never produces it again.

Categorize incoming reports by the subsystem behind them, since players only describe symptoms. Tag them as impossible generation, tunneling, false collision, or difficulty cliff. Once sorted the clusters are clear: tunneling reports correlate with high speed and frame drops, impossible-gap reports cluster around specific pattern combinations, difficulty cliffs cluster at a distance. That structure lets a small team see that what looked like scattered the game cheated complaints are really three or four distinct bugs, each pointing at the generator, the collision system, or the difficulty curve.

Setting it up with Bugnet

Bugnet's in-game report button can attach a runner's full replay context as custom fields: the generation seed, the distance, the current speed, the recent spawn pattern, and the player and obstacle positions, plus the recent frame durations. Arm a guard so a pass-through that should have been a collision flushes a report automatically with that context. If the generator throws on an edge-case pattern, the crash report carries a stack trace and device details. A complaint that the game cheated becomes a regenerable run showing exactly the gap, the tunnel, or the difficulty spike that ended it.

Occurrence grouping then ranks the failures by reach. A hundred runs ending at the same distance fold into one issue with a count that screams difficulty cliff, and tunneling reports cluster into a single issue you can filter by the speed and frame-rate custom fields to confirm it is a high-speed problem, all from one dashboard. The seeds you capture let you replay any clustered report on demand. Instead of guessing which complaints are real, you let the occurrence count and the captured seeds show you whether the generator, the collision, or the curve needs the fix.

Testing depth and speed

Endless runner bugs hide at depth, so your testing has to go deep automatically. Build a bot that runs seeded simulations for millions of meters, asserting that every generated pattern is clearable at the speed it appears and that collision registers correctly across the full speed range. Run the collision tests specifically at high speed and with simulated frame drops, because that is where tunneling lives and where a desktop test at a steady frame rate will never reproduce a mobile player's experience. Every assertion failure becomes a seeded regression case immediately.

Pay special attention to the slowest hardware you support, because a frame drop on a weak phone widens the per-frame step and turns a safe obstacle into a tunneling hazard that your dev machine never sees. Watch the captured distribution of run-ending distances as a difficulty health metric over time. Keep every reproduced seed as a permanent test. Shipped this way, an endless runner stays fair and clearable no matter how far a dedicated player pushes it, and the rare generation or collision bug that does slip out arrives with a seed that leads straight to the meter where it lives.

Runner bugs live at depth and speed. Seed the generator, capture the distance, and a run-ending complaint becomes a meter you can replay.