The Science of Speedrunning: How Glitches and Exploits Work

On August 1, 2022, speedrunner "cheese05" completed The Legend of Zelda: Ocarina of Time in 7 minutes and 48 seconds. The game's credits rolled. Link had defeated Ganon. The game considered itself finished. Yet no dungeon had been entered, no puzzle solved, no sword swing executed. Through a specific sequence of menu manipulations, the game's memory had been overwritten with arbitrary code, causing the game to jump directly to its ending — a technique called arbitrary code execution.

Speedrunning is not just playing games fast. At its technical frontier, it is applied computer science: a community of thousands reverse-engineering software through observation and experimentation, finding vulnerabilities the developers never imagined. This article walks through exactly how those vulnerabilities work, from the collision-detection assumptions that let characters clip through walls to the pseudorandom number generators that speedrunners learn to predict frame by frame, and it uses real, verified runs and investigations to show what happens when the technique is applied — or misused.

Key takeaways

• Glitches are unintended behaviors caused by incorrect assumptions in game logic — collision systems, memory layouts, timer precision — rather than intentional features.
• Out-of-bounds exploits occur when the game's collision system fails, allowing characters to enter geometry and access areas the game never intended.
• Memory manipulation glitches exploit how games store data; overwriting the wrong value can corrupt the game state into a skip-enabling condition.
• Arbitrary code execution is the most extreme glitch class: using game inputs to write and execute custom machine code within the game process.
• RNG manipulation turns apparent randomness into a deterministic tool — speedrunners can control "random" events by manipulating the pseudorandom state before it is sampled.

What a glitch actually is

Every video game is a simulation built on simplifications. The 3D world a player sees is a set of triangles; the physics are simplified differential equations; the "memory" of a character is a few bytes of data. Glitches occur when the inputs or state of the game reach a combination that the programmers' model did not account for. A useful way to think about it: a game is a map of a territory, and the map is always a simplification. Speedrunners are cartographers who specialize in finding the places where the map and the territory disagree — and stepping through the gap.

There are several broad categories:

Logic errors: The game's code makes incorrect assumptions. A common example: a door script that checks "is the player holding the key?" before opening — but the check happens only when the player approaches from the front. Approaching from behind skips the check and opens the door without the key.

Numerical edge cases: Floating-point numbers have finite precision and specific behavior at extreme values. A player moving at very high speed may "tunnel through" thin walls because the collision system checks whether the player's endpoint is inside a surface, not whether their path intersected it. If the player moves far enough in a single frame to pass entirely through a wall, no collision is detected. This is the same underlying problem that shows up in how video game physics engines work: an engine integrates position over discrete time steps, and any discrete approximation of continuous motion has gaps a fast enough object can pass through.

Memory corruption: Modifying a value adjacent to the intended variable — either through a buffer overflow or by manipulating data structures beyond their intended bounds — can produce cascading effects the game never anticipated.

Timing races: Games with multiple concurrent systems can have race conditions where the order of operations is non-deterministic or sensitive to exact frame timing. Two events happening in the "wrong" order can leave the game in an inconsistent state.

The single most surprising fact in competitive glitch-hunting: the *Legend of Zelda: Ocarina of Time* arbitrary code execution route was not found by Nintendo's own QA process in 1998. It was discovered by the speedrunning community more than 20 years after the game's release, built on a chain of smaller memory-corruption discoveries stretching back to 2013's Stale Reference Manipulation research.

Out-of-bounds exploits

Out-of-bounds (OoB) exploits allow a character to leave the playable geometry and move through or under the intended level. Once out of bounds, characters can skip large sections of the game by clipping into geometry that represents a later area, or trigger events that should only occur after other conditions are met. Understanding why this works starts with how hitboxes work in video games: the invisible shape a game uses to decide "did that collide" is almost never identical to what you see on screen, and the gap between the two is exactly where out-of-bounds routes live.

The mechanism varies by game:

Velocity-based clipping exploits insufficient collision resolution. If a game calculates a character's new position each frame by adding velocity to current position, and only checks whether the endpoint is valid, extremely high velocity can cause the character to pass through any finite-thickness wall. In Quake-engine games, bunnyhopping and strafejumping could accumulate velocity beyond the engine's tested range, enabling wall clipping. The GoldSrc and early Source engines behind Half-Life and Counter-Strike let players air-strafe while jumping to gain speed with each hop, and Source-engine titles built on the Orange Box branch (Portal, Half-Life 2: Episode Two, Team Fortress 2) introduced a variant called Accelerated Backwards Hopping (ABH), where jumping, crouching mid-air, and moving backward simultaneously produces exponentially increasing speed instead of the forward-facing bunnyhop's linear gain, according to the community-maintained Source Engine speedrunning documentation used by the SourceRuns leaderboard project.

Corner clipping exploits the geometry of collision shapes. Many games use simplified hitboxes (axis-aligned bounding boxes or capsules) rather than precise mesh collision for performance. At certain angles, the simplified hitbox can clip through a corner that the visual mesh would block. The Super Mario 64 "BLJ" (Backwards Long Jump) builds up negative velocity by exploiting the game's speed cap on backward movement but not on collision-detected backward velocity, then uses a corner to convert horizontal speed into vertical movement.

Geometry clipping exploits the fact that most game worlds are single-sided — polygons have a "front" face and an invisible "back" face. If a character reaches the back of geometry (typically from inside a wall), they pass through unchecked. Speedrunners in many 3D games find seams or corners where the game's collision mesh has gaps, allowing them to reach the geometry interior.

Why don't developers just fix the collision system to prevent this?

Because a truly gap-free collision system, one that continuously sweeps a character's full path every frame instead of just checking the endpoint, costs meaningfully more computation. Studios budget a fixed amount of processing time per frame across rendering, AI, audio, and physics; spending extra cycles closing edge cases that almost no player will ever trigger is rarely worth the trade-off against frame rate or visual fidelity.

Arbitrary code execution: the definitive exploit

Arbitrary Code Execution (ACE) represents the ceiling of speedrunning technical depth. The player's inputs overwrite game memory in a controlled way, writing machine code that redirects program execution — effectively allowing the player to program the game in real time. If a normal glitch is finding an unlocked side door in a building, ACE is closer to rewiring the building's fire alarm system from the parking lot using nothing but which doors you choose to knock on.

The canonical example is The Legend of Zelda: Ocarina of Time. The exploit chain works approximately as follows:

1. The game stores a list of "cutscene script" pointers in memory.
2. Through a specific sequence of inventory manipulation and save file interactions, the player can corrupt the actor object pool in a way that overwrites a cutscene script pointer with a value they control.
3. By carefully choosing their in-game inventory contents (which are stored as bytes in memory), the player crafts "shellcode" — a sequence of bytes that happen to correspond to valid machine instructions.
4. When the corrupted pointer is dereferenced, execution jumps to the player-crafted code, which calls the game's "end credits" function.

The players are essentially programming in machine code through game inventory management. This requires precise knowledge of the game's memory layout, the target platform's instruction set (MIPS R4300i for N64), and a stable method for controlling which bytes are written where. Guinness World Records has separately recognized both the fastest "Any%" completion and the fastest "100%" completion of Ocarina of Time, categories that speedrunners define by how much of a game's content must be completed and whether ACE-style routes count as legitimate — a distinction discussed further below.

Similar ACE exploits have been documented in Super Mario World (SNES), Super Mario Bros. 3, Pokémon Yellow, and dozens of other classic titles. Each game's ACE route is a feat of reverse engineering that typically involves hundreds of hours of community research, and it usually starts from a much smaller, previously "useless" memory-corruption bug that someone kept poking at for years before realizing it could be chained into full code execution.

How does a shellcode payload actually get "typed in" using a game controller?

Console games store player inventory, stats, and item counts as raw bytes in known memory addresses. Speedrunners work out which controller inputs write which byte values to which addresses, then perform an input sequence — menu selections, item swaps, specific button presses — that writes a chosen byte sequence into memory, effectively "typing" machine code one input at a time.

RNG manipulation: controlling the unpredictable

Games that appear random typically use Pseudorandom Number Generators (PRNGs) — deterministic algorithms that produce sequences of numbers that pass statistical tests for randomness but are entirely predictable given the initial state (the seed). This is the same principle behind why random loot feels rewarding: the "random" drop a player experiences as unpredictable is, under the hood, the output of an algorithm following a fixed formula.

Common PRNGs in games include:

PRNG type	How it generates numbers	Where it typically shows up
Linear Congruential Generator (LCG)	state = (state × a + c) mod m — a simple, fast recurrence	Classic console RPGs, older Pokémon titles
Mersenne Twister	A 623-dimensionally equidistributed bit-shuffling algorithm	Many modern engines and general-purpose game libraries
Xorshift variants	Fast bitwise shift-and-XOR operations	Performance-sensitive real-time systems

Table: Common pseudorandom number generator families used in game engines, and where speedrunners typically encounter each one.

Since the PRNG state is a specific integer value, and the game samples it at specific events, the "random" result of any in-game event is determined by how many times the PRNG has been sampled before that event. Speedrunners can manipulate the RNG by adding or subtracting PRNG calls before the critical event — waiting an extra frame, opening a menu, or moving in a specific way that happens to advance the RNG state to a favorable value.

In Pokémon games, the PRNG is an LCG that runs every frame. The probability of encountering a Pokémon on any given step is determined by the current LCG value. Speedrunners count frames meticulously from the game's startup to control which LCG state they're in when entering specific areas, ensuring they either avoid or encounter specific Pokémon as needed.

TAS (Tool-Assisted Speedrun) communities take RNG manipulation to its logical extreme. TAS players use emulators that allow frame-by-frame input and save states, enabling them to find the precise input sequence that produces the ideal RNG state for every randomized event in the game. The current Super Mario 64 "120 stars" TAS, maintained and continuously improved by a rotating team of contributors documented on TASVideos, stands at 1 hour, 20 minutes, and 41.517 seconds — nearly 22 minutes faster than the previous best, largely thanks to manipulating enemy and coin behavior that depends on the exact frame Mario's position is sampled. The resulting runs are physically impossible for humans to execute in real time but serve as demonstrations of the theoretical minimum completion time, according to TASVideos' published submission records.

When RNG manipulation crosses into cheating: the Dream investigation

RNG manipulation through legitimate means — waiting, walking a specific path, timing menu opens — is a skill within the game's own rules. But it draws a hard line against actually altering the game's code to change drop probabilities. In October 2020, YouTuber and Minecraft speedrunner Dream posted a widely viewed "any% glitchless" Minecraft speedrun in roughly 19 minutes. Other runners flagged the run's luck as statistically implausible, and Minecraft's speedrunning moderation team opened a two-month investigation, publishing a 29-page report in December 2020.

The investigators found that in the runs under review, Dream successfully bartered for an ender pearl 42 times out of 262 piglin trades and collected 211 blaze rods out of 305 mob kills, a roughly 70 percent yield rate against Minecraft's programmed 50 percent drop rate for blaze rods, a gap the moderation team's statistical analysis found was overwhelmingly unlikely to occur through chance alone, as documented in the team's official report. Dream's runs were removed from the leaderboard, and in May 2021 Dream said he had used a modified game version he believed increased drop rates inadvertently. The episode illustrates the boundary the whole community polices: manipulating your own inputs to steer a PRNG you can't alter is speedrunning; altering the PRNG or drop tables themselves is a different category entirely, and one every competitive leaderboard exists to catch.

Frame rules and timing precision

Some of gaming's oldest systems impose discrete "frame rules" — the game only updates certain states at specific frame boundaries, not continuously. Classic Super Mario Bros. famously has a 21-frame interval on level loading. Whether a level loads in 21 or 42 frames depends entirely on whether the flagpole was reached within the current 21-frame window. Losing a single frame before flagpole contact can cost a full "frame rule" of time. This is closely tied to why frame rate changes game feel: the discrete tick rate that shapes how responsive a game feels to an ordinary player is the exact same discrete tick rate a speedrunner is optimizing input timing against.

Speedrunners study frame rules obsessively because they determine which timesave opportunities actually matter. Saving 10 frames inside a 21-frame rule window is worth nothing. Saving 11 frames crosses a boundary and saves the entire rule. It's a bit like a subway system running on a fixed schedule: shaving 30 seconds off your walk to the platform does nothing if the train still leaves at the same minute, but shave off 31 seconds and you catch the earlier train.

Modern retiming standards in speedrunning communities (particularly at Speedrun.com and Games Done Quick) have moved toward millisecond timing using video analysis software like LiveSplit with load-time removal, allowing fair comparison across different hardware with different load times.

From basement hobby to charity institution

Speedrunning's technical culture did not stay in forums and Discord servers. Games Done Quick, the twice-yearly marathon event that pairs top speedrunners with charity fundraising, has raised more than $59.8 million since its founding in 2010, according to the organization's own event totals. Awesome Games Done Quick 2026, held in Pittsburgh in January, raised $2,443,414 for the Prevent Cancer Foundation, and Summer Games Done Quick 2026 raised roughly $2.41 million for Doctors Without Borders, bringing GDQ's total for the year to about $4.85 million across its two flagship marathons. Every run shown on that broadcast, including the most spectacular arbitrary-code-execution finishes, is the direct product of the reverse-engineering work described throughout this article: someone, somewhere, found the gap between the map and the territory first.

What people get wrong about speedrunning glitches

"Glitches are just bugs, so using them is cheating." Whether a technique counts as legitimate depends entirely on the category a runner enters, not on some universal rule. "Glitchless" categories explicitly ban exploits like out-of-bounds movement or ACE; "Any%" categories allow anything that gets to the credits fastest, glitches included. Both are valid, rule-governed competitions — they're just answering different questions about what "beating the game" means.

"Speedrunners just get lucky with easy games." The opposite is closer to true: the games with the deepest speedrunning scenes tend to be the ones with the richest glitch ecosystems, which usually correlates with complex, ambitious engineering for their era (large open worlds, complex physics, big inventory systems) rather than simplicity. Ocarina of Time's ACE route required over two decades of layered community discoveries, not a lucky afternoon.

"Developers should just patch every glitch." Patches are a double-edged sword: fixing a glitch can also alter unrelated game behavior for non-speedrunning players, and many competitive communities deliberately preserve access to older, unpatched versions specifically to keep beloved routes viable. A patch that "fixes" a decade-old TAS-discovered exploit can retroactively end an entire category of competition.

"Tool-assisted speedruns (TAS) are the same as regular speedruns." TAS runs use emulator features like frame-by-frame input entry and save states that no human console player has access to. TASVideos and the human speedrunning community treat these as clearly separate categories: TAS runs demonstrate a game's theoretical minimum completion time, while human speedruns demonstrate what a person can actually execute in real time, with real reaction speed and real mistakes.

FAQ

Q: Is speedrunning cheating? A: Most speedrunning communities have clear categories that distinguish "any%" (any method to reach the credits), "glitchless" (no unintended mechanics), and "100%" (all required content). Whether a specific technique is "cheating" depends entirely on the rules of the chosen category, which the community defines and enforces. Within a category, all runners use the same rules.

Q: Can game developers patch speedrunning glitches? A: Yes, and many do. Patches are a double-edged sword: they may fix a glitch but also change game behavior in ways that affect non-speedrunners. Many speedrunning communities maintain old game versions to preserve access to desired glitches, running on original hardware or patched-out emulators.

Q: What is a "wrong warp"? A: A wrong warp is when a level transition or teleport sends the player to an unintended location. In many 3D games, warp destinations are stored as level identifiers in memory. If that memory is overwritten (through an unrelated memory corruption) before the warp executes, the player is sent to whatever level identifier was written there — often an invalid location, a debug area, or a later level.

Q: How do speedrunners find glitches? A: Through a combination of systematic testing (trying unusual inputs at every boundary), memory observation using emulator debugging tools, and sharing observations in community forums. Discord servers, dedicated game-specific speedrunning wikis, and TASVideos are major hubs. Many major glitches were found years after a game's release through continued community investigation, as with Ocarina of Time's ACE route.

Q: What is "load remove" in speedrun timing? A: Many modern speedrun games have variable load times depending on hardware (SSDs load faster than HDDs, modern consoles faster than original). To compare runs fairly, the community uses software that detects loading screens (by pixel comparison or frame analysis) and subtracts that time from the final result, producing a "loads removed" time that reflects gameplay skill rather than hardware speed.

Q: What's the difference between a speedrun and a Tool-Assisted Speedrun (TAS)? A: A regular speedrun is performed in real time by a human on original or emulated hardware, with all the input limitations a human has. A TAS is created using emulator tools like frame-by-frame input and save states, allowing the creator to test and re-test every frame until they find the theoretically optimal input sequence, something no human could execute live. TAS runs are published separately, most commonly through TASVideos, and are judged on optimization rather than live performance.

Q: Why was Dream's Minecraft speedrun record removed? A: A moderation team from Minecraft's speedrunning community investigated Dream's October 2020 "any% glitchless" run after other runners flagged its item drop rates as statistically implausible. Their published report found Dream's blaze rod and ender pearl drop rates were significantly higher than the game's programmed odds, and concluded the run used a modified game version. The run was removed from the leaderboard in December 2020.

Q: Do all speedrunning glitches require memory manipulation? A: No. Many glitches, like corner clipping or velocity-based wall clipping, exploit gaps in collision detection or physics resolution without ever directly reading or writing arbitrary memory addresses. Memory manipulation and arbitrary code execution sit at the far end of a spectrum that starts with much simpler exploits, like walking through a door from an unexpected angle.

Q: Can speedrunning glitches damage a game save or console? A: Legitimate speedrunning glitches operate within the game software and generally don't damage hardware, though some memory-corruption routes can corrupt an individual save file if executed incorrectly, requiring the runner to start over. Console manufacturers and game publishers have not historically treated speedrunning glitch discovery as a hardware safety issue, unlike, for example, hardware modification.

Q: How much money has Games Done Quick raised for charity? A: Games Done Quick has raised more than $59.8 million for charities since 2010, including Doctors Without Borders and the Prevent Cancer Foundation, according to the organization's published event totals. Its two 2026 marathons alone raised a combined total of roughly $4.85 million.

The takeaway

Every glitch in this article traces back to the same root cause: a game is a simplified model of a world, built under real constraints of processing time and development budget, and the model always has edges the designers didn't fully test. Speedrunners are not breaking games so much as reading the fine print the developers never meant to write. That reading takes the same skills as professional reverse engineering — memory analysis, statistical reasoning about randomness, precise timing — applied by a hobbyist community that turned a shared curiosity about "what if I do this" into one of gaming's most technically rigorous subcultures, and, twice a year, into millions of charity dollars.

---

Read next:

• How Video Game Physics Engines Work: Simulating Motion
• How Hitboxes Work In Video Games
• Why Random Loot Feels Rewarding