One of the highlights of studying Software Engineering is when you start to have ideas about how things work.
- How are likes associated to both users and posts? Oh it’s a many-to-many situation with a join table — awesome.
- How does my browser know what sites I’m logged in to? Oh okay that’s what cookies do.
- How does Missingno work?
…
This one’s a bit outside the realm of the boot camp curriculum, but I was curious if my experience as a Software Engineer could help me better understand what caused one of the best-known glitches in video game history.
Uh, I’m sorry…Missingno?
Missingno is a glitch associated with the first generation of Pokémon games, released in the US in 1998 for the Nintendo Gameboy. Missingno stands for “Missing Number” and appears as a wild Pokémon after the player follows a specific set of steps:
1. Take an action that requires the game to change your character’s name (the most common example of this is speaking with Viridian City’s “Old Man.”)
2. Randomly encounter a Pokémon in a location without a specified encounter list. The only locations that satisfy these requirements are on the coasts of Cinnabar Island and Seafoam Island.
There are a surprising number of variables involved in these two simple steps, but in most cases, you’ll be faced with something that looks like this:
Why??
Unsurprisingly, there’s not a lot of official data on this glitch. With that said, the educated guesses out there are very educated and I’m inclined to believe that those inquisitive minds have reasonably determined how Pokémon functions. My sources will be cited at the end of this post — I highly recommend them to anyone who wants to learn more.
A critical principle to the understanding of Missingno and the original Pokémon games on the whole is that of conservation of space. Advances in RAM and hard drive technology have given modern programmers the freedom to largely focus on other challenges, but this was not the case in 1998. Gameboy cartridges could probably hold about 2MB of data and the Pokémon programmers had to make sure to use every byte carefully. If they had the luxury of additional variables, placeholders, and buffers, we may never have glimpsed Missingno at all.
One easily manageable piece of data in Pokémon was the player’s character name. Players can choose from a pre-set list or customize their name at the beginning of the game and the programmers wouldn’t have to worry about any further variation from there. Pokémon could evolve, money could be spent, items could be used, but a user’s name could not change. That one piece of memory would rest safely in its place and never be moved or manipulated.
Unless…
Didn’t we previously establish that the first step of finding Missingno is changing your character’s name? Is it possible or not? Player’s can’t decide to change their name, but that space in memory is actually replaced under very specific circumstances. For instance, when the Old Man in Viridian City teaches you to battle and catch Pokémon.
Notice the text: “OLD MAN used POKé BALL.” This is the only time in the game where the beginning of this sentence, in reference to the trainer with their back turned (usually the player, looking at their avatar in third person), will read something other than the player’s character name. In order for this mechanic to work, the Pokémon programmers had to replace the space in memory that stored the character name with data that would read OLD MAN. Then, once the tutorial was finished, they would re-insert the character name so that the game could continue normally. For anyone who has ever tried to swap two variables back and forth, you know that we require a third space to hold one of the variables to prevent permanently erasing it.
a = 1
b = 2a = b (a is now 2)
b = a (well that won’t work because we lost the value of a)OR
c = a (c is now 1)
a = b (a is now 2)
b = c (b is now 1...much better)
If we were writing this today, we might just pull out a third variable like I illustrated above. But if that variable were only used to store spare data, it wouldn’t be an efficient use of our precious space. So the clever Pokémon programmers decided to use a space that they knew would be empty at the time of the conversation to hold their variable: the encounter list.
Random Encounters
Even if you’ve never played a Pokémon game, you still likely know the slogan “gotta catch ’em all!” And that does a pretty nice job of describing the object of the game: to collect, train, and battle Pokémon (and in the future breed them, enter them in beauty pageants, take photos of them, speak to them through a microphone, help them solve mysteries, play pinball with them…but in 1998 we mainly wanted to catch and battle). So how do we catch ‘em?
Pokémon can be randomly encountered in various areas of the game such as tall grass or caves. When entering one of these areas, The aforementioned encounter list will be populated with Pokemon that you might find in said area. If you’re exploring Mt. Moon, for instance, the encounter list might look something like this:
Zubat, 5
Zubat, 6
Zubat, 7
Geodude, 5
Geodude, 6
Paras, 5
...(There will also be probabilities associated with elements in the list but we’ll ignore that for the sake of this discussion.)
If our action triggers a random encounter, the game will pull a Pokémon from this list and assign it to battle the player. The numbers in each row represent the level of the Pokemon, which is why you might sometimes encounter a level 10 Zubat and other times a level 5 Zubat. This list must be refreshed when a player changes their location — it’s the reason you won’t find a Horsea while walking through tall grass or a Magnemite in the middle of the ocean.
The programmers’ solution made perfect sense — the encounters list is empty when you speak to the Old Man, so storing some other data in there wouldn’t cause any difference in gameplay. Once the tutorial ends, the name information is retrieved from the encounters list and the game moves on. There’s no reason to actively delete it from the list, however, because it will simply be overwritten the next time a player enters an area where they can encounter Pokemon.
Unless…
Eastern Coasts
In what is most likely a programming oversight, there are two locations in Pokémon that do not have an encounter list but do allow users to encounter Pokémon: the eastern coast of Cinnabar Island and the eastern coast of Seafoam Island.
These tiles in the game are considered “land areas” that allow for random encounters. Because they do not have their own encounter lists, the Pokémon a player encounters will default to those from their most recent location. If they were in Mt. Moon, they’ll find Zubats and Geodudes, and if they were in Pokemon Tower, they’ll find Gastleys and Cubones. In a simplified version of this trick, if the user has just come from the Safari Zone, they’ll be able to find Kangaskhans and Chanseys — oh boy!
But what if your most recent location contained an encounter list that had no Pokémon at all? What if, instead of Pokémon data, the list contained one entry: your character’s name.
Hexadecimal numbers
We’ve triggered a random encounter, which prompted our game to consult our encounters list for a Pokémon to battle. That list doesn’t contain any Pokémon, but it does contain our character’s name. How does it decide what Pokémon to generate as our opponent?
Pokémon uses Hexadecimal notation to locate various data inside of its code. We’re all familiar with Decimal notation, which uses the digits 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9 in various combinations to represent values. We’ve also likely heard of Binary notation, which represents values using only the digits 0 and 1. As you might have guessed, the Hexadecimal system has more than 10 digits — it has 16. It not only uses 0–9, but also A, B, C, D, E, and F. Computers can only think in Binary, so programmers use Hexadecimal notation because it easily maps to Binary and is therefore more readable to our human eyes (2 is a prime factorization of 16: 2⁴ = 16). Here’s what a Pokémon looks like Hexadecimally:
01 2D 31 31 2D 41 16 03 2D 40 55 00 40 E5 40 21 2D 00 00 03 A4 03 38 C0 03 08 06 00
Upon triggering a random encounter, the game will expect to find, among other things, an index number in its encounters list. The index points to a larger collection of data contained in the Pokédex including height, weight, type, sprite, and cry. When the game sees the letters in the player’s name, it interprets them as an index and points towards a Pokédex entry. Let’s do some math:
There are 151 Pokemon in the original game, so there should be 151 indexes and 151 Pokédex entries. But how many Hexadecimal pairs are there? Well that would be 16²…or 256. So what happens if we hit a number that isn’t indexed?
Remember how we had to conserve space? If we go beyond the index table, we’ll hit a different table that has data that won’t make sense when constructing a Pokemon. The game will still try, though, which is what generates weird sprites and cries. We can also imagine how the rest of the characters in our name can create a “Bird” type, teach a Pokémon Water Gun twice, and allow it to grow to level 255. This is also why it’s possible to find a “normal” Pokemon when attempting to encounter Missingno — depending on your character’s name, you might hit a real Pokédex entry. (I put normal in quotes because this Pokémon is still likely to have an impossible level or moveset despite its standard Pokédex entry.)
As an aside, it’s worth noting that the index table in Pokemon actually has 190 slots rather than 151, with 39 leading to empty Pokédex entries. The most popular theory for these empty slots is that the game was originally meant to have 190 Pokemon, but that 39 were scrapped because of time or space constraints.
Conclusion
We did it! But it wouldn’t have been possible without some truly inspirational work from computer scientists across the world. Thanks very much to the authors of the following pages for their intrepid research: