And here's the clock stop version.
- Emulator: Bizhawk 2.3.1
- Aims for in-game time
- Takes damage to save time
- Does not forgo a time saving glitch
- Manipulates luck
I'd originally planned to include the four clock stop fights as branches in the
non-cs submission because of how similar the runs were. Turns out you can't actually submit tasproj files, so that didn't happen. I basically just pasted those branches into the full run and then spent the whole night resyncing everything.
Because of the nature of the clock stop glitch, the in-game time improvements are very low -- only 1.34 seconds. The real time savings are much larger, totalling
00:16.24 seconds over
adelikat's old run.
The Clock-Stop Fights
- Don Flamenco I: 11.97
- Unchanged from the previous strat. The only other option in such a short fight is to get a second star while the clock is stopped and use it in phase 2. This would get a time of 12.00.
- Soda Popinski: 31.48 (was 31.82)
- It's possible to cancel Soda's first hook sooner with a misdirected gutter. This accounts for all the in-game time saved.
- In phases 1 and 2, everything between stopping the clock and knocking Soda down has been reworked. The key change is using simultaneous hits so Mac takes damage but only loses one heart. In total, the new phases save 112 frames over the old submission.
- Don Flamenco II: 44.48
- Only one frame of game time is saved, and it's not enough to change the final time.
- Using stars throughout the fight saves a substantial amount of real time over the old submission -- 512 frames! Normally a star punch will unfreeze the clock after it lands, but a simultaneous hit with a star will keep it stopped.
- Don gets up with his middle refill in phase 2. This gives him 8 more HP, but he can now get up on 3 instead of 8. Another simultaneous hit into his first punch takes off all of this extra health.
- Once Mac gets up the second time, there's no way to squeeze in any more stars. If I were to try, he'd dodge the final star punch in phase 3 unless I delayed it.
- Super Macho Man: 34.82 (was 35.82)
- It's just barely possible to make the next second by cancelling all of Macho's hooks with gutters. In fact it only works with right guts -- even though the blocking animation for rights is one frame longer, they can be thrown two frames sooner. This doesn't apply to macho's last two uppercuts, since the delay for those is too short to gain any advantage.
- The stun glitch in phase 2 isn't just for show. Getting clock stop this way actually saves a few frames while cancelling Macho's next few attacks.
- In phase 3, I can afford to fit in a star punch before Macho starts spinning. Because he locks the timer to the next second, this doesn't actually cost any game time. Most of the 352 frames saved come from this.
Memory: So this is an interesting submission. Now optimization appears very good for the chosen goal. However, said goal is the center of controversy.
So for a little bit of background, Mike Tyson's Punch Out has a mechanic where certain actions will briefly stop the ingame timer. This is pretty much unavoidable during the course of normal gameplay and is also taken advantage of in the other submission. However, there is also a glitch where in certain circumstances you can prevent the ingame timer from resuming. This is called the clockstop glitch. Various actions will allow the ingame timer to resume, but most of them can be avoided. However, an opponent getting knocked down and getting back up will resume the timer and this is largely unavoidable. Additionally, this will not prevent the timer from starting at the beginning of future matches.
The audience reception was much worse compared to
the submission that doesn't use this glitch. I also find it a tad less entertaining due to how drawn out some fights can be. Additionally, this movie is very similar to the other submission, since only 4 fights differ. As such, this movie isn't suitable for moons.
What makes this submission interesting is that several people have made the argument that this is true vault fastest completion. This is how one obtains the lowest ingame time for the game, and we don't really have rules regarding similarity of branches for Vault,
the reason this branch was previously rejected.
However, I felt the question to ask about this was… is this a good situation in which one should rely on an ingame timer? When are ingame timers meaningful and useful?
The obvious answer to the latter is the Sonic scenario. In the old 2D sonic games if you optimize for ingame you want to trigger the goal post, or capsule or whatever as fast as possible. Gameplay is optimized to be as fast as possible. If one aims for real time, the time bonus countdown becomes a problem. Since the time bonus counts down slowly, it might be beneficial to wait a little before triggering the end of the stage to avoid a longer time bonus. This is obviously rather dull and arguably caps optimization strategies and we don’t want that.
This game has a similar problem where if one were to aim for real time, one would encounter situations where they have to wait. The knockdown countdowns aren’t counted on the ingame timer, so it would be preferable to get K.O.s where possible instead of T.K.O.s (3 knockdowns in a single round). K.O.s tend to be hidden developer easter eggs rather than requiring any sort of creative thinking. As such they are largely more trivial than T.K.O. strategies. The most notorious example is the second Piston Honda fight. In that fight there is an attack rush he performs at 1 minute which if you counter is an instant K.O., regardless of his HP. In a real time focused run you’d aim for that KO and simply wait until it is performed. In an ingame time focused run, you aim for a TKO long before the 1 minute mark and is significantly more technical.
I’d argue that ingame timers are meaningful and useful when they cover gameplay, result in faster, shorter gameplay, and generally somehow represent the time of the run.
So when aren’t ingame timers meaningful and useful? To answer that question, I came up with a series of examples, starting from most extreme and moving to less extreme.
The most extreme example is arbitrary code execution (ACE). If a game has ACE, is ingame time meaningful? With ACE you should have control over values such as an ingame timer. You could easily set the ingame timer to 0:00. Heck you could set it to -9:99. Or you could maybe even set it to T:AS. Because you have such a high level of control over the game, ingame time no longer represents time in any meaningful fashion and just happens to be some number the game displays. This is similar to how we treat ACE in regards to full completion. Ultimately all of the optimization would be for real time and so having ingame time as a primary goal seems rather redundant.
Now a less extreme example, but still rather extreme. So take this game and the clock stop glitch. However, instead of the clock resuming on the opponent getting knocked down, or at the start of a new match, it just never resumes for the rest of the game. In such a scenario, the majority of fights would have an ingame time of 0:00. The majority of the game would have to be optimized for real time, despite having a “primary” goal of ingame time. Does ingame time really represent time of the run in this circumstance? I don’t think so.
Lets say there were ways of clock stopping every fight. Some fights can get rather long, I’d think there’d be much of the game covered by RTA at this point and ingame time would be sorta redundant.
And then we have this submission right here. It’s only used in 4 fights, and only in 3 of those 4 fights is the difference in gameplay significantly big. There is a fairly limited amount of gameplay covered by real time but not by ingame time.
In my opinion, the only reason this seems questionable is because the gains are relatively small. Such a glitch could easily make ingame time just so obviously meaningless if one or two things were different. As such I cannot really see ingame time as adequately representing time in this submission.
The obvious solution is for the game as a whole to fallback to real time, but for reasons mentioned prior, that isn’t exactly ideal either. The only sensible solution therefore becomes to ban the glitch, since it subverts the purpose of the ingame-timer with regards to this game. The other submission becomes preferable as a result.
For purposes of a sort of Vault policy, I believe we might only allow aiming for ingame time if the resulting movie has shorter gameplay as opposed to things like menus or cutscenes that might add to the real time. However this isn’t set in stone currently and might be pending additional discussion.
Rejecting.
