In this video, Desert Mario 64, a ROMHack inspired by the infamous game Desert Bus, is completed as fast as possible, which, it turns out, is not very fast at all.
This is because the hack is just one near-endless flat plane with no other interesting geometry to exploit, as per the source material. The hack also adds a couple more features, in order to make the game more challenging:
• Mario has a heat-meter, which builds when he's on the hot ground. When it gets too high, Mario overheats & the floor is momentarily treated as lava, costing health
• The road Mario is on has a speed limit of 55 (units/frame). If he goes too far above that limit (i.e. over 58 units/frame), he rapidly loses health. This is actually pretty unlikely to present a challenge to anyone completing it in real-time, as reaching that speed requires several slidekicks to be chained together after a jumpdive, but for TAS this is a significant limit.
* Mario's HP is slowly restored, so if you make any mistakes they won't last forever
Under these conditions, the optimal movement for long periods of time is to repeatedly slidekick, and use joystick inputs to stay as close to 58 speed as possible without actually exceeding it. This is because slidekicking is one of only a handful of movements which conserve Mario's speed when it's above 48 (because the game caps the speed for non-sliding ground movement at 48), and the only one which does not lose speed when performed (below ~95 speed, when the speed lost in the crouch-frame increases to match the speed gained while in the air). A small amount of time can additionally be saved by breaking the 58 speed limit for short bursts every time Mario's HP is fully restored. During these bursts, the fastest movement is to continue slidekick chains while actually building speed, then perform a speedkick at the end of the chain when there is no longer time for another slidekick.
So how did I manage to TAS 6.5 hours of slidekicks optimally without losing my mind? The answer lies in their repeatability, as if I can efficiently perform a single slidekick I can just copy/paste those inputs many times to produce a full TAS.
That is actually more difficult than it sounds in this hack, and it's all because of the 58 speed limit. Without it, I could just hold the joystick straight forwards & repeat the slide over & over & over again, but with it, I need to maintain a speed as close to 58 as possible without crossing it, requiring different joystick angles. The trouble with this is that the slidekick *must* end with the exact same speed, to a very high precision, otherwise over the course of the countless slidekicks in this run, Mario's speed will begin to drift. Were it to increase, it would eventually cross the 58-speed limit at the wrong time, ultimately killing Mario. If it decreased, I would begin to lose time. Furthermore, maintaining the closest possible speed to 58 (and matching the speed exactly, as explained before) nearly always required greater input precision than could be achieved using forward-only joystick inputs. Thus, some lateral movement is needed, which also needs to be cancelled out, otherwise Mario will drift to the side until he hits the edge & bonks! Left/right joystick inputs also don't behave completely symmetrically, so no help there.
Achieving sufficiently precise speed/position matches proved to be very difficult, and even with the best circumstances I could manage I needed an additional correcting step, performed after each speed-limit abuse, to counter the slow leftward drift. Even with all this, by the end of the run, Mario still drifts noticeably to the left, which I correct at the very end for aesthetic reasons.
Because of the length of this TAS and the ability of small differences to accumulate through the many hours of the run, fully optimising this TAS down to the last frame is practically impossible. In fact, I believe around a second is savable just by getting even closer to 57.999... speed. However, I am happy with the level of optimisation of this run, and I see no need to push it further.
Now we know how this TAS was optimised, the next question is why I bothered at all. I have two answers for that:
• Because the idea of a 6.5-hour TAS of desert-bus straight-line movement is funny in an absurd kind of way
• Because optimising & efficiently TASing such a long straight-line is an interesting & unusual problem to solve (at least for a nerd like myself)
My playlist of TAS runs:
My Twitter:
Kaze's channel:
Total re-records: 4,099
Now get comfortable, this is gonna be a long journey...
0 Comments