Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Limits of common sense are pushed once again :D
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Another thought: If 'TAS timing ends as you can put the controller down' implicitly removes all blank frames after the last frame of actual input for the purposes of timing, why not remove all blank frames before the first frame too?
That's an interesting thought, but that would require most runs to start from a savestate at the first frame of input, which would make them harder to verify and harder for those who want to watch the run to set it up on their emulator.
Blank frames should definitely be removed after the movie though. There's no reason for them to be there.
Another thought: If 'TAS timing ends as you can put the controller down' implicitly removes all blank frames after the last frame of actual input for the purposes of timing, why not remove all blank frames before the first frame too?
That's an interesting thought, but that would require most runs to start from a savestate at the first frame of input, which would make them harder to verify and harder for those who want to watch the run to set it up on their emulator.
Oops, when I said 'remove' I mean 'discount for the purposes of automatically timing'.
(Alternatively, a field 'wait this many frames then begin playing back input' would be fine too.)
Oops, when I said 'remove' I mean 'discount for the purposes of automatically timing'.
So essentially only start the movie length timing on the first frame of input, ignoring the non input frames there are before it?
Also, it should be mkv time, the site hasn't used avi's in a long time.
Because AVI time depends on the publisher logo and the time he decides to spend on the ending screen.
And btw, "avi time" is a real misnomer, and has been for a rather long time. (And yes, I know the statistics page still uses that term. Maybe it should be changed.)
AVI is but just one multimedia container format. In the beginning all encodes were published using it, but that hasn't been the case for quite many years. (Also youtube makes the definition even fuzzier because we are not talking about a physical file anymore, but a stream watched using a flash application.)
However, it's hard to come up with a better alternative that's unambiguous and doesn't cause confusion.
Blank frames should definitely be removed after the movie though. There's no reason for them to be there.
Well, there would be a reason, if we didn't assume that movie watchers never press any button while watching the movie (even after seeing the "Movie finished." message). If they were less reliable, TASes would have to keep producing null input until the very end of credits, or else some movie watcher may press a button and thus skip or alter the ending.
TASing relies on many assumptions (like any other activity does certain assumptions, for example, in the 100 meter sprint you can run more efficiently if you assume that after you reach the finish line you can relax and fall into friendly hands, while in real life you would probably run so fast only because of being in a hostile environment, which requires further actions after running). Here we assume that the game is played inside a safe sandbox, which provides a consistent initiial state of the game and a reliable conditions after the movie ends. Without these things it would be impossible to ensure determinism.
If we modify our emulators to make them immediately start generating random input every time a movie ends, most of existing TASes will desync, because some of those random inputs will either pause the game a moment before ending, or reset the console, or skip ending and go to title screen, etc. This would actually be a new reliable way to automate movie length calculations, since all TASes from now on will need to have many blank frames at the end (to ensure that movie watchers will see the ending until the very last frame that matters). This "random input noise" would be just another assumption (replacing the current one), and it'd probably be closer to real life, but less convenient for TASers. But at least the site will be able to know the ending frame for sure.
FatRatKnight wrote:
This does imply that my April Fools' TAS is indeed just a little over 3 seconds long, as I do specify a final state other than empty where the controller no longer changes.
The problem is, your chosen final state makes additional assumptions (without even replacing the existing one) that are not a part of TASVideos traditional set of assumptions. And I'd say, the less assumptions we make, the better.
It's similar to using dirty SRAM - in that case we assume that the initial state of the game is different from the usual state, while in your case we assume that game controller can keep the last state of buttons (should it be a new category "Uses modified controller"? or "Leaves dirty input footprint" - since after watching the movie the emulator will be oblidged to keep repeating the last state of buttons while ignoring user's actions).
TASes using dirty SRAM aren't very frequent, since they give you an advantage that has to be justified by providing huge entertainment to the viewers. Needless to say, leaving dirty input is also very uncommon (because it doesn't match the default state of controllers seen in real life: all buttons are released) - it makes additional assumptions that reduce the percieved value of a TAS.
FatRatKnight wrote:
For this line of thought, now I'm curious what you think of my April Fools' TAS. With the information we're discussing now, should it be published for the concept of finishing a game with a really short input file?
I liked it very much and answered Yes to the question of entertainment. If the site ever adds a Demo tier, the movie should definitely be published there, along with all TASes starting with dirty SRAM.
Actually, if the movie were better recognized, say, less repetitive and even more dramatic than it is, I would suggest to publish it in Stars (the tier is so high that it's probably above rules of the site), and volunteer to modify FCEUX to make the final auto-hold put less overhead (the final state of buttons should be stored in the movie file, so that movie watchers don't have to bother with settings).
As a concept of finishing a game with a really short input log, this run is nothing special. I've seen some games that allow you to set password to appear right before the very ending (see, for example, Blackthorne for SNES) - those runs would probably be even shorter. But it doesn't look like anything wonderful, so I don't think you should promote your TAS from the point of shortest input. Instead I find it more amazing that your TAS was the only TAS that made me worry about the fate of the protagonist. You know, when we're spoiled with so many TASes that play with death, we become sceptical, because we know it's just TAS and not a live stream of someone playing right now, so everything is going to be good, unless a desync happens. When watching your TAS I also knew that the input won't change, so I was able to quickly predict that at current pace the player is surely going to die, unless some miracle happens. I guess if I wasn't familiar with the game, I wouldn't be so sure.
FatRatKnight wrote:
Mainly, I asked about a controller with no buttons pressed primarily because that is used as a standard here for ending a movie, by my impression.
It's more like a standard used everywhere. It's a default resting state of hardware, after all. Most games expect you to not press anything on the ending screen, or else the ending may be skipped. So this standard has gameplay-related roots, and is not arbitrarily chosen. Even more realistic standard would be the aforementioned "random input noise" instead of blank input, but IMO it doesn't worth the trouble.
FatRatKnight wrote:
Technically, many movies published here can be "improved" by doing everything up to the last frame, then have the following frames hold the non-null default state in order to complete the movie
That would be like improving a normal TAS with a TAS starting from dirty SRAM.
FatRatKnight wrote:
I can always modify my argument to instead pick unchanging input rather than blank input, if you prefer. I'm sure you know where I'm going by now.
I'm not sure I do, so I would like to hear the modified version.
Patashu wrote:
Another thought: If 'TAS timing ends as you can put the controller down' implicitly removes all blank frames after the last frame of actual input for the purposes of timing, why not remove all blank frames before the first frame too?
That sounds a lot like SDA timing to start counting. Can't really say anything against it, except that maybe the Power switch command is also a part of the movie.
Looking back on it, I guess it's sort of a tangent, but thanks for your thoughts on my movie. Non-null default input is an extra specification, something most controllers don't leave themselves in without something wedging the button down. It also uses a password to get a state that can't be replicated without a password.
AnS wrote:
FatRatKnight wrote:
I can always modify my argument to instead pick unchanging input rather than blank input, if you prefer. I'm sure you know where I'm going by now.
I'm not sure I do, so I would like to hear the modified version.
I will copy and modify pieces of my older post. It's largely the same argument. To keep it more terse, I'm skipping parts that won't have significant enough differences.
Why is locking a controller in an unchanging state a special method that doesn't need to be counted as part of the movie's time? Why is leaving it in a final state a desirable thing, when further changes can reach the credits faster? Is it because the input movie length is shorter? If one is looking to find a game completed as fast as possible (as currently known), the default input where further changes could do it faster denies such fastest completion.
I consider all frames (aside from the user idly messing with the keyboard) after your input list to be a part of any run, just as much as if you had actually padded your movie file with them.
Just because there is unchanging input after the end of my input doesn't mean that this unchanging input isn't part of the resulting movie. After all, people are going to watch it.
Well, it's a modification where I replace a few words. I really can't think of a different way to explain it, so I'll just make it obvious and make no attempt at hiding that it's a direct modification to my argument.
AnS wrote:
If we modify our emulators to make them immediately start generating random input every time a movie ends, [...]
An interesting way to help enforce the "fastest game completion" goal, by encouraging the TASer to produce a movie where further input can't prevent the ending.
There are still a few cases where even when the game won't accept further input that the ending can be extended or reduced a little. Super Mario World comes to mind: Mario and the princess needs to go next to each other before the rest of the ending plays, and this would have different times depending on Mario's position when you defeat Bowser. Then again, the ending is, rest assured, reached.
If there's an overall strong desire to shift the standards around, this would be a decent start. I don't hate the current method of stopping input short, but I prefer the fastest end rather than the shortest input. I don't expect standards to change that easy, as people are used to it and seem to really hate when something changes. But it's a good test for the runners that, with my preference, want the fastest end.
Being that the site is entirely focused on the use of emulators, I'm inclined to think that minimum Input File length is the main goal. Particularly because, no matter how many Frames I spend trying, my movies will *never* be entertaining. P
If there's an overall strong desire to shift the standards around, this would be a decent start.
Yeah, now an idea for a decent end. Behold the Final Solution: automatically close the emulator when the movie ends!
This way the length of the input log will be equal to the amount of frames that can be seen. So TASers would have to add blank frames until the moment where they consider the game to be completely finished - e.g. publishers stop AVI dumping where the final music loops. Of course some RAM values (and CPU registers) still keep oscillating with different intervals, producing unique states of the game. Too bad these states won't be seen by movie watchers (because emulator quits), even though they are a part of the ending. But anyway, no one will ever want to experience them all (who ever watches TASes with RAM Watch open?). People just choose a random reference point, at which they consider the game completed. This point belongs to the interval from the earliest frame where the input changes could be stopped to +∞.
FatRatKnight wrote:
There are still a few cases where even when the game won't accept further input that the ending can be extended or reduced a little. Super Mario World comes to mind: Mario and the princess needs to go next to each other before the rest of the ending plays, and this would have different times depending on Mario's position when you defeat Bowser.
Why have you chosen the point where Mario and the princess meet? What if some other point (after this point) will be delayed because of different Mario position when you defeat Bowser?
I think, this method of choosing a reference point is unreliable. Sure, regular players will be satisfied with any plausible point, but we know too much to be satisfied with a random (e.g. plot-based) point.
For example, think about what happens at SDA maraphons, namely speed challenges between two players. Let's say, the 1st player killed the last boss slightly faster than the 2nd one did it, but he's got more points, so the score tally took longer and the 2nd player reached the "CONGRATULATIONS" message slightly earlier, but then the 1st player got better subpixels and met some princess placeholder earlier, but the 2nd player got less lag and his screen faded a bit faster, but the 1st player got shorter credits, but because of longer credits the 2nd got overall shorter music (less loops) on "THE END" screen, but the 1st got better RNG thus the "falling stars" particles on his screen degraded into an infinite loop earlier, but the 2nd got better modulo of GlobalTimer (ingame frame counter in RAM), so the hidden game clock stopped earlier, but the 1st got better overall value of another oscillators, allowing them to form a stable loop in the nearest billion of years instead of the nearest trillion. Anyway, who has won the SDA race?
I'd say, the one who was able to free his hands from the controller and hit the button on the chess clock, or just shout to the guy with timer. Everything else will happen eventually (something within seconds, something within years), but the player is already free to move to the next game (if it would be this kind of maraphon).
So, for example, given the interval of frame points [200; +99999999999] we may choose any frame inbetween, but the only consistent choice is to either always take the leftmost value, or always take the rightmost. Since the right value is usually unreasonable (it's the number of frames needed to degrade the game ending output into a loop, sometimes it's actually infinity), we choose the left value.
FatRatKnight wrote:
Why is locking a controller in an unchanging state a special method that doesn't need to be counted as part of the movie's time?
Because this method exists in hardware and is used by regular players. I'm talking about the "make all buttons forever released" method.
FatRatKnight wrote:
Why is leaving it in a final state a desirable thing, when further changes can reach the credits faster?
Because credits are not the ending, but a random reference point which became popular. Some games don't even have credits at the end.
FatRatKnight wrote:
Is it because the input movie length is shorter?
No, it is because the earliest point seems like the most objective reference point.
At least it looks so from the purely technical side, which is what TASvideos is good at.
FatRatKnight wrote:
If one is looking to find a game completed as fast as possible (as currently known), the default input where further changes could do it faster denies such fastest completion.
If one is looking to find a video that shows credits (or some other point of the ending) as fast as possible, he'd better search Youtube.
Even if your movie reaches one point faster then ever, you still can't claim that the same movie actually reaches another points (of the ending) as fast as possible. Of course, most players imagine that there's linear progression, which would mean that the earlier you reach one point, the earlier you'll reach the next one, but it's not so simple (in the general case).
FatRatKnight wrote:
I consider all frames (aside from the user idly messing with the keyboard) after your input list to be a part of any run, just as much as if you had actually padded your movie file with them.
Up to which frame should we pad the movie?
FatRatKnight wrote:
Just because there is unchanging input after the end of my input doesn't mean that this unchanging input isn't part of the resulting movie. After all, people are going to watch it.
You never know up to which point people are going to watch it.
OK, the unchanging input is part of the movie, but so is the input produced by dropped controllers after the end of an SDA race. The TV may be already switched off, but controllers keep producing null input, and the game keeps updating. Should they also include the input to the timer value?
FatRatKnight wrote:
I don't hate the current method of stopping input short, but I prefer the fastest end rather than the shortest input. I don't expect standards to change that easy, as people are used to it and seem to really hate when something changes. But it's a good test for the runners that, with my preference, want the fastest end.
So you want to cater to casual viewers who have a simplified understanding of what is the end. Well, I also think the main goal of TASing is to provide entertainment, and not just find the limit of games. So I agree that Moons can have both types of movies: those that entertain people (by giving them an ending they like) and those that find the limit of the game. But when we're talking about Vault runs, I think the latter goal is more important, since their entertainment value is negligible.
£e Nécroyeur wrote:
no matter how many Frames I spend trying, my movies will *never* be entertaining.
I do see some merit in FatRatKnight's point that all buttons unpressed isn't that special of a controller state. The reason we find it to be special is that it just so happens that all default controllers for all major consoles have this as their resting state, but there's no real reason why that has to be the case.
Not sure if it affects the argument much, but many Nintendo consoles (e.g. GameCube) allow you to change the resting state of the analog stick to be pretty much as far off-centre as you like, entirely via controller input. (This is actually used by unassisted speedrunners on occasion, in order to help pull off glitches.) Also, XBox 360 controllers (among others) also have a nonzero resting state for the analog sticks (it's close to 0, but not 0); games are normally implemented to ignore analog input values sufficiently close to 0 in order to compensate for this. (Sometimes, the game gets the size of the "dead zone" wrong, leading to very frustrating spurious inputs.)
I have never understood why anyone wants to time a game only to final input. It seems to me like some weird arcane goal that someone might do for fun rather than being the standard for all runs.
These are speedruns to beat the game, and thus timing should be until the game is over just like in regular speedruns.
Moons runs can have whatever input file length is beter liked by the author and the viewers. Vault runs can only be time records, so sacrificing real time to bring the game to the completion state sooner (say, by skipping the ending cutscenes) is not justified, since the run overall was not liked and is only valuable as a time record.
Others seem to agree with feos here:
CoolKirby wrote:
MESHUGGAH wrote:
For vault, I would say shortest input should be used and other tiered TASes should aim for the more entertaining version if the viewers demand it.
This is my view on it too.
I certainly agree that people should be free to choose the most entertaining option for moon runs, and I might also agree that for the vault a set rule would be better. I'm not quite sure why that set rule should be input time though, except maybe for convenience.
I thought the vault was meant to show records only, and isn't concerned with entertainment. When I read something like this:
feos wrote:
I, on the contrary, love such endings, because they add more of the unintended touch. Everyone knows how it can be played in normal conditions. Overcoming them requires creative thinking. Some runs that end input really early need quite some planning and manipulation. It is a unique task, presenting more interesting effects.
This is not something that I would associate with a vault run. I would argue that having such an unintended touch is not what the vault is about. It is about providing a TAS that completes the actual game the fastest.
I don't see 'ending input early at the cost of finishing the game later' as anything more than a strange type of speed/entertainment trade-off (look ma', no hands!) and I think they should be treated as such. However, to use them to claim that a run is faster seems very silly to me.
Ideally, I would present game-specific times that reach some sensible and consistent end-point (e.g. final boss hit/explosion), agreed upon by people who run the game. The input file times are usually pretty close to that anyway, but when the difference is big I don't take the times on the site seriously.
Anyway, I know that won't happen and I don't mind, but as far as improving runs goes I would accept a longer input file if the game was finished quicker.
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
I don't think this discussion is making any progress (not that I think it isn't healthy to debate it). However, given the divided nature opinions and that nobody is clearly right, it has always been author's choice.
It is an interesting consideration that maybe the vault should be more strict (we do want to minimize subjectivity as much as possible with its rules). However, this discussion has not successfully convinced me that earliest input at all cost is the best policy. And given that is the only completely non-subjective choice, it doesn't benefit us to enforce any other type of ending. So I think author's choice is still the best decision.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
So, back to what spawned this thread, the Defender of the Crown submission that ends input later, having NO gameplay improvements, should obsolete the same run that finishes input sooner?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Yes.
I see games as a labyrinth designed by the developers, with the ending in the middle. For a speed-oriented TAS it doesn't matter how you reach this ending (breaking the walls, teleportation, ...), just that you do. The TAS spending the least of the viewer's time doing that wins. The only advantage of timing based on input file length is that calculating the TAS length can be (not reliably) automated; note that the viewer wouldn't even see a difference if the emulator wouldn't announce the input file's end.
I don't care about the single submission, as long as it doesn't create a precedent.
But if it's going to be percieved as a precedent, I vote No.
creaothceann wrote:
I see games as a labyrinth designed by the developers, with the ending in the middle.
That's a very limited model. And it brings us back to the discussion about whether we should perceive videogames the way they were planned or the way they were implemented (e.g. game designer planned a labyrinth with an ending in the middle, but programmers shifted the ending to the right and also left a few unintended shortcuts or even alternative ending points).
creaothceann wrote:
The TAS spending the least of the viewer's time doing that wins.
Are you talking about the Vault here? Because I thought the Vault doesn't have to strive for maximum viewer's pleasure, but for maximum effectiveness of the solution.
creaothceann wrote:
note that the viewer wouldn't even see a difference if the emulator wouldn't announce the input file's end.
A casual viewer does not notice the majority of stuff that happens during TAS, so that's not a point.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
What if some frames can be cut out at the end of the movie, but it does not affect the ending appearance? Again, it is for Vault.
Post #354762
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
So, back to what spawned this thread, the Defender of the Crown submission that ends input later, having NO gameplay improvements, should obsolete the same run that finishes input sooner?
Just let me share my opinion again with different wording.
For me, (accepted) TASes are a series of input that will ensure the game will be finished and reaches a positive end game state in the future. Using that example, the TASer spent fewer time to "implement" a strategy that will guarantee a success completion of the game while the published one takes more time to feed the game with enough input to get that positive end game state.
I think the different viewpoints ("input time vs avi time") could be distributed to
1. The time you need to "play" the game to get the ending
2. The time you need to "wait" to get the ending.
I wonder what kind of explanation would satisfy those who favors "ending screen comes up earlier".
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos: regarding our discussion in IRC, I have a compromise:
You have an alternate ending you want to offer? Great, we'll have an alternate movie in the same published movie.
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.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Ilari wrote:
Nach wrote:
You have an alternate ending you want to offer? Great, we'll have an alternate movie in the same published movie.
Double-publishing? Isn't that quite nasty to do (technically; I did it once)? Or something else?
Just have alternate movies linked in the publication.
"Hey want to see slightly different ending for this movie? See [link|this run] by so and so"
Edit: To be clear, the different ending could be links to the rejected submission with the file and encodes at the top of it, or it can be individual links to the different variants of the movie, or it can be added to the file list too. Whatever makes the most sense for this.
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.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
I guess it would satisfy just all this way.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
The fact is that both input time and movie time are valid criteria. Warp has also mentioned "end the input where no further input can make the game end faster". I thought of it myself as well and I also think that this is a valid criteria. For the purpose of this debate, I'll call this concept "gameplay time".
Input time advantages: Easy to compare times, the coolness factor of making the game beat itself.
Input time disadvantages: Null input can still be considered input, the awkward period where input is still possible but really shitty gameplay is occurring, which potentially delays the ending, and sometimes for extremely long times.
Movie time advantages: Natural way to compare times, allows comparisons with normal speedruns.
Movie time disadvantages: Difficult to define for some games with multiple endings, may require a longer input time to trigger a shorter ending sequence.
Gameplay time advantages: Allows comparisons with normal speedruns, allows comparisons with Speed Demos Archive times (not directly).
Gameplay time disadvantages: Requires brute-forcing to prove validity of movie, must define and ban reset input from that verification, may trigger a longer ending sequence.
My thoughts on the matter are as follows:
- I consider null input as input, which makes the early input end a silly concept to me.
- The difficulty of defining when exactly is a game beaten makes it hard to measure movie times in general, but it's still feasible.
- Gameplay time is not practical because of the brute-forcing verification requirement, which may be impossible to verify in a reasonable amount of time for multiple games.
- Since non-interactive cutscenes count as gameplay time at the beginning and middle of a movie, it is a bit silly to me to not include similar non-interactive cutscenes at the end of a movie as part of gameplay time as well.
Conclusion: Considering the above, I believe the best choice is to use movie time by default, and input time for the rare categories which has significant entertainment value for it. But this assumes that the TASVideos staff is up to the task of measuring movie times manually. Otherwise, input time should continue to be used.
EDIT: Added 4th thought.
