Speedrunning turns a design's tolerance into the game

A route does not merely find the fastest path through a game; it measures what its rules can survive when played without their intended pace. The clock makes a designer's slack visible.

6 min · 19 sources cited

The tension

Speedrunning's category and route rules meet game design's feedback loops and difficulty structures at the tolerances a player can optimize into a new objective.

What collides

Design needs a paced experience whose systems guide attention and consequence; speedrunning needs permission to strip those systems to the fastest reproducible sequence.

The question it replaces

What kind of authorship does a system grant once its tolerances become legible?

A rule that survives play stops belonging entirely to the design that wrote it.

A game can teach the player to look, to wait, to fear the next room.

A speedrun keeps the same code and declines almost all of that instruction.

The enemy stops being an encounter.

The corridor stops being a corridor.

The ending stops being an ending, and becomes a condition that can be satisfied.

Keep moving. Keep clipping. Keep reducing the game to the next state it will permit.

That isn’t quite vandalism.

It isn’t quite appreciation either.

It’s a measurement.

The first instrument is the category.

Any% defines completion as whatever ends the game fastest with permitted exploits.

100% defines it through a full-completion state. Low% defines it by the minimum content needed to finish.

Glitchless permits no exploits at all.

No major glitches allows small collision and timing tricks, while ruling out sequence breaks and arbitrary code execution.

Those aren’t decorative labels on one race.

They’re different games assembled from the same software.

The Super Mario 64 A Button Challenge makes the point unusually naked.

The condition doesn’t find the fastest ordinary route and then decorate it with difficulty.

It changes what the game is for.

Completion becomes a rule about a missing input.

That freedom has a cost.

A category can make an eccentric reading precise enough to share, practise and verify.

It can also turn a world into a legal brief.

There’s a reason the definitions are maintained by volunteer moderators rather than left to the developer.

Somebody has to decide whether a newly discovered glitch belongs inside the measurement, outside it, or in a category of its own.

Software rarely ships with a department for its future loopholes.

Then there’s the version.

Super Mario 64’s backwards long jump builds unbounded horizontal speed and passes through walls.

Its specific setups were patched out in later re-releases and ports.

The trick didn’t get less clever.

The target moved beneath it.

So a version tag names more than an edition.

It names the set of mistakes still available for optimisation.

A platform tag does something similar.

Original hardware, an emulator and a re-release can differ in load times, input lag, and small physics rounding.

Replaying a recorded input file through a real console’s controller port exists as a practice for a reason.

An emulator proof and a hardware proof are related claims, not identical ones.

This is the first discomfort for design.

A patch is normally an assertion of authorship.

This collision was not meant to behave that way.

A route treats the same patch as evidence that the earlier version had another possible game inside it.

Preservation is suddenly not only about keeping a release alive.

It’s about keeping the release’s unwanted affordances legible.

Tolerance is where the argument becomes intimate.

One route setup can require a single frame of accuracy.

Another can allow ten.

The first may be faster in one immaculate attempt.

The second is often faster across a season, because a clock measures the run that finished as well as the run that could have.

A tool-assisted run removes that drama entirely.

Save states and frame-by-frame advance leave zero execution tolerance to manage.

Each input can be retried until it’s correct.

Its time is a floor imposed by the route.

It’s not a promise about what a human attempt can reproduce live.

Yet the two practices aren’t sealed off from one another.

Tool-assisted work can prove an exploit executable, expose a segment’s theoretical floor, and show a live community where a route gets too narrow to carry.

Save-state practice can compress hours of full-game repetition into focused work on one transition.

In the submitted run the state-loading has vanished.

The muscle memory has not.

That line isn’t hypocrisy.

It’s the line between constructing a possibility and performing it continuously.

The distinction gets policed because the clock has an audience.

A submission hands moderators video or an archived stream, a timing method, a version, and a route under the category’s rules.

They check timing boundaries, unlisted exploits, splicing and undisclosed save-state use.

A time seen on stream is an event.

A verified time is a claim.

Design has its own instruments for this, and they look gentler.

A designer works in layers.

The rules as written. The behaviour those rules produce in play. The experience the behaviour is supposed to create.

Speedrunning makes all three embarrassingly visible.

A mechanic becomes a timing window.

A dynamic becomes a route state.

An aesthetic built from suspense or discovery becomes the small silence between resets.

Not because the runner failed to understand the game.

Because the category rewarded a different understanding of it.

Feedback loops sharpen the split.

Kart racers have used rubber banding for decades.

Racers behind draw stronger items, leaders draw weaker ones, and the gap is damped on purpose.

Chess offers the opposite form.

Losing a piece makes the next loss more likely, and the game accelerates toward its own conclusion.

A runner doesn’t automatically convert every advantage into a snowball.

A feedback loop is a mechanism, not a mood.

Fighting games reset health and meter each round, precisely so an earlier mistake can’t compound.

An optimised route can carry a disastrous early error the same way.

Or it can simply make a reset cheaper than a recovery.

The designer’s difficulty curve and the runner’s risk tolerance meet without ever becoming the same instrument.

A studio discovers pacing by watching people play, then moves it.

Chapters get reordered. A section that dragged gets cut.

The curve is built to ask the player to continue.

The runner calibrates in the other direction.

An early failure can be abandoned outright.

A narrow trick can be drilled alone, chained to the movement around it, and carried into a full attempt only when it’s reliable enough to survive one.

The finished recording contains no resets.

The route was shaped by nothing else.

Design builds a curve that asks for continuation.

Speedrunning finds out how little continuation the timer actually requires.

A skip can be a defect a later release corrected, a durable property of an earlier release, and the centre of a category’s craft, all at once.

Those claims don’t cancel.

They run on different clocks, and the game is not entitled to arbitrate between them once the code has shipped.

What kind of authorship does a system hand out, once its tolerances become legible?

What it establishes

A category definition fixes what completion and legal exploits mean before records can be compared.
A version tag and platform tag can place otherwise identical-looking routes on different leaderboards.
TAS save-state construction establishes a route floor, while RTA submission requires live continuous execution.
A one-frame setup and a ten-frame setup can reverse which route is fastest across many attempts.
Rubber banding is a negative feedback loop, while a chess-style material deficit is positive feedback.
A designed difficulty curve comes from playtesting and pacing work, while a runner chooses risk tolerance for an optimized route.

Asked and answered

Why are two records for the same game sometimes not comparable?

A speedrun record measures a category rather than a game in the abstract. Any% permits every legal exploit that reaches an ending fastest, while 100% requires a defined full-completion state and Low% requires the minimum content needed to finish. Glitchless and no-major-glitches categories also draw different lines around exploits. Different definitions produce different routes and different legitimate records.

What does a speedrun category actually decide?

A category is a moderator-maintained ruleset that defines completion, legal exploits, and the run's timing start and end. It can be maximally permissive, restrict sequence breaks and arbitrary code execution, or add an input constraint unrelated to raw speed. Because moderators can revise the definition after a new glitch is discovered, a category is a living measurement rule rather than a label supplied by the developer.

Why does the game version matter to a speedrun?

A route can depend on a collision or memory bug that exists only in one release. Super Mario 64's backwards long jump setups were patched in the 1997 Rumble Pak re-release and later Virtual Console ports, so a route for the original release does not transfer cleanly. A version tag identifies the software conditions that make a submitted time possible.

Does an emulator result mean the same thing as an original-console result?

Not always. Emulators and original hardware can differ in load times, subtle physics rounding, and input lag, all of which can alter a route with narrow timing. Leaderboards therefore may separate emulator, original-hardware, and re-release submissions with platform tags. TASBot addresses a related question by replaying a recorded tool-assisted input file through a real console controller port.

What is execution tolerance in a speedrun?

Execution tolerance is the size of the timing or input window before a trick fails. A route with a one-frame setup can be faster in a single ideal attempt than one with a ten-frame setup, yet the wider window can produce a better result across many attempts. The route is then optimizing expected performance, not simply leaving time unused.

Why can save states be allowed in practice but forbidden in a submitted run?

Save states let a runner repeat one difficult transition immediately and build muscle memory without replaying an entire game. In real-time speedrunning, that practice remains separate from the submitted performance, which executes live from start to finish without state-loading. Save states used to assemble the submitted performance make it a tool-assisted speedrun rather than an RTA run.

What does a tool-assisted speedrun prove?

A tool-assisted speedrun uses save states and frame-by-frame advance to make each input provably correct. It establishes the theoretical floor for a route segment and can show that an exploit is executable at all. It does not establish a human real-time floor, because an RTA attempt has to absorb the timing tolerance and execution variance that TAS construction removes.

Why are resets normal in speedrunning?

A reset ends an attempt after an error, usually early enough that restarting costs less than continuing a weakened route. Published runs therefore hide many failed attempts: the video shows a successful survivor, not the route's ordinary reliability. The reset is neither part of the submitted run nor part of its timed content, but it shapes which risk levels runners accept.

What do moderators verify before a speedrun is accepted?

Moderators review the run footage or archived livestream against the category's rules. They check the declared version, permitted exploits, timing start and end points, and signs of splicing or undisclosed save-state use. A recording begins before the in-game timer so the full input sequence is visible. A streamed time is therefore not automatically a verified leaderboard result.

Is every advantage in a game a snowballing feedback loop?

No. Mario Kart's item distribution is negative feedback, or rubber banding: trailing racers draw stronger items while leaders draw weaker ones, damping a gap. Chess-style material loss is positive feedback because losing one piece makes further losses more likely. Street Fighter and Tekken reset health and meter each round, deliberately preventing a round's mistake from compounding into the next.

How is a designed difficulty curve different from a runner's chosen risk?

A designed difficulty curve is tuned through observing players and revising pacing across the game. Half-Life 2 used three independent four-to-five-person design cabals, then a roughly four-month chapter-by-chapter correction pass after alpha. A runner instead selects a route's execution tolerance, often accepting a slower setup when its wider timing window produces stronger results across repeated attempts.

Game design in the AI era

Bring a sharper eye to your next game.

Making games while the tools keep changing? Get our research brief on AI, game design and production. See what generated assets and faster answers mean for the work—and bring better questions to your next design discussion.

Occasional dispatches, when there is something worth your attention.