Post subject: Movie Rules Rewrite Project: Feedback Wanted!
Samsara
She/They
Expert player, Senior Judge, Site Admin (2120)
Joined: 11/13/2006
Posts: 2792
Location: Northern California
New Progress Page: http://tasvideos.org/Samsara/MovieRulesRewrite/FullDraft.html
We already have several other massive changes going on at TASvideos, how about we add another? If you've ever tried to submit a movie, you will have been directed to the Movie Rules page at several points, and you will have likely and correctly noticed that this page is an absolute mess. It's long, it's wordy, it's complicated, and yet somehow you're expected to read the whole thing and ensure your movie complies with everything there. That's going to change. My current goal for this rewrite is to get the rules in a much more simplified state, without changing the rules themselves just yet. This thread is meant for masochists you fine people to comb through the current movie rules and discuss what we currently have, providing feedback on how it could be explained better or simplified to make sense. If you have any opinion on the complexity of the current rules, feel free to chime in. We're looking for an overall community consensus on this, not just people who currently submit runs or intend to in the future. I have to stress, though: Do not suggest actual rule changes yet! Rule changes will be a separate discussion altogether once this rewrite has finished, don't worry! Actual rule changes will become much easier after the rewrite, because... Yes, even the Judges have a hard time going through this nightmare of a page. I believe the reason things got so complicated is because we kept adding new rules without realizing that we already had rules to handle the things that we're adding rules for. If that sounds like it doesn't make sense, you're right! What it means though is that if we start implementing rule changes now, it will just continue to lead to complication, lengthening the rewrite process. I've provided a couple helpful examples of the feedback I want and the feedback I don't currently want:
Feedback Samsara Wants wrote:
Example One: I don't think we need most of the "Use the Correct Version" section anymore. It's a lot of words to say "both (U) and (J) are acceptable and nearly interchangeable". Example Two: The entire sports game section is just a jumbled mess of bullet points that could be condensed down to a good paragraph.
This is going to be a decently long process, but the more feedback there is, the faster it will go! Keep checking in on this thread and the progress page linked at the top of this post, I'll be updating them throughout this process until we finally have a readable set of rules live and ready to be actually understood for the first time!
TASvideos Admin and acting Senior Judge 💙 | Cohost
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Judge, Skilled player (1274)
Joined: 9/12/2016
Posts: 1645
Location: Italy
I support this idea! In my opinion, the movie rules appear too much intimidating. It's a long page, just unnecessarily tiring to read. The writing style is too much formal, which makes it excessively serious. The way it's structured is also important: there are a lot of system-specific rules that are grouped together with general rules, which also makes it look like things are more complicated than what they are. I'm trying to figure out how it could be improved, and I'm already having some ideas. I'll take some time to think it through, I shouldn't take too long. Edit: have here a draft, just to see if people like it. It's quite rushed and incomplete because I don't have much time at the moment, I will refine it a bit tomorrow. For now I want to note that I also suggest to change the title of the page from "Movie Rules" to "TAS requirements". Oh and I also have to note that the only part that really seems impossible to simplify for me it's the full-completion definitions paragraph. It's intrinsically complex. Edit: looks like it feasible after all. Linked pages coming soon. Edit 2: Difficulty choice belongs to the guidelines only, as it's not a hard requirement anymore. The list of acceptable movie files should belong to the submission page, as well as the statement that multimedia files are not accepted (but providing a youtube encode is encouraged). And about the warning of losing submission privileges... In my humble opinion, it should be removed entirely. It puts unnecessary pressure on the users. Getting a rejection or two is already a big let down for most people, so I think it's a very bad idea to anticipate even worst outcomes. If a judge is really tired of a submitter, they shouldn't use force to convince them to try to improve; instead, they should insist in providing help and support to the submitter, which I think it's the best way to motivate someone positively. Of course, some people may still keep failing: in that case it's ok to warn them or even actually removing privileges. Edit 3: Both version choice and difficulty choice should belong to guidelines. However it's important to mention them for the purpose of making real-gameplay improvements, which I just added in this edit.
TAS Requirements These are the requirements for having your TAS published on the site. To learn creating TASes, read the TASing Guide. For any questions that remain after having read this page, please ask a judge. Main Requirements Use an approved emulator. Click here for an updated list of emulators. Development builds and unofficial versions are allowed only if the TAS can also be synced (reproduced) on an official version. The game must be emulated well. Don't play a game that has severe video or audio glitches that don't happen on real console. Don't exploit glitches that only happen on emulator, but not on real console. The ROM used must be original (also the BIOS, if applicable). ROM hacks, bootlegs, and prototypes are allowed only if they are more than 50% different than the official game, as well to any other hack already used for published TASes. The movie should start from a clean SRAM state (record from power-on), unless it's necessary for unlocking a game mode used; in that case, you should provide a verification movie that creates the save file used. The TAS goal must be meaningful. Acceptable goals include the following three, but not limited to:
  1. Beating the game as fast as possible.
  2. Beating the game as fast as possible, while not using a glitch that would skip more than half of the game (if applicable).
  3. Completing 100% of the game as fast as possible. Click here for a list of examples for full completion. Don't use ACE or memory corruption to increment directly the percentage/progress.
Any other goal is allowed, as long it as has a clear definition and it's entertaining to watch, by showing off different contents from the three standard goals, and from other TASes already published for that game. Click here for some popular examples of alternate goals. The TAS must beat the game. For that reason, the game chosen must have an ending or final goal. If the game has multiple game modes, each is allowed as a separate movie, if it's enough different. In that case, you may beat all modes in the same movie, if you prefer. If a game has multiple endings, it's preferred the fastest one. A regular game over screen is not allowed. The TAS must beat any ideally possible speedrun attempt, or beat a previously accepted TAS on the site. (this does avoid Desert Bus while also catching Zool) The TAS must be reasonably optimized and beat or match any known TAS. Avoid obvious gameplay mistakes and use all known glitches and tricks to achieve your TAS goal as fast as possible. No cheap improvements. If you're TAS is aiming to beat a known record, make sure it's not just thanks to shorter dialogues, loading times, easier difficulty, or anything else that merely depends on the game version or game settings, but not on actual gameplay improvements. No RAM code cheats. Game Shark, Game Genie, etc. Also, don't use emulator settings that causes a game to run faster or other behaviors that wouldn't happen on real console. No secret passwords or debug codes. An exception is allowed if it's necessary for playing a unlockable game mode. Another exception is if it enables to make a TAS entertaining to watch and more than 50% different than the three standard goals, and other TASes already published for that game. It's always allowed if the password used is explicitly mentioned on the game manual or box. No adult contents. Don't use a game rated for audult-only. If a game has only partial adult contents, avoid those contents in the movie. Don't include copyrighted material in the TAS. This includes data stored in the movie file or displayed in-game through creative inputs. Don't steal a TAS. If other people collaborated in making a TAS, ask for their permission before submitting it to the site. The movie file of your TAS must sync (reproducible) from start to end, in an official release of an approved emulator. This sometimes may be impossible if you made your TAS with a development build (non-release) or unofficial version! If any extra steps are required for syncing the movie, they must be described in your submission text. Additional Requirements Virtual console: A game extracted from a virtual console is allowed at the conditions that it's emulated well and that it has something unique than the original version. For example unique glitches used, or an additional game mode, or if it's the only English version available. NES, SMS, Genesis/MegaDrive, PSX, Saturn: don't use a game version with a framerate different than the one from its original released version. Example: don't use an European version (50Hz) of a game that was first developed for Japan (60Hz). PSX, Saturn: Use the BIOS that matches the region of the game version used. SCPH-xxx0 is Japan, SCPH-xxx1 is USA, SCPH-xxx2 is Europe, and SCPH-xxx3 is also Japan. See this Wikipedia page for more information. Game Boy series: Don't use a Game Boy setting if it causes severe glitches that otherwise wouldn't happen. It's preferred to use GBA mode for most Game Boy games. (it used to be a strict rule in the past, now we just want to avoid nasty exploitations) Game Cube and Wii: Game images in the NKit format are not allowed. Nintendo DS: If you need to use the microphone, don't include copyrighted material. Currently only applicable with DeSmuME version 0.9.9a. Arcade machines: Don't buy continues through additional coins. DOS: No tampering with the files the game is composed of, and if you're emulating the system, choose a compatible machine. More details here. We also allow libTAS to run PCem as a DOS machine emulator in Linux. Only TASVideos releases of PCem are allowed. Closely follow the guides (link) to prevent desyncs! Windows, Linux: Game environment must be legitimate. More details here. Windows: You need to provide the DxDiag log to prevent sync failures due to different hardware. For instructions, see the thread on the Hourglass forum. Linux: Use stable versioned releases of games, dependencies, and of libTAS itself. Use common Linux distributions and use movie annotations to provide installation instructions; more details here. Windows through Wine games are disallowed, however for future purposes, testing this workflow is still encouraged; more details here. Monster Rancher for PSX: do CD swap action only when the game asks to, and don't use copyrighted material. Apart from that, all official PSX games are allowed. (feos recently approved this) Again, if you still have doubts after having read this page, please ask a judge.
Full completion examples (this should be its own page) Games that have a self-defined goal for full completion Some games explicitly ask the player to perform additional tasks beside beating the game, and then acknowledge the achievement in various ways. Some games show a percentage gauge for an additional task: [4010] SNES Super Metroid "100%" by Sniq in 1:01:47.03 Some games award the player with an additional story ending: [4515] PSX Crash Bandicoot 2: Cortex Strikes Back "100%" by SuPeRbOoMfAn in 1:02:50.14 Some games have their own 100% definition mentioned in their manual: [2802] NES Donkey Kong: Original Edition "all items" by adelikat in 01:33.83 Games that need a user-defined goal for full completion Some games don't explicitly propose any additional challenge beside beating the game itself, however there are often many additional challenges that the players can come up with, in the form of accomplishments that can be objectively measured and maximized. Beside that, community agreement is required for defining a full completion goal. Some games have levels that can be normally skipped: [2835] NES Super Mario Bros. 3 "all levels" by Lord_Tom & Tompa in 1:04:36.90 Some games have a limited amount of items that can be collected: [3754] Wii New Super Mario Bros. Wii "100%" by Soig in 2:58:33.27 Some games have different kind of unlockables and optional challenges: [2803] SNES Super Mario RPG: Legend of the Seven Stars "100%" by illayaya in 3:33:22.13 Some games have a scoring system that allows for a fair score competition: [4090] C64 Decathlon "maximum score" by DrD2k9 in 09:35.02
Examples of Moon (non-standard) goals (this should also be its own page) (I'd like to propose the term "Special Goals" instead of the old "Moon", but this isn't the place and moment) This page lists some good examples of non-standard goals. Read the guidelines for some advice about how to make TAS entertaining to watch. Remember that regardless of what you do, you still have to beat the game in the end! Examples of additional challenges present in the game An unlockable hard mode: [1205] NES The Legend of Zelda "2nd quest" by Baxter & Morrison in 24:59.83 An unlockable post-game quest: [2744] Genesis Sonic 3 & Knuckles "newgame+" by marzojr & Aglar in 27:31.29 An unlockable game mode: [2452] GBC Super Mario Bros. Deluxe "You vs. Boo" by got4n & negative seven in 04:54.24 An unlockable playing character: [3016] GBA Sonic Advance 2 "Knuckles" by Dashjump in 20:32.08 Examples of additional goals invented by the player I didn't include movies 3463M and 2339M because the look like full-completion goals to me, despite not having the relative tag. I will point it out in a proper place Collecting all items even if they aren't necessary for full completion: [4313] NES Super Mario Bros. "all items" by DaSmileKat, HappyLee & Mars608 in 19:48.68 Collecting a maximum amount of other limited resources: [3339] Genesis Knuckles in Sonic the Hedgehog 2 "ring attack" by Evil_3D, WST & Zurggriff in 45:01.63 Performing unintended tasks: [2372] PSX Oddworld: Abe's Oddysee "maximum casualties" by Dooty in 40:00.53 Beating multiple games with the same joypad inputs: [871] NES Mega Man 3, 4, 5 & 6 by Baxter & AngerFist in 39:06.92 Examples of self-imposed limitations Forgoing the usage of in-game features: [1868] SNES Super Mario World "no powerups, maximum exits" by PangaeaPanga in 1:18:23.22 Forgoing the usage of a glitch, even if it wasn't a major skip: [4057] NES Mega Man 2 "zipless" by warmCabin in 27:16.17 Avoiding performing actions considered normal in-game: [4524] NES Contra (Japan) "pacifist" by Mars608 & aiqiyou in 08:47.81 Examples of playaround Playing in a superhuman way, while causing funny and goofy situations: [4450] N64 Super Smash Bros. "playaround" by Noxxa in 07:55.10 Beat the game by using unintended and unlikely solutions: [1734] DS Brain Age "playaround" by Ryuto in 06:33.66 Breaking the game by causing many glitches while doing superhuman play: [2021] GB The Legend of Zelda: Link's Awakening "playaround" by Bobmario511 in 40:22.78 Assuming total game control through ACE exploits: [3050] NES Super Mario Bros. 3 "arbitrary code execution" by Lord_Tom in 08:16.23
my personal page - my YouTube channel - my GitHub - my Discord: thunderaxe31 <Masterjun> if you look at the "NES" in a weird angle, it actually clearly says "GBA"
ikuyo
She/Her
Active player, Judge (499)
Joined: 7/8/2021
Posts: 98
As someone who primarily works (or intends to work) with Linux games, I think it's also important to improve the rules to account for the fact that Linuxgames are now acceptable. And this involves reworking some rules or adding better clarifications:
    * What is the preferred update/patch number for Linux and DOS games? Is latest available preferred always? can we accept an earlier full release (v1.0+ or after launch date) if it produces faster movies? * What is the stance of TASVideos about games tied to DRM (such as Steam or EGS) that might eventually be lost due to this DRM issue? * Are early access games and episodic games acceptable? For episodic games, does a movie released later that includes more episodes automatically obsolete a movie with less content? * For games with variable graphical settings that can affect performance (such as RE games or the Towerfall 1000fps movie), is there a preferred setting? Is it explicitly the responsibility of the runner to state the environment? (environment rules such as fps are set in libTAS atm, but it's not a bad idea to futureproof)
Those are the questions that I can come up with right now, and I would expect more questions to come up as the rules get revisited.
Samsara
She/They
Expert player, Senior Judge, Site Admin (2120)
Joined: 11/13/2006
Posts: 2792
Location: Northern California
Very good questions! It's almost like I told you to post them here so I'd actually remember to put them in the updated rules!
ikuyo wrote:
What is the preferred update/patch number for Linux and DOS games? Is latest available preferred always? can we accept an earlier full release (v1.0+ or after launch date) if it produces faster movies?
Any release version is allowed, the only requirements are that the author explains why that version was chosen, and that we are actually able to access that version in order to verify it.
What is the stance of TASVideos about games tied to DRM (such as Steam or EGS) that might eventually be lost due to this DRM issue?
Currently there's no official stance except for "no DRM is preferred but not required". We've accepted Steam TASes already at least.
Are early access games and episodic games acceptable? For episodic games, does a movie released later that includes more episodes automatically obsolete a movie with less content?
My gut feeling here is that we should be able to accept them in their current forms, assuming they're "finished" enough to be able to reach an ending of some sort. Early access would definitely be obsoleted by full releases, and episodic games would vary depending on how they're presented: If all episodes are eventually released in a single game, we may prefer all episodes in one file, but if each episode is its own separate game, we'll have to take each episode individually. This isn't an official site stance though, just my personal thoughts on how it should be. I'll make sure to run it by the rest of the staff when I put together the final draft of the rules.
For games with variable graphical settings that can affect performance (such as RE games or the Towerfall 1000fps movie), is there a preferred setting? Is it explicitly the responsibility of the runner to state the environment? (environment rules such as fps are set in libTAS atm, but it's not a bad idea to futureproof)
Answering this is entirely out of my league ._. I'll run it by the smart people on staff and make sure to account for it in the new rules. I wanna say the default graphical settings are always preferred just for consistency's sake, though.
@ThunderAxe: Nice work so far! Once I finish my own first draft/summary, I'll do an in-depth compare/contrast with yours.
TASvideos Admin and acting Senior Judge 💙 | Cohost
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
Samsara wrote:
Any release version is allowed, the only requirements are that the author explains why that version was chosen, and that we are actually able to access that version in order to verify it.
Agreed.
Samsara wrote:
Currently there's no official stance except for "no DRM is preferred but not required". We've accepted Steam TASes already at least.
We had a thread discussing some aspects of DRM. Since we don't want sync to depend on outside world, on unemulated reality, on internet connection, and on availability of online services, we don't want to allow games with DRM that require any of that. If DRM dependency can be resolved by simulating it via API hooks, that's fine, if it's possible. Steam games I've seen submitted so far may depend on Steam API simulation, but overall they seemed to work fine in offline mode.
Samsara wrote:
My gut feeling here is that we should be able to accept them in their current forms, assuming they're "finished" enough to be able to reach an ending of some sort. Early access would definitely be obsoleted by full releases, and episodic games would vary depending on how they're presented: If all episodes are eventually released in a single game, we may prefer all episodes in one file, but if each episode is its own separate game, we'll have to take each episode individually.
Agreed.
ikuyo wrote:
For games with variable graphical settings that can affect performance (such as RE games or the Towerfall 1000fps movie), is there a preferred setting? Is it explicitly the responsibility of the runner to state the environment? (environment rules such as fps are set in libTAS atm, but it's not a bad idea to futureproof)
There's a difference between in-game graphical settings and those that tweak environment beyond intended specs, or sometimes even beyond possible specs. http://tasvideos.org/MovieRules.html#PcGameEnvironmentMustBeLegitimate
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.
Samsara
She/They
Expert player, Senior Judge, Site Admin (2120)
Joined: 11/13/2006
Posts: 2792
Location: Northern California
I've finished my first pass at simplifying the rules, and I've created a separate page to reflect what the rules page will eventually look like. There are some notable omissions from that full draft - These were intentional, mainly because I felt they didn't fit in their current sections and wanted to re-organize everything before adding them back in to a new, easier-to-read set of sections. We're already at about 1/6 the length of the current rules, and some further organization should push it even lower even after adding everything back in. The biggest omissions are the system-specific rules and the section on movie formats: I will not be adding these back into the rules, as I do not think they belong there. The overall rules should be applying to the majority of submissions coming in, and shouldn't be complicated by breaking down individual systems. I'm not entirely sure where they'll go just yet, though they'll most likely have their own pages.
TASvideos Admin and acting Senior Judge 💙 | Cohost
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Samsara
She/They
Expert player, Senior Judge, Site Admin (2120)
Joined: 11/13/2006
Posts: 2792
Location: Northern California
The full draft has been re-organized and rewritten. I've added a basic summary to it based on ThunderAxe's post as well. Any further feedback is appreciated here! If we all think it's ready to go right now, then I can put it up now and open up this thread to actual rule changes. There's one thing I'm still considering for the current draft: The idea of an FAQ section was brought up on Discord, and I think that'd be a great way of adding more information and clarification without further complication. Is this a good idea, and if so, what should be in it right now?
TASvideos Admin and acting Senior Judge 💙 | Cohost
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Judge, Skilled player (1274)
Joined: 9/12/2016
Posts: 1645
Location: Italy
Samsara wrote:
The full draft has been re-organized and rewritten. I've added a basic summary to it based on ThunderAxe's post as well. Any further feedback is appreciated here! If we all think it's ready to go right now, then I can put it up now and open up this thread to actual rule changes.
Thanks for the attention. There are some various adjustments I'd apply there and there, but we can brainstorm about them later; what matters for now is discussing the overall structure idea. My goal is to propose making a rules page as short as possible, and as much fool-proof as possible. For that, I think it would be better to avoid any technical wording as much as possible, and use an implicit wording. For example "Use interim builds at your own risk" or "Your system BIOS must not be modified" may look like an obscure statement to some, like: "whats an inretim bulids? how do I see if I'm using one?? what am I risking???" or "Where do I check if my NES TAS is BIOS modified?????" (this is clearly an hyperbole; in most case people may get only 'partially' uncertain in front of such wording, but keep in mind that all the many little things may pile up in someone's mind and eventually erode their confidence and their will to try TASing for the first time) Another thing I hope to see worked to the limit is the sheer text length. That's why I tried to condense all rules into short statements with a broader meaning. I think that it works, because despite expressing through wide-range definitions, the rules looked to me less restrictive than before. Just my opinion, though; please gimme feedback. Same reason why I insist of taking as many rules as possible into a systems-specific space, like the PAL/NTSC issue: it makes it look the rules less overwhelming and easier to understand and remember. I see that my approach may result a bit extreme, especially since it's been the exact opposite until now. For that reason, it could still use a separate page that explains all the rules in a much more verbose way, like... the actual current rules page. Also, many rules or nuances may moved in the guidelines page, and other nuances to the judge guidelines (in fact, many judging factors actually affect the judgement process are found only there, though until now only 1 user did go as far as mentioning the judge guidelines page, for questioning a judgement yes, I still remember about it. no, I will never be able to forget about it.)
Samsara wrote:
There's one thing I'm still considering for the current draft: The idea of an FAQ section was brought up on Discord, and I think that'd be a great way of adding more information and clarification without further complication. Is this a good idea, and if so, what should be in it right now?
I think we need to do an actual historical research to find actual examples of frequent questions done by users. Also starting polls on forum and Discord may help.
my personal page - my YouTube channel - my GitHub - my Discord: thunderaxe31 <Masterjun> if you look at the "NES" in a weird angle, it actually clearly says "GBA"
Fortranm
He/Him
Editor, Experienced player (772)
Joined: 10/19/2013
Posts: 1108
I'm not sure if this falls under rule change or clarification more, but are the typical NG+ modes considered "individual game modes" mentioned for the Standard category?
Samsara
She/They
Expert player, Senior Judge, Site Admin (2120)
Joined: 11/13/2006
Posts: 2792
Location: Northern California
Fortranm wrote:
I'm not sure if this falls under rule change or clarification more, but are the typical NG+ modes considered "individual game modes" mentioned for the Standard category?
NG+ can be considered an individual game mode, but I was more referring to title screen options, i.e Super Monkey Ball 2 having both Challenge Mode and Story Mode TASes as they are separate options, and thus considered individual game modes.
TASvideos Admin and acting Senior Judge 💙 | Cohost
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Judge, Skilled player (1274)
Joined: 9/12/2016
Posts: 1645
Location: Italy
ThunderAxe31 wrote:
For that, I think it would be better to avoid any technical wording as much as possible, and use an implicit wording. For example "Use interim builds at your own risk" or "Your system BIOS must not be modified" may look like an obscure statement to some, like: "whats an inretim bulids? how do I see if I'm using one?? what am I risking???" or "Where do I check if my NES TAS is BIOS modified?????" (this is clearly an hyperbole; in most case people may get only 'partially' uncertain in front of such wording, but keep in mind that all the many little things may pile up in someone's mind and eventually erode their confidence and their will to try TASing for the first time) Another thing I hope to see worked to the limit is the sheer text length. That's why I tried to condense all rules into short statements with a broader meaning. I think that it works, because despite expressing through wide-range definitions, the rules looked to me less restrictive than before. Just my opinion, though; please gimme feedback. Same reason why I insist of taking as many rules as possible into a systems-specific space, like the PAL/NTSC issue: it makes it look the rules less overwhelming and easier to understand and remember.
Let me elaborate. For example, regarding the interim builds part, I'd use the wording "development version" as that's how it's referred to in the places where they can be found, and I'd move this part to the movie sync section, as this is the only reason why it's advised against. IMO we don't need to explain that movies made on interim builds need to sync on an official release, so I'd put it this way: "The movie file of your TAS must be reproducible from start to end. This sometimes may be impossible if you used a development version (non-release) of an emulator! If any extra steps are required for syncing the movie, they must be described in your submission text" Also, I'd avoid saying "it must sync for multiple people", because that would imply that the submitter has to send his TAS around to many random people before submitting, which is unpractical, to say the least. On the other hand, I doubt anyone would complain if their submission got rejected because it only syncs on their pc, but not on anyone else on the whole site (when there are sync issues, there are always many different people coming forward to try syncing it); it's obvious that every TAS needs to be proven as legit, so it should be ok to leave this bit implied. Also, it's something that happens in like 1 case out of 1000; no reason to bother every author over something like this. Edit: thinking about it again, it would be even better to include it at both the emulator choice paragraph and the sync paragraph, respectively at the beginning and at the end of the page. I think that's important to make this extra clear, and also include the mention about unofficial emulator branches.
my personal page - my YouTube channel - my GitHub - my Discord: thunderaxe31 <Masterjun> if you look at the "NES" in a weird angle, it actually clearly says "GBA"
Noxxa
They/Them
Expert player, Moderator (4131)
Joined: 8/14/2009
Posts: 4083
Location: The Netherlands
I don't have any real feedback for this yet, but I'd like to say that I'm very glad to see something like this finally be done. I've been wanting to overhaul the movie rules to something more simplified way back when I was senior judge, but it is a massive task and I never really found the time for it. It's great to finally see something happen.
http://www.youtube.com/Noxxa <dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects. <Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits <adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
Use an official release of an approved emulator. Use interim development builds at your own risk.
I agree with ThunderAxe31. Or maybe we can drop the second sentence altogether in the summary?
You may not change emulator settings to gain in-game speed advantages, such as running 50hz PAL games in 60hz NTSC mode.
I'm bad at english, but we need to mention that we don't want settings that are inaccurate to the actual emulated device. If some setting gives speed advantage and is present on the real device, it's fine to use it (generally).
Any release version or patch of a game may be used, though you should be able to explain why you chose that version.
Could the patch be confused with ROM/image modifications also called patches?
- Always record new movies from power-on. Starting from a savestate is not allowed. - SRAM-anchored movies are allowed, but they require a verification movie that creates the necessary SRAM. This verification movie does not need to be optimized.
We might need users to know the difference between emulator savestates and in-game saves. The latter can be SRAM-based, but SRAM may have other meanings too. In branches and tags we call those just saves (save glitch, save corruption). Again not sure how to word this well.
Cheat codes and passwords are only allowed to access harder difficulties and/or bonus content.
Or add cosmetic improvements.
ROM or RAM modification, such as Game Genie and Action Replay, is not allowed.
Game Genie modifies the ROM.
Your movie file must sync from beginning to end for multiple people. If any extra steps or settings are required for sync, they must all be stated in your submission text.
Every movie will indeed be replayed by several people, but the wording implies it has to be sent to other people for sync verification before submitting. While this would actually be a great practice, I dunno how to word this softer.
- Do not submit other authors' movies without their explicit permission. - Do not plagiarize. This is grounds for an immediate site ban.
Don't these 2 mean the same thing?
Any%: Completing a game in the fastest time possible.
We use the term fastest completion officially instead of any%, because the former is more descriptive.
-- If the fastest time for a game is an ACE run, we also allow a separate any% branch that foregoes it.
Wasn't ACE confused with major skip glitch here?
The definition of a major skip varies from game to game, but is generally defined as an unintended skip of otherwise unavoidable content.
Would gameplay sound better here?
This is not strictly "100%": Categories such as "all levels", "best ending" and "maximum score" are also acceptable forms of full completion if the game has no other definition.
I think we want to say it's not always literally "100%". Not strictly "100%" looks to me like sometimes we're fine with just reaching 99% out of 100%. As always, I'm bad at english.
Individual game modes or level sets, including those unlocked using passwords, are also acceptable as separate branches.
As a general rule, your chosen game should have optimizable gameplay and an ending.
An ending in the game is not a requirement. If there's none, we define it ourselves.
Moons is a class that holds a variety of goals curated by the TASvideos community. Game and goal choice does not matter as much here, as long as it is widely approved by the community. It is recommended you ask for feedback in advance before starting a Moons-oriented run.
To reflect the current system, we need to mention entertainment. Long-term too, goals that can not possibly go to Standard will have to be entertaining, like playarounds.
Gameplay must be accurate to console
We emulate computers too.
Your submission must be reproducible. That is, multiple people must verify will be verifying that your input file syncs on an officially released build of an accepted emulator. Use development/interim builds at your own risk, as input files created on them may not sync even on the next official release. Anything that could affect sync, such as emulator settings or config options, must be stated in the submission text so that Judges and Publishers have the best chance of verifying your submission. If a game is not emulated well at all, it may not be accepted until the accuracy improves, as emulation bugs could provide unintentional advantages to a TAS or ruin the overall experience (?). Note: Dolphin's Beta and Development builds are considered official releases, and they are preferred to stable releases.
I think sync requirements should be a separate section. I don't think they are a part of console accuracy. Also I wouldn't say Dolphin interims are preferred. They may still be non-trivial to get a video from, and there are versions to avoid completely. Stables are the safest, and for the rest we need to link this thread probably.
Outside modification of a game or a system BIOS is not allowed: This includes Game Genie and Action Replay cheats as well as direct modification of game files, such as on a PC or Linux game.
If it's the only way to make the game work for a TAS, and it doesn't alter gameplay, modification is allowed (still safer to ask judges).
Use the correct version of a game
I suggest turning this section into regular text with examples as bullet points. Making it a nested list feels like it's just to large to grasp. After all, the points are rather independent.
Virtual Console (VC) and other ROMs extracted from official emulators are allowed, though the original release ROM is usually preferred. VC is preferred if it is the only official English release of a game, or if it provides unique features not in the original release, such as different gameplay or new game modes.
This should mention that the extracted game should actually be fully playable, without audio/visual bugs and bugs that hinder gameplay. This is important because some VC games heavily depend on their VC environment and don't function properly without it. Playing them as VC games without extraction should always be allowed imo.
SRAM-anchored movies require a verification file, which must be provided in the submission. - This verification file should create the exact SRAM state that's used in the submission. It does not have to be optimized or even TASed at all, the only purpose it serves is to verify that your submission starts from a legitimate state.
Should we note that the initial verification movie should still start from power-on? Also the wording should involve in-game saves to be more generic.
- For games that loop a set of levels endlessly, the final level before the game loops must be completed at minimum. If difficulty continues to increase on successive loops, you have the option of continuing until the difficulty stops increasing. Continuing is preferred, but not required. - For games with "infinite" levels, you may end after all unique content (enemies, level layouts, game mechanics, etc.) is exhausted.
The current rules don't allow to stop at the end of the first loop if there's still unique content after it.
Unnecessary input should be trimmed to the last input required to reach your chosen endpoint.
Somewhere we should mention that TAS timing starts from console power-on and ends on last required input.
For games with post-credits input or high score screens, you are not required to include those inputs in your input file. You may provide a separate file with these inputs for the purposes of our publication encodes.
It's preferred to have this extra input in the main file.
If you're aiming for speed, your submission must beat, or at least match, all known records.
The movie must be properly attributed
Mention that all files submitted to the site are distributed under the Creative Commons Attribution 2.0 license.
I'll go through omitted sections in another post.
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.
Samsara
She/They
Expert player, Senior Judge, Site Admin (2120)
Joined: 11/13/2006
Posts: 2792
Location: Northern California
I've gone ahead and implemented the above suggestions, and I've also done some further rewriting and re-organizing. The draft's gotten a bit bulkier, but it's still only 25% of the current rules, and once we start getting into actual changes it should deflate more as things are removed and reworked.
TASvideos Admin and acting Senior Judge 💙 | Cohost
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
Kill screens, assuming they are impossible to complete under any circumstances
To match the point above, it needs to say "a killscreen".
For games that have "infinite" levels, including a looping set of stages, you may end after all unique content (enemies, level layouts, game mechanics, etc.) is exhausted.
As an extension of this, one is also allowed to play until difficulty stops increasing.
Regional differences such as text and cutscene length are completely discounted when considering improvements. Only actual gameplay is considered to be an improvement. If your movie has 600 fewer frames solely due to version differences, your total improvement must be more than 600 frames.
I feel this should be a new paragraph.
Individual game modes (level sets, episodes), including those unlocked using passwords, are also acceptable as separate branches.

Missing stuff: The triviality clause! While there are some plans regarding it, we're gonna need it for rules that would boil down to it to get dropped. Unofficial games. Bootlegs, homebrews, prototypes, etc. While I don't feel very strong about limiting them the way the current rules do, there should still be some discussion on what to do with them in the end. I don't even ask to copy the current rules over, just some general info that makes sense to you. Regarding converted ROMs, I'm not sure. We don't want to depend on 3rd party converters unless we can host them. There's also Thread #21609: #6624: Chamale's Wii MLB Power Pros 2008 "Success mode" in 21:34.17. But things that work on actual device would be fine most of the time. Image integrity. Some games glitch out if you replace the disk with something else. While great for crazy showcase, That would need a special place to be designed to host such things (also planned). As for that one game that asks you to insert arbitrary images, I feel it would be fair to allow inserting official games for the same system to make it easier for the player. But I'm not sure where this clause should be placed. What do we do with Standard regulations? We'll be revising score attack rules very soon, but for now it should be good to mention that infinite loop techniques are not allowed (ones that delay completion indefinitely to score more points). Arcade continues are an infinite source of lives, and they make the game easier. We'll see what to do with them later, should be safe to append to the cheats clause for now. Obsoletion chapter is incredibly wordy right now, but we need at least some basic info about it mentioned somewhere. Rules for systems: Should we have a subpages under MovieRules for each system? Movie formats: Looks like it needs to be an automatic thing, also not sure where.
I've been thinking the entire day about consolidating regulations about TAS environments. There's a ton of info all around the current rules, and also some info in various places of the draft. We explicitly allow running a game in any config variant of the official and intended environment, unless it causes bugs that hinder gameplay, visuals, or audio. Important term: https://en.wikipedia.org/wiki/Open_architecture
  • For consoles and other devices with closed architecture, we don't allow deviations from official and intended environment. If it's a game released for PAL PlayStation, we run it in emulated PAL PlayStation, with all authentic config. But we allow better GBx modes unless it causes problems.
  • For open architecture, we're more open too. Emulating officially supported environment is also allowed of course. And deviations may be allowed depending on their effect on gameplay: improving framerate or audio-visuals is a good thing. Running incompatible hardware is not.
This would automatically resolve most of libTAS rules too.
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.
Samsara
She/They
Expert player, Senior Judge, Site Admin (2120)
Joined: 11/13/2006
Posts: 2792
Location: Northern California
feos wrote:
To match the point above, it needs to say "a killscreen". As an extension of this, one is also allowed to play until difficulty stops increasing. I feel this should be a new paragraph.
Individual game modes (level sets, episodes), including those unlocked using passwords, are also acceptable as separate branches.
The triviality clause! While there are some plans regarding it, we're gonna need it for rules that would boil down to it to get dropped. Unofficial games. Bootlegs, homebrews, prototypes, etc. While I don't feel very strong about limiting them the way the current rules do, there should still be some discussion on what to do with them in the end. I don't even ask to copy the current rules over, just some general info that makes sense to you.
These should all be in, now.
Regarding converted ROMs, I'm not sure. We don't want to depend on 3rd party converters unless we can host them. There's also Thread #21609: #6624: Chamale's Wii MLB Power Pros 2008 "Success mode" in 21:34.17. But things that work on actual device would be fine most of the time. Image integrity. Some games glitch out if you replace the disk with something else. While great for crazy showcase, That would need a special place to be designed to host such things (also planned). As for that one game that asks you to insert arbitrary images, I feel it would be fair to allow inserting official games for the same system to make it easier for the player. But I'm not sure where this clause should be placed.
We talked about this on Discord, but to summarize it here: I'm skipping the heavy technical stuff for now, more or less. This may just be something we want to revisit once we get into actual changes, either that or leave them off the main rules page entirely.
What do we do with Standard regulations?
I'm not entirely sure what you mean by this.
We'll be revising score attack rules very soon, but for now it should be good to mention that infinite loop techniques are not allowed (ones that delay completion indefinitely to score more points). Arcade continues are an infinite source of lives, and they make the game easier. We'll see what to do with them later, should be safe to append to the cheats clause for now.
Added both of these.
Obsoletion chapter is incredibly wordy right now, but we need at least some basic info about it mentioned somewhere.
Rules for systems: Should we have a subpages under MovieRules for each system? Movie formats: Looks like it needs to be an automatic thing, also not sure where.
I like having system subpages, though I do feel they'll end up being a bunch of fairly empty pages. If that's what we want, we'll go with it, but it may be a little cleaner to just use a single subpage for systems. Movie formats, yeah, I have no idea what to do with that section either, but I know for a fact it shouldn't be in the rules. Maybe just another subpage?
I've been thinking the entire day about consolidating regulations about TAS environments. There's a ton of info all around the current rules, and also some info in various places of the draft. We explicitly allow running a game in any config variant of the official and intended environment, unless it causes bugs that hinder gameplay, visuals, or audio. Important term: https://en.wikipedia.org/wiki/Open_architecture
  • For consoles and other devices with closed architecture, we don't allow deviations from official and intended environment. If it's a game released for PAL PlayStation, we run it in emulated PAL PlayStation, with all authentic config. But we allow better GBx modes unless it causes problems.
  • For open architecture, we're more open too. Emulating officially supported environment is also allowed of course. And deviations may be allowed depending on their effect on gameplay: improving framerate or audio-visuals is a good thing. Running incompatible hardware is not.
This would automatically resolve most of libTAS rules too.
I think this is in the same camp as heavy technical stuff to focus on later.
TASvideos Admin and acting Senior Judge 💙 | Cohost
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
Alternately, you may end when the in-game difficulty (enemy speed, AI, etc.) stops increasing.
I don't mind to make this an alternative ending point, but I should clarify that currently it works as an extension of "all content". If you want, you can play even further after all content is completed, but not instead of completing it.
I'm not entirely sure what you mean by this.
I mean these.
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.
Samsara
She/They
Expert player, Senior Judge, Site Admin (2120)
Joined: 11/13/2006
Posts: 2792
Location: Northern California
feos wrote:
I'm not entirely sure what you mean by this.
I mean these.
Apart from in-game time and secondary playthroughs, these should all be accounted for already, they're just shuffled around to more appropriate sections. NMS and independent game modes are already there, SRAM and in-game codes are under "Movie must be complete", PC environment is under "Gameplay must be accurate to hardware", and I've just added 2nd quest and IGT stuff. I'll frick around with obsoletion stuff for a bit. Thinking I might experiment with having a section at the end for things like that. EDIT: Obsoletion stuff rewritten and added, it's currently under the tech quality section. EDIT 2:
feos wrote:
Alternately, you may end when the in-game difficulty (enemy speed, AI, etc.) stops increasing.
I don't mind to make this an alternative ending point, but I should clarify that currently it works as an extension of "all content". If you want, you can play even further after all content is completed, but not instead of completing it.
I've fixed this as well. The only stuff left from your second post should be the tech stuff we all need to discuss together.
TASvideos Admin and acting Senior Judge 💙 | Cohost
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
Your improvement movie may even be slower longer than the published run, but it is still considered an improvement if it improves upon gameplay.
"Slower" feels like it describes execution. The case we're describing here is then the movie is at the same time faster and longer.
Glitches that specifically rely on poor emulation must be avoided, even especially if the published movie uses them.
In those cases we want to explicitly encourage an improvement.
Some exceptions are made to this, though these exceptions are usually explicit in the published run's judgement or publication text.
Not obvious what an exception may be made for. Also do we still make such exceptions? I think we prefer fixing the rule to match the agreed scenario. There are a few mentions of obsoletion in other chapters. I think it would be useful if everything related to obsoletion is grouped in one place (which is also why we grouped all Vault/Standard clauses together). This also needs to be mentioned in some form:
For movies of games without a definite ending, a movie which chooses a later ending point can obsolete one which chose an earlier ending point if the rest of the content is matched between the two.
For games that have a second quest or loop, you are allowed to play only the first quest. The second quest is only required to be included if gameplay is significantly different.
If the nature of the second loop is that it's a harder difficulty mode, we may allow it without the first quest. Same spirit as when you use a code to access this hard(est) difficulty.
SRAM and in-game codes are under "Movie must be complete"
That's true, but it doesn't mention that save-anchored movies must be entertaining (as of right now).
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.
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
The recently bumped C64 thread reminded me that we should list things explicitly allowed to be run in PAL mode http://tasvideos.org/MovieRules.html#NtscVsPalUsaJapanVsEurope
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.
Samsara
She/They
Expert player, Senior Judge, Site Admin (2120)
Joined: 11/13/2006
Posts: 2792
Location: Northern California
feos wrote:
Some exceptions are made to this, though these exceptions are usually explicit in the published run's judgement or publication text.
Not obvious what an exception may be made for. Also do we still make such exceptions? I think we prefer fixing the rule to match the agreed scenario.
This is pretty much direct from the current rules, and I have no idea how to fix it here. It might have to wait until we start doing explicit changes.
There are a few mentions of obsoletion in other chapters. I think it would be useful if everything related to obsoletion is grouped in one place (which is also why we grouped all Vault/Standard clauses together).
I honestly think it works better the way I have it. I already think the obsoletion section is wordy enough as it is in the draft, so compiling everything related to obsoletion there would just make it even bulkier. It should be a more generalized, succinct section to explain how the process works, while more specific cases can go under their respective sections in other parts of the rules. That is, if we're already talking about early access games in another part of the rules, it makes more sense to me to immediately explain how we're going to handle full release cases there, rather than redirect people to a separate section of the rules.
The recently bumped C64 thread reminded me that we should list things explicitly allowed to be run in PAL mode
Gonna call this a technical thing as well, and definitely not just because my eyes are glazing over trying to make heads or tails of it right now. Rest of the suggestions should be implemented by now. Honestly, I'm getting antsy to move into rule changes already.
TASvideos Admin and acting Senior Judge 💙 | Cohost
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
Samsara wrote:
This is pretty much direct from the current rules, and I have no idea how to fix it here. It might have to wait until we start doing explicit changes.
Uh I didn't read the whole thing in the original rules. It says
(An example would be movies that start from SRAM, use passwords, etc.)
which is super outdated, because the rules already allow this kinda stuff. I think this bullet point can be removed.
Samsara wrote:
Gonna call this a technical thing as well, and definitely not just because my eyes are glazing over trying to make heads or tails of it right now.
The list would not be as wordy. I wonder if it still feels too technical:
NTSC is almost always preferred over PAL, unless there are version exclusive changes to a PAL release that warrant its usage, or if the PAL release runs at 60hz instead of 50hz. US versions ((U)) are preferred, as a majority of our audience is English speaking, though any NTSC release can be used interchangeably. Using a PAL version of the game is allowed in some situations:
  • Games for handheld consoles (like GameBoy)
  • Games run in PAL60 mode (like on Wii GameCube)
  • Commodore 64 games that don't work correctly in NTSC mode (PAL mode should be used)
  • Games released in PAL Asia for Famiclones (NTSC or Dendy/Hybrid mode should be used)
  • Sega Master System games released in Brazil (NTSC mode can be used)
Actually feels like it belongs to legitimate environment rules instead, but we can always just link.
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.
Samsara
She/They
Expert player, Senior Judge, Site Admin (2120)
Joined: 11/13/2006
Posts: 2792
Location: Northern California
feos wrote:
I think this bullet point can be removed.
Gladly! PAL stuff was also added since, yeah, your writing was pretty concise there. I split out the C64/Famiclone/SMS stuff and put it under the "accurate to hardware" section just to make the "correct version" section a bit less bulky, did a little more re-organizing and rewriting as well to fit these changes.
TASvideos Admin and acting Senior Judge 💙 | Cohost
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
Probably final suggestions for this version:
US USA ((U)) versions are preferred
Somebody might read this as "us" and get confused.
Games that run in PAL60 mode (like on Wii GameCube)
Not sure why I changed the console when I copied the logic from the current rules. It says GameCube there.
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.
Samsara
She/They
Expert player, Senior Judge, Site Admin (2120)
Joined: 11/13/2006
Posts: 2792
Location: Northern California
Done. Are we good to go live and move into the change phase, now?
TASvideos Admin and acting Senior Judge 💙 | Cohost
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.