I decided to create this thread since the posts in the recent Defenders of the Crown submission show that there are different views about this issue. So, what's the deal?
The currently published Defenders of the Crown TAS aims for the shortest possible input time. This means that the final battle is manipulated so that it will complete the game, but it will not be the fastest possible final battle. This published movie has an input time of 1:46 and the final battle is won at around 2:54. The the recent submission has an input time of 1:57 and the final battle is won at around 2:02. Had this been a non-toolassisted speedrun on SDA, this new submission would be considered to be 52 seconds faster.
On TASvideos however, the record time displayed is the input time. The input file allows for this time to be calculated automatically, it's well-defined and can easily be compared. Games like Defenders of the Crown make you wonder what our real goal is though, to provide TASes that completes the game as fast as possible, or to provide the shortest possible input file.
This discussion is not new, over 7 years ago, I wrote this in the Mega Man 5 submission thread. There, I even suggested a third possible option:
Baxter wrote:
Finishing movie at final hit, and shortest avi time
I asked Bisqwit right before I submitted, and he preferred movie stop at final hit. The main reason for this was that any input after movie stop will not influence the game being finished. I did this in my movie, since it seemed it was also done in some other megaman movies like megaman 4.
Shortest input time, while keeping same avi time
I intentionally made my shot from very far away to show it could also have ended at frame 118996. The movie would have ended about the same way, and the avi would have been exactly equally long. You could prevent the game from finishing, by pressing start after input (the bullet will disappear.
Shortest input time, with longer avi time
It's also possible to make a weapon switch to napalm bomb, shoot a bomb and stop input. Since the bomb moves so slow, it will be ~10 frames faster than 118996, even with the weapon switch. Using this would result in a longer avi time, and a possibility to make the movie not finish, when playing after input time. This method would however give the lowest input time.
In my opinion, it doesn't really matter which of these is used, I would however like it if the FAQ was more clear about which one of these to pick.
A strict adherence to shortest input time (option 3) seems to create strange situations for games Mega Man 5 and Defenders of the Crown. Any thoughts on this matter?
Joined: 4/17/2010
Posts: 11477
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Haven't read the post yet, but it started from IRC discussion between me and Baxter, spawned by my post. I'll clarify my point.
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. There happened flaws in unrejecting event where games ineligible for Vault got vaulted, but it was a mistake.
Current Vault policy:
http://tasvideos.org/JudgeGuidelines.html#TiersAndGoals
Examples of delayed final battle victories that are a brilliant showcase of the shorter input file concept:
http://www.youtube.com/watch?v=YEPA3aIvdhQ&t=311http://www.youtube.com/watch?&v=zzHWqci-x48&t=398
And where it didn't work:
#3313: adelikat's NES Teenage Mutant Ninja Turtles in 16:26.23
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.
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
The rules seem to say, "Get to the end of input as fast as possible."
end when the last decisive action has been delivered.
So, I would say even if the AVI is longer due to delays in action the shorter input is what the rules say we want your input to be as short as possible.
That being said, entertainment can suffer from this or may even benefit from ignoring this (Megaman Battle Network 2's Bass ending sequence).
When TAS does Quake 1, SDA will declare war.
The Prince doth arrive he doth please.
There isn't a single best ending criteria. It comes down to TASer's choice (What is the most technically interesting ending criteria? What is the most visually interesting/aesthetically nice ending criteria?) and varies from game to game. Of course, it should not be allowed to obsolete a TAS purely by changing the ending criteria.
The question about where it's considered valid to end the input has been open for almost the beginning, and there's no unique agreement on it.
Personally, I think that the goal of a TAS is to (usually) end the game as fast as possible, not to minimize the length of the keypress input file. That latter goal is completely inconsequential and irrelevant. What matters is finishing the game, not how many keypresses were needed to do that.
Of course I also agree that keypress files should not contain any needless data after the end, because that would be useless redundancy.
Thus the principle I like the most is "end the input where no further input can make the game end faster".
Was this submission intended to be a playaround? It says aim for the fastest time, but I'm unfamiliar with the game, so not sure if it's the main mode. It got rejected for ending input alot earlier which made the ending look horrid.
The "earliest frame possible" rule allows movies to be judged against each other. Otherwise it'd be subjective.
So all the game's TASers have to do is to agree on another rule, like "fastest way to show the credits".
Joined: 4/17/2010
Posts: 11477
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
creaothceann wrote:
So all the game's TASers have to do is to agree on another rule, like "fastest way to show the credits".
Which would introduce problems if this rule is forced. Because the current order of things is reflected by the freedom the Moons tier gives to movies. The author can decide what he likes better, and as long as it is liked by the viewers, it is all legit. Be it aiming for faster credits or shorter input. Obsoletions are anyway judged by gameplay improvements. And if gameplay is not improved, it is usually rejected. As happens to movie conversions switching the ROM region.
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.
Thus the principle I like the most is "end the input where no further input can make the game end faster".
I don't think that's unambiguous enough. In Rosenkreuzstilette, there are two possible routes. One of the routes involves obtaining a particular item, spending time in the process; this lets you get a final boss fight that's faster than skipping the item, and that lets you end input at the start of the boss fight. The other route, skipping the item, means that the final boss fight is shorter, but ends earlier relative to the run as a whole (because skipping the item saves time, letting you get to the fight earlier); you have to input all the way through it.
So with your definition, it'd be faster to obtain the item; at the point when you end input, there's no way to beat the game faster from there. It is possible to beat the game faster, but only by changing route earlier.
Thus the principle I like the most is "end the input where no further input can make the game end faster".
I don't think that's unambiguous enough. In Rosenkreuzstilette, there are two possible routes. One of the routes involves obtaining a particular item, spending time in the process; this lets you get a final boss fight that's faster than skipping the item, and that lets you end input at the start of the boss fight. The other route, skipping the item, means that the final boss fight is shorter, but ends earlier relative to the run as a whole (because skipping the item saves time, letting you get to the fight earlier); you have to input all the way through it.
So with your definition, it'd be faster to obtain the item; at the point when you end input, there's no way to beat the game faster from there. It is possible to beat the game faster, but only by changing route earlier.
I don't understand. If obtaining the item makes the run longer, how exactly do you get to it being actually shorter? I'm not really seeing how you are understanding "end the input where no further input can make the game end faster."
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
I've always been on the side of shortest time until the ending is activated. If feels to me that ending input too early and delaying the activation of the ending sequence is like not getting the job done right.
There are other points though for example in my battletoads movie I have ended the input way after the ending was activated so I could accelerate one of the dark queens final messages, but that kind of thing is up for debate for each game I think.
I don't understand. If obtaining the item makes the run longer, how exactly do you get to it being actually shorter? I'm not really seeing how you are understanding "end the input where no further input can make the game end faster."
Getting the item lets you end input around frame 1000, and the game ends at 1500. No further input after frame 1000 would end this any sooner. As such, your criterium is fullfilled.
Not getting the item would allow you to start the boss fight earlier, except you'd need more input, so you can only end input at frame 1200 (which is later). However, as you've been inputting the whole boss fight instead of just the start, the game ends at frame 1300, which is faster.
Both options fullfill the criterium, but which one do you believe should be used?
Disclaimer: frame numbers are nonsense.
I remember that I never liked how this TAS ended (as evidenced by this post of mine) (for the record, I still don't). For me, a movie should end as soon as you lose control of your character. Of course, exceptions can be made, if the end result is something funny (which is not the case in Rockman 4 MI to me, since it just looks out of place, though I was pretty much the only opponent to how it ended).
Getting the item lets you end input around frame 1000, and the game ends at 1500. No further input after frame 1000 would end this any sooner. As such, your criterium is fullfilled.
Not getting the item would allow you to start the boss fight earlier, except you'd need more input, so you can only end input at frame 1200 (which is later). However, as you've been inputting the whole boss fight instead of just the start, the game ends at frame 1300, which is faster.
Both options fullfill the criterium, but which one do you believe should be used?
Fair enough. As said, I'd say that the run that completes the game fastest is the one that should take precedence. The main question is: When it is acceptable to end the input of said run? And the answer is: At the moment where no further input would make the game end faster.
Anyway, this seems to be a rather exceptional case. I have never opposed the idea of having special exceptions to the rules for individual corner cases. On the contrary, I have always supported it, in cases where the exception is justified. Rules should be flexible to accommodate special situations they might not cover well. (Also, such exceptions in no way imply creating precedents.)
Joined: 4/17/2010
Posts: 11477
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
fsvgm777 wrote:
I remember that I never liked how this TAS ended (as evidenced by this post of mine) (for the record, I still don't). For me, a movie should end as soon as you lose control of your character. Of course, exceptions can be made, if the end result is something funny (which is not the case in Rockman 4 MI to me, since it just looks out of place, though I was pretty much the only opponent to how it ended).
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.
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.
I will ask one thing: Why is a controller with no buttons pressed a special state that doesn't need to be counted as part of the movie time?
I do have an April Fools' TAS where I pick a default state other than null input, in order to cut down on the movie time. I didn't expect acceptance, hence the timing of submission. I don't disagree with its rejection, but this post isn't about the fact that a nonstandard default controller state was used. Rather, it's about the fact that ending a movie short is relying on some default controller state to finish the game, no matter how much it extends the time, simply because we're looking for a number that has nothing to do with the game itself.
Why is leaving buttons unpressed a desirable thing, when further input can reach the credits faster? Is it because the input movie length is shorter? While we may feed a shorter list of input to the emulator, the game's completion is delayed. If one is looking to find a game completed as fast as possible (as currently known), the null input where non-null could do it faster denies such fastest completion.
I suppose the biggest problem here is: How do we automate time to game completion? We can measure the length of the movie file, but not the length it took to get to the ending or credits, at least automatically. What puts time to game completion even further behind in consideration is the fact that the number of input frames is used and displayed as time taken in just about everywhere. Do we take the ease and automation of a length of a file as the one stat to focus on?
When the game gets to the credits isn't a direct result of how long the input file is. It's a result of the run leading up to it. The games we run doesn't make the distinction of input file length. I consider blank frames after your input list to be part of any run, just as much as if you had actually padded your movie file with them.
So far, most of my published TASes required some input that had a direct and immediate effect to reaching the ending or credits, and there really wasn't an opportunity to make a decision on whether to shorten the input time or the time to reach credits. But I still have a strong preference to what I want to aim for in the end, should I be given the choice from the games I run.
I want to beat the game as fast as possible. If I can add further input to make it so, I will do so. Just because I have enough input to coast to the end doesn't mean that said coasting is the fastest path, I will look for a way to speed things up. Just because there is null input after the end of my input list doesn't mean that null input isn't part of the resulting movie. After all, people are going to watch it. That is how I view things.
The most important reason to measure the length of a run by how many frames the keypress input file has is a practical one: It makes automation of the website easy. The website can automatically show the length of the run without knowing anything about the game and without the need to determine what constitutes the "ending" of a particular game. It also makes comparing lengths infinitely easier.
From this, however, the focus of some runners has shifted from finishing the game as quickly as possible to making the keypress input file have as few frames as possible. In the vast majority of cases the two are the same thing, but in a few cases they are not.
I certainly do not disagree that making a game finish with a keypress input file that's significantly shorter (in frames) than the actual resulting length of the game (iow. the ending is just left to finish on its own for a significantly long period of time) is interesting. However, I feel that this loses the main focus of speedrunning: To finish the game as fast as possible, not to make an input file that's as short as possible.
The keypress file is a mean to an end, not the end itself. The keypress file itself should be inconsequential.
However, since it's very rare for a game to be finishable with a significantly shorter input file than the game's length, this isn't such a big deal to make a fuss about, I'd say. Live and let live. Rules should be flexible.
I'm strongly in favor of shortest input.
As a viewer, I MUCH prefer to see clever use of the environment/physics/items to set up an input-less boss kill than just more standard play - bosses in TASes tend to be pretty boring anyway. It adds a neat, TAS-only goal that increases the feeling of having total control over the game, even in the future :)
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.
Therefore, I can see an argument for "shortest time to no required input change". This would usually be the same, but would sometimes allow for neat things where you hold right and A or whatever for a while, and do things on "autopilot" for a bit at the end of the run without it counting towards the time.
However, this would probably be way too counterintuitive and weird for most people, so I think we should probably just stick with the current definition of shortest input :)
A warb degombs the brangy. Your gitch zanks and leils the warb.
Let me share my point of view. I think there's no need to make specific endpoint rules.
The main goal of a TAS is to complete the game as fast as possible. This means that the TAS has enough button presses to make the game reach it's credits.
Using the Defender of the crown TASes as an example, the published one requires fewer input to finish the game to reach the ending while the submitted one requires longer input to finish the game and reach the ending faster.
Baxter wrote:
Games like Defenders of the Crown make you wonder what our real goal is though, to provide TASes that completes the game as fast as possible, or to provide the shortest possible input file.
The published one makes those actions and end them as earlier as possible that will "guarantee" a success completion of the game.
I would say you should always aim for shortest input as long as it meets the goals (so TASes targeting smallest in-game time don't need to aim for input length too).
If we would have specific endpoints (1st ending screen, 1st frame of changing some memory value that only occurs when ending is being loaded, etc) it would be too ambigous and I believe that "completing" a game is a process and not a specific state that you aim to bring it as fast as possible to clarify yourself about the end of this process.
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.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Maybe a more proper name for the topic would be "Input time vs Output time". Because AVI time depends on the publisher logo and the time he decides to spend on the ending screen.
FatRatKnight wrote:
I will ask one thing: Why is a controller with no buttons pressed a special state that doesn't need to be counted as part of the movie time?
Actual state does not matter. The thing that matters is that the state is final and does not change anymore, but the game still finishes on its own.
Some may remember that FCM movies store joypad events instead of a simple log of button states. The size of FCM files is much less than the size of binary FM2 files after conversion. You could call this a kind of lossless compression, because FCM files remove redundancy and only store the necessary data - the actual essence of a TAS movie.
FatRatKnight wrote:
Rather, it's about the fact that ending a movie short is relying on some default controller state to finish the game
No-no-no, ending a movie early is relying on the fact that the game can be finished without any further interaction.
FatRatKnight wrote:
Why is leaving buttons unpressed a desirable thing, when further input can reach the credits faster?
Clarifying: leaving buttons unchanged is a desirable thing, while further modifications of the controller state are optional.
Dropping the controller is an amusing thing that has something to do with data redundancy, entropy, chaos theory and other poetic matters. It's very TAS-tastic.
Further input changes give you more advantages, so it's not as interesting and definitely less challenging. We may as well use lots of coins in arcade games, just because we can. But last I checked, TASVideos enforces 1-coin TASes, because they look more cool. Ending input early is also cool, because it's often impossible to do without tools.
FatRatKnight wrote:
Is it because the input movie length is shorter? While we may feed a shorter list of input to the emulator, the game's completion is delayed.
Well, since I like playarounds more than pure speedruns, and I often support speed-entertainment tradeoffs, therefore I don't see any problem in delaying the game completion for the sake of showing some neat trick.
Honestly, the game completion is kind of rudimentary feature of TASing. Sure, we need it to invoke the feeling of closure, but the content of TAS is more important than AVI time (when it's reasonable).
I often enjoy reading detailed submission texts more than watching the actual movie, because I wonder which creative solutions the TASer invented being under pressure of certain restrictions (either game-related, or self-imposed, or community-imposed). The need to stop input as early as possible (because previous TASes of the game decided it) is one of such creativity-boosting restrictions - it's clear, reasonable and gameplay-related (which makes it fun).
Output-based definitions are better suited for SDA, not TASVideos.
FatRatKnight wrote:
I consider blank frames after your input list to be part of any run, just as much as if you had actually padded your movie file with them.
Sure, feel free to consider those blank frames to be part of the input log.
Meanwhile, I only consider those frames until the last change of buttons state. So, for example, if there are actual empty frames at the end of the movie file, I only consider the very first of them to be a part of the run, because after the frame the controller state doesn't change (not while the movie is still playing and not after it stops).
MESHUGGAH wrote:
The main goal of a TAS is to complete the game as fast as possible. This means that the TAS has enough button presses to make the game reach it's credits.
Uh, it works both ways:
"The goal of a speedrun is to complete the game as fast as possible. This means the run must reach credits in the lowest amount of frames."
MESHUGGAH wrote:
For vault, I would say shortest input should be used and other tiered TASes should aim for the more entertaining version
Indeed, Moons/Stars are out of question, but the nature of the Vault just asks for some strict rule.
Actual state does not matter. The thing that matters is that the state is final and does not change anymore, but the game still finishes on its own.
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 fact it uses a password makes things more questionable, but it technically completes a game faster than the King's Bounty TAS with that definition.
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? (There might be other reasons for rejection -- One stat I use might be seen as a debug value rather than a glitch value, considering the effects)
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. 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, but I believe if such an "improvement" TAS shows up, judges will reject it for not actually doing anything new (or significantly different) compared to the old TAS. But that's an extreme example.
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. Again, I only picked blank input as that's the standard I believe is used here, and that I also believe it is most widely understood around here.
AnS wrote:
Well, since I like playarounds more than pure speedruns, and I often support speed-entertainment tradeoffs, therefore I don't see any problem in delaying the game completion for the sake of showing some neat trick.
As for speed-entertainment tradeoff, I'm fine with those, should the runner choose to have a few. I'm less fine if the runner makes a significant point about avoiding speed-entertainment tradeoff but then proceeds to delay the game completion for the sake of a shorter input list. Though, I do understand the argument for a shorter input list, as that's the most consistent thing we can measure by.
An amusing thought: What if the principle of 'TAS timing ends as soon as you can put the controller down'?
100 meter sprint: Timing ends as soon as you stop exerting with any of your muscles.
Speed chess: Timing for your turn ends as soon as your fingers are no longer in contact with the piece (flinging the piece to its intended final destination is recommended as a pro tactic for saving milliseconds off the timer)
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?
