(Link to video)
Submission Text Full Submission Page
This submission is for Warlords for the Atari 2600. It's like a competitive version of breakout where you have to defend your own walls with a movable shield and attack the opponents. Our shield fell asleep on the job, but thankfully he was in the perfect position.

Game objectives

  • Emulator used: Bizhawk 2.8
  • Aims for fastest time
  • Aims for shortest final input
  • Uses "hardest" difficulty
  • Chardcore wins by doing absolutely nothing.

Comments

Well, yeah. We manage to beat game 14 (probably the "hardest" difficulty due to faster ball speed and no Catch function) by channeling our inner Luigi. The AI have a few patterns, and some of those patterns can be exploited by just... not moving.
By holding select and start for the desired number of frames, we can skip having to wait the 30 frames between select inputs and the final input has been cut all the way down to frame 17. The shield moves into place at the start automatically, that's not actually an input.
Final hit is scored on frame 43106, about 12 minutes into the video.
ALSO FLASH WARNING, a lot of the hits and kills cause flashing lights.

Memory: Claiming for judging.
Memory: replacing file with 376 frame improvement
Memory: So in some ways this submission is trivial but in others it is very much not. On the one hand it has very few inputs, basically all of them are menuing. We have rejected runs with a lot more input than this. On the other hand, ensuring that the game actually reaches the end does take a little work.
The response was surprisingly positive here for a game that largely plays itself. I find it kinda funny as a concept, a little long to watch but not heat death of the universe levels of long.
If a run aiming for fastest gameplay came along, either we'd have to consider the two runs against each other (which feels kinda eh), or we figure out how to accept both. Note that this does not and will never mean that a run that simply trims a few frames will be published alongside a run that doesn't. At best that would result in playground. At worst rejection. I would only ever consider it for cases where strategy greatly differs between TASes, but that's a discussion for later.
Honestly, even if this supposedly sets a precedent regarding triviality, it's one that is fine as long as people realize we cannot revisit all past runs at once.
Accepting.

despoa: Processing...

TASVideoAgent
They/Them
Experienced Forum User, Moderator
Joined: 8/3/2004
Posts: 13003
Location: 127.0.0.1
This topic is for the purpose of discussing #7509: ShesChardcore's A2600 Warlords in 00:00.28
ShesChardcore
She/Her
Experienced Forum User, Skilled player (1183)
Joined: 2/23/2022
Posts: 124
Location: MN
Requesting a judge replace the submission with this file which cuts the run down to 17 frames. I will not be making a new encode as the, uh, "gameplay" does not change at all from the submitted vid. https://tasvideos.org/UserFiles/Info/637894444560547687
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 690
Location: Chicago
I remember back when the issue of ending input early was controversial.
Memory
She/Her
Experienced Forum User, Site Admin, Skilled player (1409)
Joined: 3/20/2014
Posts: 1704
Location: Dumpster
OK so there's basically two concerns. First is "does fastest gameplay obsolete?" Personally I can see a case for both of them to be published since they would be very different, very least one should be sent to playground. There's the argument of "how do you know when it's different enough" and my answer is "by watching with your eyes". However, since there isn't a fastest gameplay run to compare against, this concern can be pushed till later. The second, and more pressing concern is what implications would accepting this to standard have on triviality and how we currently enforce that. We've rejected runs with far more input than this. The fact that there managed to be improvement is argument in its favor but it was "just" menuing. Personally I'd like to accept it to standard but does this more or less kill triviality as a rejection reason? Would we need to start revisiting old submissions that were rejected for this reason? Will people go "hey why'd you accept this, why haven't you unrejected my run that is way more complicated?" It is in a way Pandora's Box. To be honest a lot of that is sorta an excuse for inertia. The more we reject or maybe even accept to playground (if it gets moved to standard at any point, it will need to be encoded and published), the more runs will pile up. However, we do lack a lot of judging staff to go through submissions, let alone old ones. That is the tricky part. Do we make it a priority? Do we just say "we'll get around to the old runs when we get around to them"? Or do we put this off further? Personally I'm starting to lean a bit towards the "we'll get around to the old runs when we get around to them" approach but I could be missing something.
[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
Experienced Forum User, Site Admin, Skilled player (1152)
Joined: 4/17/2010
Posts: 10779
Location: RU
Dwedit wrote:
I remember back when the issue of ending input early was controversial.
That time is back! Wow this movie is a Goldberg machine. It simply gently pushes the ball that then takes 12 minutes to RICH while presenting you a hilarious comedy. I laughed several times, it's the funniest TAS I've seen in a long while. The main feat is gameplay that looks primitive but does in fact have variety for almost the whole time. You never know who loses next and when, and how long the opponents take to defeat themselves. At first it even looks like one of them is winning and maybe the whole thing desynced. And it's much more ridiculous to watch this in the emulator with input display, when you are already sure the actual input ended minutes ago, but keeps delivering. This movie is not trivial, even simply judging by the fact that it was revised a few times after considered finished, and quite a bit of time was saved since then. While the current input may be trivial to execute, it was not trivial to come up with it. Technically the same situation as with [4173] SMS Zool: Ninja of the "Nth" Dimension "game end glitch" by The8bitbeast in 00:21.61, the only difference is this game doesn't have a published movie yet. I also remember a movie where it was a meaningful question whether you aim for shortest input or fastest ending: #7123: Jigwally's NES Solitaire in 00:40.93.
feos wrote:
  • You can potentially delay the ending indefinitely with your shorter input. We wouldn't want t to watch a 10-second movie that makes the game end 10 hours later.
  • But you can't indefinitely speed it up in your ending-based movie. There's only so much you can do to end the game faster, and it gradually gets harder and harder to come up with new timesaves. You can't make it happen instantly.
  • And you can't indefinitely delay movie end to make the game end faster. After some point it becomes unnecessary.
So in terms of obsoletion criterion, ending-based movie is clear cut. I think for this game, judging movie optimality by when the game ends is a better idea.
There's only so much speedrun challenge to this game if one only aims for shortest input. When the only room for further optimization is those 17 frames, it's not hard to just go through them all and test them, checking if either of them leads to an ending at all. Arguably if there's some obscure combination of inputs that makes the game end even later, how do we judge it? Optimality becomes a moot concept when you sacrifice one important aspect to gain another. But if we aim for quickest ending, there's still a lot to optimize in the future. Aiming to actually win as soon as possible gives you minutes to work with, and after some time you can't make it end sooner by extending your input any further. Now the really hard question is whether we should prefer some approach to a given game or should we just start allowing both to co-exist. For me this movie is absolutely Moons, but I'm sure the ratings won't agree with my sense of humor. I'm not ready to allow both for Standard because I don't agree that they are de facto standard goals already. If you only have 2 options, and for every single movie you have to decide which to pick, it may become a part of your actual in-game goal, but it can't become a separate goal in and of itself. It can be a second version of any goal you set, depending on the game. I don't know if many people here would want to see every movie in 2 variations of how it ends. At the same time I can see unique value in both if they look distinctly different. How about this: If aiming for a different kind of ending can make the whole movie look different enough, then it's a proof it can work as a goal on its own and deserves a place in the Standard class. If it's just a minor variation of the main goal, it's up to the author and the audience which one to prefer.
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. If TASing is meta-play, TASVideos Movie Rules are meta-meta-play!
Experienced Forum User, Expert player, Judge (2227)
Joined: 5/21/2013
Posts: 413
feos wrote:
While the current input may be trivial to execute, it was not trivial to come up with it.
This sums up my thoughts perfectly. The solution is not obvious, so it shouldn't be considered trivial in the first place.
ShesChardcore
She/Her
Experienced Forum User, Skilled player (1183)
Joined: 2/23/2022
Posts: 124
Location: MN
I agree with feos regarding Moons. I was highly entertained by this video for which I haven't any bias and Memory should be receiving the bribe completely unrelated monetary donation soon.
Samsara
She/Her
Experienced Forum User, Senior Judge, Skilled player (1837)
Joined: 11/13/2006
Posts: 2644
Location: Northern California
Memory wrote:
Personally I'm starting to lean a bit towards the "we'll get around to the old runs when we get around to them" approach but I could be missing something.
This is my take on it, honestly. I have no qualms about runs like this being standard, but I recognize that setting that precedent here and now would mean a great amount of effort needed to re-judge things, and we can't reach that demand at the moment. Rule changes tend to be a lot of people bringing up their rejections and not a lot of people offering to help out with acceptances, after all. That being said, I don't think we should be delaying positive changes for very long. We should just be reasonable and forward with what we're able to do as a team, focusing on the present at the moment and popping back to the past when we have time to spare. As long as we keep a log of what needs to be looked at, and as long as the community understands that we're not omniscient superheroes that can and will automatically and instantly fix all our past mistakes, I think we can go ahead and make some changes now. My main issue is finding a way of making "fastest input time" an objective and standard category without opening the floodgates to things like taking a published run and slightly tweaking the ending input to be able to end it a few frames earlier. We sort of have some subjectivity in allowing "no major skips" runs as standard categories, though I feel fastest input time is a bit more of a minefield of subjectivity than that. It's possible we may have to delay actually figuring out concrete boundaries while also letting things through. We'll figure something out. Man, change is complicated. No wonder we refused to do it for almost 20 years.
TASvideos Senior Judge 💙 | Cohost
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Experienced Forum User, Site Admin, Skilled player (1152)
Joined: 4/17/2010
Posts: 10779
Location: RU
Samsara wrote:
My main issue is finding a way of making "fastest input time" an objective and standard category without opening the floodgates to things like taking a published run and slightly tweaking the ending input to be able to end it a few frames earlier. We sort of have some subjectivity in allowing "no major skips" runs as standard categories, though I feel fastest input time is a bit more of a minefield of subjectivity than that. It's possible we may have to delay actually figuring out concrete boundaries while also letting things through. We'll figure something out.
It sucks that games where in-game time would have been a great separate goal, sometimes don't actually have in-game time. It would fit so neatly here. It's also tough to redefine the system to make an exceptional case fit better. Maybe we need more freedom with exceptions in general? If a certain movie universally makes sense, but doesn't indicate which exact changes we need to make it a standard, maybe we simply need to see more of those exceptions first? Personally I still don't mind sending either of this game's movies to Moons, whichever one people like more.
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. If TASing is meta-play, TASVideos Movie Rules are meta-meta-play!
Post subject: Movie published
TASVideoAgent
They/Them
Experienced Forum User, Moderator
Joined: 8/3/2004
Posts: 13003
Location: 127.0.0.1
This movie has been published. The posts before this message apply to the submission, and posts after this message apply to the published movie. ---- [4717] A2600 Warlords by ShesChardcore in 00:00.28