Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
feos wrote:
DrD2k9 wrote:
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
Technickle wrote:
Hi supermanofky! I looked over your inputs. Here are some suggestions for you to implement:
My Setup:
Bizhawk 2.9.1
BSNES V115+
Profile = Tool-Assisted Speedruns
-----
Frames:
401 = Start
525 = Start
735 = Start
989 = Start
1050 = Start
1132 = Start
1337 = Start
Per User-to-User review, these are only suggestions and do not impact the official judgement from a judge
Actually even these can be improved:
Frames:
382 = Y - Clears Sunsoft Logo
506 = Y - Clears Blizzard Logo
Unfortunately the above improvements don't get to the Start press at frame 735 faster.
735 = Start - Starts game
987 = Y - Clears Cutscene
1045 = Y - Clears Cutscene
1124 = Y - Clears Cutscene
1328 = Y - Clears Level Title
This would all result in a 1,243 frame improvement just by the beginning point of Level 1. Unfortunately, this also results in a desync at the 2nd enemy, so these improvements can't simply be fixed for the submitted movie. Here's a movie file with the faster starting inputs.
That said, in judging the movie, I did some testing on various attack sequences and movement patterns. Here's some stuff I've found:
Flying yields faster horizontal movement and can sometimes allow for getting to a new destination quicker. For example, a brief flight between the first two enemies allows for attacking the 2nd enemy earlier.
The very first enemy is possible to kill faster by 2 hits then throwing it into the wall instead of using 4 hits.
At the screen scroll (when the arrow is flashing), Flying is faster than walking. In this file I was able to get to the second set of enemies 125 frames faster based on the appearance of the Eyegore enemy.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
KusogeMan wrote:
I think i might abuse this loophole in the future so if you keep the SRAM CLEAR and THE SRAM anchored movies both, prepare for trouble! I advise you to heed my warning
Exactly what is the point of this threat?
If it’s ultimately decided to have both types of runs accepted, it’s still only 2 standard publications for any given game:
1) most optimal base roster character
2) most optimal unlocked character
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
DigitalDuck wrote:
But then that leaves the question of whether a run that prioritises IGT over TAS time should obsolete, or exist in a separate branch from, one that prioritises TAS time over IGT.
While i believe there have been situations where different timing methods have obsoleted one another in the past, I don’t think this should be happening.
I feel that for any given game on our site, only one timing method should be the comparison point; without allowing various timing methods to obsolete each other.
Though even in typing this, I’m sure someone will have a arguable reason to allow it.
This is also slightly off-topic.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
feos wrote:
If the character is different and slower, that may be argued to be a harder mode/higher challenge.
This argument could be made for a different base roster character also. Would the slowest base roster character be considered a harder mode/higher challenge?
I feel this would potentially make things even more confusing.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
moozooh wrote:
I think there is somewhat of a contradiction over the fact that we'd only accept the most optimal default character for Standard while giving a "free pass" there to an unlocked one regardless of how fast it is in comparison. I mean, what if it's the slowest character? Or at least slower than the second-best default one?
I’ll use a reply to this question to submit my perspective here:
I don’t like any save-anchored run obsoleting a run based on a clean start.
I don’t see a point in having a save anchored run be slower than the clean run unless it introduces a significant amount of new/different content. I personally don’t see a different move set (from an unlocked fighter) as qualifying as significantly new/different content in terms of gameplay. So for fighting games, my perspective is as follows:
A clean start run can only be accepted to standard using the optimal base character.
A save anchored run using an unlocked character can only be accepted to standard if that unlocked character is faster than using the fastest base character. This would not obsolete but be published along side the clean start run.
If multiple unlockable characters are more optimal than any of the base roster, then only the most optimal unblocked character is eligible for standard publication as a save anchored movie. Unlockable characters can obsolete each other’s save anchored publications, but cannot obsolete the clean start run.
If no unlockable characters are faster than the fastest base character and no new content is introduced, then there’s no reason to have a save anchored branch in Standard publication for that fighting game.
The branch name needs to indicate that the run is save anchored without using the fighter’s name in order to prevent potential confusion that the site would accept all character runs.
I think my perspective rectifies the contradiction moozooh mentions about a “free pass” to unlocked characters.
As far as a name for save anchored branches:
“savegame” is good.
A similar option that may be even slightly more descriptive that the run is starting from a saved point is “save start” or “savestart” if we want to eliminate the space.
There’s also the option of using an icon to indicate that the run starts from a save anchored point. In staff chat, the classic disk icon that is used as a save icon in much software was suggested.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
" Samsara wrote:
As for the actual usage of it for TASing, my immediate reaction is to classify it under the same rules we use for language choice and emulation improvements: Using it is fine to decrease loading times, but deceased loading times won't count as improvements by themselves. Note that this is personal opinion only and not an official statement or ruling from the site as of yet.
Regarding the use of this device/system for creating cartridge format ROMs/images of games in order to shorten loading times: I offer this discussion/submission regarding doing a similar thing for Commodore 64 games.
In that case, it was decided to not be allowed. While I was originally the one suggesting the faster cartridge conversion approach, the discussion(s) helped to shift my own perspective/understanding regarding what should be acceptable for the site.
Because of this prior discussion, I am of the (current) opinion that this method should also be disallowed for ZXS. If staff/community, however, feels that it should be acceptable; then I think we need to revisit the possibility of C64 cartridge conversion being acceptable as well.
Even though my current opinion is to disallow, I can stand by a decision either direction so long as it’s consistent between the two systems (and possibly others that end up with a similar situation in the future).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
Almagnus1 wrote:
So some interesting developments have occurred within Tetris that have given rise to two possible categories:
1) Fastest to kill screen
I think option 1 would be better termed “Fastest Crash” because of the various game crashing bugs.
In my opinion, for something to be considered a kill screen, it needs to be:
1) consistent across all play throughs of the game and
2) not have when that endpoint/kill screen occurs be impacted by gameplay (at least from a human standpoint).
For example, the Duck Hunt kill screen of Level 0 is not beatable but a human (though it is by a TAS). Because that level will always been effectively unbeatable by a human in normal gameplay, it’s a kill screen.
Likewise, Pac-man’s kill screen is also always on the same level.
But with Tetris, because the crash can happen from various bugs, it’s not a consistent kill screen that would impact all players equally who reached a certain point in the game. Instead, when it occurs depends in the player’s actions.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
[5632] C64 Cosmic Combat "pacifist" by nymx in 04:02.40
This run a definitive example of the power of RNG manipulation. Without even moving the player’s ship or shooting a single enemy, nymx was able to constantly manipulate RNG through the run to cause all the enemy fighters to kill each other in order to progress through the game.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
feos wrote:
Please explain this text you enter and its legitimacy.
The RND command allows for manually adjusting an RNG seed on C64 without altering any game code.
In practice, it’s similar to adjusting/setting a real-time clock in order to pre-seed RNG.
EDIT:
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
Sand wrote:
How does the scoring work? It looks like you get points by flying close to the ground? And excess points earned in earlier stages can be applied to later stages?
The player’s score when hitting 30 miles or when the timer runs out must exceed the BONUS value in order to continue to the next level.
Flying low to the ground clips flags with the helicopter’s runners for more points.
This userfile still only contains input for 1 player.
Make sure that when you are exporting your TAS to an .fm2 file that you are selecting the 2 Players option.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
Oopla,
Overall, this is a solid run for a first submission, but I had some curiosities on potential improvements after watching through the run.
Specifically the following things I either suspect as areas where improvement is possible, or areas where I'd encourage testing if you haven't already. While not blatantly sub-optimal, these areas just drew my suspicion while watching through. Without actually fully testing all these myself, I can't claim they qualify as sub-optimal play and thus wouldn't outright prevent acceptance of the run.
Room at Frame 8438 - I suspect the last enemy may be able to be killed against the lowest section of ceiling to save some time exiting the room.
Room at Frame 8852 - I think its worth testing if switching the order of kills would be faster.
Room at Frame 11226 - I'm confident the sword enemy can be defeated quicker, you don't hit him before turning back left.
Room at Frame 13411 - I suspect the red guys can be attacked on the way up to the ceiling instead of just flying straight up there.
Room at Frame 15219 - Again, I suspect the red guys can be attacked on the way up to the ceiling, possibly going left first instead of right?
Room at Frame 15490 - May be faster to try going right first instead of Left?
Also, a significant chunk of time can be saved at the very end of the run. As TAS timing is based on the frame of final input, the last input needed to beat the game is actually on 18364 of this submission. Everything after that just adds unnecessary time to the run and should probably be cut (unless you REALLY want it in there from a stylistic perspective).
So...Which these options would you like to proceed with?
1) Have me judge the run as-is.
2) Have me truncate the run to frame 18364 then judge the run without other potential improvements.
3) Investigate the potential improvements yourself, and provide a userfile with any updates so that I can update the submission and finalize a judgment.
4) Have me do a detailed analysis of the entire run while implementing any improvements I can. Include me as co-author (assuming I find improvements) and allow another judge to judge the resulting run.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
Just as a note: while this is (rightfully) labeled as a “pacifist” run, it’s also a valid any% run as manipulating the enemies to kill each other is going to be faster than maneuvering around to shoot those same enemies (assuming the round duration is based on number of kills and not a set time).
nymx can correct me if I’m wrong on that point.
EDIT (because I’m an idiot and forgot to include it the first time around): My point being that this run should qualify for standard class if accepted.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
Technoturnovers wrote:
So, something I want to point out before this run inevitably gets canceled/rejected for, well, using a Game Genie code: strictly speaking, a Game Genie code can act as a form of romhack, and just like Wii homebrews will often implement themselves via Gecko codes, it's entirely possible to convert a Game Genie code into an ordinary romhack with an IPS patch. While this run doesn't do anything particularly interesting to merit an exception, I do think that categorically banning Game Genie codes is a bit unwise given that it does allow for interesting possibilities beyond just basic cheating.
Game Genie isn’t categorically banned from the site, it’s banned from Standard Class publications. If a run using a game genie code garners enough entertainment value, it may be publishable in Alternative Class.
Edit: Also we have this in the rules:
External codes are treated as ROM hacks if modifications are severe enough.
This modification via game genie likely wouldn’t qualify as severe enough to be considered a ROM hack.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
In general, do we not treat continues as undesirable regardless of system unless the continue provides for a special time saving technique such as the one used in The Legend of Zelda to sacrifice the life and resting to the start location/dungeon entrance?
In other words looking unfavorably on using continues to simply add more/infinite lives to a run in order to be able to keep dying until the end is reached instead of utilizing better/superhuman play to reach the end in a similar (though possibly slightly slower time).
Considering most arcade game continues are based on loss of lives—which in the arcade world is typically an indication of less than ideal play—most uses of arcade continues would be this situation of playing in a less than superhuman/ideal way and then utilizing the continue to keep going instead of just TASing better gameplay in the first place.
If there is a situation where an arcade continue provides for a special time-saving circumstance, that run could be an exception to a “No Continue” rule for arcade games (or any system for that matter).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
Heads up to any potential teammates: My time is limited, but I’ve typically enjoyed working on these.
I’m in.
Edit: CasualPokePlayer and I are teaming up.
