Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
I’ve always been under the impression that April Fools submissions are meant to be taken as jokes on the day of 4/1. .
With the old site, it was arguably harder to get an April Fools submission published due to rules of acceptance at the time. Now that rules have loosened on what’s acceptable, more April Fools publications are indeed publishable. But the general joke side of April Fools submissions is about the submission on the day of, not about getting a joke run published on the day of.
Regarding publishing non-joke runs on April Fools Day: the content should make it obvious that things published on that day aren’t commonly joke publications. Is it worth it to skip publishing for a day (or two, due to time zones) to prevent non-joke publications from being taken incorrectly? Some may feel so, but I don’t think it’s necessary to delay publication of other runs.
TL:DR It’s the submission that’s meant to be the crux of the joke, not the publication.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
feos wrote:
The savegame branch would just be labeled "savegame" + whatever other standard goal it would have, if applicable. For for Mortal Kombat: Deadly Alliance it becomes "Arcade Mode" and "Arcade Mode, savegame".
Just a suggestion on inclusion of “savegame” as part of a branch name (for any genre): Have “savegame” always be the first part of the branch name as it’s the main differentiator for that particular branch. Then any additional branch name identifiers would follow.
So for the above example: Mortal Kombat: Deadly Alliance “savegame, arcade mode”
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Something else to consider learning/using is TAStudio (assuming you’re using BizHawk). It allows for placing specific inputs on any given frame of a run without having to use frame advance or recording mode. It’s a way to ensure perfect precision on when/where inputs are applied.
Using TAStudio should allow for always being able to utilize your combo regardless of how frame perfect the inputs need to be to accomplish it.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Just a quick addition to Spike’s comments.
Judging has become a bit looser recently and runs are now more likely to be accepted based on if they visually appear optimized. Judges aren’t going to overly scrutinize every frame of your submission. That said, we still desire highly optimized runs. So if a judge or someone else can easily beat your submission putting in little effort of their own, it shows that the run wasn’t very well optimized in the first place. In such a case, the run may be rejected or you may be asked to rework the run before it can be accepted.
TASing isn’t about getting as many runs submitted/published as quickly as possible, it’s about optimizing games. Take your time and don’t feel rushed to submit just because you finished TASing through a game once. I’ll reiterate what Spike said: take some time to review and polish your work before submitting.
Also consider utilizing the feedback avenues of the forums or the TAS feedback channel of the discord server to potentially get feedback on your runs before submission. While these aren’t guaranteed ways to prevent sub-optimal submissions, they can help.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Regarding the endpoint of this run:
The lives rollover creates a kill screen for this game, and we consider kill screens valid endpoints.
In aiming for a score attack (max score) run, our rules state “Infinite scoring loops that delay completion are not allowed.”
For this game, an extra life is gained every 2000 points.
Therefore, it’s possible to attain a higher score by dying to delay reaching the kill screen then scoring more points (including enough to gain extra lives). However, there is no limit to how many deaths/extra life cycles could occur. This creates an infinite scoring loop that only allows for increasing the score by delaying the kill screen completion; this breaking the current rule.
Therefore, the highest attainable dale score at the kill screen should be considered valid for a max score run of this game.
As an odd caveat for this game, deathless should also be a requirement because of the potential scoring loop.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
PLANET wrote:
…it was not ok to be even somewhat slightly harsh to a person here, now - not even the product of this person. What's next?
Feels like a poison of (political) correctness spreading further and further...
Why would you want to be harsh toward a person, especially over something like a TAS?
Being harshly critical of the TAS itself (because you don’t like it or because you feel it wasted your time to watch the run) can be tolerated.
But being harshly critical of the individual who created the TAS for those same reasons should not be tolerated (and I will fight for it to not be tolerated).
Your original comment of “Waste of time.” does not indicate that you felt that watching the run was a waste of your time and can thus be interpreted that you are claiming the author wasted their time in making the TAS and/or that the TAS’s existence itself has no value. Neither of these are true. The TAS itself can hold value to someone even if you personally don’t particularly find value in it. The time the author spent in TAS creation also holds value (in the author gaining TAS experience and simply having fun with the creative project) even if nobody else were to appreciate the work.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
KusogeMan wrote:
Yes, the player could some day improve this with SRAM unlocked chars, but then again why would the person do it?
Because they want to, and they want to see an SRAM backed/unlocked character's run published along side the baseline clear SRAM run.
It wouldn't be an improvement and the movie would already be published with slower characters, why go through the trouble?
True that it wouldn't be an improvement to the baseline (clear SRAM) branch. But again, it can still be published along side the baseline (clear SRAM) run.
It really seems to me that you fail to realize that both types of runs can be published simultaneously (if their respective branches are labeled appropriately). You also seem to argue that nobody will do SRAM anchored runs simply because a clear SRAM run already exists. While you personally may not see the value in having both types of run published, you cannot project that opinion onto everyone else in order to make blanket statements that no one will "go through the trouble" to make an SRAM anchored movie simply because a baseline run exists as already published.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
FWIW, a “maximum score” category for this game is possible by saving the maximum possible number of lemmings. It could potentially be labeled “maximum saves,” but that may be confusing just due to the use of the word ‘save’ for save games in regards to gaming in general.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
GJTASer2018 wrote:
We save the required number of lemmings in each level, but do not go out of the way to save any more, leading to lemmings dying to save time.
Sorry, but I don't consider this a "100% run" if you're not saving every lemming every time. If anything, I would consider this "any%" or "minimum required lemmings" run instead. Barring any evidence of glitches or bad game design making it impossible to do without cheats or hacking, saving every lemming every time should be part of the criteria for a "100% run" on a game like this.
To my knowledge it’s not possible to save 100% of the lemmings in any lemmings game.
Because each of the different rank/difficulties are separate play throughs of the 30 stages with different tools/restrictions, the fastest single playthrough of any one rank/difficulty would be the any % run for this game.
As this run competes play throughs on all 30 stages in all the difficulties, “all levels” would be a better branch name than 100%.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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:
