This topic is for the purpose of discussing #8745: LoganTheTASer's NES Hyperbeatz "maximum score" in 1:41:33.22

The submission file is a .fm2 and says it was made in FCEUX 2.6.4

oh my god… why did i put bizhawk? thanks for pointing out. fixed.

I think this run would be better branched "all songs" or "full completion" instead of "maximum score." Because the game doesn't monitor score beyond one song, there's no real way to determine when to define the endpoint of "Maximum Score." If the game tracked score beyond 1 song, then maxing out the score counter itself would be that endpoint. Even if this was the case, replaying the various songs is an option. This means that the fastest method to reach the theoretical maximum score would be to replay the song that yields the most points/time spent over and over again until the max score was achieved. Considering that the game does checkmark each song once it's completed, we can claim that it does monitor a completion level of sorts. Thus 'full completion' or 'all songs' would be a better descriptor of the run. The run should still qualify for Standard publication.

I think this run would be better branched "all songs" or "full completion" instead of "maximum score." Because the game doesn't monitor score beyond one song, there's no real way to determine when to define the endpoint of "Maximum Score." If the game tracked score beyond 1 song, then maxing out the score counter itself would be that endpoint.

We used to have this clause and then it was maybe considered obvious enough to not repeat, but we can restore it:

If a game automatically resets the score as you progress (for example, in every level), "max score" must be reached in every such segment.

Even if this was the case, replaying the various songs is an option. This means that the fastest method to reach the theoretical maximum score would be to replay the song that yields the most points/time spent over and over again until the max score was achieved.

Infinite scoring loops that delay completion are not allowed.

Considering that the game does checkmark each song once it's completed, we can claim that it does monitor a completion level of sorts. Thus 'full completion' or 'all songs' would be a better descriptor of the run. The run should still qualify for Standard publication.

But does this run go out of its way to maximize per-song score too, or does it just aim for shortest time in each?

I think this run would be better branched "all songs" or "full completion" instead of "maximum score." Because the game doesn't monitor score beyond one song, there's no real way to determine when to define the endpoint of "Maximum Score." If the game tracked score beyond 1 song, then maxing out the score counter itself would be that endpoint.

We used to have this clause and then it was maybe considered obvious enough to not repeat, but we can restore it:

If a game automatically resets the score as you progress (for example, in every level), "max score" must be reached in every such segment.

I either forgot about or never knew about this clause in the past. With that perspective, then I suppose "max score" would still be applicable.

Even if this was the case, replaying the various songs is an option. This means that the fastest method to reach the theoretical maximum score would be to replay the song that yields the most points/time spent over and over again until the max score was achieved.

Infinite scoring loops that delay completion are not allowed.

If someone were going for maxing out a score counter that was retained between songs, repeating a song could be considered a scoring loop; but it would not delay completion. It would speed up the run and thus completion by repeating the most efficient song in regards to points/time. But this really doesn't apply to this game anyway.

Considering that the game does checkmark each song once it's completed, we can claim that it does monitor a completion level of sorts. Thus 'full completion' or 'all songs' would be a better descriptor of the run. The run should still qualify for Standard publication.

But does this run go out of its way to maximize per-song score too, or does it just aim for shortest time in each?

I didn't think about ending input early regarding "all songs" or "full completion" to make sure it was shortest time. If that were considered, only ending input early on the last song would make a difference in time and it would be minimal (a few seconds) over the course of a movie of 1.75 hours. I think in that case, finishing the song would be a valid tradeoff in which it could still be considered the record even if someone tried to beat it by simply skipping the last few notes. Bottom line: Given the cited clause that's in the legacy rules, "max score" is fine as a branch based on our rules. I still feel that "full completion" or "all songs" would be a more appropriate branch; but that's just my personal perspective.

Double posting as this is completely separate from branch discussion of my last post: One of the in-game options is scroll speed. This impacts how rapidly the button indicators scroll up to the line at the top of the screen. I think the run would look even more impressive if the scroll speed was maxed out. It shouldn't change the when the buttons need pressed within the song, but would just change the visual. I may see if I can add the speed change into the run and edit this post with a comparison encode later. If I can add it and we'd rather publish the faster speed, I'll provide the appropriate movie file also (no co-authorship). EDIT: Development. I've changed the scroll speed. For some reason, doing so gets to the first note of each song faster than with the slowest scroll speed, but all the other notes hit perfectly. I'm going to re-sync this whole run. I've also found better menuing controls in at least 1 place. I anticipate maybe more. MAJOR EDIT 2: I've resynced the run using the fastest selectable scroll option. The total time saved is 1,158 frames which is basically 24 frames saved per song. For whatever reason, when the game is set for the faster scroll speed it results in 24 fewer frames of lag between selecting a song and the song starting compared to the slowest scroll setting. The menuing "improvement" I mentioned doesn't actually save time; it simply puts all menu movements in a single frame instead of over 2-3 frames. The next song doesn't start any earlier. Something else caught my eye while re-syncing this run. After two of the songs, secret codes are provided by the game. One is a "Wacky" mode that introduces weird graphical changes including random (sometimes rapid) screen color changes and the button indicators moving sideways as well as vertically. The second code is a "Boost" mode which is faster song speed than normal play. These two codes are meant to make the game extra challenging. The "Boost" mode is arguably acceptable for Standard Publication on our site as the code is used to access an even more difficult mode than is normally selectable (as opposed to making the game easier). Unfortunately, I don't feel that having both a normal play publication (even at the fastest scroll setting) along side of a "Boost" mode publication is worthwhile for the site. So here's my proposal for getting the fastest publication of this game on the site: I will create a new run using the "Boost" mode code to TAS the hardest/fastest difficulty of play. I'll also use the fastest scroll setting to minimize lag. While it technically makes the game more difficult, the "Wacky" mode will not be used; because the graphical alterations may be noxious to some viewers. As I don't want to manually resync every note in the game, nor would I want to offload that effort onto LoganTheTASer _{(we need to change his name on this submission, by the way)}, I have already written a Lua script to automatically input the note presses where needed for perfect play. Ending input early is not an option as a Start press is necessary to progress from the final score screen back to the menu to show the checkmark indicating completion on the last song. Regarding branch naming: I feel that an "any %" run of this game should be required to complete all the songs as there's no other good way to define a valid endpoint of the game. Given the need of a Start press after the last song, there's no real way to end input early. So a "full completion" run wouldn't be any different than "any %" run. Also due to the final Start press, not getting maximum score doesn't speed up the final inputs. So all three branches are effectively the same from a time-perspective; getting less than a perfect score could be considered sloppy play given that it doesn't save time from an optimization standpoint. Therefore, I feel the "Boost" mode run should be considered the baseline "any %" run of this game and should be published branchless. Regarding authorship: Technically, the new "Boost" run won't have any of LoganTheTASer's actual input, because I'm making it in BizHawk. However, I still feel he deserves credit for all the work on this submission. Thus I believe co-authorship of the "Boost" run is the best way to acknowledge his work/input even though I'll be the one creating the new run almost entirely by botting. What to do about this submission: I feel the new run would be better being a new submission than 'updating' this one, so I'd suggest this run be cancelled as opposed to rejected. However, if the judge/staff feel that we should instead just update this submission, I'd concede.

Double posting as this is completely separate from branch discussion of my last post: One of the in-game options is scroll speed. This impacts how rapidly the button indicators scroll up to the line at the top of the screen. I think the run would look even more impressive if the scroll speed was maxed out. It shouldn't change the when the buttons need pressed within the song, but would just change the visual. I may see if I can add the speed change into the run and edit this post with a comparison encode later. If I can add it and we'd rather publish the faster speed, I'll provide the appropriate movie file also (no co-authorship). EDIT: Development. I've changed the scroll speed. For some reason, doing so gets to the first note of each song faster than with the slowest scroll speed, but all the other notes hit perfectly. I'm going to re-sync this whole run. I've also found better menuing controls in at least 1 place. I anticipate maybe more.

I was going to say 'IMO the scroll speed should be at a rate that is comfortably readable by rhythm game players so that they can follow along with the charts' but, well... if it saves FRAMES, rest assured I can't argue with that!!

om, nom, nom... sweet!