How Do Speedrunners Find Glitches in Games? A Step-by-Step

A speedrunner hunting glitches approaches each title as a software system whose rules can shatter under specific inputs, probing the seams where developer assumptions crack. The core workflow runs observation, hypothesis, memory or state inspection, reproduction, and community verification, with the same disciplined steps applied whether the trick skips a cutscene or triggers arbitrary code execution.

This piece walks through the workflow behind spotting, testing, and confirming exploits, from the initial hunch to memory inspection and community validation, with a look at how tool-assisted runs and reverse engineering fit the picture.

The Mindset Behind Glitch Hunting

Glitch hunters approach games as software with rules that bend under the right input, and that mental shift is what separates a casual player from a researcher. A normal player sees a wall; a hunter sees a collision mesh with edge cases at the seams, vertices, and slopes, and immediately wonders what happens if you touch that boundary with the wrong frame of inputs.

Discovery usually starts with curiosity about unusual behavior spotted during normal play, then escalates into controlled testing of edge cases. A wrong sound cue, a character clipping one pixel into a floor, or a boss entering a state it was never meant to enter each becomes a question worth probing rather than a one-off curiosity to forget.

Bug, Glitch, and Exploit Are Not the Same Word

Speedrunning communities separate three terms that casual writing often blurs, and your framing changes depending on which one you’re chasing. A bug is the underlying unintended behavior written by the developer’s code. A glitch is the reproducible side effect of that bug, the visible symptom. An exploit is the deliberate use of that symptom to gain an advantage such as skipping a boss or warping past a key.

Leaderboards treat the three categories differently: a major glitch may be banned entirely, while a minor one might be allowed inside a specific category. That vocabulary shapes how you frame the work, because chasing an exploit means asking whether the community will accept the trick once it’s found, and that social layer is part of your methodology from day one.

How Glitches Are First Spotted and Tested

Many major discoveries begin with an accident: clipping through a wall during a hard turn, a boss skipping a phase after a specific weapon swap, or a wrong warp triggered by entering a room at an odd angle. The Super Mario 64 backwards long jump, where Mario builds speed by jumping backward on a flat surface and clips through vast sections of the castle, started as curiosity about momentum at the wrong camera angle. The famous Ocarina of Time wrong warp surfaced when a player noticed the game loading the wrong scene after death warping in an unusual dungeon entrance.

Once an unusual outcome shows up, your next move is to reproduce it under controlled conditions. Reset to a known save state, repeat the same input sequence, and slowly isolate which variables actually matter. If the trick still works after the inputs are stripped down, it’s a real glitch. If it only works on the first attempt of a fresh session, it might be a one-time memory fluke, and the community will quietly set it aside.

Common Experimental Levers

Most glitch testing revolves around a short list of controllable variables, and experienced hunters change one of them at a time to see what breaks:

• ▸Position coordinates: Standing half a pixel inside a wall, or directly on a vertex of the collision mesh, can change how the game resolves your next move.
• ▸Frame-perfect inputs: Pressing a button on a specific frame, often a 1/60th-of-a-second window, lines up state changes the developer assumed would never align.
• ▸Inventory arrangements: Equipping, unequipping, or swapping items in a specific order can leave the game in a half-updated state that triggers bugs.
• ▸Console hardware differences: Games developed across generations, such as N64 and GameCube memory mapping, can produce different behavior for the same input sequence on each platform.

Controlling those levers is what turns a single lucky clip into a documented glitch. Each variable gets its own test pass, and the run that triggers the bug is saved so the inputs can be replayed frame by frame later.

Reading the Game’s Memory and Rules

Tools like Cheat Engine, BizHawk, and Dolphin allow runners to watch live memory addresses for values such as player coordinates, health, or inventory state, making invisible variables visible. Cheat Engine scans a process’s RAM for a value you control, such as your health bar, and pinpoints the address the game stores it in, while BizHawk and Dolphin expose those addresses directly through debugger windows tied to the running emulator.

When a value changes in an unexpected way after an action, that mismatch between cause and effect is the fingerprint of a glitch worth investigating further. Jump and your Y coordinate suddenly reads 32,000 instead of 0, which signals an integer overflow, a value the game stored in too small a bucket that wrapped around to a negative number and the engine read as a huge positive. That single observation often explains why a wrong warp happens and how to reproduce it.

RNG Manipulation as a Hidden Lever

Runners also study the random number generator, or RNG, learning its seed so precise timing can influence drops, enemy spawns, and damage rolls rather than leaving them to chance. Most console RNG is not random at all, but a deterministic sequence driven by a starting seed, often the in-game timer at the moment of a key event. Knowing that, runners can pre-compute the sequence and then delay a critical hit by a few frames to land on a favorable roll.

This is why Pokémon speedruns often feel scripted, where shiny encounters and specific item drops matter to the final time. The runner is following a calculated path through the RNG state, hitting specific frames so the generator produces the desired outcome. The difference between a luck-based encounter and a manipulated one is a clean understanding of the underlying seed.

“Tip: a safe first setup is an emulator, a memory viewer, and a save state you can reset freely, so you’re exploring the game’s logic without risking a real cartridge or live save.

Where Tool-Assisted Speedruns Fit In

Emulators running frame-by-frame input macros power tool-assisted speedruns, executing sustained actions no human reflexes could manage and turning TASes into discovery engines as much as optimization tools. LibTAS and BizHawk’s TAS features let researchers script a button press, advance one frame, press again, advance again, and chain thousands of inputs per second with no physical controller involved.

Running a game at variable speed, rewinding after crashes, and brute-forcing thousands of input sequences per second allows a TAS setup to surface glitches that would take a human thousands of attempts to find. You can record a known setup, then loop through 50,000 input variations overnight and return to a list of every sequence that triggered the target state. The Super Metroid Mockball and several Ocarina of Time route-shaping glitches were first mapped this way before any human attempted them.

From TAS Discovery to Human Leaderboard

When a TAS-only glitch is verified, communities often decide whether to permit it on human leaderboards, restrict it to a separate category, or leave it as theoretical entertainment. Speedrun.com and individual game boards publish rules that classify tricks as allowed, allowed-with-restrictions, or banned, and the discussion usually happens in Discord evidence channels where runners post inputs, video, and a written explanation of the underlying mechanic.

That gatekeeping matters because TAS glitches are sometimes so demanding that only a handful of humans can ever land them, which would warp the leaderboard around a tiny number of players. Splitting the board into any% and TAS-only categories keeps each ranking meaningful.

Reverse Engineering the Deeper Bugs

Advanced exploits such as arbitrary code execution, often shortened to ACE, come from understanding how the game stores and interprets data, sometimes through decompilation projects hosted on GitHub. When a community decompiles a game, like the open-source projects for Super Mario 64, Ocarina of Time, and Pokémon Red, you turn the original compiled binary into readable C code, and the exact instructions the game’s CPU follows become a public document rather than a guess.

Save corruption, buffer overflows, and type confusion bugs allow a player to overwrite game instructions with custom code, effectively turning a console into a tiny computer that runs whatever the glitcher wants. A type confusion bug happens when the game stores a piece of data as one type, say a number, but reads it as another, like a memory address, so you can swap the value to a different type and trick the engine into running your data as code.

How ACE Actually Triggers

The famous ACE through wrong warp in Super Mario 64 works because the game trusts a specific memory address to point to valid level data, and the bug lets a player replace that pointer with an address that points to code they control, often a string of controller inputs stored in memory. The result is custom music, corrupted character sprites, and on real hardware, full control over the console’s behavior.

These techniques are rare and game-specific, but they explain how some of the most famous speedrun moments actually work under the hood. The Pokémon generation 1 ACE that ends runs in seconds follows the same shape: a stored value, a misread, and a chain of effects that let the player rewrite the game’s own instructions.

Once the inner workings are exposed, the discovery has to survive public scrutiny before it can influence any run.

How the Community Verifies and Documents Discoveries

A new finding is shared in Discord evidence channels, forum threads, or during a live Twitch stream, where moderators and experienced runners attempt to reproduce it on real hardware or a clean emulator. Live verification is the gold standard, because it removes any chance of doctored inputs, and a moderator running the same trick on a stock N64 or a wiped save file is the final stamp of approval.

Successful reproductions are written up on dedicated wikis and route guides, then classified by impact as major glitches, minor glitches, or category extensions that unlock entirely new leaderboard boards. A major glitch typically rewrites a route; a minor one saves a second or two; a category extension opens a route that wasn’t possible before, like a 0xA button glitch that creates a new all-glitches board.

The social pressure of public testing filters out one-off flukes and protects the integrity of the leaderboards, turning a single lucky clip into an accepted part of the game’s speedrun history. That’s also why careful runners avoid posting unverified tricks publicly, and why moderators often hold findings back until they’re reproduced at least three times across different setups.

Categories of Glitch by Impact

Most games sort findings into a stable impact ladder, and the ladder directly shapes what counts for which leaderboard:

Category	Effect on the run	Typical leaderboard treatment
Major glitch	Skips entire sections of a run, often the trick that defines a route	May be banned in some categories
Minor glitch	Saves a small amount of time, usually under five seconds	Allowed everywhere, treated as part of the optimized route
Category extension	Unlocks a new way to play, like a different ending or 100% variant	Often spawns its own leaderboard board
Theoretical glitch	Confirmed by TAS but not yet landed by a human	Kept in a separate archive until someone proves it’s physically possible

Starting Your Own Glitch Investigation

A safe beginner setup is an emulator like BizHawk or Dolphin, a memory viewer, and a practice save state you can reset freely without risking a real cartridge or console. Install the emulator, load a ROM of a game with an active community, find a save state posted on the community wiki, and you have a sandbox where every input is reversible.

Pick one retro game with an active community, study its wiki to learn what has already been found, then deliberately try inputs and conditions that existing routes avoid. A simple first experiment: take a known minor glitch and change one variable at a time. Swap the equipped item, move half a pixel, shift the timing by a frame, and record which changes break the trick and which leave it intact.

Where to Share and What to Document

Share anything unusual in that game’s Discord or forum, because even failed attempts help the community rule out dead ends, and consistent documentation is what turns glitch hunting from luck into a craft. A good write-up includes the inputs as a frame-by-frame list, the console or emulator version, the save state used, and a one-paragraph explanation of what you think is happening in memory. Even a clean report that says you tried X and it didn’t work saves the next investigator a day of work.

Two final habits speed up the learning curve. Watch a few TASVideos research notes for the game you picked, because they read like engineering write-ups and show the level of detail a community expects. Then join a Games Done Quick chat or watch a live verification stream to see how moderators walk through a new finding in real time, because the social protocol around a glitch is half the craft.

That social layer is exactly what separates a solo hobbyist from someone who actually shifts how a game is played.

Final Thoughts

Glitch hunting is software research with a leaderboard attached, and the same disciplined steps that surface real bugs in any codebase apply to a 1996 console game: observe, hypothesize, inspect state, reproduce, and verify with someone else watching. The tools are accessible, the communities are welcoming to documented attempts, and your first finding doesn’t have to be a wrong warp. A clean reproduction of an existing trick, with a write-up that explains which input actually matters, is already a real contribution to the speedrun glitch discovery process.

FAQ