There’s a moment in the 1996 Nintendo 64 game Super Mario 64 that most players never think about. When Mario dives and immediately starts sliding, his momentum carries a fractional value that persists for a few frames before the game’s physics engine fully recalculates his position. Speedrunners call this the “BLJ” — the backwards long jump — and it allows Mario to build impossible speed, clipping through doors and walls that were meant to be impassable. It broke the game wide open. It also required someone, at some point, to sit down and document exactly how it worked.
That documentation now lives on a wiki, maintained by volunteers, cross-referenced with memory addresses and frame data. It is more thorough than anything Nintendo ever produced internally.
This is the strange, unplanned legacy of speedrunning. What began as a niche competition to finish games fast has become something else entirely: the most granular, obsessive, and technically rich archive of video game history ever assembled. And almost nobody set out to do it.
The pursuit that demands total knowledge
To beat a game as fast as possible, you need to understand it more completely than the people who made it. Not metaphorically. Literally.
Speedrunners disassemble game ROMs, monitor RAM in real time, trace individual processor cycles, and log the behavior of every enemy, every hitbox, every invisible trigger. When a runner finds a new trick — a way to skip a level, duplicate an item, or corrupt memory in a useful way — they document it. Then someone else tests it. Then someone else optimizes it. The result is a living technical manual for games that, in many cases, their original developers no longer have the source code for.
Consider The Legend of Zelda: Ocarina of Time. The speedrun community has produced detailed maps of the game’s internal memory layout, catalogued how every actor (the game’s term for any interactive object) is stored and recalled, and reverse-engineered the precise conditions under which the game’s state can be manipulated. Nintendo, which lost or discarded much of the original development material for early 3D titles, has nothing this detailed.
“We know more about how this game works than the people who coded it,” one Ocarina of Time runner told me at a GDQ event. “That’s not arrogance. It’s just what happens when thousands of people stare at the same thing for twenty years.”
That accumulated staring has produced something no one asked for: a preservation record.
What gets saved when nobody’s in charge
The traditional model of game preservation relies on institutions — the Strong National Museum of Play, the Internet Archive, university special collections. These organizations do vital work, but they operate with budgets, permission structures, and institutional priorities. They save the games. They save the boxes and manuals. They sometimes save the marketing materials.
What they almost never save is the knowledge inside the games.
Speedrun communities, often unknowingly, fill that gap. Across thousands of games, they’ve produced:
- Frame data tables — precise measurements of how many frames each animation lasts, essential for optimization but also a record of how the game was constructed at its most fundamental level
- Glitch catalogues — categorized, reproduced, and explained, preserving the game’s bugs as a kind of unintentional feature set
- Memory maps — reverse-engineered layouts of how a game stores data in RAM, often the closest thing to source code that survives
- Version diff logs — tracking how different regional releases or patches changed the game’s behavior, sometimes at the byte level
None of this was created with preservation in mind. It was created because someone needed to shave four frames off a boss fight. But the byproduct is an archive of extraordinary depth, and in many cases it exists nowhere else.
The accidental infrastructure
The speedrun ecosystem has built its own tools, platforms, and institutions, all of which now function as preservation infrastructure whether anyone intended that or not.
Speedrun.com hosts leaderboards for over 30,000 games. Each page is a structured record: categories, rules, verified runs, video evidence, and community-maintained guides. It is, effectively, a catalog of how games are played at their most extreme — a record of human interaction with software pushed to its limits.
TASVideos.org, home of tool-assisted speedruns, contains frame-perfect playthroughs of hundreds of games, each accompanied by detailed technical submissions explaining every input and exploit. These submissions are peer-reviewed. They function as both entertainment and primary-source documentation of game mechanics.
Then there are the wikis. Individual game wikis maintained by speedrun communities — the SM64 Wiki, the Ocarina of Time Wiki, the Portal Wiki — are technical documents of a kind that no game studio produces. They contain disassembly notes, collision data, RNG manipulation strategies, and explanations of how the game’s pseudo-random number generator seeds and re-seeds. For older games where source code is lost, these wikis may be the most accurate technical reference that will ever exist.
This infrastructure is fragile. It runs on volunteer labor, free hosting, and the goodwill of people who have day jobs. But it is also, right now, doing work that no archive on earth is doing as well.
The uncomfortable question of credit
Here’s the part that should bother you.
The speedrun community has produced thousands of hours of reverse-engineering work, documentation, and technical analysis. Game studios — the same studios that lost or destroyed their own internal documentation — regularly benefit from this labor without acknowledging it. When a remaster or re-release fixes a famous glitch, the fix is often based on understanding that originated with speedrunners. Fan translation projects, ROM hacking scenes, and even official debug tools have borrowed from community-produced knowledge.
Speedrunners don’t generally mind. They’re not in it for credit. They’re in it because they want to go fast, and going fast requires understanding, and understanding requires documentation. The archiving is a side effect. A beautiful, irreplaceable side effect.
But it’s worth pausing to recognize what that means. The most detailed record we have of how classic games actually function — not how they were designed to function, but how they truly behave at the level of memory and code — was built by people trying to beat them as quickly as possible. No grant funded it. No institution sanctioned it. It emerged from competition, curiosity, and a refusal to accept that a game’s surface behavior was all there was.
The archive nobody planned
There’s a particular kind of irony in all of this. Video games were long treated as disposable entertainment, unworthy of serious preservation. The institutions that eventually stepped in to save gaming history did so with the tools and frameworks of traditional archiving: collect the physical media, preserve the binaries, interview the creators. Important work, all of it.
But the games themselves — the actual behavior of the software, the physics and the glitches and the frame timings — were too granular, too obscure, too deeply embedded in machine logic for any institution to catalog. That work required obsession. It required people willing to spend a thousand hours in one game to understand a single mechanic. It required a motivation that didn’t exist in academic or institutional contexts.
It turned out that motivation was speed.
The speedrunners weren’t trying to preserve anything. They were trying to win. But in the process, they built something that outlasts the games themselves — a record of how these strange, fragile pieces of software actually worked, written by the only people who ever bothered to look that closely.
