7/3/2024: This submission has been cancelled in favour of a recently discovered “Boost” mode.
It’s finally finished. Ladies, gentlemen and everyone inbetween, may I present to you my biggest behemoth of a TAS yet - Hyperbeatz.
About the Game:
“Hyperbeatz” is a 2021 homebrew rhythm game for the NES. It was developed and published by Anthony Blackman (aka Mystical Wheelbarrow). There are 16 songs to choose from with 3 difficulties each, for a total of 48 levels.
About the TAS:
This TAS aims for Maximum Score, which means getting the highest possible score in each level.
Gameplay/Tech:
The scoring system works like this:
- Nice - 100 points
- Good - 50 points
- Poor - 20 points
- Miss - 0 points
If you perform poorly enough, you will be kicked out of the level with an F.
The hardest grade is “Star”. This means playing absolutely perfectly, which is the objective of this TAS.
In most cases, you have a 3 frame window for a “Nice”, and around an 11 frame window to get any points at all per note.
Final Scores (oh no):
Boo! (4) - 18,700 points
Boo! (6) - 35,700 points
Boo! (9) - 70,800 points
Bullet Barrage (1) - 6,500 points
Bullet Barrage (7) - 40,800 points
Bullet Barrage (11) - 90,800 points
Chipsqueak (5) - 21,500 points
Chipsqueak (8) - 47,700 points
Chipsqueak (13) - 91,700 points
Chonkotron (3) - 14,200 points
Chonkotron (6) - 40,200 points
Chonkotron (11) - 98,800 points
Culmination (5) - 26,300 points
Culmination (7) - 37,900 points
Culmination (11) - 108,300 points
Destined Path (4) - 15,400 points
Destined Path (8) - 40,800 points
Destined Path (11) - 85,800 points
Detached (4) - 15,500 points
Detached (6) - 34,500 points
Detached (10) - 65,800 points
Don’t Go Back (5) - 22,900 points
Don’t Go Back (9) - 67,800 points
Don’t Go Back (14) - 105,400 points
Eliminator (2) - 8,500 points
Eliminator (6) - 35,100 points
Eliminator (11) - 81,600 points
Gear Up (3) - 13,600 points
Gear Up (7) - 48,400 points
Gear Up (12) - 114,300 points
Night and Day (3) - 15,000 points
Night and Day (5) - 32,500 points
Night and Day (9) - 68,300 points
Poison (4) - 16,200 points
Poison (6) - 27,500 points
Poison (10) - 73,300 points
Puppy Pride (1) - 5,800 points
Puppy Pride (8) - 39,600 points
Puppy Pride (10) - 55,900 points
Quicksand (2) - 12,300 points
Quicksand (6) - 45,300 points
Quicksand (13) - 131,500 points
Space Journey (5) - 37,300 points
Space Journey (9) - 109,500 points
Space Journey (15) - 171,200 points
Velocitized (4) - 15,100 points
Velocitized (7) - 36,500 points
Velocitized (12) - 99,400 points
GRAND TOTAL: 2,479,600
And That’s It!
Due to this TAS’s length, I will not be making an encode.
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.
If a game automatically resets the score as you progress (for example, in every level), "max score" must be reached in every such segment.
DrD2k9 wrote:
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.
DrD2k9 wrote:
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?
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.
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.
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.
DrD2k9 wrote:
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.
DrD2k9 wrote:
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!!
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.
If all songs were optional, maybe you could only play the optimal ones and repeat them, but in linear games repeating some level means game end is delayed. The goal of max score is not to hit score cap at any cost, but to complete the game the quickest while also getting maximum reasonable score. Score cap is allowed too, but only if it naturally happens while playing without infinite loops.
DrD2k9 wrote:
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.
Sounds like "max score" is simply the only sensible branch for this game, and the boost mode would be preferred indeed (unless it reduces your score).
Patashu wrote:
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!!
Well, we tend to skip all skippable cutscenes, and to speedup all cutscenes that can't be skipped, so using a slower mode to make things readable in real time would be something longplays do rather than speedruns.
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.
