Completion time

This movie aims to bankrupt the CPU player in as few frames as possible, unlike other movies which aim for lowest input frames. From power-on to bankruptcy, this movie is 766 frames faster than the published movie. However, it is also 27 frames faster in terms of input. This is not the lowest number of frames possible, that would be this movie by FractalFusion. That movie is faster in input frames but much slower in terms for the actual ending. Here is a chart to help:
MovieInput FramesCompletion Frames
Acmlm18022779
Hero of the day16943793
FractalFusion16255971
adelikat17752013

Strategy

This movie utilizes trades, a glitch, and a new innovation I discovered to bankrupt the CPU. An interesting note is that this is the first monopoly submission that does not depend on "stacking the deck" on the community chest or chance cards.

The Glitch

In a trade, a player will set up the trade that they want and click "Yes". At that point the other player has a chance to say "Yes", "No" or set up a different deal. If they say "Yes", the trade is done and final. If the CPU is the first to say yes, you have the option of menuing out of the trade and doing things such as mortgaging properties. However, there is a glitch/oversight that if you mortgage a property and return to the trade, the CPU will still be set to yes! (This also works against human players, if you want to be savage. And not have friends). Monopoly speedrun strats then involve offering a trade to a CPU that's a bit too high for them, causing them to counter by adding a new property from your list or more money then saying yes. This is generally a bad deal for you, but if you can mortgage all the properties, you end up with the advantage.
The innovation that is the basis for this movie is rather simple. Set up a trade that the CPU would agree to, then simply click "No" instead of "Yes"! The CPU will immediately then say Yes to the deal. At this point, you can do the mortgage glitch. In normal play, this is completely breaking as you can set up an even trade of many properties of the same color (The cpu will always agree since they see this as even), then mortgage all your properties.

The setup

If you receive a mortgaged property in a trade, you must either unmortgage it or pay a 10% tax immediately. So the strategy is to set up a trade where the CPU has no money, and only mortgaged properties, at which point they will be immediately bankrupted.
To do this I set up where I go first. Then I roll a 12, 12, and 4 (but not 2+2 as that would go to jail). This gets me both utilities and a red property. Ollie will agree to nearly $1200 for both utilities and as much as $300 for a red. So I set up a trade of these 3 properties for $1500 and then do the mortgage glitch to immediately bankupt him

Possible improvements

  • Another route I tried was to stack the chance deck to have an "Advance to nearest railroad" card. Then do 12 + Electric Company, 10 + Chance card that advances to B&O Railroad, 5 + Water works. This has better odds since 10 is much more likely than 12, and 5 is much more likely than a non-double 4. However, the sound and animation on the card made this overall slower
  • There's always a chance to get less delay frames to get the desired result, however, I tried a variety opening menu setups that can yield a different RNG. This one is surprisingly few delay frames overall (about 12).

Is this movie an improvement?

That's surprisingly complicated here. Yes it is faster in input and completion times. However, the controversy might be that the published movie is a "Pure" movie that does not exploit the CPU . That strategy would work in any version or even over the board, if given sufficient luck (or cheating). This is potentially important as this noob suggests.
However, I would argue in favor of this movie. It exploits a glitch (always nice), and exploits this specific version of monopoly and its nuances (otherwise, why do NES monopoly as opposed to any other version).

Nach: This movie is faster than the published run, and the audience also found it entertaining, therefore it should be accepted to Moons. However, this movie is slower than other submissions going purely by frame time, which opens up some questions regarding whether this beats existing records or not.
We've always allowed players to end their input wherever they wanted, as long as the game eventually completes without further work. However, how do we handle a trade-off when one submission is faster than the other using one benchmark but is slower in the other?
The author of this movie is arguing here that the fastest end time should take precedence over faster input time. For this other movie, the author is seemingly arguing that fastest input time should take precedence over faster end time. In fact there, the difference is over 20 minutes! You cannot have it both ways.
Looking at how we've handled things on the site previously, we've never allowed an improvement that only improved by ending input earlier. That is not considered an actual game-play improvement. However actually playing the game differently to allow it to end sooner while using more input has not previously been handled to my knowledge.
One reason to prefer shorter input is because it can be more objectively measured. Less input is clear. While determining which has the earliest ending requires viewers to measure the point they consider the game to be completed. While this is less objective, there generally is consensus about where this point is in most games.
Seeing the discussion thread here, as well as some other cases where this was discussed in the past, it appears the majority of our viewers prefer the earlier ending over less input. This is even more apparent when the earlier ending is more entertaining. We even have a case where a longer movie frame-wise which did nothing other than add a few frames to reach the ending sooner obsoleted the earlier movie. In this case here, the whole game-play to the end of the game is actually faster. Therefore, I am accepting this, and considering it to beat existing records.

feos: Pub.


TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 15527
Location: 127.0.0.1
This topic is for the purpose of discussing #6587: adelikat's NES Monopoly in 00:29.53
Spikestuff
They/Them
Editor, Publisher, Expert player (2630)
Joined: 10/12/2011
Posts: 6435
Location: The land down under.
But 2013 was 7 years ago. I guess... Yes Vote, this one doesn't overstay its welcome which is nice. Also shotgun for pubs.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. Something better for yourself and also others.
nymx
He/Him
Editor, Judge, Expert player (2227)
Joined: 11/14/2014
Posts: 927
Location: South Pole, True Land Down Under
You know my thinking, improved TASes...I say Yes. :)
I recently discovered that if you haven't reached a level of frustration with TASing any game, then you haven't done your due diligence. ---- SOYZA: Are you playing a game? NYMX: I'm not playing a game, I'm TASing. SOYZA: Oh...so its not a game...Its for real? ---- Anybody got a Quantum computer I can borrow for 20 minutes? Nevermind...eien's 64 core machine will do. :) ---- BOTing will be the end of all games. --NYMX
EgixBacon
He/Him
Player (184)
Joined: 4/15/2013
Posts: 331
Location: In the attic
Spikestuff wrote:
But 2013 was 7 years ago. I guess... Yes Vote, this one doesn't overstay its welcome which is nice. Also shotgun for pubs.
Oofff, where has the time gone? And yes, I also approve of the Glitch-opoly.
FanFiction|Youtube Still on Win7! Take that, Microsoft!
Joined: 11/15/2004
Posts: 804
Location: Canada
Exploiting glitches is fair game. Yes vote.
TASing or playing back a DOS game? Make sure your files match the archive at RGB Classic Games.
Banned User
Joined: 8/2/2017
Posts: 89
Location: Brazil
Yes vote but i think this TAS is going to be rejected since board games TASes isn't allowed anymore in tasvideos.org
Cuphead TASes desyncs unfortunately.
Noxxa
They/Them
Moderator, Expert player (4107)
Joined: 8/14/2009
Posts: 4089
Location: The Netherlands
Bluely wrote:
Yes vote but i think this TAS is going to be rejected since board games TASes isn't allowed anymore in tasvideos.org
This only applies to the Vault. It does not apply to Moons (which all currently published Monopoly movies are in) or Stars.
http://www.youtube.com/Noxxa <dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects. <Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits <adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3806)
Joined: 11/30/2014
Posts: 2827
Location: US
It's significantly slower then the one by FractalFusion and I don't really see the point of moving the goal posts here. It's an interesting glitch I guess though.
Mitjitsu
He/Him
Banned User
Joined: 4/24/2006
Posts: 2997
I agree with Alyosha, this movie amounts to changing the yardstick.
Player (13)
Joined: 6/17/2006
Posts: 506
First of all, Yes vote for entertainment. Second, I'm with adelikat about this movie being faster that the current one. In my opinion, completion time should have priority over input time. I understand that measuring movies by input time is more convenient, but I don't think it should be the primary goal. To be more exact, my opinion is that the primary goal should be reaching a specific state at the end of the ending sequence as fast as possible. I believe this is the best choice, as this particular goal prioritizes getting to the very end of a game over everything else. Third, I do not understand Alyosha and Mitjitsu's objection, as I could not find any Monopoly judgement that prioritized input time over completion time. In fact, it appears that Hero of the day and FractalFusion cancelled their submission for that very reason. Finally, given that this run abuses a glitch that goes against the actual Monopoly board game rules (mortgaging properties after the other party agreed to trade them), it's worth considering whether a separate category is justified here. In my opinion, it is for that very reason, and since both movies offer completely different content, they are in my opinion justified to coexist.
Joined: 2/27/2011
Posts: 69
Location: Calgary, Alberta
I have a soft spot for Monopoly and the NES version. I approve of finding a glitch although I hate the CPUs offering trades all the damn time so it's good to get back at them :P I voted yes and I would obsolete the acmlm run leaving this and the 4 CPUs run which is still amazing :P
Joined: 1/27/2014
Posts: 181
Interesting video! Thanks for putting it up adelikat.
Personman
Other
Joined: 4/20/2008
Posts: 465
This is kind of a weird situation, since the only unfavorable comparisons are cancelled. It seems like it's definitely good for this site for this to be published one way or another, since the currently published movie is now obsoleted three different ways. 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. So I guess honestly my realistic preference here is to fudge the "beats all known records" rule slightly, and replace the published movie with this, but retain the link in the description to FractalFusions cancelled run. Alternately, FractalFusion could just submit that run again, and that could be published. Regardless of publication outcome, it's neat to have yet another Monopoly strategy. I was absolutely entertained and voted yes.
A warb degombs the brangy. Your gitch zanks and leils the warb.
GJTASer2018
He/Him
Joined: 1/24/2018
Posts: 299
Location: Stafford, NY
Personman wrote:
Alternately, FractalFusion could just submit that run again, and that could be published.
The problem with that idea is that FractalFusion's run is from mid-2006 using a very old version of FCEUX (0.98.16). I highly doubt any judge is going to seriously consider any submission made on an emulator version from 13-14 years ago, and judging from the cancellation notes I don't think FractalFusion is likely to be persuaded to try to replicate the run in a more modern emulator version.
c-square wrote:
Yes, standard runs are needed and very appreciated here too
Dylon Stejakoski wrote:
Me and the boys starting over our games of choice for the infinityieth time in a row because of just-found optimizations
^ Why I don't have any submissions despite being on the forums for years now...
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3569)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
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.
It's hard to look this good. My TAS projects
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3569)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
GJTASer2018 wrote:
The problem with that idea is that FractalFusion's run is from mid-2006 using a very old version of FCEUX (0.98.16). I highly doubt any judge is going to seriously consider any submission made on an emulator version from 13-14 years ago
This is nonsense. First of all, FCEU isn't notably less accurate than FCEUX (they are both bad). Secondly, the movie likely would sync on FCEUX and even BizHawk. If not, we could resync it. We have options here, and if there's a publishable movie hanging around in the queue, we could absolutely resurrect it.
It's hard to look this good. My TAS projects
Noxxa
They/Them
Moderator, Expert player (4107)
Joined: 8/14/2009
Posts: 4089
Location: The Netherlands
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 00:02.58 seconds earlier while the game ends 00:00.00 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. In any case, this movie should obsolete the published movie, as it's faster in all aspects, while none of the other movies beat it in all aspects - particularly not the aspect by which the currently published movie was selected over the cancelled alternatives, which is game completion time. (Also yes vote for entertainment)
http://www.youtube.com/Noxxa <dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects. <Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits <adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
Personman
Other
Joined: 4/20/2008
Posts: 465
adelikat wrote:
I am now watching a longer movie because you want to optimize the tasvideos submission parser's reported time instead of the real time.
Obviously people are going to have different preferences and that's fine, but I just want to point out that optimizing the viewing experience is a second-order concern. In the absence of speed/entertainment tradeoffs, the purpose of a TAS is to finish the game as quickly as possible, and it's what that means that we should be arguing about here. The "shortest time to goal state" metric is the most obvious one, and is clearly valid. 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! Personally, I think a one-minute input that results in a two-hour movie that plays itself to completion is dramatically more exciting than a half-hour input with a half-hour movie. I might not actually watch all two hours, but I'd love to read about it and skim through it to understand how it all plays out.
A warb degombs the brangy. Your gitch zanks and leils the warb.
DrD2k9
He/Him
Editor, Judge, Expert player (2210)
Joined: 8/21/2016
Posts: 1085
Location: US
My $.02 regarding timing convention between end-of-input vs reaching some 'end-game' point in the game's code: Having the metric for timing to be variable on a game-by-game basis makes much more sense than holding all submissions to either one or the other perspective. For some games, there could be equal value from both perspectives; just different methods of execution. My understanding is that this is how things currently are done on the site, if there's a consensus on the timing method used; otherwise shortest input is typically the default. As Personman said, the accomplishment of a 5 minute TAS for a 2 hour run is pretty superhuman, even if it may not be as satisfying to watch as a run that got to the end-game in 30 minutes but required input the whole time. I personally don't have a problem with 2 different Monopoly runs published. I can enjoy and be impressed by either variation for this game.
Memory
She/Her
Site Admin, Skilled player (1551)
Joined: 3/20/2014
Posts: 1765
Location: Dumpster
Personman wrote:
but I just want to point out that optimizing the viewing experience is a second-order concern. In the absence of speed/entertainment tradeoffs, the purpose of a TAS is to finish the game as quickly as possible, and it's what that means that we should be arguing about here.
Since when has this been the purpose of a TAS?
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Personman
Other
Joined: 4/20/2008
Posts: 465
Huh? Since always. I'm not actually sure what your objection could possibly be — I specifically mentioned the major exception, which is when speed is traded off for entertainment. Everything in my post was regarding situations where that's not happening.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Editor, Skilled player (1198)
Joined: 9/27/2008
Posts: 1085
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. I'm decidedly for the idea of getting to the ending faster. Despite this, I still ended input early for R.C. Pro-Am, as it ended the run humorously. My April Fools' Guardian Legend TAS took default input state in a different direction, by having a button on auto-hold rather than having it affected by the movie file. If we're waiting for null input, that will never happen, but the game ending does take place anyway. Unsurprisingly, the TAS was rejected (and misses the Vault criteria in at least two ways), but I feel the statement has some merit regardless. As an aside, the Dream Team Contest #6 could have a different winner depending on "ends input early" vs. "fastest game ending." My team won, but if it was ruled for fastest ending, our setup to get the boss to kill itself on our permanent damage box would have been worthless, and we would have been in second place (based on some memory of calculating things a while back). Looking back on this, with my outlook, I do feel like we deserve the #2 spot, but it still provided a nice demonstration of a glitch in the end, so I feel positive overall. I thought a bit of my history may add a little perspective. It's mostly been author's choice from what I understand. Input length is easier to measure, as it's practically automatic with the size of the file, but time to ending doesn't care about semantics of what input is.
Joined: 1/27/2014
Posts: 181
Regardless of the outcome of this movie, I'd love to see Fractal fusion's run resurrected so that it could be published. I watched that and liked it too. One other thing I'd also like to see is a redo of the bubble bobble movie that was cancelled before the current vault rules. It is totally publishable under current movie rules, but was withdrawn by the creator. Would it be possible to have the movie resubmitted and credited to the original creator? I don't believe there would be any required input changes in order to publish the moive as is due to the Vault change. (original rejection was due to bad game choice, 100 levels completed out of a 100 level game).
Aran_Jaeger
He/Him
Banned User
Joined: 10/29/2014
Posts: 176
Location: Bavaria, Germany
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.
collect, analyse, categorise. "Mathematics - When tool-assisted skills are just not enough" ;) Don't want to be taking up so much space adding to posts, but might be worth mentioning and letting others know for what games 1) already some TAS work has been done (ordered in decreasing amount, relative to a game completion) by me and 2) I am (in decreasing order) planning/considering to TAS them. Those would majorly be SNES games (if not, it will be indicated in the list) I'm focusing on. 1) Spanky's Quest; On the Ball/Cameltry; Musya; Super R-Type; Plok; Sutte Hakkun; The Wizard of Oz; Battletoads Doubledragon; Super Ghouls'n Ghosts; Firepower 2000; Brain Lord; Warios Woods; Super Turrican; The Humans. 2) Secret Command (SEGA); Star Force (NES); Hyperzone; Aladdin; R-Type 3; Power Blade 2 (NES); Super Turrican 2; First Samurai. (last updated: 18.03.2018)
Editor, Skilled player (1198)
Joined: 9/27/2008
Posts: 1085
Aran Jaeger wrote:
[...] Also for TASes that go by how soon the last frame with ''non-trivial'' input 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.
Absolutely yes on this detail, on the interaction of my viewpoint of what constitutes an end of the TAS, and the exclusion of all other possible metrics apart from input length. To get my viewpoint to work at all, the length of the input file will always be considered infinite, and therefore the metric imposed will always fail as we're unable to compare infinity. That therefore means the interaction of this metric and the measurement to game end is inherently flawed. As for the rest of the post, the take away I'm getting is simply: * TASVideos is a site dedicated to perfection of video games by removing the human element. * The non-null length of input can be trivially machine-verified. * The definition of the game's end is pretty arbitrary, pretty "human", in what makes it get to the big win. * * As an aside, some runs beat the final boss as simply a part of clearing their target goal, not the final endpoint. * Without a hard machine fit-all of determining the game's end, we can't remove the human element of determining when an ending begins. * The other metric of non-null input is what's left. Therefore, my preferred method of determining when an run ends (time to game's ending) is inherently mired in human limitations of what determines the ending. I don't see a problem with that. Most of my arguments really just boil down to human interactions. After all, we're making machine-perfect runs for us mere humans to enjoy. The human can readily identify when an ending happens. Or at least a good enough one. It's not up to the machine to determine when we perceive the ending. The machine can always determine the differences of lengths of input, and when all that's left is an infinity of null input. So the only (obvious) machine method of measurement would be these lengths. In the quest to remove the human part, this is what's left. Let's move on to the TASVideos tier system. We have Stars and Moons, and then we have Vault. The Vault category is the most rigid tier, as it doesn't depend on the human notion of entertainment. If the run is Stars or Moons compliant, then we're already in human territory, so judgement can be based on what ends the run "better," for whatever definition of better is to be used. For Vault, which strives to remove the human element as much as possible, I am left with a question: Is "time to ending" valid for being largely only measurable by humans? Normally, the difference between shorter input and quicker ending is trivial. Usually, most of the TAS in question remains intact, except for the last few seconds at the end. In the case of Monopoly here, the strategies are apparently widely different. Are we in Moons (or Stars) territory? If so, then we can side-step answering the above paragraph until another submission. All that really needs to be answered is whether the run appears better than the previous. = = = Unrelated to the argument, I enjoy seeing the CPU lose before they roll their dice for the first time. I'm always disappointed when there are after-ending activities like the high score naming, or even mini-games in credits, that are entirely ignored when the TAS finishes. After all, null input is still input...