>> ES | Español
>> FR | Français
>> IT | Italiano
>> JA | 日本語
>> RU | Русский
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.


This is a short summary of our baseline requirements.

Before Starting...

When choosing a game...

When TASing...

When submitting...

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.
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.
Runs that optimize In-Game Time (IGT) are only allowed in Standard if they contain faster gameplay than a real-time focused run.
Cheat codes and passwords are only allowed to access harder difficulties and/or bonus content, including cosmetic improvements.
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:


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:

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:
ROM hacks must not be overly obscure. If a hack is known to GoodTools, ROMhacking.net, SMW Central, or some other well-known database, that usually means its quality is decent and it won't be completely lost in the future.

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 [b], [h], or [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 game in an unintended environment, including modifying emulator settings for unintended speed advantages.
For PC games, environment settings explicitly supported by the game or its documentation are allowed.
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:
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.
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:
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.
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:
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 necessary input. If you're unsure exactly when to end input, submit it as-is and staff will truncate it for you. 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:

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.
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.
See the TASing Guide for how to make a high quality TAS, and the Guidelines specifically.


Obsoletion of published movies is determined by an improvement of the stated goal. Examples:
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.

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.

MovieRules last edited by feos 29 days ago
Page History Latest diff List referrers View Source