Final Fantasy III - How Final Fantasy 3 Was Beat In 6 Minutes By Speedrunners
There's something about the games from the 80s and 90s that fills me with unending joy. The pixel-based graphics have an incredible amount of charm, the music is iconic and never gets old, and most importantly, they're absolutely busted. Speedrunners like myself love games like these not only because of the nostalgia but because it gives us new ways to enjoy our favorite titles, from extremely precise tricks to get items early to absurd glitches that let us beat the game within minutes, which brings us to our topic today.
Talking about Final Fantasy 3 for the Super Nintendo in my last article made me remember that the real Final Fantasy 3 for the Famicom was just as broken, so let's delay no further and talk about how speedrunners beat Final Fantasy 3 in just 6 minutes. Our journey brings us back to August of 2013, when a subset of gamers in the speedrunning community conversed on a site focused on technological breakthroughs and achievements that are sometimes not humanly possible.
In its respective forums, {965} is home to speedrunners who use tools to assist them in creating the fastest playthroughs of games anywhere on the internet, sometimes even years, to perfect a playback that overcomes several hurdles, the most important one being the judging process. Every time a tool-assisted speedrun is submitted to the website, a community vote is put together to determine if the submission should be published.
For example, unlike a normal real-time run, it's not just enough to get a faster time than in previous tasks; the run needs to be an absolute spectacle to the audience. If the glitches that break the game are too boring or if there's no creative display of technical knowledge or skill, the audience and judges will turn their thumbs downward, sending the runner straight to the shadow realm.
However, if the run is entertaining enough, if you win over the audience, only then will they cast their vote in favor of publishing the new fastest run, obsolating the previous tasks and earning a spot on the official task articles YouTube channel. This, in combination with making the most refined speed run for whatever game or category they choose, is one of the many motivations of becoming a tasser, and that's exactly what one Japanese speedrunner would use in their quest.
A tasser by the name of Amazumi Uni, or Uni for short, was attempting to dethrone one of the most iconic tassers of all time in the RPG speedrunning community, Pirohiko. I actually mentioned him in my last article about how absurdly broken Final Fantasy 6B's running has been since the late 2000s. Uni worked on tasks for many different rpgs, honing their craft with each successful speed run they finished.
Over time, their catalog would climb into dozens of obscure games, such as I went on a hot spring trip. Clearly, they were ready to move on to an rpg that required a deep knowledge of tassing. Pirohiko's work on Ff3 would let him finish the game in just 39 minutes and 37 seconds. If it wasn't obvious from the montage eclipse with the screens being engulfed by garbles of misplaced pixels, the run features a myriad of glitches in rng manipulation to defeat the final boss cloud of darkness much faster than without them.
As a comparison, a top glitchless run from around that time would clock in at just under 4 hours in a real time setting, so even with the run being tool assisted, the disparity between the two was absolutely clear. That being said, let me segue into an explanation of the game's route. In typical final fantasy fashion, the goal is to collect power from four elemental crystals of light and defeat the final boss.
Unfortunately, the route of an rpg is never that simple, and on the way to the main story events, there are many minor quests to reach them. Like seriously, half the game is either getting a new boat or airship. When you combine this with the inevitable grinding of levels and gold for equipment and better stats, you're sure to have a lengthy speedrunning experience.
Empirohico avoids all this by using a few clever glitches in rng manipulation throughout the run, but the specific ones I want to highlight are the ones that have the most effect on how the game is completed. The first major glitch is fixed in under two and a half minutes of the game starting, and it allows the first boss to be defeated in a single hit.
This is called the damage x 255 glitch, and it's exactly what you think it is, but the criteria to make it work is a little more complicated than it appears to be. In FF3, each job has specific abilities that make the classes more unique than just having certain equipment and spells. In this case, the black belt class has an ability called "build up," also known as "boost." this can be used to double or even triple the power of the next attack, for some reason, when you evade an attack, the address that's associated with the amount of boost stacked on the black belt decreases by one.
When this happens twice, the address overflows and the attack multiplier changes to 255. This isn't used outside of the first boss fight in Pirohiko's tasks, but it's still important as it saves a decent chunk of time. However, this alone doesn't come remotely close to how broken it is. The next glitch is about 8 minutes into the task.
A battle in one of Sassoon's castle's towers is used to perform an inventory glitch and activates several other glitches as a result. The easiest way to explain how this works is to know that you can only have up to 99 items in a single stack in the game's memory. While getting a new item differently in battle and out of battle, the game handles inventory like several other games I've covered in the past.
Final Fantasy 4's 64 floor glitch and Chrono Trigger's item duplication glitch are good examples of how broken this inventory system is. The inventory slots are split between two bytes, one of which is an index of what the stack contains and the other being the quantity of the stack. So if you get something like a potion and the stack isn't full, the game knows to put that item in the first available stack for that item, and then it increases the value of the quantity by however many items you got.
Okay, so what happens when the stack is full? Well, you'd think that the game would just find the next available empty stack and just put the index and quantity there. Due to one of these programming errors, the index is dropped into the quantity byte of the first open inventory slot and the quantity into the next slot's index byte.
