I have been a semi-regular viewer of speedruns for many, many years, and one of my all-time favorite games to watch speedruns of has been for quite a long time The Legend of Zelda: Ocarina of Time.
For quite many years it appeared that 17 minutes is the lower limit of how fast the game can be completed (with the world record being just a couple of seconds below it, and having been so for quite some time). However, very recently a new exploit was found that has allowed sub-12 minutes completion of the game using a completely different strategy and exploits.
I wrote recently a blog post about why I didn't find this exciting in the least, even though I have been a huge fan of OoT speedrunning for several years.
Knowing more details about the particular techniques used for this new route hasn't changed my opinion. Here I'll list all the reasons why I don't really like this new any% speedrun route, from the least objectionable to the most objectionable (all in my personal opinion, of course).
1) It resets the console mid-run.
This is just a really, really minor nitpick, and if it were the only "objectionable" thing in the run, then it wouldn't really even be worth mentioning. It's just something I personally don't really like in any speedruns (unassisted or tool-assisted), a pet peeve of mine, because I don't really consider it part of gameplay proper. It steps out of the boundaries of the game itself to affect it from the outside, with an action that's not really input to the game itself, and its gameplay.
In this case the resetting is not part of any exploit, but merely used to save a bit of time (something like 10 seconds or so). Whether this makes it better or worse, I haven't actually decided.
2) It "abuses" the second controller.
The ACE (arbitrary code execution) exploit, at least as of writing this (which might change in the future), requires a second controller to be plugged into the console, in order to input very specific values that make the exploit work. In order to do this, not only does the second controller need to be plugged in, but its buttons and thumbstick need to be in very particular positions. The runner is unable to have these in their positions when the exploit happens, so they use things like rubber bands and other means to keep the correct buttons pressed, and the thumbstick to be positioned in the exact correct direction, while the runner himself plays with the primary controller.
This bothers me for a similar reason as the reset button, except it's in a way even worse. The game is not a two-player game, so the second controller is not really part of input to the gameplay proper. It's affecting the game in a manner other than by playing the game itself. Not only that, but it requires the use of additional "tools" to have the controller input the proper values.
(Again, this is mostly just a minor annoyance. Not crucial, but nevertheless adds to my overall disapproval of this entire route and exploit.)
3) Typing the file name is not counted towards completion time.
The ACE exploit (at least as of writing this) requires a very particular "file name" to be entered when starting a new game (as this data is what a crucial part of the exploit relies on). However, none of the time spent in the main menu of the game entering these characters is counted towards the run's completion time. The runner could, if he wanted, spend a minute on this screen entering the file name, and it wouldn't be counted towards the completion time, even though it's a crucial part of the run that makes the exploit work. Without this part, it wouldn't work.
4) It runs custom code.
Arbitrary code execution itself has always been extremely contentious in my view, regardless of whether we are talking about tool-assisted speedruns, or unassisted speedruns.
Arbitrary code execution goes beyond just glitching the game to jump somewhere where it normally wouldn't (such as for example loading the wrong level of the game because of a glitch or bug). This kind of exploit causes a particular set of machine code instructions to be put into some memory location and then, using some glitch, have the CPU of the console jump to that particular memory location and running that custom code, in order to do something completely out of what the original game code has.
In this particular case the amount of custom code isn't much: It's just a jump instruction, taking something like 4 bytes, and that's it. However, it's still code that did not exist in the original game, and was entered by the speedrunner into memory, and making the CPU jump to that memory location to execute it (which in a normal situation the CPU would never do, because no part of the original game code jumps to that location).
In my view, once the CPU starts executing custom code entered by the runner, the original game itself has ended. That's the end of the speedrun. It doesn't matter if said code then jumps back to the game's own code.
Another way of looking at it is that this is now a modded game, not the original game. The game code has been modified to be different from the original, to do something that wasn't there originally, but was entered by the modder or, in this case, the runner. It doesn't matter that the "mod" was entered in real-time during gameplay, it's still a mod. It also doesn't matter that the "mod" was entered with the game controller (or in this case two game controllers) using an exploit, it's still a mod. This is not the original game anymore. It's a modded one.
For these reason I don't really consider ACE runs of any game legit, because they aren't running the original unmodified game. They may be considered "legit" runs of a modded version of the game (even though the "mod" is being created on-the-fly), but not the original.
5) It doesn't reach the end of the gameplay proper.
The ACE exploit makes the game jump to the middle of the ending credits. It doesn't even jump to the start of the ending cutscene, or even the beginning of the ending credits, but the middle of them. The ending of the gameplay proper (ie. final blow to the final boss) is never reached.
As I already wrote in my previous blog post about the subject, I don't consider this a legit completion of the game, a legit reaching-the-end of the game. The end of the game is never reached, and thus I, personally, don't consider this a legit speedrun.
It doesn't exactly help that the rules of the any% category at speedrun.com needed to be changed to accommodate this new ACE exploit. The old rules only stated that timing ends when the final blow to Ganon is delivered. They needed to change that in order to make this new exploit "legit". Which is telling, in my opinion. The new route wouldn't actually have been technically valid by the old rules, so they needed to change them.
For quite many years it appeared that 17 minutes is the lower limit of how fast the game can be completed (with the world record being just a couple of seconds below it, and having been so for quite some time). However, very recently a new exploit was found that has allowed sub-12 minutes completion of the game using a completely different strategy and exploits.
I wrote recently a blog post about why I didn't find this exciting in the least, even though I have been a huge fan of OoT speedrunning for several years.
Knowing more details about the particular techniques used for this new route hasn't changed my opinion. Here I'll list all the reasons why I don't really like this new any% speedrun route, from the least objectionable to the most objectionable (all in my personal opinion, of course).
1) It resets the console mid-run.
This is just a really, really minor nitpick, and if it were the only "objectionable" thing in the run, then it wouldn't really even be worth mentioning. It's just something I personally don't really like in any speedruns (unassisted or tool-assisted), a pet peeve of mine, because I don't really consider it part of gameplay proper. It steps out of the boundaries of the game itself to affect it from the outside, with an action that's not really input to the game itself, and its gameplay.
In this case the resetting is not part of any exploit, but merely used to save a bit of time (something like 10 seconds or so). Whether this makes it better or worse, I haven't actually decided.
2) It "abuses" the second controller.
The ACE (arbitrary code execution) exploit, at least as of writing this (which might change in the future), requires a second controller to be plugged into the console, in order to input very specific values that make the exploit work. In order to do this, not only does the second controller need to be plugged in, but its buttons and thumbstick need to be in very particular positions. The runner is unable to have these in their positions when the exploit happens, so they use things like rubber bands and other means to keep the correct buttons pressed, and the thumbstick to be positioned in the exact correct direction, while the runner himself plays with the primary controller.
This bothers me for a similar reason as the reset button, except it's in a way even worse. The game is not a two-player game, so the second controller is not really part of input to the gameplay proper. It's affecting the game in a manner other than by playing the game itself. Not only that, but it requires the use of additional "tools" to have the controller input the proper values.
(Again, this is mostly just a minor annoyance. Not crucial, but nevertheless adds to my overall disapproval of this entire route and exploit.)
3) Typing the file name is not counted towards completion time.
The ACE exploit (at least as of writing this) requires a very particular "file name" to be entered when starting a new game (as this data is what a crucial part of the exploit relies on). However, none of the time spent in the main menu of the game entering these characters is counted towards the run's completion time. The runner could, if he wanted, spend a minute on this screen entering the file name, and it wouldn't be counted towards the completion time, even though it's a crucial part of the run that makes the exploit work. Without this part, it wouldn't work.
4) It runs custom code.
Arbitrary code execution itself has always been extremely contentious in my view, regardless of whether we are talking about tool-assisted speedruns, or unassisted speedruns.
Arbitrary code execution goes beyond just glitching the game to jump somewhere where it normally wouldn't (such as for example loading the wrong level of the game because of a glitch or bug). This kind of exploit causes a particular set of machine code instructions to be put into some memory location and then, using some glitch, have the CPU of the console jump to that particular memory location and running that custom code, in order to do something completely out of what the original game code has.
In this particular case the amount of custom code isn't much: It's just a jump instruction, taking something like 4 bytes, and that's it. However, it's still code that did not exist in the original game, and was entered by the speedrunner into memory, and making the CPU jump to that memory location to execute it (which in a normal situation the CPU would never do, because no part of the original game code jumps to that location).
In my view, once the CPU starts executing custom code entered by the runner, the original game itself has ended. That's the end of the speedrun. It doesn't matter if said code then jumps back to the game's own code.
Another way of looking at it is that this is now a modded game, not the original game. The game code has been modified to be different from the original, to do something that wasn't there originally, but was entered by the modder or, in this case, the runner. It doesn't matter that the "mod" was entered in real-time during gameplay, it's still a mod. It also doesn't matter that the "mod" was entered with the game controller (or in this case two game controllers) using an exploit, it's still a mod. This is not the original game anymore. It's a modded one.
For these reason I don't really consider ACE runs of any game legit, because they aren't running the original unmodified game. They may be considered "legit" runs of a modded version of the game (even though the "mod" is being created on-the-fly), but not the original.
5) It doesn't reach the end of the gameplay proper.
The ACE exploit makes the game jump to the middle of the ending credits. It doesn't even jump to the start of the ending cutscene, or even the beginning of the ending credits, but the middle of them. The ending of the gameplay proper (ie. final blow to the final boss) is never reached.
As I already wrote in my previous blog post about the subject, I don't consider this a legit completion of the game, a legit reaching-the-end of the game. The end of the game is never reached, and thus I, personally, don't consider this a legit speedrun.
It doesn't exactly help that the rules of the any% category at speedrun.com needed to be changed to accommodate this new ACE exploit. The old rules only stated that timing ends when the final blow to Ganon is delivered. They needed to change that in order to make this new exploit "legit". Which is telling, in my opinion. The new route wouldn't actually have been technically valid by the old rules, so they needed to change them.
Comments
Post a Comment