Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
OtakuTAS wrote:
Score attack/endless games must complete to game to where there is no new content.
It is no longer a hard requirement to complete all new content in endless games. We recently changed the rules to only require 1 loop of looping games even if there is new content beyond. Pertinent Rule:
https://tasvideos.org/MovieRules wrote:
If there's no clear ending, end after completing the first full game loop. However you may play further and end after any of the following:
All unique content (enemies, level layouts, game mechanics, etc.) is exhausted and completed.
The loop with the hardest in-game difficulty (enemy speed, AI, etc.) is completed.
In games with a score counter, you may end when you reach the maximum score the game allows.
In other words, there are multiple potential end points for looping games.
So the main thing to check with this particular game is how many courses are included in 1 loop of the game. Finishing all those courses would then be the minimum requirement for completion.
EDIT: Another consideration is, when the looping starts, the loop may not go all the way back to the first stage. A game may only loop later courses. For example:
Game A has 5 stages, begins looping after the 5th stage, and loops all 5 stages: 1-2-3-4-5-1-2-3-4-5-...
Game B has 5 stages, begins looping after the 5th stage, but only loops the 3rd-5th stage: 1-2-3-4-5-3-4-5-3-4-5-...
In both of these scenarios, only 5 stages would need completed to have the minimum required 1 loop. But for authors wanting to do one of the more complete options, runs completing more than 1 loop would be a different number of levels needing to be completed. If both games stopped adding new content after the 2nd loop, Then Game A would require completion of 10 stages to exhaust new content, while Game B would only require 8 Stages to do the same.
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
Regarding rerecord counts in submissions:
Spikestuff makes an excellent point regarding rerecord counts being used to validate/explain why a poor/high quality movie is poor/high quality. And this particular use of rerecord counts (assuming they are accurate in the first place) is a very valid reason to (at minimum) maintain keeping the rerecord count in emulator input files.
Yet, I'm inclined to agree more with feos regarding listing of rerecord counts; in that we limit publication of rerecord count only to movies where the author explicitly requests it.
Specifically, listing rerecord count in submissions provides potential viewers an opportunity to pre-determine whether or not they think a submission will be of poor or high quality. This anticipated quality level may then bias their actual viewing of the run and cause them to deem the run either as having more/less quality than they would otherwise have done had they not started with a preconceived expectation. This could occur in a couple different ways depending on what the initial expectation is.
1) RR count is low and quality is assumed poor by the prospective viewer; who then deems a truly poor quality run as even worse than they would have otherwise, or a good quality as significantly higher than they would have otherwise because it significantly exceeded their expectation. Beyond this, it's also possible that a low rerecord count may bias a potential viewer's expectations so severely that they may choose not to even watch a run that they may otherwise enjoy and/or be impressed by.
2) RR count is high and quality is assumed good by the prospective viewer; who then deems a truly good quality run as even better than they would have otherwise, or a poor quality as downright awful because it didn't come close to their expectation.
Bottom line, rerecord counts should never be used to set one's expectations for a submission. They should ONLY be used, as mentioned above, to explain why a movie is the quality that it is. Rerecord count alone should never be used as a reason to NOT watch a movie.Regarding inclusion of rerecord counts on official publication encodes:
As published runs have already been deemed of high-enough quality to be published in the first place, including the rerecord count here doesn't really serve much purpose, in my opinion. I can't really see any particular pro to having it listed in the encode. I can however see some potential cons:
1) A high/very high rerecord count may potentially detract other TASers from trying to beat the current publication. This could theoretically limit discoveries from being found because no-one looked into the game further.
2) A low rerecord count may unfortunately dupe a TASer (particularly newer TASers) into thinking that not much work was needed for a current publication and that they may be able to beat it easily. Then when they actually get into the process of TASing the game, they become discouraged for not being able to beat something they expected would be easy to beat.
3) Having rerecord count listed on publications provides for a method of competition that really shouldn't be a method of competition on our site. Some TASers may want to have the highest count, others may want to have the lowest. I recall someone a while ago in the discord server effectively boasting about making a TAS with legitimately zero rerecords because they seemed to think that was something to be proud about. (Not that there's anything wrong with being proud of any legitimate accomplishment, but it was a perfect example of the wrong view of our site). Our site is based primarily on optimization quality with a secondary emphasis on entertainment...not on how simply/complexly one achieves that goal.
Regarding rerecord counts in general:
I primarily don't put much stock in the values presented due to issues of accuracy/tracking including (but not limited to): emulator crashes, using multiple project files instead of branches within one project file, and manual editing ability of the input file itself.
A rerecord count is only truly comparable to another when it's regarding the same game, and then only when both movies are being authored by TASers who hold equal knowledge of the game prior to starting the construction of the TAS. Any difference in knowledge will impact what one TASer does over the other and may result in more/less rerecords due to said knowledge. The discrepancy between rerecord counts then wouldn't be a fair comparison of actual work put into the TAS.
Comparing rerecord counts of one game to another makes no sense whatsoever. For one game, 10,000 rerecords may be quite a lot; while for a different game, 100,000 rerecords may be miniscule.
Low rerecord counts don't mean poor quality. If a game is simple enough to understand from an optimization standpoint, it may not take many rerecords to produce a truly optimized run (Duck Hunt: Game A). Likewise, high rerecord counts don't mean high quality, they just mean stuff changed a lot. It's absolutely possible to spend thousands upon thousands of rerecords optimizing a sub-optimal route.
All this shows, in my opinion, that the value presented by rerecord count only holds true meaning after a movie has already been watched. And only then as a data point aiding in clarification on why the resulting movie is the quality that it is. For this reason, I feel that if someone truly feels they need to know the rerecord count before watching a run, the impetus should be on them to look it up from the input file. We shouldn't blatantly provide it ahead of time.
TL:DR I agree with feos. Going forward, we should eliminate public display of rerecord count on submissions and publications' encodes unless explicitly requested by the author in their submission notes. I don't feel it's necessary to retroactively change all current/obsolete publications (not that we couldn't...someone may just be really bored someday and want something to do).
All that said: If rerecord counts are maintained, given the inherent issues I have with the statistic, I see no good reason to continue truncating botted rerecord counts. To me, a rerecord is a rerecord regardless of how that change was produced. So if we are going to keep them around. I feel we should stop automatically reducing botted runs to 0 rerecords (or any other arbitrary number just because that's what the author believes they did manually).
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
WhiteHat94 wrote:
Gryzor (Contra). Port of the arcade version. I used spread the whole run but I think Laser is potentially faster, tho you would need to be much more precise with it. I abuse deaths in the final stage cause it seems much faster than fighting the bosses.
RTA run - https://www.youtube.com/watch?v=_VwI449-JaI
I started a TAS of this a while back. And IIRC, I was using laser. I might need to go dig that out again.
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
Nice work with the improvements so far. I still think there's more potential, so I'm going to go ahead and set this submission status to "Delayed" and see if I can't help more directly with further input improvements. If I can find more, I'll un-claim this for judging.
I'll see if I can find you on discord and touch base.
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
enderpal7.
I've come across a couple details that will improve this run. None of them, at this point, would result in rejection. But I wanted to check with you and see if you wanted to implement these things before this submission is fully judged.
Specifically:
1) You can start the game 5 frames earlier (on frame 352) and clear the intro text faster (on frame 375). This will get into the first stage faster.
2) As you've already mentioned in the submission notes, killing unnecessary enemies adds time to the run due to the end-stage score tally. You kill an unnecessary enemy in stage 1. This can be removed and improve the time.
3) It's not intuitive, but in the Space-Shooter stages shooting actually delays the end of the stage. I'm not sure exactly why this is the case, but I'm guessing that shooting somehow affects the game's autoscroll code. So I'd recommend eliminating all shooting in these stages (except the final one which obviously require shots at the end to finish).
4) There are also a couple places where movement optimization can be improved (jumping over one of the volcanoes in stage 2 for example).
Unfortunately, changing the above stuff will impact movement sync so some movement improvements may not still be valid after resyncing. Hitboxes are weird in this game.
Just let me know if you want to update the run before it's judged, or if you want it judged as is.
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
signupredir26,
What is the primary goal of this run?
Is there something about this that is meant to distinguish it from our current publications as a different branch/goal other than just beating the game?
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
It would ultimately depend on how the game is coded and how the answers are stored in that code. Some games do have the answers directly coded in with hex values being equivalent to a specifical letter in the alphabet. But to my knowledge there's no generalization of this practice for similar games.
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
Review/Snipe:
I was able to get this to sync with ROM Venice Beach Volleyball (AVE) [!].nes which is the same hash.
While this run does beat the games of volleyball quicly by serving only ace serves, unfortunately, I was able to find a much faster way to do this than what is presented in this submission.
Instead of serving on the last possible frame, if one serves on the first possible frame, an ace serve occurs as well.
I have submitted a run of this improvement.
I'm sorry, ShesChardcore. I'd recommend cancelling this submission.
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
Review:
I couldn't find a ROM that matched the SHA1 hash in the .bk2 0B6D75BCC99D34A42CD58558CB555C6A80ACC263, but the run still syncs on one with this hash EE3603417CCB2058866B6C16396503609EF272AE. (headerless hash = A017A0A0AEE71FEA7BCFCB5D889E710516AB330C)
I couldn't find any further improvements.
This run looks solid and is an improvement over the current publication.
Summary
I have had a number of instances where TASing using the C64 core results in desyncs after TASing a while and then clearing greenzone. Specifically, I'll load/run a game and begin TASing. Then after clearing greenzone the game will load in differently causing a desync for inputs beyond the loading process. I'm wondering if this has to do with changes in input during loading and/or savestates during loading affecting the Loading process of the games, but I don't know how to describe much beyond this.
I can say that nearly every time I've had this occur, the loading time after clearing the greenzone appearss to be faster, but not always.
I've only ever TASed in BizHawk using TAStudio, so I don't know if anyone donig classic frameadvance TASing would also experience this issue.
In discussing with NYMX, he has also seen this issue.
I probably should have reported this issue before, but wasn't sure exactly how to describe it. I'm not even sure what I have described is enough for the devs to go on.
Repro
I unfortunately don't have a way to definitively reproduce this bug. Soemtimes it happens, sometimes it doesn't.
Output
There are no error codes associated with this bug.
Host env.
-I've had the issue with multiple host computers from different manufacturers (MSI, Dell, HP) with both AMD and Intel processors.
-I've seen this issue over multiple versions of BizHawk. I'm fairly confident I've seen as far back as version 2.0, but I can't remember exactly when I first encountered it to know if I also saw the issue in 1.x.x versions.
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
I personally don't see a problem with resetting the FRAMES variable usign this POKE command in either ZXS or C64 runs/TASes.
To me, this is akin to pre-setting the RTC clock on other systems in order to manipulate RNG--which we currently allow (DOS, some handhelds, etc).
The key to allowing something like this for C64 and ZXS, in my opinion, is that the POKE command must be performedbefore the LOAD command. If it was done after the LOAD but before a RUN command on C64 (and possibly ZXS, as I'm not as familiar with that system), the POKE could potentially modify what the game has written to RAM, which would be more like cheating as the game is already (at least in part) loaded into memory.
Therefore, (theoretically) any RAM location could be manipulated by a POKE command prior to loading a game. When the game loads it will either overwrite whatever data is in RAM or ignore it. Any leftover/ignored RAM not specifically set by the game could theoretically be any value, and thus fair game for pre-load manipulation.
A pre-load POKE command wouldn't modify the game in any way but simply change pre-load RAM status. If the game reads any of this pre-load RAM information, I see no reason why such modification of that RAM shouldn't be allowed. Ultimately, the site staff will have to make this decision though.
FWIW, the console verification of my Gameboy Donkey Kong run required a separeate program to be run first to initialize the RAM (that's not directly initialized by the game) to a specific value to allow RNG to match what was created in BizHawk. Off the top of my head, I cant currently remember if BizHawk pre-initializes all RAM values to 0xFF or 0x00, but the initial RNG seed for Donkey Kong is pulled from a region of RAM not initialized by the game itself--which could be any value on a real system. The separate program just made it match BizHawk for console verification reasons.
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
GJTASer2018 wrote:
"Plexar was here" - I wonder who or what this "Plexar" is. None of the sources you used seem to mention that message, and neither does the Digit Press database. GameFAQs shows part of the message in their image gallery on the game, but no one seems to have asked about it there.
Even trying to look at the archive of GameWinners doesn't seem to yield anything. Do you have any idea what this message is about?
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
Precedent regarding not using level select codes from the Movie Rules before they were simplified:
No skipping to the end with a password
The point is to demonstrate how quickly a game could be beaten if the player had superhuman abilities; skipping major sections of it with a password defeats the purpose.
Granted, humans can use level select passwords/cheat codes...so does TASing with these options simply show superhuman ability of using those options?
Personally, I don't think intended level select methods should be allowed in most cases (this one included), but ultimately the staff/judges will have to make a decision on this one. Now if a glitch were abused to skip the levels, that's a different situation.
For what it's worth: this run, as presented, looks pretty decent at a cursory glance and is relatively entertaining. If the judge/staff decide the level skip is acceptable, I don't readily see any other reason to reject this submission.
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
feos wrote:
But we can still have guidelines on what is most likely a videogame, and what is most likely not. For example, a videogame requires repeated player input to advance. It also has some kind of gameplay, usually posing a challenge, a way to lose and to win. What else?
Just a brief comment on winning/losing: some games (a number of adventure games, for example) cannot actually be lost, aside from the player just giving up because they can't figure out how to win.
That said, the vast majority of applications qualifying as "games" would still retain some sort of win condition (assuming one accepts our site's derived win conditions for looping games).
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
Firstly, I want to say that I've been waiting for a full TAS of this game for a while now, and had even considered attacking it myself.
Review:
Syncs on FCEUX 2.2.3 (yea I should probably upgrade this sometime soon).
Desyncs on BizHawk when converted to .bk2 - Even when adjusting the first few inputs to get the first stage starting correctly, desync occurs by the end of the first stage.
I'd be concerned that trying to fuly re-sync this for bizhawk may be a major challenge with RNG manipulation.
Full transparency, I did not watch the entire run at normal speed, I watched it completely at turbo-speed. From what I saw, the run looks pretty solid overall.
Regarding optimization: Since the game limits the collapse of buildings to one-at-a-time, optimization is effectively going to be limited to getting the first building falling as fast as possible, then attacking the remainign buildings to be ready to collapse by the time the first (or previous) is done collapsing. A cursory viewing seems to demonstrate that this is accomplished on most, if not all, levels.
For anyone familiar with casual play of this game, it will be immediately noticalble how little damage is taken. This aspect of the TAS alone makes it superhuman.
The only improvement I can imagine would be finding a stage where it may be possible to get a different building collapsing earlier. Unfortunately, I anticipate that this would affect RNG and require full redo of everything beyond that stage. If I have time before a judge ultimately decides on this submission, I may look into going through stage-by-stage and seeing if I can get differnt buildings toppling earlier, but I'm pretty limited on time right now.
One other possiblity for improving the run might be adding the 2nd player. Normally speaking, a 2nd player wouldn't speed anything up in regards to toppling buildings due to the on-at-a-time building collapse rule. However, if there are stages where Player 2 can get a building toppling faster than Player 1 can due to proximity of the building to the right hand side of the screen, it would yield a faster overall TAS. This would obviously require a complete redo of the game using 2 players. OR, if it would be acceptable, use the "join a game in-progress" feature to use this run as a base and join the 2nd player in just before the first stage where the first right hand building collapse would be faster. Personnally, I think just starting with 2 players would be the better/more impressive option.
I may do a more in-depth review of optimization of 1st builidings later on if I'm able. I may also consider doing a 2-player run myself someday.
I would have made a temp enocde if I could have gotten a bizhawk sync, but I couldn't. And I always seem to get crappy audio when dumping temp encodes from FCEUX, and I don't have time to troubleshoot that right now.
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
feos wrote:
I wonder if there are other icon options, something more default (but no less important).
What about a D-pad or joystick? They're pretty standard for most video games (with some exceptions like PC mouse/keyboard), as being able to actually control one's video game is pretty important.
Added benefit of not being associated with any one particular game/series.
We'd then have:
A D-Pad for standard goals
A music box for alternate (artsy) goals
A star for the special runs as they already signify
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
andypanther wrote:
Would it really be too much to ask if we required these types of submissions to work with nothing more than the unmodified game,...
If the primary purpose of these types of runs were to be submissions on the site, then that would be a restriction worth considering (though we already allow runs of ROM hacks, which are essentially modified games). It would also make sense to require full adherence to the current site rules, IF the primary intent was submission.
But, while this run has now been submitted, the primary purpose of its creation wasn't to submit to tasvideos.org.
It was first and foremost created to be presented live as a form of entertainment, art, and TAS showcase.
The perspectives against having these kind of runs allowable on the site seem, to me, to center around the issue of treating them as if they were any other typical submission that was created for the primary purpose of being submitted to the site.
We must realize that these aren't typical submissions. They shouldn't be judged via the typical judging process. Nor should they get a typical publication as with the main runs on our site. But none of this means that we can't/shouldn't somehow acknowledge these runs and the awareness/promotion they provide to the TASing community. They need a place somewhere on our site.
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
TASBot showcases at various live events has been a major, if not the biggest (YouTube itself may be bigger), contributing factor of exposure for both 1) the hobby of TASing and 2) our site to the general public as well as to other speedrunning communities.
I find it absurd that one of our greatest exposures has been effectively prevented from having some aspect of inclusion on the site directly.
I, myself, would likely have never gotten into TASing without having seen dwangoAC and TASBot promoting both the hobby and the site.
Can such showcases exist within our current publication model? Obviously, no. The reasons have already been well explained. And I agree in that they shouldn't be housed simply mixed in amongst the normal movies/publications on the site.
But this doesn't mean we can't create a special space for these showcases (gruefood delight is not adequate). If we do create a special part of the site to house such runs/events, it could/should be CLEARLY noted on that page that these runs don't follow normal site rules and aren't judged as normal submissions are. That note should further include that these runs inclusion on the site is due to the awareness that such runs bring to the TASing community as a whole and to the extents of what TASing is capable of accomplishing.
These showcases are TASes. They are Tool Assisted Superplays. Even when human interaction is also required, the results still require TAS inputs.
Are they speedruns? Not always. Are they superplays? Typically. Do they promote TASing as a hobby? ABSOLUTELY! And they often promote our site directly.
At bare minimum, i feel we should have a highlighted wiki page that at least links to the videos of the original runs/events.
As a response to the idea that our site is solely for hosting entertaining TASes and world record TASes: if this is truly the case, then we should eliminate things like player profiles, player points, or anything else that's not strictly necessary to host entertaining TASes and world records. These live TASing showcases are no less valuable than player profiles. On the contrary, they are arguably more valuable to the site as a whole than player profiles or player points.
Adding these showcases (with the appropriate notes mentioned above) doesn't take away from the site's goals of hosting input files for world records and entertaining TASes, nor does it lessen the value of those goals and the accomplishments of the movies that we publish through our normal publication methods.
Having these showcases wouldn't suddenly make our site NOT the site that houses TASing records and entertaining TASes, nor would they suddenly become the major purpose for visiting our site.
Adding these showcases does, however, allow our site to officially recognize the promotion these TASes provide for our hobby.
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
Just posting to voice my support of accepting board games to Standard.
I've never liked the claim that a board game on a console/pc isn't considered a "real" video game effectively because it began its existence (or is also available) in a non-video format. It's a game being played on a video screen that uses inputs in the same ways as nearly all other video games. That alone makes it a video game in my opinion. They can also be TASed like any other game, and they often have potential for optimization (i.e. through RNG manipulation as mentioned in posts above).
Another consideration: many puzzle games (like Boxxle), that are already accepted, could easily be converted to physical materials and played on a board on a tabletop as a board game. Would those have been unacceptable if the board game version had existed first?
The one caveat i would add regarding potentially accepting board games, is that competitive board games should require at least one computer/ai opponent to be acceptable in Standard.
TASes of competitive board games that only use "human" players should need to meet community consensus for acceptance to Moons/Alternatives. Otherwise Playground could be considered as a possible landing spot before outright rejection.
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
To avoid two-word names we could just pluralize and use
Standards
Alternates (or Alternatives)
Then in judgements the language "Accepted to Standards" or "Accepted to Alternates/Alternatives" could be used.
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
As NYMX mentioned, I had been discussing with him that I was under the impression that exhausing all difficulty increases was no longer strictly required for looping games, so long as new content was not being introduced as the method of increasing the difficulty (i.e. speed increase as the only difficulty increase). I would have sworn that I remember seeing a disucssion about this somewhere, but for the life of me, I can't find it now. I had also mentioned that I was under the impression (again from that discussion that I can't find at the moment), that longer runs which showcased more of the harder dififculty loops would be preferred over shorter runs of fewer loops when such runs came under consideration for obsoletion. But I was still under the impression that a singular loop of a game would be sufficient if no new content were introduced thereafter. I had also shared with Spikestuff that this was my understanding of site policy for loopign games.
Here is the rule as it's currently are written:
If there's no clear ending, end after all unique content (enemies, level layouts, game mechanics, etc.) is exhausted.
-Alternately, after completing all unique content, you may end when the in-game difficulty (enemy speed, AI, etc.) stops increasing.
The way I read this; the first line states that exhausting unique content is the minimial end point for looping games. The second line allows for (but does not require) continuing farther onward through all difficulty increases.
These are the basis for my understanding of the policy on looping games, and also the reasons I believe that one loop may be sufficient for a game like this one.
FWIW, I will be performing a formal review of this run as-is. I'll update this post with that review once I complete that review.REVIEW:
I was able to sync the run.
Optimization looks solid; I wasn't easily able to find any improvements.
Completely theoretical improvements:
1) Forest Stage - IF the vine swings could be better manipulated, this stage may be improvable.
2) River Stage - There are two types of crocodiles (standard and rogue). Multiple standard crocs can be on-screen at one time with their spawns being separated by 64 frames on a count-down timer stored at RAM address 0x64. Only one rogue croc will be on-screen at any one time. Having a rogue croc on-screen prevents standard ones from spawning even if the timer hits zero. So IF it were possible prevent rogue crocs from spawing and yield only groups of standard crocs, it would be possible to clear the necessary 14 crocodiles faster. I was not able to readily deduce how the game determines when to spawn a rogue instead of standard. (I tried using trace-logger to no avail).
3) Boulder Field - There are a couple large boulders that Winslinator ducks underneath instead of jumping over. Ducking stops horizontal leftward movement slightly delaying progress. While it is possible to jump over the first of these two large boulders (pressing UP while jumping in this stage increases Dashly's jump height slightly) and maintain forward momentum, I was not able to jump the second without manually delaying movement anyway. So waiting to duck for this second large boulder effectively eliminated the savings made by high-jumping the first. I didn't dig in to see if the boulder sequence is predetermined or if it's RNG, but IIRC it is RNG based in other ports of the game. So IF it's also RNG based in this version, it may be possible to manipulate boulders in such a way that could yield a sequence where no ducking was necessary; this would save a few frames.
Thoughts on difficulty:
1) The game's manual allows for staring on two different difficulties; this run uses the harder. The manual also mentions that the difficulty increases in subsequent loops after rescuing Lady P, but does not specifically describe HOW the difficulty increases.
2) In other ports, a monkey is added to the Forest stage. The monkey climbs on vines and can knock Dashly off a vine, thus making that stage more difficult. This port does not contain the monkey.
3) The gators do increase speed on the loop immediately following this run, but their speed doesn't seem to increase further with subsequent loops. (The loop number is stored in RAM address 0x0B, and selecting the harder difficulty at the start simply increases this from 0 to 1, effectively making this run's starting loop what would normally be the second loop if starting on easiest difficulty).
4) In the Boulder stage, the boulders do seem to bounce slightly different heights when poking different values into the adress that holds the Loop #, but this is mitigated by holding UP on the jumps. The sequence of boulders was otherwise unchanged, and thus is either pre-programmed or based on RNG values from earlier in the game.
5) I did not note any differences in the Cannibal stage regardless of what values I was poking into the Loop # address.
SO....thoughts on difficulty while also considering my comments above this review: I believe 1 loop of this game is sufficient to satisfy the rule requirement of exhausting new content. That being said, it would require only one more loop of play to also exhaust difficulty increases of this otherwise never-ending game (the loop counter resets to 0 after 255). Therefore, while I feel this submission is acceptable as-is, I'd strongly encourage Winslinator to revisit this run and complete the 2nd loop so as to also exhaust difficulty increases.
Editor, Experienced Forum User, Judge, Published Author, Skilled player
(1830)
Joined: 8/21/2016
Posts: 945
Location: US
For now, I only have a comment on number 3:
I don't think we should accept SRAM that isn't obtainable through normal/TAS play (i.e. via hex editing in max stats that wouldn't be obtainable otherwise).
While I understand the argument (and potential time benefit to the author) of being able to manually create an SRAM file that would be possible to achieve through normal play, I personally feel that we should still restrict SRAM anchored movies to provide verification movies.
I realize this may require more work from the author's position, but it would simplify judging. If a judge has the verification movie inputs, it's more readily determinable that the utilized SRAM is legitimate. If, however, verification inputs are not provided/unknown, the judge would then be tasked with first verifying the legitimacy of the SRAM before consideration of the submission in question could even begin.
Much like Samsara, I tend to lean toward a wider acceptance of runs for publication, but there does have to be a line somewhere.
Hypothetical example; if i hex edit a savegame file for a DOS game to provide an longer than legitimately achievable invulnerability time, I could breeze through a game much faster than without that ability.
So if i provide a run that has that savegame situation without any verification inputs, the judge would first have to determine if that ability is achievable normally before they can even start judging the run submitted.
Even if someone provides a manually created SRAM while claiming it's indeed possible to yield that save information via real play, it still falls to the judge to verify that claim if there is no verification movie.
TL:DR In my opinion, SRAM should only be accepted with verification movies provided that create said SRAM state. The impetus for proving legit SRAM should be on the author, not on the judges.
