Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
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
(2081)
Joined: 8/21/2016
Posts: 1018
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
(2081)
Joined: 8/21/2016
Posts: 1018
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
(2081)
Joined: 8/21/2016
Posts: 1018
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
(2081)
Joined: 8/21/2016
Posts: 1018
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
(2081)
Joined: 8/21/2016
Posts: 1018
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
(2081)
Joined: 8/21/2016
Posts: 1018
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
(2081)
Joined: 8/21/2016
Posts: 1018
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
(2081)
Joined: 8/21/2016
Posts: 1018
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
(2081)
Joined: 8/21/2016
Posts: 1018
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
(2081)
Joined: 8/21/2016
Posts: 1018
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
(2081)
Joined: 8/21/2016
Posts: 1018
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
(2081)
Joined: 8/21/2016
Posts: 1018
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).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
Radiant wrote:
I suppose you've tried this; just to check: killing the giant with the sling may be faster than waiting for him to fall asleep? And climbing down the beanstalk may be faster than using the stairs. An odd detail in the run is that the screen shaking (when you fall) is so slow; I suppose that's because it waits for vsync whereas nothing else in the engine does.
I eliminated killing the giant from my routing plans simply because of all the extra screen transitions it requires. Specifically going out of the way to get the pebbles by the beach, then out of the way again to to get the sling before returning to the giant to kill him. I did not test this option, as I felt all the extra travel would add time (perhaps I should have tested it).
Routing was also the reason I went up the beanstalk instead of the cave climb. There are simply more screen transitions to use the cave going upward (and more distance traveled on those screens for the cave as well).
As far as coming down the beanstalk...from the giant, the cave is closer than the top of the beanstalk; and the bottom of the cave is much closer to the castle. So while the beanstalk is faster routing going up, it's slower routing going down.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
fsvgm777 wrote:
Can you tell us where you got your FreeDOS image from? Its ID doesn't match with the imported image that came with the JPC source (yours is 45c3f118cbca79f176307142c73f780c, the imported one from the JPC source is f334bc4d5dc5f393feb0ca2d1e1cdc25 (which you have used in the past, mind you)). In fact, it doesn't even match with the imported 1.2 image (b47e30f0d3574d8be004742104ada494).
The only thing I can think of is that my FreeDOS is a slightly modified version of the one with the JPC source. I edited the autoexec.bat to automatically load the mouse into linear mode instead of accelerated (this makes TASing mouse based games much easier). I then extracted the resulting drive to a new image.
I can get you a copy of the image if you like.
Side note: The input event stream syncs with both of these version of FreeDOS.
Dacicus wrote:
Some questions that didn't affect my vote:
Does the ending song freeze or something? It's a well-known tune that I'm too lazy to look up, but it doesn't seem to actually reach the end.
Is the RNG in the cave for a dwarf or an elf?
I have no idea why the ending music froze. Bad movie dump maybe? I'll re-dump to see if this is the case.
I had done a quick TAS using debug mode as joke for the RTA community. The end music played fine on that one.
According to the game logic files, it's a dwarf in the cave.
£e Nécroyeur wrote:
The music does freeze. The song is "Greensleeves".
DrD2k9, does the game freeze at this point, or is it only the music? Is it still possible to clear the credits dialog box after the music has frozen?
If a new dump doesn't clear the problem, I'll have to do some checking on whether or not the credits can be cleared after the music freeze.
As a side note: The credit's message can be cleared immediately upon showing up....however this results in just seeing the newly crowned King Graham sitting on his throne while the music plays.
In my opinion, the TAS should end on the last input to get to the credits message, not on the input to clear those credits.
MAJOR EDIT:
I realized that typing "fast" to change the game-speed is actually faster than using the menu. Unfortunately this happens at the very beginning of the run. This required a complete redo of the run.
Here is a link to the new movie file. Someone with the power, please update the submission.
Notes on the new run:
As the mouse isn't needed, I used the stock FreeDos image instead of the modified one. I also bypassed the Autoexec.bat and fdconfig.sys files on boot.
The submission text has been updated to detail changes.
Regarding the concerns addressed earlier in this post:
The game did indeed freeze on a re-dump of the original submission. Clearing the credits wasn't possible.
I've confirmed that this new movie does have normal music through the end, and the credits could be cleared after the music ended.
Though I did not test the event stream of the new run on both FreeDOS images, I'm guessing it would sync on either as it did before.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
Radiant wrote:
For this game in particular, please consider a 100% run as well because (unlike most of their later games) KQ1 is pretty elaborate in allowing multiple different solutions on most puzzles.
I'm all for doing the 100% run. That said....I could really use some help with routing it.
RNG may not be quite as easy to manipulate on this one. Unlike SQ1, this game doesn't have the option to type "Y" to advance the random seed. Screen scrolling would work, but would be a slightly slower than "Y" was in SQ.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
feos wrote:
Requiring devices that don't normally come with the console or the computer in question, nor with their games, and aren't even among common peripherals for casual use, sounds like using a devkit version of the system or the game: arbitrary requirement that one is not supposed to have to simply play those games. It's a shaky ground, and it might sound simple for simple systems, but with modern ones that support tons of peripheral types and approaches, it will drive us crazy if we allow arbitrary addons.
This perspective makes sense. Also, I had a brief, but good discussion with someone on discord who was concerned that this approach may set a bad precedent for other systems.
To paraphrase that discussion, the concern was that finding a way to alter loading times on some systems can affect gameplay timing/strategy because gameplay occurs simultaneously with loading times.
The example used was loading a Wii game from a USB instead of a disc, which might cause some rooms/map areas to load faster and alter whether or not certain glitches/strategies could (or couldn't) be utilized when they are for the standard/original media.
While I'm unaware of any C64 games that have such loading periods simultaneous with gameplay, there may be a few out there that do. So, as much as I'd like to see the shorter loading times accepted for C64, I don't want to set a bad precedent for other systems.
Unless the staff feels that there is still potential for this method to be accepted (via whatever rule/guideline updates may be necessary), I am willing to cancel this submission.
If an official ruling would be better so as to set a precedent in the other direction--preventing such media conversions--I am also willing to let it stand and be 'judged' officially.
Either way the decision ultimately goes, I feel the site stands to gain a more concrete approach to TASing across all systems.
Thank you all for your perspectives and consideration.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
ThunderAxe31 wrote:
feos wrote:
So for this submission, it'd have to be tweaked to use a non-arbitrary extra image that meets the requirements, it can even work the same as the image used here. Then we'll judge the actual movie finally.
...I'll try to make a handcrafted image that syncs for this movie, as resyncing the movie would basically mean to re-do everything fron scratch.
If a different image would result in a more optimal monster...it's worth redoing anyway.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
Memory wrote:
From what I see...
DrD2k9 wrote:
One last thought that may or may not mean anything for whether or not this is acceptable for the site: These types of conversions are actually possible on real hardware. If I had the EasyFlash cartridge to do this on my own C64 (or something similar for my Vic-20 for that matter), I would do it in a heartbeat.
Contradicts
I do not know what it would have taken to convert a game to cartridge format on the system itself (if this was even possible).
What do you mean?
I was saying that I'd gladly use an EasyFlash cartridge on my C64. As the disk2easyflash program is a PC program for converting from disk image to crt image format, the conversion wouldn't take place on the C64 itself.
Regarding the part about converting from disk to cartridge on the system itself: I don't know what all would be required to create a classic cartridge. At minimum, you'd need all the cartidge hardware and an EPROM programmer to program the cartridge from the C64.
It does appear that it's possible to create a .crt image on the C64 itself from data on other C64 media and then copy that .crt image to the EasyFlash cartridge. see here. http://skoe.de/easyflash/doku.php?id=writecrt I don't know how/if disk2easyflash is better/worse/equivalent to doing so in this manner....but it's a heck of a lot easier in my opinion.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
Some further thoughts from me on this whole concept:
The C64 could copy between Tape and Disk formats using commands within the system itself.
Much of the copy protection of the era was based on specific data positioning on whatever format was used for the game (which is why so many game versions currently available are cracked to begin with--to bypass this type of copy protection).
I do not know what it would have taken to convert a game to cartridge format on the system itself (if this was even possible).
The way I understand the Disk2EasyFlash program is that the C64 reads the .crt image as it would any other cartridge. The conversion basically makes the original disk-based game code run from the EasyFlash cartridge as if it's reading from a disk drive (only a much faster disk drive than the 1541).
Basically, I see the conversion somewhat akin to reading the game information from a 48x speed rom vs a 2x speed CD rom. Or reading data from a USB drive instead of an old floppy drive.
The game data remains effectively the same. It's just where the C64 looks for that information is changed from the 1541 Disk Drive to the cartridge slot. Then the converted .crt image mimics the disk drive to provide the C64 with the game data. It's why there is still a loading screen when using the converted image.
The reason the converted image has faster loading is because data transfer from the cartridge slot was much faster on the C64 than data transfer from a 1541 disk drive--which itself had a known issue that made loading from the 1541 slower than it even needed to be (fastload carts were made to help this particular issue, thought that might be off topic a bit).
So to answer feos' question about what is lost/missing...other than for games that won't convert in the first place, nothing from a game itself should be lost by the conversion. The only thing lost/missing is waiting periods for loading.
As far as the C64 system itself is concerned...how long a game takes to load isn't important to the C64; only that the data is present in memory when it's time to actually run the program.
Further, I can't imagine a programmer specifically tying whether or not a game works properly to how long it takes to load the game's information from a disk/tape; because that timeframe can vary slightly in a real-life situations from one C64 system setup to another.
As far as load time affecting the game itself, the conversion shouldn't affect how the game plays aside from possible RNG effects as described below.
There are two possibilities where a game's RNG may be affected using this conversion method:
1) Situations where a game bases its RNG on the C64's internal time value--how many jiffies (1/60th of a second) from 'power on'. Games using this RNG approach are equally affected by sitting idle on the boot screen before loading a game for any number of frames as they are by loading times.
2) Situations where games require multiple loading sequences during the course of gameplay. If these secondary loading sequences affect frame/time based RNG, it could potentially affect the RNG outcome of the game. If the loading sequences do not affect the frame based RNG, this is not an issue.
So loading faster should only change RNG values, not the how the C64 runs the loaded game code itself. In either of the above RNG situations, the game should still play as it always would, just with different RNG.
One last thought that may or may not mean anything for whether or not this is acceptable for the site: These types of conversions are actually possible on real hardware. If I had the EasyFlash cartridge to do this on my own C64 (or something similar for my Vic-20 for that matter), I would do it in a heartbeat.
EDIT: For this specific submission, the RNG wasn't affected at all by the difference in loading time/system time. RNG is therefore affected only by in-game actions or by the time since the game-code was 'run' (which is equal between the submission and the published run).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
EZGames69 wrote:
DrD2k9 wrote:
The whole point of this submission is to get feedback from the community's perspective.
You could have easily did that if you made a topic about it in one of the other form threads. You didn’t have to make a submission just to ask the community what they thought of the idea.
I did it as a submission on adelikat's suggestion.
