Experienced Forum User, Published Author, Senior Judge, Site Admin, Expert player
(2126)
Joined: 11/13/2006
Posts: 2798
Location: Northern California
adelikat wrote:
My vote would be that it is a hard requirement that a verification file is required, in order for it to be accepted to standard. There's too many ways to exploit SRAM, for it to be considered Standard and not a fringe goal, we need the verification.
Verification would still be required for any and all SRAM-anchored submissions. On Discord, we were even discussing the possibility of attaching verification files directly to submissions and publications, which is something I definitely agree with.
Darkman425 wrote:
In general I can agree with having SRAM acceptance in standard since there's quite a number of games that lock full game features behind game completion, such as difficulty levels and characters that change how the game's played. Regardless of entertainment factor, those would generally be considered genuine categories outside of TASVideos worth exploring and should at least be in consideration. This would make less risk of making a TAS for something that takes literal hours to generate the SRAM that might be rejected on the grounds of entertainment.
This is precisely why I'm bringing up the topic, as I alluded to in my thoughts in the OP. There are still explicitly objective categories that require SRAM, it doesn't really make sense to continue locking SRAM-anchored runs behind Moons.
Darkman425 wrote:
On the idea of other methods of verification, the e-Reader for the GBA is an interesting case to think about. For Mario VS Donkey Kong, there are e-Reader exclusive cards that I can't generate SRAM for in BizHawk but I can in mGBA. With a little work I can generate SRAM in mGBA that's compatible with BizHawk. That isn't something that can currently be done with verification files but is reasonably repeatable with instructions for generating a valid save file. I could also use a cheat to do the same thing but since I know of a kind of time consuming but provable way to generate a certain game state without a verification file I feel it's a valid game state to work with. If there are New Game+ or other states that would take unreasonably long to generate but is achievable without making a verification movie, using extra tools to make the same thing is probably fine if there's solid enough proof that the game state can be achievable via proper means.
I feel like your example should be fine, in that it's verified in that the state is achieved through normal gameplay, and that it would be something that BizHawk should eventually be able to do itself but currently can't. At the same time, though, I think the process itself might be up for debate. It's more verifiable in this case since it's effectively mGBA to mGBA conversion, but if we allow something like that as-is we'd have to word it in such a way that ensures we don't have people thinking they can download and convert some premade save off the internet and have it be acceptable.
DrD2k9 wrote:
For now, I only have a comment on number 3:
I don't think we should accept SRAM that isn't obtainable through normal/TAS play (i.e. via hex editing in max stats that wouldn't be obtainable otherwise).
Right. Something like that would go no higher than Playground. I'd even encourage it to be made for Playground, to be honest!
DrD2k9 wrote:
While I understand the argument (and potential time benefit to the author) of being able to manually create an SRAM file that would be possible to achieve through normal play, I personally feel that we should still restrict SRAM anchored movies to provide verification movies.
I realize this may require more work from the author's position, but it would simplify judging. If a judge has the verification movie inputs, it's more readily determinable that the utilized SRAM is legitimate. If, however, verification inputs are not provided/unknown, the judge would then be tasked with first verifying the legitimacy of the SRAM before consideration of the submission in question could even begin.
Keep in mind that the verification file must itself also be verified by Judges. In the hypothetical case of a NewGame+ run that requires dozens of hours of setup to be completely optimal, a Judge would have to watch that file and ensure that it does in fact create the same SRAM state as legitimately as possible. In a way, allowing carefully monitored external tool usage might actually be simpler for both parties.
At the end of the day, I've always felt creating a TAS is almost always more complicated than judging one, and as Senior I would much rather have my process be more time-consuming and complicated if it means simplifying the process of the authors in turn. I want TASing to be as accessible as possible while remaining exactly as legitimate as before, and any way I can find to make that happen, I will at least consider. I understand your point, though. I don't want judging to be overly complicated, especially as someone who isn't particularly gifted in coding/assembly knowledge, but it's more important to me to widen the field of opportunity for the thousands of TASers out there than it is to keep the process of a handful of experienced volunteers as quick and easy as possible.
DrD2k9 wrote:
Much like Samsara, I tend to lean toward a wider acceptance of runs for publication, but there does have to be a line somewhere.
Hypothetical example; if i hex edit a savegame file for a DOS game to provide an longer than legitimately achievable invulnerability time, I could breeze through a game much faster than without that ability.
So if i provide a run that has that savegame situation without any verification inputs, the judge would first have to determine if that ability is achievable normally before they can even start judging the run submitted.
Even if someone provides a manually created SRAM while claiming it's indeed possible to yield that save information via real play, it still falls to the judge to verify that claim if there is no verification movie.
TL:DR In my opinion, SRAM should only be accepted with verification movies provided that create said SRAM state. The impetus for proving legit SRAM should be on the author, not on the judges.
If we were to allow external tools, cheats, hacking, etc, we would require the author to tell us what tools and methods were used in order to generate the save file or SRAM used in the run. Ideally, it would be a step-by-step recreation process that any of us can follow to generate the necessary verification, and it would be transparent enough to be able to pick out people trying to fleece us with illegitimate game states (such as your invulnerability example). Without an explanation, I feel as though we wouldn't be able to accept the run at all. To me, that feels like an acceptable balance between accessibility and complexity for both parties.
Your case in particular is interesting, because on a surface level it sounds both easy to identify as illegitimate, but also easy to overlook if the Judge isn't familiar with the game to begin with. A required explanation would help mitigate those scenarios, but I feel as though it could still be possible for an illegitimate run to slip through the cracks. New Judge guidelines can be workshopped here, and I don't even think it would amount to anything more than a little extra research. Your hypothetical invulnerability scenario would be disproven by just double checking a guide, or playing the game from power-on with no save. Judges would likely be more in the mindset of "something could be off" if they were given an externally hacked file, even if it was presented and explained in great detail, it wouldn't be too much of an issue to just codify that mindset into the guidelines.
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
You are allowed to start with premade in-game save data (SRAM) for categories that require it, though keep in mind that these categories must be entertaining enough to make it to Moons. This requires a verification file which must be provided along with the submission. The verification file must start from power-on and not be SRAM-anchored itself. It should create the exact SRAM state that's used in the submission.
This brings to mind three questions:
Should runs with SRAM be allowed as standard?
How should we be allowing SRAM usage in TASes?
Are there more convenient ways of handling verification?
I'd like to expand on each of these questions and offer my own thoughts. Spoiler alert: I support allowing more things!
1. Should runs with SRAM be allowed as standard?
I think the main complication with the rule in its current form is that we are explicitly saying that SRAM usage must be entertaining, which feels reductive to me. It definitely goes against the current direction of the site. The way I see it, SRAM does not remove the objectiveness of any given category. It just adds save data. While a point could be made that the varying nature of SRAM is impossible to make objective for a lot of games (think RPGs with New Game + carryover), that subjectivity only applies to the SRAM itself and not the underlying categories. NG+ any% is still objectively completing the game as fast as possible.
I don't feel the need to argue a case that I think everyone already agrees with, but I may as well give people the option to argue against it. My requirement would simply be that SRAM always remains a separate category.
On that note...
2. How should we be allowing SRAM usage in TASes?
This one's a bit trickier. Prompted by the Fire Emblem: Thracia 776 submission, this is about the varying ways that SRAM can be used in a TAS and whether or not said ways should be allowed. In FE776, when you have a completed save file, you are given the ability to speed up unit movement, saving several minutes across a run. The problem with this is that, as far as I'm aware, the rest of the run is unchanged.
This creates kind of a paradox with my requirement from the previous section: Is there a reason to have this be separate from a potential power-on run of the same category? There would be 100% content overlap, just that the units would be moving slightly faster in the SRAM run. In situations like this, where features unlocked with SRAM leave their respective TASes virtually identical to those without SRAM (faster movement, cutscene/text skipping), should we prefer one to the other, and if so which one should we prefer?
I'm really on the fence about this. The easiest way to handle this would be through superseding, i.e we accept the first one we get and obsolete with the other, but we still have to figure out what option we prefer. SRAM better fulfills the goal of being as fast as possible, though it introduces conflicts of "legitimacy", for lack of a better word, in that a run that starts purely from power-on can be instantly verified as legitimate while SRAM needs further investigation to prove that nothing unfair is being carried over.
I'd love to see some discussion on this. I might be overthinking it, but then again, I am Samsara, so me overthinking something is already a given.
3. Are there more convenient ways of handling verification?
Currently, all runs that require SRAM also require a verification input file that creates the exact SRAM state used in the main run. In most cases, this is just a full game playthrough, which can easily be done RTA with save states, but in some cases there's a lot more setup that needs to be done. Consider a New Game + run of an RPG where everything carries over: There's an incentive of getting all of the best items and equipment in the game and grinding to max level, perhaps even manipulating random stat increases to be their highest possible values. This could be an input file dozens of hours long, having taken weeks or even months to make. Is it reasonable for us to require that level of time, effort and dedication to a verification file? Granted, we would never require an absolutely perfect file, but as TASing rolls on, increasingly more complicated setups will be needed for runs to continue improving.
I'd love to find some easier methods for this, with the caveat being that any alternate method would still need to provide a legitimate game state. For example, maxing stats in an RPG through external methods (cheats, save editors, SRAM hacking, etc). It sounds reasonable at first glance, but one would have to verify that maximizing stats is possible to achieve legitimately through normal gameplay before it could actually be allowed.
This all comes together to form a potentially huge change for how the site looks at and accepts runs going forward, so I'd like to get as many opinions and alternate ideas as possible. Positive, negative, indifferent, it's all useful feedback to me. Please step in, share and discuss.
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Experienced Forum User, Published Author, Senior Judge, Site Admin, Expert player
(2126)
Joined: 11/13/2006
Posts: 2798
Location: Northern California
UI for moving runs from Playground to publication would be my biggest want, here. Vice versa would be nice (nersa) for the extremely rare occasions where a rule-breaking run slips through the cracks, but absolutely not a requirement. Otherwise, that all looks good to me.
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Experienced Forum User, Published Author, Senior Judge, Site Admin, Expert player
(2126)
Joined: 11/13/2006
Posts: 2798
Location: Northern California
I'm having trouble figuring out why this run was submitted. It's the same category as #7569: Chamale's GBA River City Ransom EX "alternate final boss" in 10:09.75, but nearly 20 seconds slower. The strategy change, while interesting, does not make up for the time loss in terms of how we judge submissions. Is there a possibility that this strategy could be optimized further and become the fastest run for this category? If so, is that being worked on in any way?
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Experienced Forum User, Published Author, Senior Judge, Site Admin, Expert player
(2126)
Joined: 11/13/2006
Posts: 2798
Location: Northern California
1UPMushroom wrote:
p.s. if samsaras reading this (im assuming she wont) would you mind giving me the fceux file of the any% and 100% tases? that would be greatly appreciated.
I work here, dogg. I'm always reading.
I don't have any of my old WIPs, if that's what you're asking, but the movie and submission files are very much available in the publications. I wouldn't mind getting back to doing this myself someday, but I'd greatly appreciate someone taking it on before me. It's been a long while, a lot of new things were discovered, and my any% improvement is definitely improvable even without the new finds. I'd love to help out as a co-author, I just can't see myself working completely solo on a TAS for a long while, especially for a game as complicated as Gimmick.
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Experienced Forum User, Published Author, Senior Judge, Site Admin, Expert player
(2126)
Joined: 11/13/2006
Posts: 2798
Location: Northern California
The ROM you used is good. In the future, check the bottom left corner of the BizHawk window for a green checkmark after loading a ROM to see if it's verified good or not.
I'll keep trying to work on a test file, but good lord this game loves crashing on me (and the boys). Should this submission be cancelled in the meantime?
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Experienced Forum User, Published Author, Senior Judge, Site Admin, Expert player
(2126)
Joined: 11/13/2006
Posts: 2798
Location: Northern California
I did some playing around with this.
First, it seems that simply delaying jumps can allow the faster special shots to hit the CPU opponents, even on Hard difficulty:
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.
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Experienced Forum User, Published Author, Senior Judge, Site Admin, Expert player
(2126)
Joined: 11/13/2006
Posts: 2798
Location: Northern California
dwangoAC wrote:
Note: I don't want to see content limited to just things I'm involved in or that come in through the TASBot community that's formed out of the adjacent "on console TAS content" work. I very much want to see a future where someone can submit something shown live and have it included regardless of where, so long as it's verified to have legitimately taken place at an event (online or otherwise). I'm of course well known as an inclusionist but I think we can find a happy balance. I'd also include the entire ambassador team in the list of folks with access to help validate runs submitted this way.
This would be the case, of course! I was primarily using you/TASBot as an example because of the prominence of the GDQ showcases, but it would definitely be open to anyone and anything that fits the criteria.
DrD2k9 wrote:
We need to find a way to officially recognize/publish these showcase runs that otherwise can't be processed through our standard judging process due to the need for extra hardware or external data only possible at such a live event.
This and the rest of the post are exactly why I want this solved as soon as possible, because it's honestly silly that we've gone this long without even considering finding a solution. It almost comes off like we're saying these runs aren't valid, even though they clearly are. Their validity just comes in a different form.
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Experienced Forum User, Published Author, Senior Judge, Site Admin, Expert player
(2126)
Joined: 11/13/2006
Posts: 2798
Location: Northern California
Alright, let's get some discussion in here. There's two questions to ask regarding this run and the state of this category in general.
1. Should we allow "maximum score" as a standard branch universally?
Currently, we allow it as a form of full completion, but this does not catch 100% of cases, which is a bit ironic for full completion, really. The proposed change to the rule here would just be to allow "maximum score" as a branch independently of full completion. We would likely lessen the rules on methodology in this case, maybe only disallowing unassisted infinite loops and ACE.
This change would also apply to timed games where the only objective method of competitive play is score. This could mean allowing timed sports games as well, but the mere thought of having that conversation again is giving me PTSD. We'll see.
2. For infinite games, how do we define "maximum score"?
Max score for timed games like Sharp Shot is easy to define, but what about games like this where play can be infinite? Some of the prior discussion in this thread has revolved around the nature of this game's score counter, and defining maximum score in relation to that counter is an important distinction for us to make, especially if we're going to broaden how we treat the category itself. In this case, the distinction is between the displayed score and the internal score counter. The display score is indeed maxed out and overflowed, but the game continues to internally keep track of score beyond that. Should we demand that a maximum score run max out the internal counter, or should we just stick to display score?
My personal stances here are "yes, allow max score universally" and "stick to display score", but I'd like to see other opinions. That, or a bunch of people agreeing with me. That also feels nice.
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Experienced Forum User, Published Author, Senior Judge, Site Admin, Expert player
(2126)
Joined: 11/13/2006
Posts: 2798
Location: Northern California
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 xxxxM for Movies, xxxxS for Submissions, and xxxxG 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.
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Experienced Forum User, Published Author, Senior Judge, Site Admin, Expert player
(2126)
Joined: 11/13/2006
Posts: 2798
Location: Northern California
TheAmazingAladdin wrote:
You can TAS Vita3K using libTAS!
Yeah, let's not do this. We don't need the massive text announcement, the stolen screenshot, and the complete lack of known and relevant information. It's heavily misleading.
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Experienced Forum User, Published Author, Senior Judge, Site Admin, Expert player
(2126)
Joined: 11/13/2006
Posts: 2798
Location: Northern California
Sorry I'm late to this discussion, I've had kind of an insane week and it's stunted my ability to think about video games in slow motion. I can post more detailed thoughts tomorrow, when it isn't Literally My Birthday Today.
feos wrote:
In my opinion most issues can be resolved by a rule like this:
In-game codes that add gameplay are allowed for a separate branch in Standard, as long as such codes are used optimally.
So I suggest adding this rule:
External codes that modify the game are judged as unofficial games if modifications are severe enough. Otherwise, external codes are allowed for Moons only if they unlock gameplay or content that in-game codes can't access.
These look good to me.
In general, I'm a very hard "NO" on allowing external cheats universally. The logistics of judging that would be impossible to figure out. Not for lack of trying: It's been a thought of mine for well over a decade, and I have yet to come up with a single passable solution. We have Playground now for that sort of thing. People can make their own rules, every run exists on entirely its own merits, and we don't need to figure out some kind of insane logic with cheat usage and obsoletion in order to keep things sane. The way the suggestion is worded right now fits in with the maximum I would personally allow. It limits things sanely and nicely.
I'm way more lenient on in-game codes, but there's still a lot of things that need to be figured out there. The suggested rule is pretty much perfect, though I could see it being relaxed even further in the future.
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Experienced Forum User, Published Author, Senior Judge, Site Admin, Expert player
(2126)
Joined: 11/13/2006
Posts: 2798
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 Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Experienced Forum User, Published Author, Senior Judge, Site Admin, Expert player
(2126)
Joined: 11/13/2006
Posts: 2798
Location: Northern California
This isn't a fun thing for me to remember, but: #4799: arandomgameTASer & Samsara's NES Chase in 01:15.61
Level 1 is even between the two. Levels 2, 3, 4 and 5 are slower in this submission. I see no differences in emulation, apart from a single extra frame of lag on the linked submission, likely due to the QuickNes core being used. On top of that, there's User movie #24955764634818867, which is much faster than both submissions.
Also, there's no 100% in this game.
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Experienced Forum User, Published Author, Senior Judge, Site Admin, Expert player
(2126)
Joined: 11/13/2006
Posts: 2798
Location: Northern California
Moons, absolutely, but honestly I'm starting to lean standard on this. We definitely need a discussion thread for allowing in-game cheats in standard as separate categories.
Given class changes are effectively a free action on the site (some changes to publications require an updated re-encode, class changes don't), there shouldn't be anything holding us back from accepting to Moons now and changing to standard later once we get that discussion going.
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Experienced Forum User, Published Author, Senior Judge, Site Admin, Expert player
(2126)
Joined: 11/13/2006
Posts: 2798
Location: Northern California
It's been... Just a bit of time, shall we say, since this was submitted. A slight bit of time, perhaps. Couple days, maybe? I dunno, I lost all grasp on time millennia ago. Since submission, a lot has changed regarding the site. Notably... The site itself, but also the evolution of how content is treated and accepted.
I'd like a fresh set of perspectives on this run, some new feedback (and even the repetition old feedback from people who already posted) to determine how to handle this run. Was it enjoyable? Does it differ enough from the published Genocide run? Is it something worth showcasing? That last one's a trick question. The answer is yes. But still, there's been enough time since submission and enough changes to the site that it's worth essentially starting over on feedback.
please do not take another 7 months ._.
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
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.
