Some general thoughts for the beginning:
Credits in general are variable for many if not most games, when credits can show different stats (game-time, highscore, and many other things depending on the game) or correspond to different endings story-wise (for when a game has a story), so it makes sense to look at them as a whole set of credit sequences.
And as soon as an input file (with active, non-trivial, strict inputs) reaches out to connect to some ''branch'' of what one may call the ''tree of possible credits'' for a game, then to me it makes sense to see a TAS but also in particular at least the from the game demanded activities on the player side for reaching the (proper) end of the game as finished at that point.
Another manner to be considered in which a TAS could reach out realtime-wise earlier to the credits while at the same time taking more frames to enter the credits (independent of how one would define the beginning of the credits among possible reasonable ways in which one may want to do so) could for some games be by changing the platform one is playing the game on, if the game is the same on either platform, except of possibly tiny framerate differences (
http://tasvideos.org/PlatformFramerates.html ) allowing to accumulate to realtime differences.
- - -
On the topic of the definition of what initiates the credits:
When it comes to what in particular one wants to define to be it that triggers the credits (provided one doesn't just define all frames past the last frame with non-vanishing input as part of the credits or some variation of that), one might then have to find something that is consistent over all or most games, and for games where there is multiple TASes that compete with each other and have different credits, one may have to hunt down the concrete routine or what it'd be that one may want to use to determine a reference for where all variations of the credits for a given game start (if such can be found). And then, since the game operates solely on its own towards the credits past the last frame with inputs, and if the reference frame for when the credits start wouldn't already coincide with the last frame that had (non-trivial) input, then that'd mean one would possibly have a whole collection of routines in the code that would constitute valid candidates as ''official references'' for when the credits start. So that for any routine that may be used as a reference for when credits start, one could find a whole chain of other routines before it and may have to decide between all of them. And once one would have chosen such a routine, one may have to make sure there's no way to beat the game with valid credits being triggered at the end that somehow skips either that specific routine or it's for credits triggering specified behavior.
The definition of where credits actually or ''officially'' begin or do not yet begin is also an important topic, I think. And for me, the set of all ''automatic game state chains/sequences'' at the end of a game that together define all viable, legitimate credits would always already start at the 1st frame of no input beyond which no input follows afterwards anymore. And how this influences how some TASes end up optimized in that regard (like SNES F-Zero with bouncing strategies in the final track; or using automatic damage to a final boss to kill it off and reach the credits) is a different question, separate from that. As such, on could just as much say the opposite, namely: The credits in adelikat's movie actually do not start earlier in this TAS (in the sense that the input work to trigger them ends later) than in FractalFusion's TAS (
http://tasvideos.org/1166S.html ), but much rather this TAS lacks some initial optional bonus content preceeding later shared parts of the credits that the other TAS covers (among a variety of branches of ways in which the credits may play out, which may eventually merge within some range of game-states-defining aspects). And for this particular game, in the credits, the actual name-giving aspect that makes credits the credits, namely the appraisal of the authors (
https://en.wikipedia.org/wiki/Closing_credits ) of the game (usually in the form of a list of names) at least according to the video that was provided doesn't exist and wouldn't be something one could use as reference in this case (and it looks like this appraisal is by game design placed at the beginning of the game, instead).
- - -
Declaration of Independence (between full game optimization versus optimization of ILs over the united states of a game over all game states):
For full game TASes, optimizing for the full game should obviously take the priority over the optimization of any individual levels (ILs) or pieces that are parts of it. The main reason is that the optimization of ILs (that could consist of almost anything, like tracks for a racing game, levels where 1 level follows another, fights in a fighting game, or generally a structurally coherent part or building block of a game that is clearly enough in many qualitative aspects separated from other parts of the game) may be (and certainly factually is in many games) incompatible with the goal of at the same time optimizing for the shortest total (input) time for the whole game, as there can be local sacrifices in terms of resources or other things that can make an IL take longer but save more time later. And on the flip side, one could intentionally make time sacrifices early on that get in the way of optimizing for a frame-wise earliest full game TAS completion, before one gets to a given IL that one wants to optimize, as having more resources or different RNG or just different lag behavior for an IL may be benefitial to optimizing it (in a realtime sense or in-game time sense). As such, if one would be interested in the shortest amount of time in which a game's IL can be done in TAS manner, then that should be separate, split from full game TASes, as having both (a without compromises optimized full game TAS together with all individual levels or separate blocks of it being individually optimized to the best they could be, no matter how one would change what comes before any of them) generally is just impossible. Because of that, IL optimization normally is in the way of a full game TAS and has it's place elsewhere separately, but not in a full game TAS, where one consequentially also shouldn't expect it.
Furthermore, for IL optimization, there is a tag on TASVideos specifically for this, which would be the
Single Level tag (
http://tasvideos.org/MovieClassGuidelines.html ) for non-standard TAS branches or goals (
http://tasvideos.org/Movies-C4000Y.html ).
Why would I write about ILs in here you may ask? Well, because some people may think of other problems that the ''soonest final frame with (non-vanishing) input'' goal for full game TASes may have (for example when it comes to racing games and the final lap of a final track), but the above would explain that from a plain optimization perspective this would be a non-issue, but may then only anymore come down to entertainment differences. And at least normally if a game's community is interested in what the fastest IL completion times are, they are interested in those times with respect to everything that can be done in the game to help lowering the completion time of an IL (or within some general abstract ruleset), but are not interested in the best times within which an IL could be completed within the context of a full game TAS that carries additional ''boundary conditions'' that restrict which options can be taken for an IL at all within the full game TAS without increasing the total frame count, which means that outside of a full game TAS setting the ILs typically could be done faster.
As such, at least from the perspective of ''making the final IL (whatever that may be for NES Monopoly) more entertaining to watch and consequentially keeping input usage going further than necessary'' for the the NES Monopoly game in particular, I don't think it is a game for which ILs are at the focus of interest by many people.
- - -
On the topic of generalisations & potential consequences:
If the concrete goal-change related manner in which this TAS may be seen as being in an obsoleting position with respect to the former alternative TAS by FractalFusion which was accepted and then later cancelled by FractalFusion (as one can see here:
http://tasvideos.org/1166S.html ) does end up giving rise to a new generalized fashion in which movie obsoletions are allowed to take place, then (depending on specifics) this may lead to a whole flood of obsoletions of older movies (for example I'd think there would be a lot of TASes that end at final boss fights and have inputs end as soon as the last attack is initiated that does the rest, and instead of letting the game play itself out that way one may likely in some of them be able to reach to the ''credits'' quicker by speeding up the final boss fight using further inputs, and maybe alongside this one may also in other games be able to use such a downtime near the end for showcasing glitches for which there otherwise would be no time). I probably could list up a number of examples of movies where changes may then be ''impending'', but I think that's not needed as people probably could think of or find example TASes that may fit into this case on their own easily enough.
So, if this TAS makes changes compared to a different TAS on the same platform and exact same game (including version), and ''improves'' it effectively solely by means of changing the ''goal post'' (i.e. swapping the ''soonest final frame with non-zero input'' goal to ''earliest frame of entering the credits'') together with adaptions to that and saving frames with regards to it over the other TAS that wasn't optimized for this purpose but for input frames, together with just introducing some otherwise not showcased or not incorporable glitch, would this then mean that TASers are free to go and look over the vast variety of published TASes on this site and apply a very similar reasoning to obsolete them that way and have a new TAS published over that, provided that this would be generalized as a rule for acceptable, priority-taking TASes in this manner over TASes with soonest ending input frames? Is that something that makes sense to do, even when obsoleting another TAS by such means may happen to be or feel ''cheap''?
- - -
Submission #1166:
http://tasvideos.org/1166S.html
[quote Submission #1166]For Monopoly, there isn't much point to fastest input anymore.
This submission can be beaten by a less entertaining run by 8 frames. [/quote]
I think such an 8 frames improved TAS should then be published and should be prioritized over this TAS, provided such an 8 frames improved TAS (over FractalFusion's cancelled TAS) were to be made and submitted.
[quote Personman]I personally love input length as a metric. I guess I'd be okay with switching which thing we care about on a game-by-game basis? I'd also be okay with them being separate branches when they are both interesting, but it seems that "having two monopoly runs published" is not a popular idea. [/quote]
I mostly agree with Personman on this, but I think that if the differences are just quantitative but not significant & in a qualitative manner besides the frame count difference, then ''soonest final frame with (non-vanishing) input'' should generally for all games take priority over ''earliest credits''. And otherwise (for the case that there would be significant qualitative differences) I'd be in favour of then making separate branches accordingly, over having 1 TAS obsolete the other TAS with their different optimization goals.
[quote Personman]The "shortest input" metric is compelling to me though because it centers the idea of the TASer as a superplayer — who cares how long the stupid old console takes to figure out that you beat it? YOU know know with certainty that you did, and are free to just walk away and start your next run. Now that's efficiency! [/quote]
I also agree with this, and it may also be used as point against the claim that one would have to wait or watch a published TAS then longer, which honestly is just a matter of lacking signal or declaration in a TAS video for the point in time at which inputs have ended, so that the audience would be able to know that the rest is something that plays itself from that point on, rather than being an optimization issue where a longer video time that includes all of the credits to play out (how ever one may define an end of the credits, but this would be less problematic and reasonable cutoff times can be found) would be counted against the TASer's efforts for frame optimization when it comes to concurring TASes.
[quote FatRatKnight]My own personal view is that null input is still input. Fact is, even if you drop the controller, you are still feeding empty input to the game.[/quote]
Empty input is the only kind of input where if one had to actually in person (let me call it ''traditionally'' or ''commonly'') play a game, one wouldn't have to be physically present for this and only this combination of input presses being present (admittedly though there would be ways in which one could use other tools to fix something to a button to keep it permanently pressed, but unless a game platform together with a game and controls were to already start out in such a manner one would then still have to set this up before it could be left alone). As such it makes sense to see it as the default ''effortless'', inactive input state, which is also how games usually go about interpreting the effect of it in the game by doing ''nothing''. It is not as if one could for any platform take all different combinations of buttons (including other input mechanisms like joysticks, of course) held and check (for every game and every combination of buttons that are pressed) which cases among them make the game not do anything interesting or any progress, and would then find a uniform distribution for this being the case for all different combinations of buttons being held in about an equal amount of times for each of them. No it'd not be like this, but rather one consistently would find the ''no input held'' combination to be the default for a game state that best corresponds to inactivity for what the game does. Also for TASes that go by how soon the last frame with ''non-trivial'' input appears (or one could say how soon the last strictly active input state appears), the ''no input state'' also being seen/interpreted as counting input for the length of a TAS would deem every in this manner optimized TAS to be unable to ever finish, effectively infinitely long on-going, and would mean all such TASes would be instantly unacceptable for TASVideos as the input file in that sense would keep having input for ever and ever as the input files (and associated videos) would never end.
[quote adelikat]I'm going to throw a very strong vote for completion time over input time. Very strong.
FractalFusion's movie is a slower movie than any I listed in the submission.
It's neat when someone cleverly lowers input time while still completing the movie as fast as possible. It adds a level of strategy and complexity. Shortening input but drastically increasing the actual completion time is not so cool. I am now watching a longer movie because you want to optimize the tasvideos submission parser's reported time instead of the real time.[/quote]
However, as you pointed out, FractalFusion's (by now cancelled but formerly accepted) TAS (
http://tasvideos.org/1166S.html ) finishes doing the work (in terms of non-vanishing inputs) needed the soonest afterall. The completion of the work (on the inputting tool-assisted player side) needed that leads the game into doing whatever it all goes through for the credits constitutes the completion time already. It is a standard procedure that blank frames after that are cut from movie files, as opposed to an individual game by game approach being taken in which the TAS files are meant to continue with blank frames up to some (in whatever manner determined) frame during the credits, maybe just before a part of what is displayed during the credits starts looping, or just before one would gain control over the game again by being able to jump back to the title screen for example. This is not how TASVideos handles TAS movie files. It is not accounted for in the Movie length (in frames and realtime) when it is stated next to a TAS (if it is on submission pages or the actually published videos which commonly show shorter completion times than what the actual length of the video is, and as sidenote on that, from this alone someone watching the TAS let's say on youtube can comfortably get to know when the input part of a TAS ends and the game solely playing itself begins) and at least from that perspective part of TASVideos' manner of documenting TASes isn't considered to be part of TASes.
[quote Mothrayas]In my opinion, ending input early is an interesting ending option, but only if the early input end outweighs the delay to the game's completion time itself.
In this case, if comparing this submission to FractalFusion's cancelled submission, FractalFusion's movie ends input 2.57 seconds earlier while the game ends 1:05.85 later than adelikat's movie. In my opinion, that's not a worthwhile trade. See also for instance Magician Lord obsoleting its shorter input equivalent, where the early input end also was not considered worth for how much extra time was added to game completion. [/quote]
But how would one even want to unambiguously (and maybe also decently accessibly to TASers so that it'd not be too much work to get information about it if one wanted to TAS a game) define ''game completion'' in an all (relevant) games overarching manner? To my knowledge it hasn't even been stated yet how ''game completion'' according to NES Monopoly's code with its instructions and routines is suggested to be defined for this particular movie submission.
And if one were to try to figure out some ''general unavoidable earliest merging point/game state for all possible outcomes for the credits'' for games in order to then define such a merging point as the beginning of the credits (for example if from such a merging point on most differences between different ways in which the game plays out on its own are gone), then I see a few problems that could come with such an approach (as ACE TASes may be able to skip otherwise unskippable points at which all variations of the credits would merge; and separately from that, glitches may be found later that prove some point that was thought to be a merging point wrong; or there may not exist just 1 merging point for all different credits and one might need multiple) and at that point one could only anymore wish good luck in determining/finding such a thing for all games.
- - -
I suspect that this may be even more of a direct manner of providing a TAS that may test the limits of the rules (especially as it's a TAS by a staff member and expectedly staff members are more interested in the specifics about TASVideos' rules, compared to if it were just any ''random'' TASVideos member's submission) in order to get more interest and as consequence feedback on it rather than being just a plain submission, but I may be wrong about that.
Sidenote: There's a typo (''backrupt'') in the video's description (
https://www.youtube.com/watch?v=gh7_2Jg-GjU ). I guess it may not be that important, but I thought I'd mention it anyway.
