Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
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
(2088)
Joined: 8/21/2016
Posts: 1026
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
(2088)
Joined: 8/21/2016
Posts: 1026
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
(2088)
Joined: 8/21/2016
Posts: 1026
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
(2088)
Joined: 8/21/2016
Posts: 1026
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
(2088)
Joined: 8/21/2016
Posts: 1026
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
(2088)
Joined: 8/21/2016
Posts: 1026
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
(2088)
Joined: 8/21/2016
Posts: 1026
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
(2088)
Joined: 8/21/2016
Posts: 1026
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
(2088)
Joined: 8/21/2016
Posts: 1026
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
(2088)
Joined: 8/21/2016
Posts: 1026
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
(2088)
Joined: 8/21/2016
Posts: 1026
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
(2088)
Joined: 8/21/2016
Posts: 1026
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
(2088)
Joined: 8/21/2016
Posts: 1026
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. :)
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
How will this affect the completion times of currently published runs?
For example, Circus Caper requires a few inputs to progress through the end-game story after beating the final boss.
If the completion point is considered to be the last input needed to beat the final boss and start the end-game sequence, the completion time listed is incorrect.
If the completion point is considered to be the last input needed to finish the post-game story, the time is correct.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
Not yet...I have one other idea to test. If it doesn't work, then I'm going to give up on syncing this particular submission.
EDIT: As with ThunderAxe, I was able to create from scratch images that acquired the correct monster...however the run desyncs.
Here is the from-scratch image I created if anyone else wants to try re-syncing the inputs.
https://www.dropbox.com/s/u362n94dry060xx/TEST-CD.zip?dl=0
I may attempt to re-sync myself at some point in the future, but that's pretty low on my priority list at this point.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
I was invited via pm to join Truncated's team.
While I had originally planned to not join any specific team and instead just see who I would randomly be grouped with...seeing as I'm the only individual currently signed up and not yet on a team, I have changed my mind and have accepted the invitation.
So this serves as my confirmation of joining that team.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
The biggest problem I see is this: If someone uses a legit copy of the game and someone else uses a pirated/DRM-free copy of the game, how do you compare the resulting TAS? Especially if the DRM-containing run is longer only due to the DRM being present (loading times, etc).
The recent discussion about format conversions for C64 might be slightly applicable in this context too. Namely, that discussion resulted in the rules being clarified to only allow using formats of the game know to have been legally released unless those original formats cannot be obtained. This added to the previously existing rule that disallowed cracked versions of games unless no un-cracked version is obtainable.
For my opinions specifically on using pirated versions of games:
If the game was legally released in both DRM-free (GOG, Steam, etc) and DRM-containing (Disc, Floppy, etc) versions; either version is fair game for TASing and either can obsolete the other.
If the game was never released in a DRM-free version, a pirated/hacked version is only allowable if the original version containing the DRM isn't obtainable. (This is based on currently established rules regarding cracked/hacked games for other systems.)
If the un-pirated game is obtainable, pirated versions shouldn't be allowed simply to save time and/or increase compatibility due to a lack of otherwise intended DRM.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
I'm in for participating, don't have a team yet.
For anyone who ends up on my team...I'm unfortunately limited to 32-bit versions of BizHawk (namely 1.13.2 as of this message).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
I apologize if using the different FreeDOS and BIOS images made/make things difficult.
I had done a bunch of testing a while back while trying to get CD based games working on JPC-rr.
Some of that testing I held over, as I felt it was better to use an updated BIOS and FreeDOS image with linear mouse function (from a TASing perspective).
If these new(er) images need to be provided somewhere (assuming it's legal to do so). I can get them to whoever wants to post/host them.
Specifically for the FreeDOS image; I can't imagine trying to TAS anything (at least in c-square's click/drag modified JPC-RR 11.2) using accelerated mouse movement when linear is an option and the mouse pointer can typically cover the entire screen in any given frame. Even TASing in a different version of JPC-rr that doesn't have the click/drag support, moving a mouse pointer the same distance using linear vs. accelerated would simply require inputting a different (often larger) number into the mouse movement box for linear than it does for accelerated; but this wouldn't change the frame count that it took to move the mouse (at least in any game I've tried in JPC-rr).
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.