[TAS] Desert Mario 64 in 6:32:23.43 (Yes, really)

Channel:

DyllonStej Gaming

Subscribers:

58,000

Published on September 26, 2021 9:30:10 PM ● Video Link: https://www.youtube.com/watch?v=uQo-_-ACLWE

Game:

Super Mario 64 (1996)

Duration: 6:33:03

10,161 views

446

Special thanks to YouTube's copyright system for requiring me to mute the entire video.

Desert Mario 64 is a Super Mario 64 ROM Hack created by Kaze Emanuar that replicates the gameplay of Desert Bus in the style of Super Mario 64. In this, Mario travels from Tucson, Arizona to Las Vegas, Nevada on foot, similar to the original game, with other elements added to spice up the experience, including a heat meter that turns the road into lava if you stand on it for too long (Which doesn't matter much in the context of this TAS)

More notably, if Mario's speed goes above 58 in-game units per frame, he starts to rapidly take damage until he goes back under the limit (Specifically, Mario takes 32 damage per frame when above the speed limit, and heals 1 damage every two frames regardless of speed, meaning mistakes are eventually forgiven by time). This isn't much of an issue for RTA players, as the only movement option that repeatedly conserves speed beyond 48 units per frame are frame-perfect slidekicks, but it becomes a very glaring limitation with frame-perfect TAS abilities.

As manually TASing each and every action for this long of a time period would be completely infeasible, looking for repeatable sections that can be copied over and over is the best course of action. Thanks to the aformentioned speed limit, however, it's unfortunately not as simple as holding forward on the control stick and continuously doing frame perfect slidekicks.

To remain right under the 58 speed limit when necessary (Only breaking it in short bursts when Mario's HP is back to full), purely vertical control stick values don't offer enough precision, which means horizontal control stick values also need to be taken into account. This leads into another issue: If the deviation between Mario's position relative to the center of the road is large enough between input repititions, Mario will eventually veer to one side of the road and bonk on its edge. You would think that balancing a given rightward input with a respective leftward input would perfectly balance things out, but the control stick is unfortunately *just slightly* asymmetrical, which leads to net movement with anything that isn't purely vertical.

Thus, the repeatability problem is two-fold: A balance of speed (Keeping right under the limit while healing, and breaking it in very occasional bursts) and road position (So Mario doesn't eventually hit the road border and stop moving entirely).

SuperDavo0001, who made the first TAS of this hack, opted to get as much repeatability out of one single slidekick, and copy that small set of inputs across the entire run (Alongside the limit-breaks mentioned before). In optimizing to reduce Mario's net deviation, his total speed value wasn't as optimal as it could be (As he mentioned in his own writing), which is where our methods separate.

I noticed several key patterns that allowed me to get proper repitition in much longer timespans. After a speed burst, it takes exactly 100 slide kicks for Mario's HP to get back to its maximum value; in combination with the speed burst, a single cycle takes 3928 frames, which means the 6.55 hour journey takes exactly 180 cycles. This means 90 repititions of two-cycle sets (One cycle geared towards the right and one towards the left, to reduce drift), which eventually leads to a net displacement of 2.65 units every 7856 frames, or 0.01 units per second. The width of the road is roughly 1600, meaning Mario can afford to deviate 800 units from the center, at a rate of 0.034 units per second across 6.55 hours. 0.01 is much smaller than 0.034, which means bonking on the side isn't an issue.

I also found several precise control stick values that get just under 58 speed when accelerating towards the value (37,-91/39,-97/49,-125 for rightward directions, and -39,-96/-41,-102 for leftward directions) and remain perfectly at that value with a speed increase of only 0.00003 per frame or so (36,-68/-37,-70 for right and left respectively); this allows me to keep Mario right at 57.999X at all necessary times.

This eventually leads to a 15.19 second timesave across six and a half hours of slidekicks (When comparing the time stated in Davo's YouTube encode vs. the total time of my input file; the visual time is different because of loading and whatnot). I imagine that it's still very much possible to squeeze even more time out of this, but that's a project for another person to deal with, as I think I've hit my comfort limit in this exercise.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Check out my Patreon! https://www.patreon.com/DyllonStej
Discord: https://discordapp.com/invite/T7rZqbm
My Other Channel: https://www.youtube.com/channel/UCL_aWcJRBfVKqn1QnYJyt4g
Twitter: https://www.twitter.com/DStejGaming
My Mods: https://www.dropbox.com/sh/67ce97vfa4xh9pn/AAAILWUMsqJ1I9NxHLwpsvaCa?dl=0

Other Statistics