I present to you, the first ever Cheetahmen II TAS that plays the original (not bugfixed) version AND shows the final boss!
History
Cheetahmen II was never released. Copies of this rare cart were discovered in a warehouse after the Action 52 company went out of business. It was a prototype for a sequel for the "hit" game Cheetahmen on the Action 52 cart. Not releasing this was a good decision, not only is it a terrible game, it had numerous bugs that made the game unplayable. The most significant was a bug that prevented the game from progressing after you beat the level 4 boss. While the game had 6 levels, for a long time people did not know this, due to not being able to get past level 4.
However, it was discovered that sometimes the game would start on a random level, and it was discovered that one of these was level 5! Now people could finally see the rest of the game (unfortunately for them).
The reason for this glitch is due to the fact that the board registers start off in an unpredictable state. This is a known issue in hardware, and most any board is built to clear out registers before attempting to use them. Good NES carts like MMC3 would do this for instance. Also, good games are programmed to loop and clear out ram, and set registers BEFORE attempting to use them. However, Cheetahmen II uses a custom board built by the Action 52 company and not surprisingly, this board is bad. It has no logic for clearing out these registers. Cheetahmen II is a badly programmed game, so it actually reads from mapper registers before setting them. Furthermore, in this perfect storm of crappiness, the game is built on a multi-cart board design. So it happens that each level is built on a separate PRG bank. Normally if the PRG register was set badly in a game, it would likely crash (as any program would if you started it halfway in).
Determinate indeterminacy
In TASing emulators, random register states and ram are bad things, they will cause indeterminacy and it is impossible to have a movie sync reliably. So emulators tend to program ram values to 0's, and all mapper registers as well. However, this is just one of many valid and possible start up scenarios! I suggest that a TAS can and should be able to exploit the initial state of hardware! If the all powerful superhuman that TASes represent can predict future RNG values, why can't he have full control over when to turn on the hardware to get the values of his choosing? With this in mind, I modded Bizhawk so that you can set the initial register values inside a movie file. This way we don't violate determinacy issues, while still giving full power to the TASer to control this situation. In this case of this submission, my movie file starts the game on PRG bank 11 (which is the start of level 5) with a prg mode of 1 (not terribly important detail, but needed for the game to run properly from bank 11).
Ending
After you kill the level 6 boss (or level 4 boss), the end of the level does not trigger. The "Fixed" from fixes this bug. But since an ending was never programmed into the game, it simply triggers a game over screen.
I don't care whether the game gets technically finished or not, from the encode it clearly appears that Cheetahmen dies on the final boss and restarts at stage 3, then the encode abruptly cuts off.
Link to video
I could understand if Cheetahmen dies and you reach a credits screen or something, but that's clearly not the case.
As for the whole initial state of hardware controversy, I actually don't mind it and agree with this post:
However, if it can happen on an actual cart, via power cycling, I don't care what initial register state is possible vs which was used. We'd know its possible to get a certain outcome from certain hardware, so we have to emulate that as best we can. Maybe the IC is in some glitched metastable state. Emulating that faithfully isnt even sensible. But emulate it we must, as best we can, and if that means by arbitrarily selecting startup values that match known behaviours (as we do for RAM) then so be it.
On the other hand, I fear this sets a bad precedent if every movie on the site could theoretically be obsoleted by those clever enough to find the best initial hardware state for their TAS, which increases the amount of technical knowledge required to make a TAS. We should be looking to decrease the learning curve for new TASers, not increase it, make it as accessible as possible.
I don't care whether the game gets technically finished or not, from the encode it clearly appears that Cheetahmen dies on the final boss and restarts at stage 3, then the encode abruptly cuts off.
http://www.youtube.com/watch?v=JPoLBTaJ2JU
I could understand if Cheetahmen dies and you reach a credits screen or something, but that's clearly not the case.
The game has no ending, it was not programmed in the game. The fixed version simply transitions to a game over screen as if you died. I achieve that same "ending" by....dying.
Vykan12 wrote:
On the other hand, I fear this sets a bad precedent if every movie on the site could theoretically be obsoleted by those clever enough to find the best initial hardware state for their TAS, which increases the amount of technical knowledge required to make a TAS. We should be looking to decrease the learning curve for new TASers, not increase it, make it as accessible as possible.
If that honestly is a concern, then simply ban RTC while you're at it since knowing how RNG is affected by system time " increases the amount of technical knowledge required to make a TAS."
In that case, couldn't the character just die anywhere? Like, why bother start on level 5 at all, just start at whatever level lets you die the quickest.
Emulator Coder, Site Developer, Site Owner, Expert player
(3599)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
Inzult wrote:
In that case, couldn't the character just die anywhere? Like, why bother start on level 5 at all, just start at whatever level lets you die the quickest.
Well, I am trying to complete the game, as much as it can be completed. To that end, I make it to the final boss, and deliver enough damage to kill him. I do what is required to win, even though the victory is not given to me :( However, I still argue that the CONTENT is there, even if the visuals aren't.
On the other hand, I fear this sets a bad precedent if every movie on the site could theoretically be obsoleted by those clever enough to find the best initial hardware state for their TAS,
That's not actually the case, since the vast majority of games do initialize their hardware properly before reading from it.
On the other hand, I fear this sets a bad precedent if every movie on the site could theoretically be obsoleted by those clever enough to find the best initial hardware state for their TAS,
That's not actually the case, since the vast majority of games do initialize their hardware properly before reading from it.
Also, if that was indeed the case, I'm just surprised how runs like Tetris was able to be console verified several times by different people. :P
In that case, couldn't the character just die anywhere? Like, why bother start on level 5 at all, just start at whatever level lets you die the quickest.
Because then you're not reaching the end of game. The end of the game doesn't have to be the credits. In this case, there are no credits. In this case, the final point where no further progress is possible is lowering the final boss's hp to 0 (or whatever it is).
In that case, why die at all? If 0 hp is the goal and not the death, why not, say, pause the game once that threshold is reached? Or, perhaps, pause then hit select to go back to the title screen in stead?
Why could the person in the video that inspired this TAS kill the boss?
Also, why couldn't this glitch be done in the fixed version of the game that is beatable?
I think this TAS is unpublishable in its current state.
The only relevant precedent was the swordless run of Zelda in which the player chose to freeze the game as he couldn't beat the boss, but even that one TAS got its goal terms changed so that Link can get the sword after the challenge is over and kill Gannon, if memory serves me well.
In that case, why die at all? If 0 hp is the goal and not the death, why not, say, pause the game once that threshold is reached? Or, perhaps, pause then hit select to go back to the title screen in stead?
Probably because adelikat thought it provided a better ending than just ending the video abruptly.
The only relevant precedent was the swordless run of Zelda in which the player chose to freeze the game as he couldn't beat the boss, but even that one TAS got its goal terms changed so that Link can get the sword after the challenge is over and kill Gannon, if memory serves me well.
Not exactly the same situation. The currently published run does actually beat the game, and in the video showcasing the bug that Adelikat aims to replicate (by using a specifically tailored emulator) the player does destroy the boss (probably because of another bug that cannot be replicated this way).
Emulator Coder, Site Developer, Site Owner, Expert player
(3599)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
DrJones wrote:
Not exactly the same situation. The currently published run does actually beat the game, and in the video showcasing the bug that Adelikat aims to replicate (by using a specifically tailored emulator) the player does destroy the boss (probably because of another bug that cannot be replicated this way).
The destruction of the boss in that video is because he is using a FIXED version of the ROM (not the same fixed one that the published TAS uses, but still)
Joined: 8/14/2009
Posts: 4083
Location: The Netherlands
I found out it is possible to beat the final boss after all:
User movie #10498514182923544
My apologies go to adelikat for proving him wrong.
At least now the game has a much more acceptable ending point.
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
I found out it is possible to beat the final boss after all:
User movie #10498514182923544
My apologies go to adelikat for proving him wrong.
At least now the game has a much more acceptable ending point.
I thought we had many games where we cuold not emulate elements of randomness intentionally chosen by use of data of a unknown initial state. I thought the status quo was to just go with the emulator defaults, accepting it as not the best possible hardware luck. Example being the pokemon games that use screen blank timing or hardware LCD values to initialize random seeds. Is this really all that new? What's been the running policy? [does this change if the use of unknown data by the game is unintentional, and we can prove it so?]
DRybes wrote:
-Do we have other games that instantly load at the non-beginning level from launch?
My posts are often long winded but I would like if someone could address ^ these two simple questions. Thank you.
I thought we had many games where we cuold not emulate elements of randomness intentionally chosen by use of data of a unknown initial state. I thought the status quo was to just go with the emulator defaults, accepting it as not the best possible hardware luck. Example being the pokemon games that use screen blank timing or hardware LCD values to initialize random seeds. Is this really all that new? What's been the running policy? [does this change if the use of unknown data by the game is unintentional, and we can prove it so?]
DRybes wrote:
-Do we have other games that instantly load at the non-beginning level from launch?
My posts are often long winded but I would like if someone could address ^ these two simple questions. Thank you.
1. the only other cases where values are set outside of the game, that i know of, are things like real time clocks, and profile settings (such as on DS). These can be set to any value the taser wants.
2. I highly doubt it.
-Do we have other games that instantly load at the non-beginning level from launch?
There's this, which is not the same as starting on a different level, but in a similar way, the starting character is chosen non-deterministically at power on (possibly due to something like register entropy or reading from dirty RAM). So there is precedent for hardware start-up conditions which cannot be directly influenced by the player dramatically changing how the game plays out.
Games acting differently depending on uninitialized memory is known in other situations too, and is sometimes part of gameplay.
1 - My favorite example (and the one I think most relevant) has to be X-Men 2: Clone Wars for the Sega Genesis. It starts right to the first level, not the title screen, yet there's selectable characters. So for the first level it selects them randomly. My little brother and I, on our Sega Genesis Model 3, would simply reset the system until we got the choices we wanted for the first level. If you're on an emulator that starts all types of memory in a set state (like Gens), then I hope you like Wolverine or Beast because you'll end up with one of them on each cold reset, depending on if you have a 6-button controller or a 3-button controller set up. However on emulators that seem to do a little randomization first (like Kega Fusion), you're properly given a random char, like you would be on a physical system.
2 - Another example is how Super Mario All-Stars inherits SM3's debug mode stuff, but unlike SM3, neglects to wipe/reset that specific address. So you could, depending on the last game played on your system (or entropy/chaos/whatever as some articles mention), start up SMA:SM3 and find the debug mode enabled on a physical SNES. But not so on an emulator that sets all ram to things other than 0x80 each and every time.
EDIT: Oh, whoops, the above post already mentioned example 1. Oh well, at least it's known then.
If you're on an emulator that starts all types of memory in a set state (like Gens), then I hope you like Wolverine or Beast because you'll end up with one of them on each cold reset, depending on if you have a 6-button controller or a 3-button controller set up.
The above is mostly true, but additionally, the buttons you press while the screen is black before the first stage loads also influences which character you get. That is how we managed to get Nightcrawler in our TAS.
I don't know how the game randomizes characters on startup on a real Genesis. Uninitialized RAM is a possibility, but we'd have to reverse engineer the game to know for sure. If it is only uninitialized RAM then it is strange that changing the controller type affects it...
I don't know how the game randomizes characters on startup on a real Genesis. Uninitialized RAM is a possibility, but we'd have to reverse engineer the game to know for sure. If it is only uninitialized RAM then it is strange that changing the controller type affects it...
It could be both? Maybe the rng is initialized with uninitialized memory, and then changes based on the controller state.
If controller state is used just to roll the routine while idle, it will very well affect the result. In Battletoads it is so, and a run done for 1 plugged controller won't sync if you plug one more.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Emulator Coder, Site Developer, Site Owner, Expert player
(3599)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
Ok, replaced the submission file with a movie that does kill the boss.
What I didn't realize was that there is indeed a bug that was fixed in the fixed version. But the logic is that if you have 1 health you can't kill the boss. If you have at least 2, he will in fact die. Unfortunately when I was figuring all that out, I was down to 1 health >.<
