Gameplay time disadvantages: Requires brute-forcing to prove validity of movie
I wouldn't say this would be a requirement. Giving the verification some leeway is perfectly reasonable IMO. In other words, if nobody can come up with further input that would end the game faster using a reasonable amount of work, the submission can be considered acceptable (in this regard.) Or even more generally: Unless someone can point out how the game could be ended faster (by appending keypresses to the file), then it's acceptable.
I don't think there's any need to be as strict as you suggest.
The reason why I believe brute-forcing needs to be a requirement for gameplay time is because perfect knowledge of a game is impossible. Over the years it has been proven countless times to never believe anything at face value for speedruns. Say, for instance, who would have thought possible to beat Super Mario World in less than 2 minutes from power on? Assuming a movie is valid based on current knowledge goes against that principle. If you want accurate times, you need absolute requirements based on zero assumptions.
Let me explain with an extreme example. Let's say that TASVideos transitions to gameplay time. One day, somebody figures out a super obscure way to interrupt what everybody thought to be a non-interactive cutscene and render a publication invalid, and it will turn out that the previously-obsoleted movie was actually faster. Sure you can correct the mistake, but it will not change the fact that the published record was a complete lie all that time. This is an unacceptable scenario in my opinion.
I honestly cannot understand what your point is.
We accept submissions as currently-best-known records even though we know perfectly well that the vast majority of them are not 100% optimal. We do not require for them to be provably optimal, just that a reasonable effort has been made by the author to get as close to it as possible, and that there's no obvious flaw that can be pointed out. This principle is sensible and practical.
I see absolutely no reason why the exact same principle couldn't be applied to "end the input where no further input can make the game end faster."
The reason why I believe brute-forcing needs to be a requirement for gameplay time is because perfect knowledge of a game is impossible. Over the years it has been proven countless times to never believe anything at face value for speedruns. Say, for instance, who would have thought possible to beat Super Mario World in less than 2 minutes from power on? Assuming a movie is valid based on current knowledge goes against that principle. If you want accurate times, you need absolute requirements based on zero assumptions.
Let me explain with an extreme example. Let's say that TASVideos transitions to gameplay time. One day, somebody figures out a super obscure way to interrupt what everybody thought to be a non-interactive cutscene and render a publication invalid, and it will turn out that the previously-obsoleted movie was actually faster. Sure you can correct the mistake, but it will not change the fact that the published record was a complete lie all that time. This is an unacceptable scenario in my opinion.
This reminds me of when I played 4-dimensional noughts and crosses at school. One of the rules we added was (understandably) that you didn't win unless you pointed out you'd won. You could call the movie suboptimal on the basis of nobody specifying a way in which it was optimal.
I guess it's worth looking at what sort of game would cause pathological results with each of the definitions:
Gameplay time: A game where there are two routes, one of which takes longer to get to the final boss but which turns the final boss into a slow autoscroller that can be completed with no input (and cannot be completed faster no matter what), one of which gets there faster but has to actually fight the boss (thus requiring more input). (This situation is also pathological with input time, but it at least fits the spirit of movie time; the problem is that the autoscroller route is faster in gameplay time when the spirit of the rules indicate that it should be slower.)
As I noted earlier in the thread, games that work like this actually exist (e.g. Rosenkreuzstilette).
Input time: A game in which it's possible to set up the RNG so that the game completes itself, then wait many minutes for it to actually complete itself. (I remember an April Fools TAS that did this with half a sports game, but sadly input was needed to move from one half to the next.) I can't think of any situations where input time gives an unexpected result, but some of the expected results can be unwanted by many players.
Movie time: A game in which it's possible to waste time in order to get a shorter end credits. Offhand, I don't know of any games that actually work like this (anyone have examples), but it would give quite an unsatisfactory result if it did happen.
In general, I think I'm in favour of allowing the runner to choose which timing method is used, like we do at the moment. What makes the most sense can depend on the game, and input time can lead to interesting "concept" TASes in the cases where it makes a big difference. (I think that that April Fools TAS would have been published if it actually completed the entire game.)
Gameplay time: A game where there are two routes, one of which takes longer to get to the final boss but which turns the final boss into a slow autoscroller that can be completed with no input (and cannot be completed faster no matter what), one of which gets there faster but has to actually fight the boss (thus requiring more input).
I really think you are reading more to the rule than there is.
The rule just answers the question "at which frame is it ok for me to end the input file?" It says absolutely nothing about what route to choose or what the length of the run should be. It's not intended to dictate things like those.
And even if it were, if there's one game in a million where it makes a difference, then we can perfectly well make a special exception for that one game. I see no problem.
Any timing method will dictate route, because if the timing methods aren't all equivalent (they aren't), it's going to be possible for one route to be faster on one method, and one route to be faster on another method. Just like input time favours routes which let you end input early, even if you have to go out of your way earlier to gain the ability to end input early, and encode/movie time favours routes that have a shorter end credits.
There's not a "reading more into the rule than there is"; there's just "comparing rules with each other". Some timing methods will encourage certain routes simply because those routes happen to be friendlier to the timing method. This isn't a deficiency of the methods; it's just a fact.
In order to determine which method is best, then, we look for what counterintuitive actions result from each of the possible timing methods. There are some no matter what you do.
There's not a "reading more into the rule than there is"
From the about one thousand runs currently published, in how many would you estimate that this rule would affect their route (or anything for that matter)? One?
Yes, I think you are reading more to it than there really is.
There's not a "reading more into the rule than there is"
From the about one thousand runs currently published, in how many would you estimate that this rule would affect their route (or anything for that matter)? One?
Yes, I think you are reading more to it than there really is.
Well if the timing rule doesn't affect the route, it doesn't really matter what you do; the run's basically the same anyway.
I think it affects many of the win-via-total-control TASes, but that's about it. (Do you aim for the start o the credits? Or the end of the credits? In the latter case, the fact that the game's been won is pretty much unobservable from the encode.)
Well if the timing rule doesn't affect the route, it doesn't really matter what you do; the run's basically the same anyway.
I don't know how I could explain this more clearly than I already have. The purpose of the rule is to answer the question "at which frame is it ok for me to stop the run?"
The goal is to give a simple, unambiguous rule that both makes sure that there's no extraneous input left at the and of the keypress file (to make automatic comparison of runs possible and useful), and that the game is still completed as fast as possible (via the route that the runner chose.)
The current rules on this are a bit vague, and the intention is to disambiguate them.
Since there are always exceptions and stuff, if we need a rule, I'd personally pick something like that:
"Aim for shortest input time by default. If you want to aim for another thing, like shortest avi time or ingame time for example, state it in the submission and explain the reason for it if you think an explanation is needed."
We have the viewers and the judge to deliberate in the end, if the goal is a special case (shortest input time can be a special case sometimes, I guess, but it's rare).
I think that time to completion is better than time to end input. Example that just popped up to me is a racing game, where you can lay off the gas and coast to an eventual victory.
I do not deny that some games have unconventional ways to end input way early, ultimately ending up with game completion. To me, this strategy would be classed as a speed-entertainment tradeoff.
I think that time to completion is better than time to end input. Example that just popped up to me is a racing game, where you can lay off the gas and coast to an eventual victory.
I do not deny that some games have unconventional ways to end input way early, ultimately ending up with game completion. To me, this strategy would be classed as a speed-entertainment tradeoff.
I didn't watch a lot of racing games TASes, but I think that's a typical example of "aims for ingame time". People like to see some speed records in these.
The Sonic games come to mind too.
I think that time to completion is better than time to end input.
Maybe, but the big problem with it is that it cannot be detected automatically (so that the website could automatically and accurately represent the length of the run). Moreover, with many games it's a question of opinion at which point the game has been "completed."
A semi-universal rule of thumb could be that the game has been "completed" at the point where it starts its non-interactive ending routines (that ultimately lead to the ending of the final credits, or whatever the game uses to indicate that the game has completely ended.) So it shouldn't be hard to agree that the input can be ended at this moment at its latest. (Of course there are exceptions to this with some games.)
The problem still remains, though: It's basically impossible to automatically detect when the game reaches this point.
The proposed rule addresses this quite nicely, IMO: It doesn't delay reaching that point, while still being quite unambiguous and easily comparable in an automated manner. In the vast majority of games it also coincides with the start of the non-interactive ending routines. (In the few cases where it doesn't, it isn't that important, really. The end result is still the same: The ending is reached as fast as possible.)
A semi-universal rule of thumb could be that the game has been "completed" at the point where it starts its non-interactive ending routines (that ultimately lead to the ending of the final credits, or whatever the game uses to indicate that the game has completely ended.) So it shouldn't be hard to agree that the input can be ended at this moment at its latest. (Of course there are exceptions to this with some games.)
This is the rule that SDA uses (for games with no accurate in-game timer), and it works reasonably well there. Probably the most common case where it fails is when a game has playable credits, but it's not clear what a TAS should do in that situation anyway.
