How is it possible that classic 3D video games such as Super Mario 64 and Ocarina of Time can contain such bizarre "glitches"?

Question

I've been watching "speedrunners" play those games for quite some time. I still can't believe what my eyes are seeing. Somehow, they have managed to find bizarre bugs in the games which enable them to do things which I cannot imagine that I or anyone would ever encounter by playing the game.

I'm talking about standing at precise spots against walls and pressing keys in an exact manner to somehow cause Mario to start flying at super speed through the walls and other objects, for a long time, until he drops into some warp zone further away in the level. It looks unreal. I have real difficulty believing:

1. That it's the original game and not some kind of modified copy. (But it actually is.)
2. That somebody is able to reproduce these reliably.
3. That somebody encountered these in the first place.
4. That a game, even if 3D and thus complex, can actually contain such strange bugs.

Maybe I can understand that the collision detection code has a bug so that you can fall through certain objects or walls. OK. That makes sense.

But how can the game make Mario seemingly start ignoring all the rules of the game world and go flying (while seemingly standing) across several rooms at super speed? How does that actually happen? How does that make it into game code? And how does anyone find that, no matter how popular the game is?

Unless this entire reality has been set up just to mess with me, this is real. But I don't understand how it can be real.

I've never, even once, encountered even a minor glitch in any game while playing it. The speedrunners press the buttons and move the analogue stick around to seemingly freely warp around in the game world and do whatever they feel like. It's as if they had enabled some sort of crazy debug mode with a "Game Genie" or "Action Replay" cartridge hooked up to the console, but it's actually done on the original game, not using an emulator or modified ROM.

I simply don't understand how it can be the case.

Answer 1

3D games like Super Mario 64 and Ocarina of Time are time-step-based physics simulators. Their basic design is based on the assumption that nothing goes above a certain speed. Each frame, Super Mario 64 calculates four time steps, in which it (among other things):

• moves Mario ¼ of the distance he's supposed to travel in that frame; then
• pushes Mario out of any walls / floor / ceiling he's found his way inside.

There are three oversights that make this a massive source of glitches:

• When the game calculates that Mario “should” move out-of-bounds and stops him from doing so, he doesn't slow down.
• “Out-of-bounds” is defined as “places without a floor under them”.
• Long-jumping only has a speed limit in the forwards direction.

This means that all you need to do is find a thin wall without floor behind it, long-jump a distance away from it, hold the control stick backwards and keep sustaining that long-jump; if you time it just right, you'll land just before the wall so that ¼ of your speed would put you out of bounds, so you can keep mashing the A button and go as fast as you need to.

Also, at least in Super Mario 64, there's only bounds checking for regions without floors; areas of floor that extend outside or between rooms are perfectly accessible if you can clip through walls.

The game developers really didn't expect anybody to go so fast that they leave the map behind, so everything that occurs outside the map is an artefact of the design of the rest of the game; most of the glitchiness you'll observe there doesn't really count.

Because Super Mario 64's floor collision calculations use 16-bit integers (unlike the rest of the game, which uses floats), there are partial copies of the level repeated every 2¹⁶ units in the x, y and z directions. If you go fast enough, you can enter them without going through an out-of-bounds region, which has interesting effects.

Most of the other glitches are due to synchronisation issues:

• A crate can be picked up for a couple of frames without stopping the despawn timer, causing Mario's hands to point to uninitialised memory that's later populated by the next item to spawn.
• Once activated, a text box will wait until you're on the ground before showing, but if you jump just after it's activated and fly away, you can get it to show (and run the associated code) in a completely different part of the level, letting you trigger bits of the level's scripting out of order.

Certain code is keyed off animation states, so being in an unexpected animation state can suppress its execution; e.g., the “fell in lava” animation can't run during the “sliding” animation, and the “lose health” script is keyed off the “fell in lava” animation, meaning you can slide across lava without losing health.

I'm not sure of the details of Ocarina of Time, but since it uses almost the same engine I assume most things are the same.

Answer 2

The short answer is: These games are built on code which is supposed to simulate the laws of physics, at least for motion. But they are also games, which means that that code has to run fast enough for the game to be playable. To do that on the original hardware (which, after all, cannot run arbitrarily fast like nature does), the code author had to take short-cuts in the physics simulation. Those short-cuts cause side-effects which are not necessarily obvious (especially to a developer under pressure to get the product out now). People who play the games often enough and with enough variation in action eventually stumble on those side effects - and occasionally they are exploitable.

Answer 3

You probably don't encounter these glitches because you play the game as the developers intended.

In Oblivion you can pickup plates and stuff to move or throw (which is the intended use), but if you place the plate below yourself while holding, you could jump on it making you and the object move up and then you could jump on it again and again (which kinda makes your fly). But in real life you would never try to jump on a plate you holding below yourself, so why would you in the game.

It probably helps if you know some programing, but this behavior kinda makes sense from a programming point of view. So knowing what kind of mistakes people can make while developing a game, and just trying lots of random stuff. You will probably find a few glitches in any game.

Lots of retro games can now also be simulated on the computers, which give the users lots of tools to find these bugs easier.

IGN has videos of developers responding to speedruns, they sometimes explain what went wrong in development for the glitch to happen. Or Stryder7x has videos in which he explains glitches in Mario the thousand year door.

Answer 4

No software is ever bug-free, and games are no exception. The reason most of these bugs seem so crazy is that they're complex and frequently require several things to go right (wrong?) at the same time, combinations of things that rarely make sense in the context of normal gameplay.

A large portion of these exploits are discovered by people playing the game in an emulator. When you're emulating the hardware, you can pause the emulation and examine the internal machine state at any point in time. You can see exactly which memory locations get modified when you pick up a coin or when you change the direction that you're moving. After you understand how all of the individual pieces of the game work, you can start thinking about what might happen when you combine those pieces in unintended ways. If you want to travel across the map quickly, you might start by examining moves that temporarily increase your movement speed and then try to make that increase permanent by finding a way to interrupt or bypass the code that resets your movement speed to normal at the end of the move.

In other words, those exploits likely weren't discovered by someone who decided to stand in this particular corner and press a random button sequence to see what happened. They were discovered by someone who studied how the game worked and is actively trying to break it. You start with the effect that you want, then you contrive some sequence or situation (the exploit) that could cause that effect.

Once you have the exploit created, you can use it in the original, non-emulated version of the game as well. This makes it look more impressive since you're obviously not using some sort of modified version of the game. Some exploits require timing so precise that it's not feasible for a human to do by hand. Those exploits typically require an emulator, so that software can trigger the exploit with the required precision (as in a "tool-assisted speedrun").

Answer 5

A good way to think about it is to consider board, card and tabletop games:

A board game has rules: who goes first, what happens when you land on a space; and state: whose turn is it, where the pieces currently are, how much each player has. So does a card game like Magic the Gathering, and a tabletop role-playing game like Dungeons & Dragons has a lot more.

Do these games have glitches too? They do, in a manner of speaking! What is a glitch? Let's say it's a vastly unexpected interaction that comes about because of some combination of states according to the rules of the game.

(Let's discount non-repeatable glitches that come about by freak specific circumstance. Knocking over the board, stealing money, pulling out the cartridge...)

If there was some quirk of the rules in Monopoly that, if strictly followed, meant that a player could take infinite turns, or collect $200 GO money every turn, that'd be a glitch. Dungeons & Dragons is vastly more complicated than Monopoly - by 'some interpretation of the rules', a super-powerful character like Pun-Pun can be developed. This and similar characters are made by looking at the rules of the game, coming up with some assumptions about how the model of the game works, and finding through trial-and-error or exhaustion the limits where the rules no longer apply. Look at the conditions you have to follow to make that character - doesn't it resemble the totally weird sets of button presses and conditions the player has to input to execute a Super Mario 64 glitch technique?

The RPG and Board & Card Games Stack Exchanges are all-but dedicated to the resolution of unusual cases and combinations of states and rules within games like this.

The 'advantage' of these non-electronic games above computer games is that the rules are being interpreted by humans. Humans have the advantage of understanding the context of the world, and can be flexible with the rules - every non-electronic game is played by mutual agreement and understanding of the players involved. If the rules listed a human player character's standard running speed in miles-per-second instead of miles-per-hour, you'd understand that it was a mistake and perhaps a misprint, unless they were The Flash. If a rule is blatantly unfair or unrealistic in context, even by design, you can strike it out.

The glitches of Super Mario 64 are more striking compared to a tabletop game because everything happens in real-time: resolution of the rules is automatic and instant, and the rest of the game continues as normal around it. There's no referee to appeal to - if 'the rules' say Mario can do it, and XYZ happens as a result, that's what happens.

How are things like this found? By accident, through observation and repetition. In video games there's also a sneaky way that we don't (yet) have in real life: examination of the code.

It's like a scientific discipline - when something unusual happens, you construct a mental model of what is happening and why, what the rules and state are and how they're represented, attempt to repeat the conditions you've laid out, and ultimately determine the conditions by which something does and doesn't happen. The game Super Mario 64 is an imperfect realisation of the intended design, either through compromise or error.

Why would 'the rules' be wrong with respect to the intent?

A perfectly stable game would have the following properties.

• The model considers every possible interaction of every possible set of objects under all circumstances.
• There's a sensible response to each of these circumstances.
• It's impossible to violate the assumptions built into the model.
• The model is an accurate description of the intended simulation.

When one of these conditions isn't met, your simulation won't match your expectations, and you'll have a glitchy game.

If you're already carrying an object, can you pick up another? What if you're sliding down a ramp while crouched and collide with a Wing Cap? Does collision still apply during the 'putting the hat on' animation? What happens if you get hit while opening a door? Is there a maximum speed if you continue move using a specific maneuver? Somebody has to think of all these things. If a limit isn't explicitly established, it doesn't exist. It might implicitly be bounded as a consequence of other rules, but if those rules can be evaded, then speed, location, score, lives, time are all up for grabs.

Answer 6

Since Ocarina of Time was mentioned, I'll say a little about that too, and things that aren't related to faulty collision detection. Many of the really game-breaking glitches in this game (i.e. which speedrunners would find useful) depend on the player doing two or more things simultaneously (or in quick succession), and the game doing unexpected things as a result.

Here is a simple glitch that anyone can try out. It will replace any item in your inventory with a bottle (perform at your own risk). Have an empty bottle equipped, and go to something you can catch in a bottle (say a fish, that is easiest). Use the bottle. As Link starts swinging the bottle, pause and equip something else instead of the bottle. Unpause, let Link finish capturing. You now have a bottle with a fish equipped, and if you go to the item screen, you will see that the item you equipped over the bottle is replaced with your new bottled fish.

So what happened? The developers didn't make it so that equipping something over a bottle cancels the capturing. That's all. It's a simple oversight. To understand the result, let's take a look at how a capture normally works:

When Link has captured a fish, the game looks back in time at what C-button was pressed to do the capture. It overwrites the empty bottle that was there with a filled bottle. But the item menu must also be updated. For this purpose, the game also keeps track of what item menu slot has been equipped to what C-button (if you're familiar with the look of the item menu, basically, where the white squares are). And then it just overwrites the corresponding slot with the same filled bottle. It doesn't check that that slot previously held an empty bottle. Why would it? You must have had a bottle equipped on the C-button in the first place, right?

And now you can probably see how you can replace your deku nuts or your hookshot or whatever else with a bottle. If you, between the time when you started the capture, and the time when the capture is completed, change which item is on the C-button, then the newly filled bottle will be written to some other item location. The game just carries on without bothering to check that what it does makes sense.

Many of the more advanced glitches you will see speedrunners do, at their core, are in much the same way about doing two or more things simultaneously or right after one another, make the game similarily confused, and through that gaining access to changing pieces of memory that a player isn't normally supposed to have access to, or achieve other crazy effects. This particular glitch is quite limited in what it can write to where, but other glitches are much more flexible.

For instance, say you managed to get a bottle on your B button (which is done by timing button presses much like the pausing and equipping above, but it is more precise, and I don't know the exact approach myself; the effect is that you confuse the "looking back in time" part of the above to make the game think you used your sword last). Using that bottle will completely confuse the "where is the white square" part of the above description (conveniently based on what item you have equipped on your C-right, because of how the memory is laid out). This gives you access to much more than just the items in your inventory, and lets you force, say, the game to write a "bottled fish" into your medallion or song collection. This is the glitch known as "reverse bottle adventure".

As for how people find these, some of them are found on accident. Some have been discovered, thought to be some funny one-off thing with no application, and years later found to be game-breaking ("stale reference manipulation" and "wrong warping" come to mind, and reverse bottle adventure was thought to be nothing but a stepping stone to the now less known "bottle adventure", until it was discovered to have its own very useful effects). And some glitches are hunted for. There are people who have a tremendous understanding of how the game works, think of something they want to achieve, and use their knowledge, together with their community, to see if they can make it happen. Barrier skip from Wind Waker is the most well-known successful such community driven glitch hunt that I know of.

Answer 7

I'll be focusing first on the "How does anyone find that?" part of your question, but that will lead us to the "how did they get there" portion too:

There are a few ways.

Chance

Some things will just happen by random chance. I have come across glitches in some games where I've fallen through the floor, for example. Often these funny mistakes get spread around, because they are interesting and unusual. With millions of players, playing for cumulatively 10's or 100's of millions of hours of game time, you'd be surprised at the "glitch" conditions which can be generated purely by accident. Some of these things will be spread around, by word of mouth or particularly in the internet age, by videos etc. on social networks or on YouTube.

Programming knowledge leading to discoveries

Second, if you have ever tried to program games, or even if you've just tried any kind of coding in general, you may be able to, when you play a game, think about how it's likely to have been coded. For example, I have only ever coded one thing which somebody might charitably call a game - as part of a university project. That game had collision detection, admittedly only in 2D and really only for the player character, so it would have been much simpler than the implementation in Mario, but there are still some things we can learn.

Collision detection is a system with code which figures out if the character you are controlling (or indeed, any other object, character etc.) has collided with an object, the floor, another character, etc. - typically, for the player character, it will work something like this:

For each frame:

• Move the character where you're telling it to move (calculate a new position based on movement speed and direction)
• Check if any part of your character (or maybe just a subset of points related to the character's limbs to make it simpler, or sometimes just one point relating to your character's position, depending on the nature of the game, player models, etc.) is inside of another object (or character etc.) - if this is the case: move the character back so they are just touching the wall/character/object, and possibly perform some action - if Mario has run into a wall fast enough, he might "bonk" off of it and say "ow!". More generally, not just for collision detection, the process is: Change some state about the game (player position, move speed, etc.), check the new state for anything important, if anything important has happened or there are problems with the new state (such as the character being inside a wall), do something about it (resetting values, having a collision "bonk" and repositioning, updating the player's score, killing the player, etc.).

Having coded a very basic implementation of this myself, I ran into a problem: My player character could speed up as the game progressed. If he went fast enough, I could (potentially) run into a problem where on one frame he is to the left of a wall moving rightwards, I would calculate his new position based on direction and speed, check to see if his position was intersecting a wall or object, but find that because of his high speed, he has actually passed entirely through the wall or object so that he is fully on the right side of the wall, without intersecting on the next frame, and therefore my collision detection code would say "Nope! Everything OK! Don't need to do anything here!". One of the key things to realise here is that speed, position etc. are calculated and checked in discrete increments - in most modern games this will be 60 times per second as this is the frame rate the game runs at - and as the travel speed increases, as the character travels further between each frame, the distance between each check that occurs increases.

There are ways to code around this, but it was what's called an "edge case" - the character would have to be going very fast for this to happen, and it's extra work to code in this more robust way - besides, I worked it out and the character could never actually get up to a speed fast enough to cause this to happen.

But what if I was wrong about that? What if there's some edge case or just outright mistake in the code which calculates the character speed? What if I've limited the speed a character can run at, but I've got something which increases your speed when you do a certain kind of jump? Like a long jump? Even if only temporarily? Say I've coded it so that when you do a long jump, you're travelling faster than the max run speed while you're jumping, but you very quickly slow back down again when you hit the ground, say within 2-3 frames (to make the animation look smooth, for example). What if, then, the player realised that with extremely precise timing they could chain long jumps together, and have it so that the second (and third and nth) long jumps increased the speed even further?

Well OK. I've realised this and caught it, and coded in a hard speed limit for the character. The character can now only move forwards at a maximum of 20 units per second (this is an arbitrary number but you get the idea). What I've failed to account for though is that under certain circumstances such as standing on a steep staircase, the player can perform a long jump but it'll actually move them backwards! I've put a forwards speed limit in but not a backwards one, and now the character can do a backwards long jump over and over again, provided they are standing facing down a steep enough slope, build up extreme speed, and that with this extreme speed they can end up in the situation I mentioned where they clip straight through a wall very quickly (essentially they would be "inside the wall" between frames and position checks), and the collision detection code which is meant to stop your character passing through that wall doesn't detect any problems.

So what you can take from this is two things:

• Glitches are often a result of edge cases which the programmers thought were either impossible (mistakenly) or that would be so rare that it wasn't worth the extra effort to code around. They might also be a result of multiple edge cases for different systems in the game (movement and collision detection in this case) interacting with each other.
• If you understand how at least some aspects of game coding in general work then you may be able to make guesses about how you can break the game - in this case, knowing how collision detection is generally implemented, you might already have realised that a) speed can break it, and b) there's a speed limit for Mario going forwards, but when you see a backwards jump which seems unusual, you may think "Ah, I wonder if they remembered to put a speed limit in for that?", test it out, and it turns out that no, they didn't, and voila, you can break the game.

Deconstructing the actual game code

This next method is a step further from the above: If you can manage to get the code onto a PC (which could be done all sorts of ways, from just reading game discs directly, to more involved methods like connecting to console expansion ports, sometimes by the creation of additional specialist hardware; soldering additional wires to console main boards, etc.) then you can decompile the code. Source code for any kind of program typically looks something like this:

PlayerAccel=2
PlayerSpeedMax=20

If ButtonPressed.MoveForward = true; Has the player pressed the button to move forward?
   PlayerSpeed += PlayerAccel; Increase the player's speed by PlayerAccel figure
EndIf

If Player.Speed > PlayerSpeedMax; Check player speed
   Player.Speed = 20; Reset player speed
EndIf  

Now this is a very simplistic example, not from a real programming language, but the point is that you can look at it and fairly easily (especially if you know the particular language) work out exactly what's going on. This is how the original game programmers make the game. If you had access to this code you could very easily look for things that are not coded robustly and exploit them. Unfortunately the code you get from dumping game files is not this - the code is compiled which means that some software takes it from easily-human-readable codes and converts it into code which the computer chip can execute very quickly. It looks something more like this:

(Note this is not the same code, this is a random example - also this is x86 code for a PC, and not Nintendo native code, which would look different, but be more or less as difficult to read)

As you can see it is NOT easy to read, there are no variable names or comments to tell you what's happening. There are additions, subtractions, moving data from one memory location to another, conditional jumps to new places in the code etc. - it is not easily-human-readable but that's fine, because the computer only processes the numbers and outputs the results, it doesn't need to know whether a figure relates to the player's speed in order to perform the necessary calculation. Unfortunately, this is what you get back when you decompile the code from a game. Now importantly, with the use of emulators and tools, you can look at the values of any one of these variables at a point in time.

So it is possible to do things like look at the variable held in a particular memory location and watch how it changes over time. If you were looking for a "Player Speed" variable, you could put a watch on 20 different variables, play the game a bit, move around and see which variable changes as you'd expect with player movement (increasing as you run faster). Another thing which can help is that sometimes messages which come up in game, like "I'm sorry Mario, the Princess is in another castle" may be in the code in plain text, so they can give you clues as to which variables make certain things happen. Alternatively you could make changes to some value (change a 1 to a 2) and see how that affects what happens in the game - though often this is more likely to just break a game and make it crash.

Once you've figured out which variable it is you've been looking for, you can use decompilation software to start reconstructing something like the original code, (note you can never reconstruct a perfect version as some information is lost - but you can make educated guesses) and name that variable as something like Player.Speed instead of something unreadable. You can do this again and again and again until you have something which more resembles the original game source code, piecing it all back together as you go. It's a long and arduous process, and the result will be messy, and the variables won't have the original names, and there will be no comments on the code (except any which you add to help you keep track) but again, it doesn't need to be perfect to still help you figure out how you can break the game.

In fact, people have done this exact thing, with Mario 64, and almost certainly with other games too.

Source code leaks

Occasionally, although very rarely, the actual original source code, that is, the code which the programmers wrote when the game was originally created, in easily-human-readable code, with comments and helpful variable names etc., gets leaked to the public. In some cases, a developer will freely release the code - Id Software did this with a number of its older games including Quake 3, but it's something Nintendo, to my knowledge, have never done. It would need to be released by somebody working for the company, or somebody who has hacked into the company's servers etc.

However, the (I think partially incomplete?) source code for Mario 64, Ocarina of Time and Majora's mask did finally leak this summer, back in June, which was huge news at the time.

Anyway, as explained above, if you can see the game's code (either by seeing the actual original code or reconstructing some semblance of it) then you can find glitches more easily.

I realise I've been talking about Mario here but the general processes described above will work for any game... it can be a lot of effort for a complex game - it may take thousands of hours to decompile and reconstruct - but these days with vibrant speedrunning communities etc. more people have the incentive to do it. Also bear in mind that often in order to break certain aspects of a game you might only need to deconstruct a small percentage of the whole game's code. If you're only trying to break movement, then you don't have to reconstruct the code for the game's item-handling system, for example.

So generally we can walk away with the following knowledge:

• Programmers make mistakes and miss things - programming for every possible situation is really hard and rarely worth the effort.
• Programmers are lazy - or to put it more positively, they make efficiency choices about programming around edge cases - if something will happen very rarely, like a player would have to do something with very very precise timing, multiple times for something to happen, and it's very unlikely to ever happen by chance for more than one in 100,000 players, is it really worth spending 10's or 100's hours changing all of your code in complex ways to make sure that can't happen, or is it not really worth it?
• Gamers will go to great lengths to figure out ways in which they can break a game they're trying to set records for (or sometimes just to find interesting secrets).
• There are ways in which you can make educated guesses about how a game is coded and then test those hypotheses to find glitches.
• There are ways to look at the nuts and bolts of how the game actually works, and again if you have decent programming knowledge this can help you to "break the game".

Answer 8

In programming, it's common for a seemingly benign oversight to result in wild behavior. (e.g. division by zero, infinite loops) Weird behavior still notoriously happens even in big-budget, more modern games by Bethesda. In SM64/OOT, the glitches tend to happen because A) the player is able to build up speed beyond the intended cap (backwards long jumping repeatedly to stack speed) or B) the game is unable to calculate/handle certain types of collision. Basically, an underflow/overflow type of programming error where the game doesn't know what X/Y/Z coordinates to put the character, so it goes somewhere unintended.