Joined: 3/10/2014
Posts: 10
Location: United States
what Mojo said is true. Dustmod basically tries to prevent the inconsistencies from desyncing the playback, if a level load takes 1 frame longer it wouldnt cause the TAS script to break, instead it will dynamically wait for the load to finish before starting the next sequence of inputs.
The composed replays can be watched in an unmodified version of the game and verified to work, and the nexus scripts function identically to the composed replays in terms of input playback.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
TheBirdOfPrey wrote:
I believe a site admin or Senior Judge is the type of person that would need to make judgement on this. If anyone has any questions, feel free to ask, as I understand making an exception to these types of things is not done very often.
Our rules are the same regardless of the system or game in question. There are no per-game exceptions to allow for a (near)complete disregard for our rules. Whatever playback software is used, it must achieve the playback quality we expect. If it doesn't, other more accurate or capable tools will need to be created.
TheBirdOfPrey wrote:
What that means is we can currently only TAS the Individual Levels of the game.
Individual level TASs are not allowed.
TheBirdOfPrey wrote:
What this means is that if we were to complete a TAS of the game, as we are currently able to do (eventually, still lots of work to be done) we would have the entirety of it saved in these fake replays as segments. From there, a spliced video file, made from these segments, could be created.
Individual level TASs are not allowed.
TheBirdOfPrey wrote:
There is an overworld, and the gameplay of the overworld is the same to the gameplay inside of levels. We can use the game's Level Editor in order to copy the overworld and turn it into a Custom Level, and then we can create a fake replay, using the composer again, in order to TAS the overworld movement. This is not ideal, but the functionality of it exists.
Individual level TASs are not allowed.
Also at this point, the playback of each of these levels now comes into question, as to how accurate it is when taken out of the main game. Therefore, again, individual level TASs are not allowed.
TheBirdOfPrey wrote:
My questions are mostly focused around a theoretical future date, in which the game has been completely optimized, but Hourglass still does not work with the game. How would/should we go about making a submission to tasvideos?
Fix Hourglass or create other tools which can achieve TASVideos rules.
TheBirdOfPrey wrote:
I don't know what that page is supposed to show. The playback of each of these levels is in question, as to how accurate it is when taken out of the main game. Therefore, again, individual level TASs are not allowed.
TheBirdOfPrey wrote:
These segments will sync for any computer that is powerful enough to run the game without lag, and matching the OS used to create the replay (Windows is what we use currently, Linux and Mac versions of the game that attempt to watch those replays made in Windows may desync in places)
The fact that different machines and OSs cause different results all the more enforces that levels taken out of the main game context are also different results.
TheBirdOfPrey wrote:
I understand this is a somewhat unique and unconventional situation to be in, especially for myself as I have not made any submissions to tasvideos before.
There's nothing unique about this, many games do not currently have a way to create TASs for them which comply with our rules.
BrotherMojo wrote:
To be completely honest, a vanilla game would probably play back the inputs properly. Not as in "we're pretty sure that it works the same," but "there's unpredictability in the vanilla game."
Dustforce as a game was designed with a lack of randomness in mind. In theory, everything should happen the same way every time if you use the same inputs.
This is contradicted by:
TheBirdOfPrey wrote:
These segments will sync for any computer that is powerful enough to run the game without lag, and matching the OS used to create the replay (Windows is what we use currently, Linux and Mac versions of the game that attempt to watch those replays made in Windows may desync in places)
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
a lot of thebirdofprey's response (what you went over for the first half of your post) is pretty outdated at this point... most of it can basically be disregarded as information in that post is almost a year old now. we no longer have to splice together IL replays or do anything video editing wise to create a full run of the game. a user in our community created a tool that allows us to run input scripts, which feeds inputs in to the game in real time similar to movie playback tools on any other emulator. currently, we have an input script that consistently completes the game from start to finish.
seemed to be a bit of confusion there, hope that cleared it up a bit. im not the person to really discuss OS issues, so somebody else could probably clear that up. we just mostly want to know what would need to be done with this tool to meet submission requirements on the site. hourglass seems completely out of the question for the foreseeable future, and various race conditions and hardware-based loading inconsistencies make a run on a perfectly vanilla version of the game seem completely impossible. the 5 of us have spent nearly 20 months now working on this TAS, and would really like to be able to have the run showcased here, so whatever we need to know for moving forward would be appreciated.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
If a tools allows runs to be played backed in accordance with our rules, then it can be accepted.
If there is such a tool, provide info regarding it, backing up that it complies with our rules, and allowing our users to review it to ensure that's the case. Also make the format details public so we can implement it into the site parsers. The format itself will need to include details regarding its video-frame length, and indicators if something may not entirely comply with our rules in a particular recording.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Information regarding Dustmod is available at the developer's blog, and information regarding the TAS script format, specifically, is listed in this post.
There are a few commands, such as LOAD, that were used during the development of the TAS but aren't necessary for a full game playback (and the use of which could be considered cheating, since they allow the user to forcibly set certain aspects of the game state such as character position). A full game playback currently only uses:
- input lines: which game inputs are being pressed for a given frame
- MOUSE commands: act as though a mouse click is happening at a specific point onscreen simultaneously with the next frame of keyboard/controller input, used 4 times during the run
- SYNCLOAD commands: wait for load time to complete and for the user to regain control of the character
Optionally, INCLUDE commands can be used to allow the script to be broken apart into several files, but the full run could be compiled into a single script file instead.
It's comparatively easy to get "frame count excluding loads" by just taking the number of input lines in the script or script files in question. On the other hand, the full length including loads will vary according to the computer it's being played back on.
The biggest potential issues I currently see are:
- "video-frame length" will vary by computer or potentially playback-to-playback because of variable load times.
- the format is currently "dumb" and doesn't include metadata, because it's designed to be human-readable and -editable.
But we're fairly certain any viewer with a copy of Dustforce who has installed Dustmod could reset their game save then play back the same input file and get the same result, though again load times may vary.
So, if this does not meet requirements, what can we do to correct these issues?
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
You'll need to provide sufficient details for those that have zero experience with your game or any knowledge regarding it. As is, your links assume too much prior knowledge, leaving too many questions open.
Is this summary for TAS site parsing correct?
LOAD - Cheating
MOUSE - Ignore
SYNCLOAD - Ignore
All others - Count as frame?
How do frames relate to real time?
When you talk about loading times, is the amount of loading times encountered in the entire game consistent on a single machine. Meaning if I play the game start to finish on machine X, will I have a total of Y loading time every single time? Or does it depend on how it's played? If play itself can affect when there is and isn't load, then the total amount of input is not an indicator of real time finesse in playing the game.
Also, with all this, I don't know what I don't know. What should meta data be informing us of? Are there multiple players at once, and if so, does it matter?
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Frames, for input purposes, the game tries to keep locked to 1/60th of a second. If things are bogging down, the game will try to poll inputs and process game logic at 60FPS even if it's not rendering at 60FPS.
Summary for parsing is a little more complicated than that. I think it's that a line of numbers is an input frame, and anything else is handled as either a command or a comment (i.e. not a frame), but I'll have to get back to you after confirming with msg555 on how exactly Dustmod parses a TAS script file.
Regarding load times, the game has 75 levels that are played in the TAS distributed across 3 different "nexus" stages, and playing through the game will involve loading a nexus, then loading a stage from that nexus, then returning after finishing the stage, etc. back and forth. Including the two extra transitions from the "Main Nexus" to the "Nexus" and the "Main Nexus" to the "Virtual Nexus," there will thus be a total of 152 loads over the course of an ideal "all levels" playthrough.
...though hm, there's a trick which lets you skip one load time by going straight from the final Nexus level directly to the Main Nexus without visiting the Nexus in between. Measuring in this fashion, that would take about a quarter second "more time" than just exiting the level followed by exiting the nexus if you don't count load times. We're trying to optimize for real time regardless, but that's slightly awkward.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
There also needs to be a way to dump video. In video dumping mode, since the speed of the machine isn't really relevant, the question is what gets written to video during those segments, and the video dumping process can normalize it. Like all those segments are 3 seconds of blank or repeated frames. Whatever it is, that info should be present (calculable) from the movie format.
Also, how much does this tool alter the game? How can we be sure of its faithfulness?
Finally, does the movie recording format for this even have a name?
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Hi all! I'm the author of Dustmod and let me see what light I can shed. First of all let me say that dustmod is created with the generosity of Hitbox Team who donated the source code to me to work on modding. In particular if it comes to releasing code or having it reviewed I'd need to have their permission as they hold the copyright and have asked me not to further distribute.
Also, how much does this tool alter the game? How can we be sure of its faithfulness?
While developing features for Dustmod it was always my intention to leave normal gameplay (no mods selected) unchanged. However, the code base has grown significantly and it's certainly possible there is a mistake (although we have evidence of it's faithfulness in our IL TASes that match on vanilla and dustmod when watched via in-game replays). If it's useful I could create a bare bones mod that just contains what's necessary for these TAS scripts.
Despite trying to keep gameplay unchanged, I have patched the following things intentionally to achieve deterministic playback that have some affect on gameplay.
1) Camera shake (created by attacking, landing, etc...) randomly moved the camera minor distances. However the camera position is used to determine what entities should be loaded and simulating. Because of this, when certain entities were loaded in was slightly random. I patched this by only visually simulating the camera shake and leaving the camera unmoved for loading purposes. Such an execution is always consistent with a possible execution in the base game. This is an extremely minor bug that we got pretty far into TASing before finding it to be an issue.
2) The main game loop had to be fixed to be deal with time properly. The original build will feed the game loop the time delta since the last call to the game loop and the logic should forward the game state by that time delta. An unfortunate property of the way the game loop was implemented was that invoking the loop twice for 1ms would not necessarily give the same result as once for 2ms. This manifested itself as occasional input drops and fairly variable load times, sometimes even simulating the world an extra frame before you can move.
I fixed this by making the game loop properly additive with respect to time. I also instrumented the vanilla build to find the average load-in and load-out times (in terms of frames) and made dustmod determistically match that. In particular the SYNCLOAD is not actually required for the nexus scripts anymore and could be replaced by blank inputs. It looks like BrotherMojo was mistaken about this aspect in his earlier comments; frame length of the video will be deterministic.
Finally, does the movie recording format for this even have a name?
I've just been calling them 'Nexus Scripts'. If we needed a name for tasvideos 'Dustforce Script' is probably appropriate.
Is this summary for TAS site parsing correct?
LOAD - Cheating
MOUSE - Ignore
SYNCLOAD - Ignore
All others - Count as frame?
Unfortunately with the SYNCLOAD command it's difficult to calculate frame counts. However as I mentioned above this command is not needed anymore and is purely convenience at this point. If we remove these commands then the length of the video (in frames) is the number of normal input frames.
There also needs to be a way to dump video. In video dumping mode, since the speed of the machine isn't really relevant, the question is what gets written to video during those segments, and the video dumping process can normalize it. Like all those segments are 3 seconds of blank or repeated frames. Whatever it is, that info should be present (calculable) from the movie format.
Can you point me to any resource on how other systems do this? I'm not certain what's involved here.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Some of the timing and randomness changes are possibly suspect. It has to be deterministic for playback, but actually altering the behavior is questionable. I'll let others weigh in on this what they think.
The Dustforce Script format needs to contain enough to achieve proper parsing without errors. If a submitted run will only contain MOUSE and regular input, it sounds reasonable.
Here's some details on what features TAS tools are expected to have: http://tasvideos.org/EmulatorResources/Features.html
Here's some details on requirements (including some video dumping details): http://tasvideos.org/EmulatorResources/Requirements.html
Mainly, you want to allow the ability to dump video and audio from the game, into some kind of lossless format. You can allow for writing AVI files which are pretty straight forward. Or, you can allow settings of an application to pipe video and audio to over stdout -> stdin, and let the third party application deal with encoding it.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Some of the timing and randomness changes are possibly suspect. It has to be deterministic for playback, but actually altering the behavior is questionable. I'll let others weigh in on this what they think.
Based on 'Such an execution is always consistent with a possible execution in the base game.' I think it's OK. (I think the idea is that it's morally equivalent to RNG manipulating each screen shake so that relevant entities don't load sooner or later, which you could eventually do by e.g. changing what system time the TAS is started on, or whatever causes the RNG initial state to change.)
In regards to the minor changes, they are always undesirable, but each were concessions that we felt necessary to allow deterministic playback and uphold the quality of the movie.
The issue with camera shake causing some entities to randomly load at different times could disrupt enemy cycles. This can be very problematic with attacks requiring frame perfect timing or tight cycle-based grouping of enemies to allow multiple to be destroyed at once. Camera shake RNG is unaffected by gameplay, so we chose to remove it for the sake of determinism rather than sacrifice time attempting to correct for its inconsistency.
The change to time in the game loop was necessary to ensure both that load times were consistent (which would otherwise vary randomly and by machine) and solve the problematic issue that when you gain character control in a level could randomly vary by a frame. The variance in gaining control would mean having to create scripts that would work for both starting frames, which would sacrifice at minimum a frame in every level and would overall reduce the quality of the gameplay.
To verify the faithfulness of the modified game, we can compare the play between the two using composed individual level replays. These replays (which are input-identical to the level portions of the full-game script) can be seen to sync on the unmodified game 90+% of the time. Although we cannot verify the gameplay in the overworld outside the levels, neither of these issues are a problem there since there are no meaningful entities for them to affect.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Any reason why the RNG isn't seeded consistently at the start, and replacing all time-based RNG lookups to offsets from the current frame count? In other words, keep RNG, but deterministically so.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Any reason why the RNG isn't seeded consistently at the start, and replacing all time-based RNG lookups to offsets from the current frame count? In other words, keep RNG, but deterministically so.
The game is pretty obviously designed with the plan to have no randomness in its gameplay. There is an RNG, but it's only used for "purely visual" effects, e.g.: how dust particles scatter when you clean dust from surfaces, what kind of harmless woodland creature is freed when you clean a floating lump of leaves... and how the camera shakes when you hit with an attack or fall hard onto a surface. Given that, the fact that camera shake could affect how entities load and unload seemed like an oversight, and so the logical solution seemed to be to just correct that rather than merely make it predictable.
...that said, I understand that's not exactly a decision made in the interest of "being faithful to the original release." The mod is developed for Dustforce players as a whole, it has quite a few great features for TASing but some of the decisions have also been made with the RTA player-base in mind. In that case, the decision was made so that determinism would be preserved on an individual-level basis, so if you miss a critical attack on a group of enemies, that means you positioned yourself incorrectly, or mistimed it, or some other mistake on your part as a player, rather than having gotten bad RNG.
Also, because of how the RNG is used, a deterministic RNG could theoretically be implemented for a locked 60 FPS framerate, but normally the RNG can be called any any time a frame is drawn, which would potentially still result in desyncs as framerate climbs and dips normally.
...that said, I understand that's not exactly a decision made in the interest of "being faithful to the original release." The mod is developed for Dustforce players as a whole, it has quite a few great features for TASing but some of the decisions have also been made with the RTA player-base in mind. In that case, the decision was made so that determinism would be preserved on an individual-level basis, so if you miss a critical attack on a group of enemies, that means you positioned yourself incorrectly, or mistimed it, or some other mistake on your part as a player, rather than having gotten bad RNG.
Well, the good news is that if msg555 has the source code from the dustforce team, and they actually intended there to be no RNG, it shouldn't be difficult to convince them to pull your patch and release it in the base game assuming it was done cleanly.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Joined: 3/10/2014
Posts: 10
Location: United States
The camera shake only moderately-consistently caused a desync to occur in 1 level in the entire run to our knowledge, the other 74 levels and all of the overworld movement, which is another approx 77 pieces of the run are not affected by the change at all.
Your suggestion of having the devs push a patch to the game is not so simple, they would have to deal with publishers, verifying the build stability, there is many more steps and bureaucracy to that process than is immediately obvious.
I would personally not feel comfortable asking that of them
Your suggestion of having the devs push a patch to the game is not so simple, they would have to deal with publishers, verifying the build stability, there is many more steps and bureaucracy to that process than is immediately obvious.
...
Thank you for that lesson on the complexities of indie development and publishing of which I was entirely unaware.
I'm not suggesting that they're going to drop everything and do it, but it's entirely possible to get them to roll it into a maintenance patch, presuming they're still touching the game, or at the very least sign off on it as being closer to the ideal of the game than they published, which will make it an easier sell to the site staff.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
figured I'd give a quick update since it's been about a year and a half since the last post, and we've recently made a push to finish the SS all TAS, which has been in progress this whole time now. we've "finished" the TAS, save for some input clean-up and possible last minute ideas (luckily dustforce is an incredibly easy game to sync), and intend to release the TAS either by the end of the year or early 2019.
our concerns in the past with publishing the TAS to this site was that there were no adequate emulator to run a TAS on a 100% vanilla version of the game - hourglass would essentially softlock on a login screen just after booting the game, and the vanilla version of the game has a few minor loading inconsistencies and other non-deterministic headaches that made a TAS of a completely vanilla version of the game rather annoying, if not impossible. therefore, up to this point we did all TASing on Dustmod, which included TASing support in the form of loadable input scripts and fixed the non-determinism I mentioned earlier. however, there were flaws with this approach - this tool was not running a 100% vanilla version of the game, thus making it incredibly difficult to be accepted as a valid TASing tool on this site, and also lacked several other features that were necessary for such a tool to be accepted (video encoding was the big one, and currently the creator of Dustmod is quite busy and is hesitant to get involved in large updates or new features, save for bug fixes and such). read through the last few posts on this thread and you'll see discussion of this.
the suggestion of getting the devs of dustforce to patch some of the minor fixes Dustmod made into the vanilla game was suggested, and unfortunately it doesn't seem possible. again - it's a lot easier to do that sort of stuff for a game you have personally worked on and been invested in, but hitbox team has moved on to other projects and has not made an update to dustforce in almost 4 years at this point. we were not going to even bother with this, but one of the devs caught wind of this discussion and very kindly offered to see what they could do for us, but unfortunately they hit a hiccup along the way (I believe they didn't have a way to compile a version for mac OSes, among other things) and the idea died out. frankly, this killed a lot of our momentum and interest in getting this TAS published, so we simply decided to instead focus on getting a version working on Dustmod that anyone with the mod could watch in-game after running our full-game input script. (not to blame anyone - we understand the standards must be high and don't want to seem like we were begging for an exception or other hand holding) after all, the majority of the competitive player base for Dustforce plays on Dustmod, and thus being able to let them watch the TAS in-game with access to debugging data, slow down, etc. would allow them to more closely study or appreciate some of the intricacies of the run, without forcing them to download external tools.
...that being said, luckily libTAS seems to run Dustforce quite well - Kilaye ran a few of our input scripts for several levels and they synced up just fine. admittedly, we haven't looked too far into everything, but this is definitely something we will pursue when we have finished the full TAS on Dustmod. I believe we even have a script that will translate Dustmod's input script syntax into input data that libTAS can read, thus getting a TAS on this version could literally just take a few hours of minor tweaks and fixes if we were to get lucky and not encounter any major hiccups.
so tl;dr, we are pretty much 99% done with our TAS, which we will release on Dustmod by the end of the year - once this is done, we will try to convert this TAS over to libTAS for submission on this site, along with tons of other documentation (we want an extremely in-depth submission text and audio commentary(s) for the run, for audiences not familiar with the game). this would probably take a couple more months of work, but (fingers crossed) we might be able to get this TAS published on this site on a vanilla version after all!
About libTAS, it supports Dustmod without any problem and can replay inputs made on that tool without desyncs (only tested a few stages but I'm confident).
Regarding the vanilla game, the main issue is a slight change in a trigonometric computation that makes replays from Dustforce/Windows and Dustmod/anyOS desync on Dustforce/Mac and Dustforce/Linux. I don't know the exact change, so I don't know if it could be patched into libTAS to make the replays to sync.
aaaaaaaaaaand the run is already obsoleted :D https://streamable.com/gkq04 18 frames saved with a new dust route at the start to catch a massive boost that a player accidentally discovered today.
joking aside, happy to have the run "finished", we'll be taking a break for a couple weeks before we worry about getting this TAS working on libTAS for submission on the site.
