Game Dev · July 6, 2026
Speedrun Support in Indie Games: Built-In Timers, Splits, and Replay Verification
Shmups already reward mastery through score, but a dedicated speedrunning community optimizes for a different axis entirely: time. A few small engineering decisions determine whether that community can form at all.
Published July 6, 2026
Score chasing and speedrunning overlap but are not the same discipline. A score-focused player takes routes that maximize graze, extends, and pickups even when they cost time. A speedrunner takes the route that finishes fastest, sometimes skipping scoring opportunities entirely. Both communities exist around most long-lived shmups, and both benefit from the same underlying infrastructure: an accurate, tamper-resistant way to measure and verify performance.
In-game timer accuracy is the foundation
External stopwatch timing, where a runner starts a timer manually on the first visible frame of input, is what most speedrun communities use by default when a game provides nothing better, and it is a poor substitute for an in-game timer. Human reaction time alone introduces 100 to 200 milliseconds of error on both the start and stop, which is enough to make close runs impossible to compare fairly. An in-game timer tied directly to the simulation's frame count, started on the first frame player input is accepted and stopped on the frame a run-ending condition triggers, removes that error entirely and gives the community a shared, trustworthy number.
The timer needs to be paused during any menu, loading screen, or unskippable cutscene that is not part of the actual challenge, and that pause behavior needs to be consistent and documented, or the community will end up maintaining unofficial "loadless" timing rules on top of your official one — which is exactly the kind of fragmentation that kills momentum for a small game's speedrunning scene before it starts.
Splits need stable, well-defined trigger points
A split marks the moment a runner crosses a defined checkpoint — stage clear, boss kill, specific enemy wave start. For splits to be useful and comparable across runs, the trigger condition needs to fire at the same simulation frame every time, which means it should hook into the same state transition system used for stage progression rather than a proximity check or a timer-based estimate. This overlaps directly with the state machine work covered in scene and state management in shmups: a clean state transition from "stage N gameplay" to "stage N clear" is both a design requirement and, for free, a perfect split trigger if you expose it.
Replay verification without an anti-cheat budget
Small teams cannot build server-side anti-cheat, but they can make cheating pointless by making runs independently verifiable. A deterministic replay system that records only the initial random seed and the input stream, then re-simulates the run to reproduce the exact same outcome, lets anyone reproduce a submitted run frame for frame on their own machine. If a submitted replay does not reproduce the claimed result when re-simulated, the run is invalid, full stop — no manual scrutiny of pixel-perfect gameplay needed. This is the same technique covered in more depth in save and replay systems in shmups, and speedrun verification is one of the strongest reasons to build it even if the feature never ships as a player-facing "watch my replay" tool.
Category definitions belong to the community, but the data should not fight them
Runners will define categories — any percent, all bosses, no-bomb, single-credit — largely on their own once a game has a scene, and a developer should not try to over-specify this in advance. What a developer can do is make sure the underlying data supports whatever categories emerge: expose bomb count used, continues used, and per-stage completion flags in whatever run-summary output the game produces, so category verification does not require a runner to manually screen-record their entire bomb count for proof. Community-run leaderboard sites like speedrun.com are where most of this activity ultimately lives, and the less friction there is between "the game can tell you what happened in a run" and "the community can verify it," the more likely a scene actually forms.