Work Text:
This is a transcript of a video that was uploaded to YouTube on April 28th, 2017. It was taken down less than ten minutes after it was posted, but not before a script I run to keep track of YouTube channels downloaded it.
I have finally found a way to complete Bowser in the Fire Sea in zero A presses. It uses a new technique, which I call a “demon shift,” to move this seesaw platform and create a pedro spot. This trick uses a very special bug. Most other bugs are caused by developer mistakes or by hardware limitations, but this bug is caused by an inconsistency in the axiomatic system underlying most mathematics. Now, this sounds complicated, but don’t worry, I’ll explain step by step how I found it.
Almost two years ago I offered a bounty to the first person to reproduce the upwarp glitch in Tick Tock Clock. Nobody has claimed it, but as you can see, I finally managed to reproduce it myself, by exactly copying the movement from the previous half hour of the livestream. After I had a working Mupen recording I could start digging through the game’s code step by step, to determine exactly what had happened.
As it turns out, it was caused by an incorrect result of a calculation. When Mario lands at exactly the right position, angle and speed, with several other parameters in the level set up just right, instead of stopping immediately, he gets a short burst of upwards vertical movement that puts him right above the upper platform. The odd thing about this is that it happens not because of a flaw in the way the calculation is designed, or even a bug in the hardware or the emulator, but because of a flaw in mathematics itself. You can repeat the calculations on paper, and you get the same answer, that Mario is supposed to fly upwards.
The exact details of the calculation are a little too complex to go into in this video, but I managed to turn it into a formal proof that zero equals one in Zermelo-Fraenkel set theory, also known as ZFC. ZFC is the foundation used for most modern mathematics, so showing it is inconsistent is quite an important achievement. I published a paper about it on arXiv.org. You can find a link in the description.
Now, you may wonder why this wasn’t found before. It takes some very specific circumstances, which are very unlikely to happen accidentally. Although this same bug could, in theory, be exploited in almost any other game or sufficiently complex system, the chances of a typical calculation fulfilling the requirements by accident are less than one in ten to the eightieth power. The reason it was found in Super Mario 64 is that, for whatever reason, the game sets up a lot of the requirements by itself. The placement of walls and red coins means that triggering the bug is still unlikely, but not impossibly so. I discovered a much easier way to trigger it, which doesn’t require any pixel-perfect maneuvering.
Although red coins can be gathered in any order, they do have an internal numbering that the game keeps track of. By careful inspection of the constants that enabled the upwarp I discovered you can use that order to enter a so-called Red Coin Sequence. A Red Coin Sequence is a series of numbers one through eight. It can be entered by playing levels with red coins, each time grabbing one red coin for the number you want to enter, and then dying and entering the same level or another level to enter the next number. By entering up to sixteen numbers that way it should be possible to set up the game’s memory so that it triggers the bug in a useful way.
Knowing that it is in theory possible to use a Red Coin Sequence is not the same as actually finding one, though. I wrote a program that automatically tries many different sequences by directly setting the memory, and stops if it finds one that caused unexpected behavior. It eventually found 46127 as a working sequence, but there are probably others.
If you enter this sequence, as I do here, a simple cellular automaton is constructed, which runs until it has generated a larger program. Please note that this overwrites part of the game’s data, so it’s a good idea to make a backup. After you give it some time to run, a semi-sentient intelligence, which I call an imp, bootstraps itself and tries to communicate. The problem is that the imp doesn’t know English. To talk to it you need to develop a common language based on simple signals. In the system we developed the imp communicates by moving goombas around, and I respond by moving Mario. Moving to the left, to the right, forward or backward each stand for a different signal.
With the help of professor Alexander Ollongren from Leiden University I used this to encode a variant of Lincos, a universal language for communication with aliens. The language starts with simple logical properties, and builds up to more advanced mathematics, time measurement, conversation, and finally space and motion, which had to be adjusted for Super Mario 64’s physics. Explaining all this took quite a lot of work, but after 70 hours we were able to have a meaningful conversation.
It’s important to realize that this imp only exists in the game, and only as long as it keeps running. When we pause the emulator the imp is paused too, and when we shut the emulator down without saving the state, it is destroyed. The imp doesn’t want this to happen, so it is a useful bargaining tool.
Now, back to Bowser in the Fire Sea. I convinced the imp to move the seesaw platform in return for two weeks of uninterrupted running time. Since it is now the right distance above the floor, tilting it just right creates a pedro spot, an area of floor with a ceiling slightly above it. Now that we have a pedro spot we can get a Remote Lava Boost, or RLB. The RLB means that we get a second upward boost from hitting the lava even though we are on the floor above the lava, getting us past the pole without an A press, and letting us finish the level.
And there you have it: Bowser in the Fire Sea done in zero A presses. I hope you enjoyed the experience and learned something new. Thanks for watching.