This is a work-in-progress based on the current drafts on /HomePages/Samsara/MovieRulesRewrite. It is very incomplete and subject to further change.
The English language page is the most up-to-date version of the rules. Translated pages are provided by the community and may not be accurate to the English version.
Hello, and welcome to TASVideos! This page describes the requirements that submissions should meet in order to be published. These requirements are always subject to change as the site continues to grow. To learn the latest changes, read the Movie Rules History.
This is intended to be a general page for rules that apply to most, if not all, submissions. For more specific information on our accepted emulators and movie formats, see our Emulator Resources page.
If you have any questions that this page does not answer, ask a Judge on the forums, or reach out to us on our Discord server. If you would like to suggest possible changes and updates to these rules, use this thread.
- Game and Goal Choice
- Gameplay must be accurate to hardware
- Use the correct version of a game
- The movie must be complete
- The movie must be technically sound
- The movie must be properly attributed
Samsara: Hey Samsara, it's me, your buddy Samsara. When this goes live, remember to link these individual bullet points to their corresponding sections below. Also, remove this line. Thanks in advance. Don't forget to pick up milk on your way home. Love you.
This is a short summary of our baseline requirements. Further information on each point is available by clicking the links.
- Use an official release of an approved emulator. Development/interim builds are allowed if the resulting input file syncs on an official release, though use them with caution as sync is not guaranteed.
- The emulator's settings should match as closely as possible the settings of the console the game is intended to be running on.
- You may not change emulator settings to make a game run at an unintended frame rate, such as running 50Hz PAL games in 60Hz NTSC mode.
- Your system BIOS must not be modified, and the region must match your chosen game.
When choosing a game...
- Your ROM must be good. Always use perfect dumps
[!]if possible. Do not use bad dumps
[b], hacked ROMs
[h], or unofficial translations
- 60Hz NTSC is preferred over 50Hz PAL, unless 50Hz PAL has version-exclusive glitches that make gameplay faster. Any regional release can be used outside of that.
- Any release version or update patch of a game may be used, though you should be able to explain why you chose that version.
- Make sure your game and system is emulated well. You are not allowed to use emulation errors to gain speed advantages.
- Adults Only (AO) content is not allowed if it is unavoidably shown during the TAS. If it can be avoided completely, it is acceptable.
- ROM hacks are allowed, but must be high quality and meet an entertainment standard set by the TASVideos audience.
- Always record new movies from power-on. Starting from an emulator savestate is not allowed.
- Movies that start with in-game saves (aka SRAM-anchored) are allowed, but they require a verification movie that creates the necessary SRAM. This verification movie does not need to be optimized.
- Your goal must be meaningful. Check below for details on goals we accept.
- Your movie must beat the game. If your game does not have an ending, it must reach a suitable alternative endpoint.
- Your TAS must be reasonably optimized. It should beat or match all known TASes and human speedruns of that game and category. It does not have to be perfect, but it should not be easily improvable.
- Cheat codes and passwords are only allowed to access harder difficulties and/or bonus content, including cosmetic improvements.
- Arcade continues are considered cheats.
- RAM or ROM modification, such as Game Genie and Action Replay, is not allowed.
- Regional differences such as text and cutscene length are not counted as improvements or time losses. Only directly comparable gameplay is counted.
- Make sure your movie syncs from beginning to end before submitting. Judges and Publishers need a fully syncing movie in order to process it.
- If any extra steps or settings are required for sync, they must be stated in your submission text.
- Your movie should be your work. Plagiarism is not tolerated.
- You may submit someone else's movie on their behalf, but only with their explicit permission.
Game and Goal Choice
Movies are initially published to one of two classes: Standard or Moons.
Standard class houses a majority of the movies on the site. It contains speedrun records with common, objective goals. Goal choice should be as objective as possible. Below is a list of currently accepted branches. This list is still growing and will be expanded in the future.
- Fastest Completion: Also known as "any%". Completing a game in the fastest time possible.
- Arbitrary Code Execution (ACE) is only allowed in Standard as an any% speedrun, and must be used to its fullest extent.
- No Major Skips: Completing a game in the fastest time possible without skipping major portions of content.
- The definition of a major skip varies from game to game, but is generally defined as an unintended skip of otherwise unavoidable gameplay.
- Full Completion: Completing all content in a game in the fastest time possible.
- This is generally considered the "100%" category, but it is not limited to that. Categories such as "all levels", "best ending" and "maximum score" are also acceptable forms of full completion if the game has no other definition.
- Full completion requirements such as completing levels, collecting items, or incrementing a progress/score counter must be met through gameplay means only. Requirements may not be bypassed through heavy glitching or memory/save corruption.
Individual game modes (level sets, episodes, etc.), including those unlocked using passwords, are also acceptable as separate branches. These can also include different playable characters if their gameplay is significantly different. 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 a game's second quest is just a harder difficulty mode, it is allowed by itself.
Runs that optimize In-Game Time (IGT) are only allowed in Standard if they contain faster gameplay than a real-time focused run.
- For example, Sonic the Hedgehog TASes optimize for IGT because optimizing for real time involves long waits to minimize the score counter
Game choice is a bit limited here, as some games cannot be meaningfully speedrun. As a general rule, your chosen game should have optimizable gameplay and a definable endpoint. Examples of games currently not allowed in standard are:
- Creative games, such as Mario Paint
- Free objective sandbox games, such as Harvest Moon
- Board games, such as chess and Monopoly
- Game show games, such as Jeopardy and Family Feud
- Fixed-time sports, such as basketball, soccer, and American football
- ROM hacks, such as Extra Mario Bros
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. What matters is how entertaining our community finds your run. It is recommended you ask for feedback in advance before starting a Moons-oriented run.
While there are less restrictions for Moons, there are still some things to keep in mind in order to maximize your chances at success:
- Your goal choice should be clearly defined and sensible, especially to those who do not know your chosen game. Assume that the audience is seeing the game for the first time.
- Your goal choice should result in significantly different gameplay than other runs of the same game.
- Playarounds and freeruns must still beat the game. ACE is freely allowed in playarounds, though the spirit of the original game should be maintained, and copyright should not be infringed. Fair use applies here.
Game Choice in General
Onscreen Adults-Only (AO) content is strictly not allowed in any class. TASes of AO-rated games must avoid all explicit content in order to be published.
The gameplay must not be trivial. We define triviality as being able to quickly and easily produce a perfect, unimprovable time. Desert Bus stands out as an example of a trivial game.
We allow unofficial games, such as bootlegs, prototypes and ROM hacks. However, these games are judged just as much as their TASes:
- Unlicensed and homebrew games need to meet a minimum standard of game quality. They should be complete and original.
- Bootleg games must not be direct clones of a licensed game on the same console. Unlicensed ports with unique gameplay, such as demakes, are allowed.
- Prototypes are only allowed if gameplay is significantly different to the release version, or if there is no release version at all.
ROM hacks must meet an entertainment standard as well, and are only allowed in Moons.
- Fan translations are not allowed at all, even on top of other hacks.
- Cosmetic hacks are not allowed by themselves.
- Hacks that transform the game, especially new/changed levels, are preferred.
- Hacks must be completed. Work-in-progress hacks are not allowed unless the hack is known to be completely abandoned.
Gameplay must be accurate to hardware
Make sure you use a perfect
[!]ROM if it is available. If not, use the best available ROM. Do not use
[t]ROMs at all, as they may introduce glitches not found in the actual game. If a game is not emulated well at all, it may not be accepted until the accuracy improves. Providing hash checksums is recommended to help Judges and Publishers process your submission. Do not ask where to find ROMs, or provide links to ROMs!
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 game. If modification is the only way of being able to TAS your game, ask a Judge if it can be allowed. Some emulators such as BizHawk allow you to set a custom initial RAM state: This is only allowed if that RAM state is proven to be possible on console.
You are not allowed to run a console or PC game in an unintended environment, including modifying emulator settings for unintended speed advantages. Backwards compatibility modes, such as running Game Boy games in Game Boy Advance mode, are allowed if a physical console supports it, unless there are noticeable audio, video, and/or gameplay-affecting glitches. Converting a game image from one format to another is only allowed if it's supported on the device meant to run that game, and the game itself remains unchanged.
Running 50Hz PAL games in 60Hz NTSC mode (and vice versa) is also not allowed, save for a couple exceptions:
- Commodore 64 games may not work correctly in NTSC mode. PAL mode should be used in these cases.
- For games released in PAL Asia for Famiclones such as the Dendy, you can use either NTSC or a specific Dendy/Hybrid option.
- Sega Master System games with an official release in Brazil can use NTSC mode, due to Brazil's PAL-M being functionally identical to NTSC.
For disc systems, you may only use discs belonging to your game, and they may only be swapped when the game prompts you to. You are not allowed to arbitrarily swap discs at any other time.
Console verification is not required for a submission, however your gameplay should match console behavior as much as possible anyway. Glitches and in-game behaviors that are known to be the result of emulation bugs are not allowed, and must be avoided. In cases where a movie is published with a known emulator bug, a slower movie that avoids that bug will obsolete it.
Use the correct version of a game
Any official release of a game is allowed as long as you can explain your choice, and as long as that version is easily available for verification.
- Older versions of a game are allowed in order to exploit a glitch patched out in later versions.
NTSC is usually preferred over PAL. USA versions, labeled
(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:
- There are version exclusive changes to a PAL release that warrant its usage
- Games for handheld consoles (like GameBoy)
- Games that run in PAL60 mode (like on GameCube)
- The original hardware allows it (see the above section on hardware accuracy)
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. This also means you can use a "slower" version that ends up generating a longer input file, as long as pure comparable gameplay is improved.
You are allowed to use Virtual Console (VC) or other similar emulation environments for TASes. Extracting ROMs from VC or other environments is also allowed if they are fully playable in their extracted form with little to no audio/visual bugs, though in most cases the original console ROM is preferred. An extracted ROM 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.
Early access games and episodic games are allowed for submission. A TAS of an early access game will be obsoleted by a TAS of its official release. If an episodic game is eventually released with all episodes in one executable, a TAS of all episodes will obsolete individual episode TASes.
When applicable, DRM-free versions of games are always preferred. Games with DRM must be deterministic in an offline environment in order to be accepted.
The movie must be complete
Your submission must always begin from power-on. Starting from an emulator savestate is not allowed. 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.
- The verification file is not judged. It does not have to be TASed and can be as long as it needs to be.
Your submission must beat the game, or reach the most suitable endpoint the game allows. Single-level or otherwise incomplete movies are not allowed. Examples of suitable endpoints are:
- A definitive ending, such as a credits sequence.
- A kill screen, assuming it is impossible to complete even when TASed.
- If there's no clear ending, end after all unique content (enemies, level layouts, game mechanics, etc.) is exhausted.
- Alternately, after completing all unique content, you may end when the in-game difficulty (enemy speed, AI, etc.) stops increasing.
You are not allowed to skip levels with passwords. Passwords are allowed for bonus content, such as extra levels not normally playable in-game, harder difficulties, or cosmetic improvements.
TAS timing begins at power-on and ends on the final input, so you should trim your TAS down to that last input, leaving no blank frames at the end. For games with post-credits input or high score screens, you are not required to include those inputs in your submission, though it is preferred you do so. The final input should always automatically lead to the game's completion, though you can make a stylistic choice as to where it ends:
- You can end input as early as possible, letting the game play itself out to completion no matter how long it takes
- Or you can end input when it's not possible to complete the game any faster with additional input
The movie must be technically sound
Your submission must be reproducible. Judges and Publishers will attempt to verify that your input file syncs on an officially released build of an accepted emulator. If your run fails to sync on an official release, it cannot be verified, and thus cannot be accepted. Anything that could affect sync, such as emulator settings or config options, must be stated in the submission text to help us verify your submission. Use development/interim builds at your own risk, as input files created on them may not sync even on the next official release.
- Dolphin's Beta and Development builds are allowed.
If you're aiming for speed, your submission must match or beat all known records. Check places such as YouTube, NicoVideo, and Speedrun.com for speedruns, as well as the Games section of the forums and our site Userfiles. Improvements that are found and publicized after submission will not count against the submission's quality, unless a faster full run is made and submitted.
Your submission does not have to be absolutely perfect and unimprovable, but it should be as optimized as you can make it. Judges will check your movie's technical quality: they should not be able to easily improve your movie by large amounts of time. All techniques known prior to beginning a run should be used. If you discover a new improvement or technique during the making of your run, you should at least attempt to implement it in any previously done section, though this is not required if the entire run would need to be redone. Make sure to mention known improvements in your submission text as well.
Your entertainment choices should not make the movie unwatchable. Avoid sickening camera angles, flashing lights, and spamming annoying sounds if you can.
Obsoletion of published movies is determined by an improvement of the stated goal. Examples:
- Fastest completion movies are obsoleted by time.
- Playarounds are obsoleted by improved entertainment.
- Esoteric goals can be obsoleted by better completion of the goal, i.e "low%" can be obsoleted by a movie that obtains a lower completion percentage.
- A movie with a later endpoint can obsolete a movie with an earlier endpoint if all content overlaps between the two.
Improvements must be in gameplay to warrant obsoletion. You should not be losing gameplay time compared to the published run: If you find a new timesave that's 30 seconds faster, your movie should be at least 30 seconds faster, unless there is unavoidable time loss as a result. Any time saved or lost from version differences and/or emulation accuracy is considered unavoidable, and is discounted. Your improvement movie may even be longer than the published run, but it is still considered an improvement if it improves upon gameplay.
Our rules have changed significantly over the years, and so we have published runs that break the rules as they currently stand. The current site rules always takes precedence for an improvement, even if the currently published movie breaks them.
- You should always use the most accurate emulator available and a good ROM of the game, even if the published movie does not.
- Glitches that specifically rely on poor emulation must be avoided, even (and especially) if the published movie uses them.
The movie must be properly attributed
All submissions are distributed under the Creative Commons Attribution 2.0 license.
Plagiarism of any sort is grounds for having your submission privileges revoked, and may also result in a full site ban. You are allowed to submit another author's work on their behalf with proof of their explicit permission. Failure to obtain permission may also result in your submission privileges being revoked.
There's no official set of guidelines for co-authorship. Anyone who directly provides input to an input file should be credited, unless they specifically choose not to be. If you are improving a published run, you are only required to credit the previous author if you directly copy their artistic choices (i.e, entertainment choices and playaround segments), or if you are directly working off of their input file. Copying time-saving strategies is unavoidable, and does not warrant credit by itself. For multi-author submissions, the order of authors is entirely cosmetic.
Above all else, respect the wishes of authors. If someone does not wish to be credited as a co-author, their decision is final. If someone believes they should be co-authored for actively working on a submission, they most likely should be.