Forewarning: I wrote this in a bit of a hurry. Information is based on my understanding of the situation and could be misleading or even wrong due to that. If so, it will be corrected ASAP.
#4947: dwangoAC, Ilari & p4plus2's SGB Pokémon: Red/Green/Blue/Yellow Version "Pokemon Plays Twitch" in 08:11.42
I'd love to end the OP there, just linking that submission, but I do feel more explanation is in order. Let's talk about why we currently can't publish these runs.
For those of you unaware, TASvideos procedure regarding judgement, acceptance and publication revolves around input file verification. The input file for a TAS is provided and a Judge verifies that it is legitimate first and foremost. Legitimacy here means availability, determinism, reproducibility, and ensuring that the file is presented as-is with no outside modification needed. This is why the GDQ showcases were a hard sell for publication for us at the time of the above submission.
The nature of the GDQ showcases means that these criteria for legitimacy cannot be met through the input file. To the best of my knowledge, every single TASBot ACE showcase outside of
the very first one has required a very, very specific setup of consoles, hardware and software that fall far outside the boundaries of the original game. The input files for these showcases were built specifically for the showcases, built specifically to be played back on console, and as such would not be able to be downloaded and reproduced by anyone at all. There are also issues with legality at times, in that certain showcases may include copyrighted content baked into the input file. This, notably, has been an issue for
some currently published ACE showcases as well.
There is a simple-
sounding solution to this: Make it so we don't need an input file for these showcases. However, that comes with a few caveats. The easiest one to deal with is that the site isn't currently equipped to handle submissions and publications without input files. This could easily be handled through dummy input files, with the only issue there being we would need to explicitly state that the input file is a dummy file specifically created to fit the site's need to have one.
A bigger caveat is that, well, it goes against how we've been operating for nearly 20 years. We would effectively have to redesign our standards of verification for these showcases to be able to judge their legitimacy without the need of an input file. Granted, I personally also find this to be an easy fix: These are console verified in front of a live crowd. In a way, they are almost
more legitimate than a decent chunk of our published runs. I have no qualms accepting them as-is, personally, but that is purely a
personal opinion, and not an
official stance from the Senior Judge. Defining the protocol for how we verify showcase runs would have to be a decision we come to together as a staff team, ideally with some community discussion.
So, well, let's have that community discussion.
I'd like to outline our potential plans for the present and future of handling the showcase runs.
Current:
Showcase runs are submitted by dwangoAC or any of the involved authors, using dummy input files to mitigate that requirement. The runs are taken as legitimate and verified by the nature of the live performance. They are accepted and formally published. The official encode would contain the entirety of the GDQ showcase, plus any additional material deemed appropriate by dwangoAC or any of the involved authors. Whether or not these videos are also hosted on TASVideosChannel is up for discussion. Publication descriptions would contain any additional information necessary to understand the runs.
Future:
Showcase runs are given their own URL code, i.e xxxx
M for
Movies, xxxx
S for
Submissions, and xxxx
G for
Games. Some proposed codes are
L (for Live),
D (for Demonstration), and
E (for Event). These would be added and maintained through an entirely separate UI from submissions, with the permissions to use it being locked to Admins and dwangoAC, potentially Senior staff as well. These would function identically to publications, just without the need to be processed through the submission system, and without the need for input files. Any formally published GDQ showcase would be moved over to this new system.
Other suggestions and ideas are more than welcome, of course.
I consider this high priority for us. I find it embarrassing that we are yet to finalize a way of making this work. I'd like to start implementing new procedures for this as soon as possible in order to correct this ongoing mistake. If you have anything to say, even if it's just "I support these plans", please say it.
Given how long it takes for the delayed shots to connect, this by itself should save a significant amount of time over the course of the run, assuming that every single shot could be made to hit, which I believe is possible. Different amounts of delaying and changed positioning should help with this.
What bothers me more is that the current strategy could also be heavily improved just from playing a little more aggressively. At around 0:26 in the encode, the CPU launches a delayed shot of its own, which you let hang in the air before coming down. It's easily possible to catch the shot as it hangs in the air and counterattack immediately:
In fact, across this entire first match, it doesn't seem like you move at all while the CPU is attacking, even though several seconds could be saved by doing so in order to catch their shots closer to the center.
I feel this needs a lot more work. I'll put together a file of a more optimized first match that should hopefully show what I'm talking about.
