Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
When it comes to timing runs, TAS movies and RTA speedruns typically (but not always) use different timing conventions/rules.
As a general rule, our runs/publications are timed from power-on to final input. RTA timing rules can vary greatly from game to game. Many (if not most) don't start from power-on. Many have visual cues for end-of-timing as well, not the last necessary input.
Would it be worthwhile to have a site page dedicated to recording how our TAS runs would be timed using game-specific RTA rules (likely from speedrun.com and/or speeddemosarchive.com)?
For example:
NES Circus Caperhttp://tasvideos.org/3393M.html
TAS Time using TAS Rules = 7:03.75
Current (as of this post) HUMAN speedrun.com WR = 6:40
TAS Time using RTA Rules = 6:20.72
RTA Rules Link = https://www.speedrun.com/Circus_Caper
As can be seen for this particular game, the TAS timing rules result in a longer finish time than the RTA rules. This is not always the case, sometimes the RTA rules are longer than TAS rules timing.
What such a page would primarily accomplish is to highlight the comparisons of TAS vs Human ability (at least in regard to outright speed).
Not having the comparison, a quick glance makes it appear that the human RTA run is faster than the TAS run. Showing the TAS's time using RTA rules however clearly demonstrates that the TAS is in truth approximately 20 seconds faster than the current WR human run.
I'm willing to curate such a list if it would be considered a valuable resource.
So...what are your thoughts? If we do go for something like this, what should we title the page?
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Svimmer wrote:
From a scale from success to Charlie Sheen, I'd like to give this a very stocky "Winning!" This will directly improve the odds someone will want to TAS Alone in the Dark some day (a game I've been studying for years to run segmented: a TAS-only category is speculated to exist).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
There are a lot of games that no one cares to rate (regardless of platform). The overall low number of post-publication ratings across any game published on the site is testament to that. Even some of the most popular NES games, for example, have only 30-50 ratings, if that. That seems to me a very low number of ratings considering the member base we have here.
I mean no offense to those who actually do post-publication ratings with the following statements.
The number of ratings most published games receive (regardless of platform) appears to me to be connected to a game's general popularity not to the fact that it's been published, thus popular games get more ratings (even then very few, as mentioned above) and subsequently have more valid post-publication values.
It appears to me that the bulk of watchers simply aren't interested in doing post-publication rating (many probably aren't interested in pre-publication voting even). This again brings up the debate on whether pre or post publication entertainment feedback is more valid for determining tier.
So here are 2 proposed solutions:
1) Publish a run into a given tier based on its pre-publication feedback (which we pretty much do). Then have have some threshold number of post-publication ratings necessary (i'd recommend no fewer than 10) before a run can be promoted/demoted based on it's post-publication rating score. The threshold number needs to be high enough to ensure a sampling of more than 2-3 people's opinions. If the threshold is not met, it cannot be moved from its current tier. A low number of ratings alone shouldn't demote a run. Low interest is not equivalent to low entertainment.2)Publish all accepted runs into a 'holding tank.' They can then only be moved from the holding tank to the star/moon/vault tier once they achieve the required threshold of ratings. If a vault ineligible run results in low rating value after the threshold is met, it is simply purged from the holding tank and not moved to moons tier. I don't expect encoders/publishers to like this method as it may cause them more work, but it would eliminate the possibility of future low entertainment non-vaultable runs from erroneously being published in moons with no way to remove it from that tier.
EDIT: ok it may not completely eliminate the possibility of future low entertainment non-vaultable runs from erroneously being published in moons. But it should at least drastically minimize the possibility.
END EDIT
Side note 1: 2 questions:
Can non-members rate published runs? (allowing this may garner more ratings...or maybe it won't)
Why/how are anonymous ratings allowed?
Either all ratings should be anonymous (worse idea in my opinion) or all ratings should be attributed publicly to who made the rating (better idea in my opinion). There shouldn't be both options allowing some people to hide ratings behind anonymity. I'm not claiming they should be required to, but raters should be willing to defend their rating(s). This follows the same trend judges use with pre-publication voting (votes with forum explanations tend to hold more value than unexplained votes).
Side note 2: Kudos to Arc for actually taking the time to rate EVERYTHING post-publication!
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
I've run into the same QuickNES/NESHawk thing before too. When I asked about it, the response I received was something along the lines of the following:
QuickNES is set as default in BH because it's a bit faster emulation for casual playing of games, and the accuracy differences aren't likely to be drastic enough for a casual player to notice. Yet, even though it's a bit slower, NESHawk is the preferred core for TASing due to accuracy.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Regarding full completion: I know we tend to not consider RTA guidelines, but for reference...
speedrun.com/crystalcaves2#100 wrote:
Collect all items that award points in each level, including all hidden gems, all treasure chests, and all five B+O+N+U+S eggs (in the levels that have them), but NOT including the fruit that randomly appears.
There are no runs yet, so the above definition of "100%" is open for debate. (For instance, I did not include the "Perfect Health" bonus since that would prevent any damage boosting, though maybe it would still be interesting?)
Glitches are allowed. Use of XTRA, NEXT, and ZEUS cheat codes are NOT allowed.
Timing starts when you gain control of Mylo in the "Main Level", and ends when Mylo begins to exit the final level (for the exact frame, this is when the final door begins to open).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
feos wrote:
A couple questions while I'm checking optimality:
Does this game have any kind of full completion criterion?
At minimum, all colored gems (except hidden in-block ones) must be collected in each level. Then all levels must be marked as completed to get to the end game story/credits/HS table.
A theoretical 100% run could include getting all point items, killing all enemies, etc. This would not need to include the random fruit that pops up in various places.
feos wrote:
How much time does the OoB glitch save? So far doesn't sound like that'd be eligible to the fastest completion category.
The OOB glitch eliminates having to complete two levels by using a glitch to mark two of the levels complete without entering them....thus it'll save two levels worth of time. IIRC it's Levels 8 & 9 as internally numbered by the game. I don't know which of the two levels in this run are 8 & 9.
The glitch exists in all 3 Crystal Caves games (levels 8 & 9 in all three I believe) .
As the glitch allows for faster completion by negating the need to complete two levels, this should probably have the branch "all levels" or something similar to differentiate it from a true fastest completion run. (Though one doesn't exist...yet)
EDIT: As a note. The current publication of CC1 should probably also contain the branch note as it also doesn't use the OOB glitch.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Isn't there an exit to go through to complete the game? I think the pathway doesn't open up until all the treasures are in the trophy case thing inside the house. If I remember correctly, once the path opens, taking it leads to an endgame which is essentially the lead-in to Zork 2.
EDIT: With being able to buffer key-presses, this could be a really quick run. Also I think you can stack directions and commands.
Typing 'NW' will go Northwest
Typing 'N W' will go north then west. (it may require a comma between commands 'N, W' )
I believe you can even do room actions within a stream of direction commands.
'N W Pickup X E E S'
EDIT 2: I'd be willing to help if you want to collaborate.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Lil_Gecko wrote:
In Final Fantasy VII, you can swap disc during FMV to load the wrong one and shorten it a lot or even skip it. Since you swap between Disc 1, 2 and 3 of the same game, is it allowed to do so ?
It's not allowed to load the discs in the wrong order. See italicized portion below taken from the Movie Rules.
Movie Rules wrote:
The ROM image must be integral
It is not allowed to make use of images that are not intended to belong to the game being TASed. It is considered intended, if it is endorsed by the game or by its publisher (as an add-on, for example).
For games that consist of multiple images that are intended to be used in a specific order, inserting a new image is only allowed when the game explicitly prompts for it, and the intended order must be respected.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
The bigger question is 'can a marathon run include enough novelty to warrant a separate publication than individual runs of each game?'
It may.. given that in latter games have the paladin class character possibilities. But I don't know how much the gameplay differs with the different classes.
EDIT: Also, any marathon run or single game run which uses a saved character from a previous game will need to garner enough audience support for moon tier publication. Neither of those scenarios would be vault eligible.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Nach wrote:
Throughout the game there are many levels which have a single Starman block but a multitude of Continuous Starman blocks. If you play them quickly, you can be invincible throughout, while if you progress slowly, you have to fight with enemies.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
c-square wrote:
I agree, this is a special case where starting with the character from the previous game is a valid, and even encouraged, entry point to the game. As with any save game start TAS, it would require a verification movie. The bigger trick is somehow extracting the save file from the verification movie so you can use it (not an issue for a marathon run).
It's possible to dump a JPC drive's current status to a new disk image. So steps to extract the saved character to use in a TAS of the sequel game would be as follows.
1) Create a disk image for the first game.
2) Create a different disk image for the second game.
3) Mount both images in JPC at the same time.
4) Play through the first game to both get the saved character you want to export and create your verification movie.
5) Exit the game back to DOS within JPC
6) Copy the saved character file from game 1 drive to game 2 drive.
7) Dump game 2 drive into a new image that will now contain game 2 and the saved character from the game 1 verification movie.
8) Re-Assemble JPC mounting only the newly dumped game 2 image with the saved character and TAS as you would any game from scratch.
This should work for any game that stores the save information in a separate file.
Specifically for QFG: If you're wanting to continue this character all the way through the series, you have to repeat the above steps for each game; where the newly created game 2 image becomes the next game 1 image for each game transition.
Where this becomes difficult is for submitting movie files. For submissions, only the game image needed for the run should be mounted. Which means a verification movie shouldn't be submitted as a run because it's got multiple disk images mounted; one of which isn't necessary for the game being played (which is against rules/guidelines that say to only have necessary files).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
feos wrote:
The way I see it, any emulator configuration and hotkey should be banned during playing. In MAME I can simply erase all hotkeys that access emulator features, and when a TAS is played back that uses them, it desyncs. I only leave game controls enabled, and the run that uses only them works. Don't know how this is set up in dosbox, but we'll try to limit it in the same manner: config prior to tasing.
There are hotkeys for changing cycle speed in DOSBox. I think they're Ctrl+F11 and Ctrl+F12 for increasing/decreasing cycles. It's also possible to set cycle speed in the DOSBox config files.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
feos wrote:
Just letting you know guys, DOSBox inside libTAS has very high chance of being accepted for DOS TASing. And libTAS has input roll like in lsnes.
I saw that as well. And it'll likely open the door to many more games being TASable.
Still, JPC will remain a useful and viable option for those who can't/don't want to learn/use Linux just so they can TAS a DOS game.
A bit off topic, but I have a question on TASing DOSBox via libTAS...how are CPU speeds (DOSBox cycles) going to be regulated? With JPC, the CPU speed is set and unchangeable mid run. In DOSBox, cycles can be changed at any time.
If it helps....the approximation formula for converting between cycles and CPU clock speed is as follows:
DOSBox Cycles = 7.45(CPU clock speed in mHz)2
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Thank you for all your work that went into this! The DOS TASing community will benefit greatly from this.
I'm very much looking forward to trying this out next time I do some DOS TASing. Although it may be a while as I've got a number of other projects with a bit higher priority.
If I had any worthwhile programming ability, I'd gladly help with implementing all this into a new JPC version....but it's way beyond my understanding.
EDIT:
In case it happens to anyone else. Chrome is warning me that the download may be dangerous because it's not a commonly downloaded file (whatever that means).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
BrunoVisnadi wrote:
I'm not sure what you meant, but the goat's movement will be restricted by the fence itself. So you are looking for the ratio between the radius of these 2 circumferences, so that the blue area is equal to the red area.
Yep...that's what I'm not smart enough to figure out quickly...if the tether is anchored to a specific point on the fence (circle).
If the tether is not anchored to that specific point, but can freely slide around the circumference of the fence then blue and red are equal area this way.
My solution makes the assumption that the fence end of the tether isn't anchored to a set point. The other (probably proper) solution makes the assumption that the tether is anchored to the specific point on the fence.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
If the goat's tether can freely travel along the fence around the entire circumference of the field, the goat's tether length (T) can be solved with the following formula.
T=R/sqrt2
If the tether can't freely travel around the fence, then I'm not smart enough to figure it out quickly.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Warp wrote:
In my opinion, run timing should end on the last input to defeat the final boss; as all runs should be even timing through this epilogue portion (barring lag differences between emulators). The last input that impacts gameplay/timing differences is the last input for the final boss.
Just to avoid confusion: Are you talking about this one game in particular, or a more general rule of thumb?
My comment regarding the epilogue timing being equal for all runs was meant for this game specifically.
Regarding Generalities:
My opinion of when any game has been beaten is the last input that guarantees the game will progress to its end (credits, "the end", etc.), not the input that gets to the end. This I believe is a more accurate numerical value for how long it took to 'beat' a game.
My reason for this general opinion is that there may be current games (or potentially future games) that have multiple possible epilogues of varying length, and which epilogue that plays depends on in-game variables.
So in the hypothetical instance that there is a game with the above multiple-ending situation...the following could be a possibility:
--The game has two submissions awaiting judgement.
--Run-A has a longer game-play section than Run-B, meaning Run-B is the faster method of guaranteeing the game will get to the credits.
--The epilogue for Run-A, however, is significantly shorter than the epilogue for Run-B; resulting in Run-A getting to the credits sooner than in Run B.
--If those respective epilogue sequences require gamepad inputs to progress through, it's possible that the Run-A would be timed as shorter based on current submission timing.
--In my opinion, Run-B is the more impressive run from a speedy game-play standpoint because it is the faster method of guaranteeing the credits are reached even if it takes longer to actually reach those credits due to a longer epilogue input sequence. And thus, in my opinion, Run-B is the one which should be published, not the Run-A with shorter submission time. (This goes for all tiers including vault.)
The above hypothetical situation attempts to provide an example of why I feel it's so important to highlight the time required to guarantee progression to the credits as compared to the time required to get to them. So thank you, feos, for helping me get this process started even if it doesn't result in changes to official publication times.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Maintaining the current method of determining publication time is fine with me (and requires much lest work on just about everyone's part).
So...How about we (meaning me with some help) add the wiki page for time comparisons.
We could list current TAS run time and what the run time would be based on RTA convention timing.
Then IF we wanted to also add this time comparison to publications as a side note, we could simply print something along the lines of 'Run time using RTA timing convention = XX:XX:XX.XX'
The question at this point is, (when they differ) do we use SDA timing rules or the speedrun.com timing rules to determine the RTA timing method?
To be blunt...I personally rarely visit speeddemosarchive.com and look more to speedrun.com for record RTA runs.
So...anyone want to help me get this started? Once it's begun, I'd do what I could to update and maintain it myself.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
feos wrote:
I don't object to adding a textual note to every such publication, telling what time it gets if you stop it at the last frame of real gameplay. But clearly not to the point of adding a secondary movie to every such publication.
Not sure where to put all your research tho. If it's in this thread, the rule is always obviously visible, which helps people to get used to it. And the announcement already happened, so why not keep this discussion in one place? What about a wiki page?
I agree a secondary movie is unnecessary and would be a lot of extra (pointless) work. I would just suggest using the current input files to determine the 'new' final frame.
The question is which time is listed where?
1) Do we maintain the main publication time as the the final input to get to the end and add a text note of the alternate, shorter 'end-of-gameplay' time?
2) Or do we alter the main publication time as the input to guarantee progression to the end and make a note of the longer full-input time in the text?
I feel the main publication time is the one people look at from a 'beating the game' standpoint. I feel it should be the one to reflect when the gameplay is complete, not necessarily when the end credits are reached. For that reason, I think option 2 above is more appropriate way of indicating the main publication time.
I'm ok with a wiki page for comparisons....but I'd need help with formulating/maintaining that. I'm mostly wiki illiterate.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
feos wrote:
Having post-completion input inside the main movie is preferred, unless the author explicitly wants to exclude it. So no need for truncated versions.
I completely understand wanting the post-completion input provided in the submission from a publication standpoint...it's easier for the judges/publishers to do their jobs.
However, this topic does introduce the question of whether or not our published times are an accurate representation of how long it actually took a TAS to beat a game; at least in comparison to a human player (superhuman play is, frankly, a part of the whole point of this site).
Let's use the already mentioned Zelda TP as an example:
The current WR for RTA speedruners is 2h 56m 35s from file-select to final blow delivered to Gannon
The run awaiting publication stands at 2:44:46.77. Which includes both time from power-on to file-select and time after killing Gannon
While 12 minutes faster than human is impressive, if we knock the additional 11ish minutes off that number from when gannon is killed to the final trivial input, we end up with something closer to 2:34:00 which is even more impressive than humans. It's also a more accurate representation of how quickly the TAS actually beats the game.
I guess my point is that we need to reconsider when we qualify a game as having been beaten. Currently, the general rule is the last input necessary to get to the credits/game over screen.
Should we not reconsider this rule (if only for timing purposes) as something more along the lines of 'the last input necessary to guarantee the game will progress to the end with or without trivial progression inputs.'
I realize that this perspective borrows somewhat from the RTA community conceptually on when a game is beaten, but I also believe it's a more accurate representation of how long it actually takes to beat the game...especially for comparing against human-play.
TL;DR Having post-gameplay trivial inputs included in publication times, artificially increases the perceived time of play and misrepresents how superhuman that gameplay actually is.
FWIW I'd be willing to be the person to go through our library of publications and seek games that may warrant having their completion time adjusted based on this concept. It shouldn't be too difficult as the input files are already hosted and it would simply be a matter of redetermining the last necessary input to guarantee progression to the end.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Warp wrote:
DrD2k9 wrote:
For example, Circus Caper requires a few inputs to progress through the end-game story after beating the final boss.
"End-game story" sounds like part of the actual gameplay, rather than just ending credits.
Should the run end after the last boss is defeated, or right when the actual end credits (or whatever the game clearly considers an equivalent) is reached?
If there's some kind of epilogue (as seems to be the case in a minor form here), shouldn't it be played through normally?
Firstly, I don't see a difference between 'end-game story' and 'epilogue.' To me, that's semantics. The fact that inputs are necessary to progress from one screen to the next in this story/epilogue is trivial.
In my opinion, run timing should end on the last input to defeat the final boss; as all runs should be even timing through this epilogue portion (barring lag differences between emulators). The last input that impacts gameplay/timing differences is the last input for the final boss.
Also, there are no end credits, just a "The End" screen after the epilogue/story.
Here's a truncated version of the run that ends with the last input for the boss. Feos (or whoever) can do with this as they feel appropriate.
EDIT: The truncated file will save 599 frames off the publication time if the time is updated.
EDIT 2: It would be interesting to see how many other current publications have similar trivial inputs after the last necessary gameplay input has been accomplished.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
c-square wrote:
FYI, I'm getting close to completing an emulator upgrade that will make this a whole lot easier. I'm expecting to have it out by the end of the year. :)
My solution makes the assumption that the fence end of the tether isn't anchored to a set point. The other (probably proper) solution makes the assumption that the tether is anchored to the specific point on the fence.