Emulator software can choreograph every button press down to a single frame, producing playthroughs that chain input sequences no human hand could sustain during live play. The author saves the work as an input file that recreates the same run bit-for-bit on the same game and emulator, which is why the community treats it as a verifiable artifact rather than a recording.
This guide breaks down how tool-assisted speedruns are scripted frame by frame, the emulator setup that powers them, and how the TASVideos community reviews and publishes the resulting runs.
The Core Idea Behind a Tool-Assisted Speedrun
Speedrunning shifts from a live race against the clock to a puzzle desk when every input is scripted and optimized frame by frame. The author treats a game like a math problem and uses software to produce the cleanest possible string of inputs, pausing time, rewinding mistakes, and trying a different press on the very next frame. Because the work happens on an emulator, every limit that binds a human hand gets removed.
The result is stored as an input movie, sometimes called an input file, which is a list of button presses tied to specific frames. Feed that file back into the same emulator with the same game ROM, and the exact same playthrough happens, bit-for-bit, every time. That reproducibility is the whole point, and it is why the output is treated as a reproducible artifact rather than a one-off performance.
Where TAS Fits in the Speedrunning World
Tool-assisted speedruns live alongside human speedruns but occupy a separate category, because the input source is fundamentally different. A human speedrun is judged by what a person can do on a controller in real time, while a TAS is judged by what software can express when given unlimited attempts at every frame. Most communities keep the two categories clearly separated, so a human world record is never challenged by emulator output.
How a Speedrun Differs From a Tool-Assisted One
The cleanest way to see the difference is to watch the same stage played both ways. A human Super Mario Bros. 1-1 run might clip the flagpole at frame 216, a number elite runners treat as a meaningful threshold, and settle for that. A TAS of the same stage is built to reach the most efficient end-state possible, even if the wall-clock time looks slower because the emulator renders every frame without dropping any.
That wall-clock gap confuses most newcomers, since the TAS often looks slower on a stopwatch. The point is not raw speed but input precision, which is the metric the category actually rewards. Glitch exploitation shows up in both worlds, but a TAS can chain glitches that demand sub-frame timing, while a human runner must settle for the variant that reflexes can actually land.
That precision gap is exactly what the toolchain is built to exploit.
Side-by-Side Comparison
| Aspect | Human Speedrun | Tool-Assisted Speedrun |
|---|---|---|
| Platform | Console or original hardware | Emulator with rerecording support |
| Input source | Human hands in real time | Frame-by-frame scripted input |
| Error handling | Live recovery, no rewinds | Unlimited rewinds and rerecording |
| Time measured by | Real-time clock on hardware | Frame count, converted to in-game time |
| Glitch precision | Reaction-time dependent | Sub-frame and pre-frame manipulation |
| Leaderboard status | Official human records | Separate TAS category, ineligible for human records |
The Toolchain That Makes a TAS Possible
Every tool-assisted speedrun starts with the right emulator, and not just any emulator will do. The program has to support rerecording, which means it can record inputs, rewind state, and re-record over earlier segments without losing the underlying game memory. Popular choices include BizHawk for NES, SNES, and Genesis, Dolphin for GameCube and Wii, Snes9x for Super Nintendo, and LibTAS as a cross-platform option for Linux authors. Each one exposes precision tools a human speedrunner never sees on a retail console.
The Core Tools and What They Do
- Frame advance moves the game forward by exactly one frame, the smallest unit of time the console can render, which becomes the canvas for every decision.
- Save states snapshot the entire machine state, including memory, audio buffers, and controller input, so you can branch experiments without losing progress.
- Memory inspection exposes internal values like health, coordinates, and random number seeds in real time, so you can see variables the player normally cannot.
- Lua scripting automates repetitive input patterns and lets you plan sequences that would be impossible to hand-place frame by frame, which matters most in long RPGs and fighting games.
- Luck manipulation sets up prior conditions to steer dice rolls, enemy spawns, and item drops without ever modifying the game code itself.
Tip: Try a short, deterministic game like Super Mario Land as your first TAS project. Short runs teach the loop of frame advance, savestate, and input placement faster than any tutorial.
Inside the TAS Creation Workflow
A real run often takes weeks or months, even on a short game. You start by picking a target category, such as any-percent, 100%, or a specific glitch showcase, and study the game’s memory layout, hitboxes, and physics in advance. A rough route gets drafted from community notes or prior research, then refined one frame at a time, with each segment rerecorded until the inputs are theoretically optimal. The run is never really “finished” so much as “no longer being improved.”
Optimization, however, does not mean perfection. Many published runs leave a small number of “TAS-only” errors in place on purpose, since a flawless 30-minute run can feel monotonous without moments of dramatic tension. The aim is a balance between mathematical optimality and watchability.
From Input File to Verified Run
Once inputs are locked in, the author assembles an input movie file that contains nothing but button presses and frame numbers. That file is uploaded, and reviewers re-run it on the same emulator and ROM, checking frame count, category compliance, and any visible mistake. The same input file always produces the same output on the same game version, which removes ambiguity from the result. Some authors then send the file to TASBot, a custom controller robot that replays the run on real console hardware to prove it is not an emulator artifact.
Once the file passes that hardware test, it enters a community review process with its own norms and history.
TASVideos and the Culture Around Published Runs
TASVideos, founded in the early 2000s, is the central hub where authors submit runs for peer review. A judge panel evaluates each submission for technical accuracy, entertainment value, and adherence to the publication rules, which include the requirement that all inputs be reproducible from the uploaded file. A tiered rating system signals quality, and the Star rating is reserved for runs that meet the community’s highest standards for both optimization and presentation.
The site’s archive spans thousands of games and consoles, and functions as a long-term record of how each game’s limits have been mapped over time. A useful side effect has emerged from that archive: it routinely turns up glitches and routes that migrate back into human speedrunning metas, and a glitch discovered in a TAS often becomes a new category or strat for human runners years later. That feedback loop is one reason the publication rules matter as much as the runs themselves.
Famous Runs Worth Knowing
A few examples anchor the history. The Super Mario Bros. warpless run set the standard for what optimal play looks like on the NES. The Super Mario 64 16-star run showcases A-press chains and backwards long jumps that no human can sustain. The Legend of Zelda: Ocarina of Time any-percent run features a Wrong Warp that collapses hours of gameplay into seconds. Final Fantasy runs illustrate how RPG routing and luck manipulation combine across long sequences, with some chains requiring thousands of manipulated RNG rolls.
Why Tool-Assisted Speedruns Are Worth Watching
Most people who seek out a TAS for the first time expect something dry, and almost all of them change their mind by the second minute. A well-made TAS feels closer to an animated short than a speedrun, with movement, collisions, and camera angles choreographed at a scale the original developers never intended. The Super Mario 64 A-button challenge category is a clear example, since it requires holding A the entire time yet still finds ways to manipulate the camera and momentum into creative paths.
Beyond spectacle, tool-assisted speedruns have produced lasting tools and discoveries. Memory maps built for one TAS often get reused in other games on the same console, and Lua libraries written by one author get shared across the community. Glitches that started as theoretical curiosities end up reshaping human metas years later, which gives the discipline a cultural weight that goes well beyond leaderboard prestige.
Practical Reasons to Care
- Route discovery: a TAS often finds shortcuts human runners later adopt, so watching one is a way to see the future of a game’s speedrun meta.
- Glitch documentation: many game-breaking bugs were first cataloged in a TAS, which is the cleanest way to study how they trigger.
- Programming showcase: arbitrary code execution runs double as a tour of how a console’s memory and CPU actually work under the hood.
- Art form: the run is judged on both optimization and entertainment, which is why the best ones feel closer to short films than to gameplay footage.
Tip: A great first watch is any star-tier run on a game you already know. Familiarity with the level design makes the TAS tricks land harder, since you can see how far the route has drifted from the intended path.
How to Start Watching Tool-Assisted Speedruns
Because tool-assisted runs live in a separate category from human leaderboards, appreciation does not require treating them as competition. Most viewers end up treating them as a distinct creative medium, part engineering, part animation, part detective work, and that framing is what gives the activity lasting appeal. The work has a reason to exist beyond a stopwatch.
The clearest next step is to browse TASVideos by console, pick a familiar game, and watch a star-tier run with the author notes open so the reasoning behind each frame is visible. After a few minutes, the term “tool-assisted” stops sounding like cheating and starts sounding like its own craft.
FAQ
What is a tool-assisted speedrun?
A it is a playthrough of a video game produced through emulator software rather than human reflexes. The author places each button press one frame at a time, using tools like frame advance, save states, and memory inspection to build a sequence of inputs no human could sustain in real time. The run is saved as an input file, not a video, so it can be replayed exactly on the same emulator and game version.
How do tool-assisted speedruns work?
The author uses a rerecording emulator to load the game, then steps the game one frame at a time with frame advance while recording inputs at each step. Save states let the author rewind and try alternatives without losing progress. Memory inspection and Lua scripting reveal and manipulate the game’s internal state, including random number seeds, which is how luck manipulation steers dice rolls and item drops.
What is the difference between a TAS and a regular speedrun?
A regular speedrun is performed live on console hardware, with human reaction time, controller quirks, and no rewinds. A TAS is performed on an emulator with unlimited rewinds, frame-perfect inputs, and the ability to manipulate the game’s internal state. They are judged by different metrics and live in separate leaderboard categories.
Are tool-assisted speedruns considered real speedruns?
Within the speedrunning community, its are a real and distinct discipline, with their own leaderboards, rules, and publication standards. They are not eligible for human world records, because the input source is software rather than a person, and most communities keep the two categories clearly separated to avoid confusion.
What software is used to make a TAS?
Common choices include BizHawk for NES, SNES, and Genesis games, Dolphin for GameCube and Wii titles, Snes9x for SNES work, and LibTAS as a cross-platform option. Most setups pair the emulator with a memory watch tool, a Lua scripting environment, and a save state system that supports rerecording over previous attempts.
Can tool-assisted speedruns be performed on any game?
Most console games have at least one emulator capable of rerecording, which makes TAS work possible in theory. In practice, the author needs a deterministic game build, a stable emulator, and enough community knowledge of the game’s memory layout to plan routes. Games with heavy anti-piracy checks or heavy randomness are harder, but rarely impossible.
