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 💙 Currently unable to dedicate a lot of time to the site, taking care of family.
Now infrequently posting on BlueskywarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Emulator Coder, Site Developer, Site Owner, Expert player
(3571)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
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.
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.
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.
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).
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.
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.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
The main thing I wanted save-anchor to be allowed to Standard for was explicit "newgame+" modes, and it's the most objective thing. But just like with codes, there can be other in-game goods that are only unlocked post-completion, and I feel we should treat save-anchor similarly to codes that unlock things. So as long as it remains its own branch, it should be fine in both of those cases.
I don't want save-anchored movies to compete with power-on ones in Standard, because the former kinda give themselves a handicap which would somehow not count as a part of its completion time. I feel it's fair to instead have more branches. But in Moons, I think we can obsolete goals with and without save-anchor if they are too similar, and if there's consensus. I'd argue save-anchored would generally be more entertaining.
I can't come up with ways to verify legitimacy of save-anchor other than by making a verification movie, be it the author who makes it or the judges. I'd argue it's generally harder for judges to make one because they may see the game for the first time and be unaware of gotchas. Without a verification movie, what do we even compare the provided save-anchor to? Simply editing RAM to flip some flags may not be enough, even if there are online resources that explain how memory is mapped in a given game. In order to verify, we will need to complete the game ourselves. And even if we poke memory to skip directly to the final boss and beat the game that way, there's still too many variety and unknowns. I would not want that in Standard. But I may be fine with it in Moons!
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.
Hooray! I've been wanting some things to change regarding this.
1. Agreed 100%. When I was judging the Resident Evil 4 Mercenaries runs, I never liked that they had to be Moons to get published. A game mode is a game mode, whether it requires SRAM to unlock it or not.
I think the simplest way to allow these that would fit within our framework is just to consider them independent game modes. This would not only cover unlocked modes like the Mercenaries maps, but also New Game+ modes that are unlocked after completing the game. It also means that these modes could have their own Full Completion runs, or any other Standard category. Obviously a New Game+ run would be a separate mode from one with a fresh save file.
2. I think obviously we accept it as-is right now, but I think I might prefer the SRAM one, because it's faster and doesn't detract anything from the normal run? I can see why others might feel differently though, from a legitimacy standpoint. I also thought we were going in the direction of not superseding Standard branches even if content overlapped, so maybe both would be ok.
3. This is one where I don't think there's going to be a neat solution. I get that some SRAM can be a huge burden to make (some examples were brought up before that I forgot), but what's the alternative? Hacking the SRAM can bring up a host of issues, since you would still have to prove that such a state is achievable, which would need a complete playthrough of the game anyway. Sorry, but I don't have any good ideas on this at the moment.
1. Yes. Buuuuuuuuuuut...
2. I feel that the safest approach is to expand gradually. We don't want to overwhelm ourselves. So "safe" things to accept to standard earlier include unlockable modes, difficulties, and characters. Convenience things (cutscene skips etc) I could see accepting at some point to standard but maybe not right away. Any sort of glitched goals that involve sram need to be explained thoroughly for all classes.
3. So there's two different goals in play. SRAM verification movies can be annoying but absolutely provide legitimacy. Some sort of hacked save is more convenient, but lacks the potential legitimacy. IMO, a SRAM verification movie should be provided if it is convenient enough to do so. If there is a good reason for not providing an sram verification file, we can accept it on a case by case basis.
[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
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Memory wrote:
IMO, a SRAM verification movie should be provided if it is convenient enough to do so. If there is a good reason for not providing an sram verification file, we can accept it on a case by case basis.
To Standard?
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.
to wherever makes sense at the given time. I'd be ok with putting off accepting to standard tho in such a case and revisiting this later.
[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
Joined: 11/13/2006
Posts: 2822
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 💙 Currently unable to dedicate a lot of time to the site, taking care of family.
Now infrequently posting on BlueskywarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Emulator Coder, Site Developer, Site Owner, Expert player
(3571)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Good discussions. And in general, I'm not opposed to almost any decision here.
But, I still have hard line stance that to be in Standard, we must require a verification movie. Otherwise it can be moons (which needs a better name now but that's another discussion).
There's a deceptive amount of trickery (including unintentional) that can be done with just a random .sram file. There's an illusion of legitimacy compared to a savestate run but you can very much exploit sram in hard to detect ways. Standard should be for things that do no require this level of questioning and scrutiny. I'll leave this as exhibit A, and challenge anyone to be able to tell me why: #1039: Bisqwit's NES Mega Man in 00:19.55
#3519: RingRush's PSX Croc: Legend of the Gobbos "glitched" in 01:10.12 is probably a more infamous example of sram exploitation at this point. However, I think rather than being overly cautious about the 1% bad faith scenario, it would be better to build rules around the 99% good faith scenario. A lot of games lock things like modes, difficulties, and characters behind sram. It'd be far-fetched saying that using sram is a non-standard way of playing the game. Preventing movies that require sram from reaching standard means locking such goals behind an entertainment requirement that many cannot reach. Some only reach it barely.
While we absolutely should try to determine if sram usage is legitimate or not, mistakes might happen. However, I think that's fine. Plenty of mistakes happen. We sometimes accept runs that actually abuse emulator glitches. We sometimes accept runs that don't even beat the game. As long as we can replace these runs as they are discovered, I don't see this as necessarily a problem.
[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
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Memory wrote:
A lot of games lock things like modes, difficulties, and characters behind sram. It'd be far-fetched saying that using sram is a non-standard way of playing the game. Preventing movies that require sram from reaching standard means locking such goals behind an entertainment requirement that many cannot reach. Some only reach it barely.
I don't think anyone is against using SRAM-anchored movies in Standard. The argument was about whether or not we should require a verification movie for SRAM in Standard. While I'm absolutely for allowing simulation of SRAM effects via external tools in Moons, allowing that for Standard would mean something really daring: allowing external codes/tools for Standard.
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.
Standard should be for things that do no require this level of questioning and scrutiny.
I'm aware of what he said prior about not being opposed to anything but I wanted to address specifically the direction of standard.
[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
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Regarding directions, I agree that SRAM based goals are standard in the gaming world, but I'm not sure how standard SRAM simulation is. On SRC mods probably just judge by the effects, but how do they verify the initial info about those effects when accepting a new category?
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.
Regarding directions, I agree that SRAM based goals are standard in the gaming world, but I'm not sure how standard SRAM simulation is. On SRC mods probably just judge by the effects, but how do they verify the initial info about those effects when accepting a new category?
They don't think about it on that level. They mainly aim for just having the correct starting stats, possible starting equipment etc. They don't really check the integrity of it beyond that.
[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
Ok, I want to throw in my 2 cents on this since there's a project I've been working on that entirely relies on SRAM to make it possible.
In Club Penguin: Elite Penguin Force, there is a feature where you could download free additional content through the now defunct Nintendo Wi-Fi Connection.
Along with newsletters, the player could download 2 new missions and play through them. That's right, a Club Penguin Nintendo DS game had DLC capabilities.
The missions are called "A special message from Aunt Artic" and "The Puffle Pranksters". I'm currently making a TAS for The Puffle Pranksters.
The DLC itself is stored as a "download.arc" file inside of the save file itself, so if you delete your save data and start a new save, the DLC is deleted with it.
This is a DS game after all, it's not a modern game where the DLC is a separate thing from the base game.
Thankfully, both DLC missions have been preserved and archived and can be played on emulators.
Not to mention a tool called EPFExplorer lets you inject these missions onto any save file making them widely accessible.
In the context of making a TAS and submitting it to the site however...
All of this means is that making a verification file for a TAS for these missions is basically IMPOSSIBLE.
Since NWC is dead, and Club Penguin is also dead, and even if they weren't, it would still be impossible since it would require emulating the wi-fi features and making a movie out of it that has to consistently sync just to download a single mission from the menu and that is just not happening anytime soon.
So I'm basically stuck in a rather interesting position. It is actually one of the reasons why I haven't worked on this TAS for a long while. That and some personal life stuff but that's besides the point.
I had already made a TAS for "A special message from Aunt Artic" and submitted it for April Fools, since you can barely call that a mission:
#7062: dekutony's DS Club Penguin: Elite Penguin Force "A special message from Aunt Artic" in 00:16.78
The Puffle Pranksters is the only real DLC mission that was ever released for the game, and a TAS for this mission has been greatly anticipated by the Club Penguin speedrunning community. So the thought of it being rejected just for the SRAM situation is kind of underwhelming for me. Some of you may say: "Oh, then this movie would be a perfect fit for the Playground!"
Uh, here's the thing: ...No. I don't want that to happen either. I don't want this movie to end up in the Purgatory Playground, it just doesn't sit right with me...
At the end of the day, I really hope this save data issue can be sorted out eventually, I do however want to hear your thoughts about this very specific, weird situation.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
dekutony wrote:
At the end of the day, I really hope this save data issue can be sorted out eventually, I do however want to hear your thoughts about this very specific, weird situation.
If it's impossible to TAS this content without external tools, that sounds like a decent reason to allow them, as long as there's explanation on how to reproduce the correct save data. This feels okay because the external tool seems to aim to just replicate what was an actual working first-party thing, without any extra hackery. Ideally we'd have an explanation of why it can be trusted. But if there's no way to prove it with 100% certainty anymore, it feels like allowing non-good game dumps in cases when one simply cannot be found anymore (which we also allow).
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.
I'm still leery about dropping the verification movie requirement for Standard. I think the way that runs without SRAM need to be judged case-by-case. Extenuating circumstances should never be grounds for disqualifying a run, but I also think situations where making the SRAM is impossible is rare. We can deal with those as it comes along and accept dekutony's Club Penguin.
Joined: 11/13/2006
Posts: 2822
Location: Northern California
I will say that verification files, in some form, are always going to be strictly required for any SRAM submission. There are cases where a movie may not be possible (such as dekutony's Club Penguin DLC case), in which case we would work with the author to find the best way of handling that specific case.
As of right now, I feel that we've come to a good enough conclusion on what we want to push through right now. These are not official yet, but I will announce when they are:
SRAM will be allowed in standard publications.
- SRAM-anchored movies will be separate branches.
-- They will exist alongside clean branches even if there's significant content overlap, i.e a run that uses SRAM to skip cutscenes will be published alongside a clean run that does not.
- Verification movies are still required. Failure to provide one will result in rejection, unless it is impossible to provide one.
-- If it is impossible to provide a verification movie, the author and staff will work out a solution.
The following SRAM-anchored branches will be acceptable as standard publications:
- Unlockable modes, characters, and difficulties.
-- Assuming they can't be unlocked with in-game codes, of course.
- New Game +
-- This would include minor benefits such as text skipping and cutscene skipping, even if the rest of the run remains the same.
-- There's still a bit of issue with, say, RPG runs that have complete data carryover, but we'll figure those out when we start getting them.
- Glitched runs that rely on premade SRAM.
-- More meaning GEG/save glitch runs that explicitly need SRAM to work. For example, the aforementioned Croc submission would not count as the SRAM usage in that run was simply to load the completed save while the visuals were glitched.
- DLC missions and equivalents such as E-Reader, as long as verification is possible in some legally hostable form.
Verification movies are still a requirement unless otherwise impossible, in which case the author should reach out to us so we can work together to figure out the best possible solution. Verification movies will now be attached to publications using the Additional Downloads section (example here). Support for non-input files is an open issue and will be implemented in the future.
As far as I've read from the thread and followed up on with staff, the above is what the majority of the community has agreed on. Unless there are any objections, this will go into effect within the next week. Thank you all for your input!
TASvideos Admin and acting Senior Judge 💙 Currently unable to dedicate a lot of time to the site, taking care of family.
Now infrequently posting on BlueskywarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Joined: 11/13/2006
Posts: 2822
Location: Northern California
Samsara wrote:
Unless there are any objections, this will go into effect within the next week. Thank you all for your input!
Done! Thank you all once again for the input! I will leave the thread up for when I inevitably want to revisit the topic of verification, though this will likely not happen for a while.
TASvideos Admin and acting Senior Judge 💙 Currently unable to dedicate a lot of time to the site, taking care of family.
Now infrequently posting on BlueskywarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
- SRAM-anchored movies will be separate branches.
-- They will exist alongside clean branches even if there's significant content overlap, i.e a run that uses SRAM to skip cutscenes will be published alongside a clean run that does not.
Note: Starting from reset was necessary to use hard mode. However, doing so is normally not allowed — refer to the rules to see the reasons.
Both of these "full completion" movies start from SRAM to access the hardest difficulty, as pointed out in their (now outdated) footnotes. While they are both in Star class as of now, I suppose the former is actually Moon for having the "inbounds" additional requirement while the latter is Standard for being the, well, standard fastest full completion.
Now, if we take this rule word by word, wouldn't that mean the former can compete (or be competed) against a Normal difficulty clean movie for having a Moon goal while the latter cannot because it has a Standard goal?
(Note: Both of these movies also do take advantage of the fact that cutscenes can be skipped on replays compared to [1478] GBA Castlevania: Aria of Sorrow by Kriole in 20:58.62, but the fact that the Hard difficulty is not accessible without beating the game once means that's in a sense an inherent feature of it even if the difficulty choice is not done for that reason.)
[2658] GBA Castlevania: Aria of Sorrow "Julius mode, all bosses" by McBobX in 11:36.38[2876] GBA Castlevania: Aria of Sorrow "Julius mode, all bosses" by hellagels, KSeptuple & Pike in 11:52.03
Then there is the case of these two where the former, done on Normal difficulty, is obsoleted by the latter, done on Hard difficulty. This practice would still be perfectly in line with the new rules even if they might both be categorized under Standard with the new guideline. Why? Because they both require save anchor to begin with.
In other words, while having runs done on different difficulties obsolete each other is a rather standard and reasonable practice, we now have situations where that cannot be done when a difficulty choice is locked at first because that requires save anchor yet the same can be done for unlockable alternative modes in the same game because they would all require save anchors anyway.
With all these said, here is my proposal:
What if we limit the "SRAM-anchored movies would never compete against 'clean' movies under Standard" clause to the Fastest Completion types of categories only, or at least do not apply them to the Full Completion categories? While they are all categories under Standard, full completion is ultimately not exactly about "beating the game as fast as possible" in the most literal sense and is arguably less "sensitive" to certain differences that would have caused relatively bigger impacts to fastest completion runs in many cases.
Maybe that doesn't sound like a good justification for this specific proposal, but the general idea is that it's probably reasonable to allow obsoletions between save-anchored and "clean" movies for non-fastest completion categories based on how different they actually are instead of having a blanket "ban" on all obsoletions between movies with different save-anchor statuses under all of Standard.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Samsara wrote:
The following SRAM-anchored branches will be acceptable as standard publications:
- Unlockable modes, characters, and difficulties.
-- Assuming they can't be unlocked with in-game codes, of course.
- New Game +
-- This would include minor benefits such as text skipping and cutscene skipping, even if the rest of the run remains the same.
-- There's still a bit of issue with, say, RPG runs that have complete data carryover, but we'll figure those out when we start getting them.
There's been a disagreement among staff regarding labeling of save-anchored branches that don't involve unlockable modes. It makes perfect sense to generalize the label for all such modes and just call it the most iconic name which is NewGame+, but when we just unlock a character and use it in the movie without entering any new modes, it feels confusing if we also call that branch NewGame+.
There's an option to label them by the character name, but then it's confusing in a different way, because it may look like we accept all different characters now, while we only allow the most optimal one in standard.
There are a few labels that don't sound very good like literally "save-anchored" or "unlockable X", and interestingly they kinda cover the NG+ case as well.
Note: calling it just SRAM is incorrect, because SRAM does not persist across power-off unless it's battery backed, and it's not the only way to store progress anyway (memory cards are not SRAM but Flash).
Any ideas how to neatly call save anchored branches so it covers all kinds of unlockables?
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.
Maybe more specific examples would help. For example, I thought New Game+ would cover everything, and I couldn't quite understand from the previous post why that one wouldn't work.
Just to throw some ideas around (and get them refuted), couldn't we call it "2nd run" similar to the "2nd quest" things we have? Or are there some situations where you don't actually have to beat the game story?
In that case, why not just "savegame" or "saved game" like wikipedia calls it.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
I think there is somewhat of a contradiction over the fact that we'd only accept the most optimal default character for Standard while giving a "free pass" there to an unlocked one regardless of how fast it is in comparison. I mean, what if it's the slowest character? Or at least slower than the second-best default one? (Thinking of something like Streets of Rage 3's Roo here.) Would it not be better to accept all characters for Standard?
But to answer the question, if we need a generic branch name, would something like "fully unlocked" work?
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
