Game Description
“Zool – Ninja of the Nth Dimension” is a platformer released in 1993 for various consoles including the Sega Master System. The game varies drastically across platforms. The Game Gear version has similar mechanics to Master System, but entirely different level layouts.
The Master System version was exclusive to Europe, hence the PAL settings were used (sorry encoders :P)
The objective of each level is to collect 99 objects. These objects could be food, z-tokens or items such as super jump. Once you collect 99, the arrow will point to the exit. The exit does not exist until you have 99.
The final time for this TAS is 21.609 seconds, making it the fastest Master System TAS on TASvideos!
The New Credits Warp
My current published TAS uses a credits warp in 2-1 which involves being hit by an enemy onto a bouncy surface. The earliest this warp can be done is in 2-1 (level 5) as there are no bouncy surfaces in levels 1 to 4. After this TAS, an RTA community for this game emerged. During a run, cxrnxr encountered an earlier credits warp in 1-2
https://youtu.be/pUnCy4g7G08
After this credits warp was found, a gold rush to push it earlier begun. With lots of help from the community, I was able to pull back the credits warp to the start of level 1.
The key to the credits warp is to have Zool teeter on an edge and press up (Note that you can also press P2 Up or P2 Down). Pressing up appears to reset/affect Zool’s teetering animation and doing this with specific positioning at specific spots of the animation will cause the game to warp you to the credits.
There is also a third method of credits warp that has been found by Phozon, but it is slower than the teetering method. In the clip Phozon gets hit by an enemy into a bouncy surface, then grabs a wall. The game warps him to the credits upon him grabbing the wall. It is currently unknown if this is possible without the bouncy surface.
https://clips.twitch.tv/WildPunchyStapleAMPTropPunch
Optimizing the Game End Glitch
As the game end glitch has to do with Zool’s teetering animation, causing certain things to happen with the animation can trigger it.
One option is to wait for Zool to teeter and experiment with pressing up at certain points of the animation. This is bad as you have to wait for some time before he will start teetering.
The alternative is to press up on the frame you reach 0 speed. Simply reaching 0 speed from not pressing buttons doesn’t work, but reaching 0 speed through pressing L, R or L+R gives potential to cause the glitch. Therefore, in the TAS, I aim for the fastest time for Zool to be:
-In the teeter range of the edge while
-Pressing L, R or L+R and
-Reaching 0 speed on the same frame (I’ve never seen the glitch occur with nonzero speed)
As such, I hold L at the start of the TAS until Zool has moved to the left enough that letting go of L will allow him to reach the edge. Here is a list of acceleration values with the buttons that are pressed shortly after letting go of L:
| Buttons Pressed | Acceleration to the right |
|---|
| Neutral | 0x48 |
| Right | 0x40 |
| Down | 0x15 |
| L+R | 0x00 |
| L | -0x40 |
It is important to note that shortly after letting go of L, pressing R, L+R or nothing will all have the same effect on speed, which is equivalent to the acceleration of letting go of L. The R or L+R accelerations from the table only come into effect once you have a speed below 0x0200, which occurs 9 frames after letting go of left at top speed (0x400). Despite not affecting speeds when at high speeds, pressing R or L+R has some affect on the glitch as it affects the teetering animation.
Counter intuitively, pressing R actually causes Zool to decelerate slower, making him go more to the left! This can be used to potentially make it to the edge while letting go of left a frame earlier.
This TAS reaches 0 speed on frame 1073, at which point it presses up as it’s last input. The previous input was a R input with some speed about to hit 0. As discussed previously, this can lead to the glitch.
My main concern is that it is possible to reach the edge with 0 speed on frame 1072 by utilizing down presses. However down presses have an acceleration of 0x15, which misaligns your speed value modulo 8 and there is no way to restore the alignment other than hitting 0 speed (using neutral inputs) or using 8 down presses. Unfortunately, it doesn’t seem possible to trigger the glitch by pressing up on the frame you hit 0 speed if you achieved that 0 speed through a neutral d-pad input.
Jumping
Jumping causes faster acceleration and deceleration, but it is not useful as the smallest jump lands later than the last input of this TAS and there does not seem to be a way to trigger the glitch in the air.
Brute Forcing Attempts
In a desperate attempt to save that potential extra frame, I wrote some scripts to brute force this TAS. As mentioned above, we can remove jumping from the search, but each frame we have any combinations of U,D,L,R, shoot to choose from. From here I noticed that down has the highest priority and up has the lowest priority, meaning that I didn’t include any inputs in my brute force that had combinations of up or down with left or right.
I also didn’t do much brute forcing with bullet shooting because it didn’t seem to have a serious impact.
Most of my attempts only pressed up at the end of the inputs, since it doesn’t seem to do anything in game apart from messing with your teetering animation and triggering the glitch.
My method for detecting a game end glitch was to look at the level value and check that it wasn’t 0. The glitch always corrupts your level value to something different.
Below I’ll summarize a number of different approaches that I took to brute forcing, but it is likely that I missed some attempts that I’ve forgotten about.
Brute force attempt 1
My first attempt literally started searching the whole d-pad and shooting space before I realized the search reduction methods above. I got about 5-6 frames in with the brute forcing and did not trigger the game end glitch.
Brute force attempt 2
I started the run by holding left for a bit, then went 1-2 frames before this TAS lets go of left and searched the space with the minimizations above.
I got 6-7 frames in without triggering the glitch.
I also only allowed neutral and R within 7 frames of letting go of left. Both neutral and R do the same thing to your speed, but have different effects on your teetering and hence the glitch. L+R and R have identical effects in all aspects within 7 frames of letting go of left.
Brute force attempt 3
I held left until the frame before I let go of left in this movie and searched the whole space. I noticed that L+R, R and neutral did the same thing within 7 frames of you letting go of left. Once again, I got 8-9 frames in without triggering the glitch
Brute force attempt 4
Here I assumed that left wouldn’t be used after I let go of left, so I removed this from the search
Brute force attempt 5
I let go of left 1 frame earlier than this movie and removed down from the search space as down results in the speed misalignment. I did not find a solution that was faster than this TAS
Brute force attempt 6
Same as attempt 5 except that I let go of left on the same frame as this movie. Here I reproduced the glitch at the same speed as this movie through the brute forcer. Interestingly, last input was on the same frame as this movie, but the fadeout to the credits happened 2 frames slower. This was because the brue forcer stumbled across a slightly different pattern of pressing right vs pressing neutral in the 7 frame window after letting go of left.
At this point I concluded that the brute forcing attempts were finished and I had not found any improvements to my original solution by hand (this submitted movie). It’s possible that the fadeout could happen quicker than this movie, but not the last input.
I’m extremely confident that I exhaustively searched the space of left, right and left+right inputs. However it was too computationally intense to search the space including down inputs fully. I did however search a large portion of that down input space.
This means that I’m relying on my understanding of the glitch triggering conditions to conclude that this it optimal. Although, the elusive potential frame save still bothers me a lot, hence all the brute forcing attempts and delayed submission.
My original script can be found at this link, but I ended up with about 10 different scripts in the end for different phases of testing. This is just my first script:
Userfiles/Info/61050675887497989
RTA Community and “Console Verification”
Shortly after my original TAS, an RTA community popped up for this game. This led to many discoveries including the new game end glitch that allowed me to save so much time with this TAS.
After finding the new game end glitch, I quickly made a TAS which matches this submission’s TAS timing. I realized that this would be possible to match RTA as it only relied on hitting 2 frame perfect inputs. After some trying, I managed to get the WR of 9.88 seconds RTA timing. Note: RTA timing starts from pressing 1 on the title screen and ends on the first fully blue frame after the level fades out to the credits.
I made a tutorial on how to achieve 9.88 and we eventually had 40 people tie my RTA world record of 9.88!
Of significant note is btrim who achieved 9.88 on console
https://youtu.be/RNwVmRxMNXw Considering he held the 1 button from bootup, he actually completely matched this run in timing from power on. This makes this *technically* the first console verified Master System TAS!
A Faster Run in RTA Timing (9.84)
It’s possible to make the game fade to the credits 2 frames faster than this TAS. You need to pause and unpause frame perfectly within about a 10 frame window near the glitch. This is a general glitch which will make any level fade out 2 frames faster. This is not used in the TAS because it causes your last input to be 2 frames later.
Note: It’s quite possible that there’s an alternate method to trigger the glitch that fades out much faster. As I said in the brute forcing section, I found one with an almost identical setup that fades out 2 frames slower. I haven’t put heaps of effort into finding a faster fade out as that wouldn’t affect the TAS timing.
RAM Addresses
| Address | Description |
|---|
| 0x0AB5,0x0AB4 | X Vel |
| 0x0AF8,0x0AF7,0x0AF6 | X Position |
| 0x0AB7,0x0AB6 | Y Velocity |
| 0x0AF5,0x0AF3,0x0AF4 | Y Position
|
| 0x0A92 | HP |
| 0x0A80 | i-frame timer |
| 0x0ADDD | Object count |
| 0x0A84 | Level |
| 0x0B95,0x0B85 | Boss HP |
Final Thoughts
Thanks again to Revenged2, greysondn and Synahel for making sure the original game end glitch wasn’t lost. It was finding the post in the TASvideos forum where I actually found out about this amazing TAS game.
Thanks to cxrnxr and the rest of the RTA community for helping to find the faster credits warp
Thanks to EZscape for bringing more attention to this game and the Master System
ThunderAxe31: Setting to Delayed, in view of a possible improvement.
ThunderAxe31:
Sadly, this movie fails to meet one important rule: a speed-oriented movie must beat all existing records. This rule is strict, since one of the main basis of this site is to represent TAS records. What's worse, is that those already existing records were played without using TASing tools, which means that this submission doesn't feature superhuman play.
Before proceeding with the verdict, I've considered the possibility to let the author replace the submitted movie with a version that triggers the ending 2 frames earlier, at the cost of having additional movie inputs, if that resulted faster than all known records. This could have been taken into consideration, in light of a recent
precedent that preferred a movie that beats the game earlier by using more inputs, as opposed of a
counterpart that beats the game later with less inputs. However, it turned out that the RTA community
tied the faster ending movie as well. The author mentioned the hypothesis of triggering the ending even earlier, but he in the end he wasn't able to do so.
So in any case, this submission is rejected for failing to beat known records.
Beside the judgement itself, I have an additional note. First, I want to thank the author for making and for submitting this movie, despite the fact that it somehow could have appeared unacceptable from the start. Failing to beat known records is usually considered as an obvious mistake, however this is a special case because it opens to a new problematic scenario that has not really figured out yet. While the gameplay execution is considered trivial for this submitted movie, it isn't the case for the currently published
movie, as it well featured superhuman gameplay and did beat all known records at the time. Submissions that get rejected for trivial gameplay are usually the result of a bad game choice, as it's the game itself which is not able to feature superhuman gameplay in any form. However, in this case we have a typical game that allows for developing and showcasing plenty of superhuman play, except when the specific game end glitch technique present in this submission is applied. As I mentioned at the beginning, beating all known records is considered a strict requirement, but I wonder if an exception should be raised for the usage of glitches that produce a trivial movie for games that would otherwise be suitable for featuring tool-assisted superplay. Otherwise, the currently published
movie would remain perpetually not obsoleted, despite eventual discoveries that could improve it without making use of the trivial glitch used for this submission. The very same situation also applies for
this game, so we're not talking about an isolated case and we may see more games falling into this limbo, in future.
In any case, the aforementioned problem doesn't concern this submission, as in itself doesn't affect the current judgment, so this matter should be duly discussed in the
Ask a Judge thread, or in any future submission thread that will aim to obsolete the currently published
movie, without making use of a specific technique that could render a whole movie trivial to match with real-time play attempts.
ThunderAxe31: After reading some opinions in the submission thread and discussing with other staff members, I decided to reconsider my current verdict for this submission and start over this judgement process.
ThunderAxe31: At first, I was sure that this submission shouldn't be accepted because it doesn't stand out from unassisted speedrun play. However, after extensive discussion with other staff members, I've come to change my mind about it. I used to think that a TAS should be considered as such only if it's impossible to be matched by real-time attempts, but in the end we can't really draw an objective borderline for defining what it's within human possibilities and what is beyond that, as we've seen over time speedrunners breaking the limit multiple times over history. And on the other hand, trying to enforce such requirement would also uselessly limitate TASing possibilities, as the TASing community did also repeatedly surpass the previous feats, to the point of reaching paradoxical results. In this specific case, the paradox consists in having optimized gameplay so much that it actually turned out easier for human play attempts, to the point that they could in fact match its timing.
So, since the staff come to agreement about allowing these kind of movies, the
Movie Rules and
Vault pages have been updated accordingly. Specifically, submitted movies are not required anymore to beat all known records, but just to at very least match them. Note that this rule change wasn't made just for the sake of accepting this submission, but rather because it was considered as more appropriate for its original intent.
Another important rule change was the introduction of a better definition of triviality. We want to restrict triviality on a game-by-game basis, depending on if a game can or not produce TASes that aren't too easy to make or to match in RTA. This basically means that even if a new submission results easy to make or to match in RTA, it will be accepted anyway if that game was previously known to feature at least one TASing record that wasn't trivial to match in new TASing attempts, with the tech knowledge available at that time. Please note that this new rule is referring to edge cases like
GB The Adventures of Pinocchio, which isn't exactly the case for this submission, as it required some extensive research in order be made, as well as appreciable efforts in order to be matched by real-time attempts.
Lastly, I want to note that the requirement of being "distinguishable from the best real-time speedruns" was removed from Vault and implemented to
Alternative and
Stars tiers.
Now that we sorted out the technical matters about rules and policies, and come to the conclusion that this submission should and is acceptable, let's look closer at the movie itself. Even though this movie was considered to be matchable by real-time attempt by its own author, even before that it was submitted, I have to remark that this is a TAS in all aspects. It features proficient use of the TASing tools, as well as a deep understanding of the specific game mechanics and quirks. Also, a lot of efforts have been put in order to make it optimized as much as possible, given the currently available techniques and knowledge. So even though it's matchable by human play, it wasn't trivial to make. And now that the Movie Rules are officially not requiring anymore to beat all known records, there isn't any issue on the technical side to be found.
Regarding entertaining, we've seen mixed reactions from the audience. There have been a relatively enthusiastic response, but this doesn't change the fact that there is little to be watched, as gameplay visually resulted extremely short and basic.
For the rest, I have to note that we already have a published movie that beats the game by triggering the credits routine early via a glitch. Since the movie goal is the same, this submission has to obsolete it.
