Collecting Feedback From Your Speedrun Community

Speedrunners play a different game than the one you shipped. They live in the cracks: the frame where a collision check is skipped, the input sequence that clips through a wall, the exact pixel where a load trigger fires early. Their feedback is the most precise you will ever receive and the hardest to reproduce, because it depends on frame-perfect timing and a deep model of your systems that they understand better than your design doc does. This post is about collecting that feedback, reproducing the frame-tight tech behind it, and deciding what to fix versus what to deliberately leave in.

Why speedrunners find what testers cannot

A normal player and a QA tester explore your game's intended space. A speedrunner attacks the boundaries on purpose, repeating a single input sequence thousands of times until they find the one frame where the game does something you never anticipated. That repetition and intent surface a class of bug ordinary testing never reaches: collision skips, out-of-bounds clips, memory manipulation through specific menu sequences, and timing windows so tight that hitting them requires tool-assisted patience. They are effectively a fuzzing harness made of human determination.

This makes them invaluable and exhausting to support. The bug they report is real but might fire once in two hundred attempts, and your repro instructions are useless because the trigger is a frame-perfect input you cannot describe in prose. To use their feedback you have to capture the conditions of the exact run where it happened, not the conditions you imagine. The community already records everything; your job is to receive that precision in a form your engineers can replay rather than a forum description that no one can act on.

The vocabulary of frame-precise feedback

Speedrun feedback comes with its own dialect: frame windows, input buffers, lag frames, RNG manipulation, wrong warps, clip setups. Learn it, because dismissing it as jargon means missing the substance. When a runner says the trick is two frames tighter on the new patch, that is a precise, falsifiable claim about your physics or input timing that you can verify if you capture frame-level data. Treating that as vague vibes wastes the single most actionable bug report you will get all year.

The specificity cuts both ways. Because runners describe behavior at the frame level, you can usually map their report directly onto a system: a changed coyote-time value, a reordered update loop, a modified collision pass. The hard part is bridging their input-level description to your code-level model, and that bridge is context. Give them a channel that captures the run's build, settings, and input timing automatically and the translation from they clip here to the collision check runs after the move is solved gets dramatically shorter.

Fix it or protect it?

Not every speedrun exploit is a bug to fix. The community often builds an entire category, years of competition, and dozens of records on top of a glitch you might casually patch out. Removing it can erase records, invalidate strategies, and alienate the most dedicated players you have, all to fix behavior that harms no one in normal play. The decision to patch a speedrun tech is a community decision as much as an engineering one, and making it carelessly is how studios accidentally declare war on their most loyal fans.

So build a deliberate process. When a runner reports an exploit, classify it: does it hurt normal players, enable cheating in competitive modes, or corrupt saves, or is it a harmless skip that the community loves. Harmful ones you fix and communicate. Beloved harmless ones you may protect explicitly, even documenting them as supported. The point is that the choice is conscious. The worst outcome is silently breaking a major speedrun tech in an unrelated patch because you never knew it existed and never gave runners a way to flag what matters to them.

Reproducing the unreproducible

The central technical problem with speedrun feedback is reproduction. A bug that depends on a frame-perfect input cannot be reproduced from a written description, so you need the actual conditions of the run. Capture the build version, the full settings, the platform, and ideally a slice of recent inputs or logs at the moment the glitch fired. With that, your engineers can replay the state instead of guessing at the timing, and a bug that would have been closed as cannot reproduce becomes a fifteen-minute fix.

Encourage runners to report at the moment of the glitch rather than after the run, because the relevant state is freshest then and the surrounding context is intact. Runners are meticulous record-keepers and will happily provide more if the channel makes it easy, but they will not transcribe a frame log into a web form. The lower the friction and the more the system captures automatically, the more frame-precise reports you receive, and the more of your game's deepest edge cases you actually understand.

Setting it up with Bugnet

Bugnet turns frame-precise feedback into something reproducible. When a runner hits a clip or a crash mid-run and taps the in-game report button, Bugnet captures the build, platform, settings, and a recent log slice automatically, so the report arrives with the exact conditions of the run instead of a prose description nobody can replay. For the crashes that exploits sometimes trigger, you get full stack traces and device context, which is often the fastest path to understanding what the exploit is actually doing to memory or the update loop.

Custom fields let runners tag the category and trick name, and player attributes let you filter to your speedrun cohort so their reports do not drown in the general stream. Occurrence grouping tells you whether a glitch is one runner's setup or a widespread tech the whole community relies on, which is exactly the signal you need to decide between fix it and protect it. One dashboard holds the frame-tight edge cases alongside everything else, and filtering by build lets you confirm whether your last patch changed a timing window the community cares about.

Treating runners as a QA team

The most useful reframe is to see your speedrun community as an unpaid, relentless, expert QA team that you would never be able to hire. They test your game harder than any studio ever could, they document obsessively, and they care more about your physics than most of your developers do. Give them a real channel, learn their vocabulary, and respond to their reports with the seriousness you would give a senior tester, and they will surface a depth of edge-case behavior that makes your game more robust for everyone, including players who never attempt a single trick.

Make the relationship reciprocal. When you fix an exploit that mattered, tell them why. When you protect one they love, say so out loud. When you accidentally break a tech, apologize and consider restoring it. That respect compounds: a community that trusts you will route their discoveries straight to you instead of quietly trading them in private, and you will be the rare studio that learns about its frame-perfect bugs before they become a viral video about how broken your game is.

Speedrunners are your sharpest free QA team. Capture frame-level context so you can reproduce their tech, then decide on purpose what to fix and what to protect.