This page describes the rules for acceptable movie submissions.
Failure to abide by these rules will result in rejection.
To learn creating TASes, read the TASing Guide.
Table of contents

The movie must play the game from the beginning

Giving yourself a headstart is not allowed. The game must start from a common starting point, which is the very beginning.

The movie must begin from console power-on

The movie must begin from the game's power-on state (no loading of saves). That is, the following option must be chosen:
"Record from SRAM" and "Record from now/savestate" or similar is not allowed, except under special circumstances (see the next paragraph).

Installed games

Games that require installation to separate storage media before playing don't count as starting from a save as long as you haven't actually started the main game executable.
We require detailed installation instructions if the instructions included with the game are not sufficient to perform the installation. The movie will be rejected if we can't produce a compatible installation.

We do not allow save-anchored movies.

We want a standard starting point for movies (power-on). Saves introduce an infinite amount of possible variation that may cause the game to behave differently compared to starting from power-on. They also can be hacked, allowing nearly transparent cheating.
However, there are certain games with unlockable modes, second quests, or other things of interest that can only be accessed if a save file (or an otherwise "dirty" SRAM) is present. If you really wish to submit a movie made on such a mode, you will need a verification movie made and provided alongside it. Any input file that starts from power-on (for example, a previously submitted movie for that game) and creates the exact circumstances for your submission to sync will generally do.
Note that you don't have to optimize the verification movie: it only serves as a save or SRAM generator that makes it possible to claim the legitimacy of your effort. This submission is a good example.
In any case, ensure a run of your unlocked mode provides meaningful content over a fresh game. For example, if the unlocked mode features all new bosses, but your run triggers the endgame sequence before meeting any of them, and this same glitch exists in a fresh game as well, then there is no benefit to unlocking this mode.

No skipping to the end with a password

The point is to beat the full game, skipping major sections of the game with a password defeats the purpose. Exceptions may be granted under special considerations (such as the game being too long and repetitive); consult with a judge first.

The game must be acceptable

Game choice must conform either to the standards of Moons for entertainment-based movies, or the game choice rules of the Vault for speed-based movies.
Additionally, specific other types of games are not allowed in any circumstance. Video games rated adult-only, or other adult video games with strong sexual content and/or extreme violence to AO standards, are not allowed.

The game must be real

The movie should look like it could have been played with authentic hardware. This makes it easier to relate to.
This details to the following points:

The ROM must be good

Play games that are emulated well

Emulation of several platforms such as Nintendo 64, Sega Saturn, and PlayStation is still far from perfect, and some games work worse than others. This may be grey area on such systems, but we generally aim to publish videos that look like they could be played back on the original video game system. Movies of games that are not emulated well (have graphical or functional glitches that do not exist on the real console) should not be submitted.
Accurate emulation is preferred over inaccurate! The goal of our movies is to show what could theoretically be done on a real console. Exploiting emulation bugs goes against this goal.

Non-official games (hacks, homebrews, etc...)

Non-official games are allowed for submission. However, they go through more scrutiny than other games. This is because the game itself also becomes a subject to judgment, so it must be a high quality and notable hack or homebrew with a strong following. The TAS should be high quality on its own merit, and must also show something interesting compared to other game(s) made on the same game engine, if applicable.
Do not use fan translations for your movies — see above for more on this. This rule is strict.

No cosmetic hacks

We don't allow hacks that only serve to change the looks of the original game. Hacks must provide unique gameplay.

No tampering with the files the game is composed of

Some systems, such as DOS, exposes the separate parts of the game to the user. You are not allowed to manipulate game files except as normally done during install, if the game needs to be installed.
That means no renaming/copying/deleting/replacing/editing files.

Tools that manipulate ROM or RAM (e.g. Game Genie codes) are not allowed

They count as hacked versions of the game if they touch ROM areas. Either convert it to a real hack or don't use it at all.

Arbitrary Code

Entering arbitrary code into a game via an exploit is allowed as long as some additional qualifications are adhered to.

Speedruns

Players can use arbitrary code to quickly complete games, skipping large portions of them.

Playarounds

Players can also use arbitrary code to create their own entertaining playarounds which do fun things with the game.

No questionable emulator settings

The emulator should be set to emulate the system as closely as possible while still allowing the game to be played. You should not depend on a particular emulator hack to gain speed.

No randomized or unverified custom initial RAM state

Emulator settings to initialize RAM a specific way are not allowed unless the entire RAM state as a whole is proven to be a possible starting state for the console being emulated. This also applies to fully random RAM state initialization, which is guaranteed to generate an invalid starting state the vast majority of the time for most consoles.

The region settings must be correct

If you are running an NTSC game ((U) or (J)), you must set your emulator to record in NTSC mode. Likewise, if you are running a PAL game ((E)), you must record your movie in PAL mode. Any other setting will get your movie promptly rejected. Note that such settings are enabled automatically in most emulators, but it's better to check before you start recording.
If you are obsoleting a movie that was recorded with the wrong settings, that movie's completion time will be adjusted to account for the fact that PAL games run at 50 Hz and NTSC at 60 Hz.
This rule only comes into effect on older console games that have badly programmed region lock-out.

The BIOS must be real

If the system you are using makes use of system BIOSes, only use real BIOSes, not hacked ones.

Match the BIOS region to the game's region.

If BIOS images are region-dependent, do not use an image from a different region. Only use USA BIOS for (U) versions, Japan BIOS for (J) versions, and Europe BIOS for PAL versions ((E) or other). See below for details in general about using non-USA region games.
In the case of PSX, the region is determined by the last number in the BIOS revision, 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. Any official PSX BIOS version is accepted, provided it matches the region of the game played.
Note that SCPH-5501 and SCPH-7003 are completely identical, and therefore can be considered interchangeable.
Make sure to mention the BIOS name used in your submission notes.

Use the correct version

(J) vs (U)

Keep in mind that time gained solely through basic ROM differences will be discounted for the purpose of comparison. This includes:
Only actual gameplay improvements will be considered. For example:
The improvement to be judged in this example is just 1 frame; the 100 frame gain from a shorter title screen is discounted.
It is up to the author to do the math and elaborate upon the version differences during the submission process. The more information you present, the easier it will be to judge your movie.

NTSC vs PAL (USA/Japan vs Europe)


The movie must be good

In particular:

A speed-oriented movie must beat all existing records

If your movie is going to beat something, be sure it beats it.
If your tool-assisted movie is slower than the non-tool-assisted world record for the same game, aiming for the same goals, your movie will be rejected.
Do your research to avoid this. Look for the existing unassisted speedrun records. Look for previous TAS movies in the submission queue or on the forums.
Check places such as YouTube or NicoVideo for speedruns, tool-assisted or otherwise.
Failure to beat existing movies will result in rejection.

The movie's technical quality must be acceptable

Don't be lazy. We will try and beat your movie. We should hopefully not succeed. See the Guidelines on how to make a movie that meets the site's standards.

Cheats, debugging codes, and arcade continues are not allowed

This includes any input sequences such as the Konami Code, as well as immediately accessible hidden menus. Note that, if the button sequence is mentioned in the manual as a normal means of playing, such as level restart shortcuts in the Legend of Zelda or Metroid, it is usually allowed.
Additionally, buying continues with coins in arcade games is considered to be a cheat-like practice, as it provides the player with a free and virtually unlimited power resource, and as such goes against the typical concept of a TAS.
These rules are not strict, but are motivated by the same concept as the guideline that says you should play on the hardest difficulty. As such, you can use a code to unlock the hardest difficulty, although it's better to first ask on the forums if this is a good idea. Indeed, sometimes it may make the movie worse!

The movie must be complete

Your movie should begin from the console power-on and end when the last decisive action has been delivered. There are no specific rules for an exact endpoint but it must adhere to the following rules:
If a game never ends, then it may be considered complete once there is no new content introduced, and the difficulty no longer increases.

Obsoleting a published movie

When obsoleting a published movie that aims for fastest time, the goal should be to adhere to its playing standard in both technical and entertainment aspects.
Site rules still apply even if the published movie breaks them. We make mistakes sometimes, but that doesn't provide a green light for you to break the rules.

The movie must be reproducible

It is not enough that you did it once, we need to be able to run the simulation and get the same result as you did. A movie that only synchronizes on the author's computer won't be accepted.

Use an official emulator version

Every officially supported TAS emulator has a repository to host official releases obtainable as a package (like binaries). These official releases are supported by TASVideos. Using custom or interim builds compiled from emulator source code (from e.g. svn or git repositories) is not officially supported. Always make sure your movie syncs on the official releases; use interim builds at your own risk. If a movie syncs on some interim build, but doesn't sync on any official release, it will be rejected.
Note that some emulators require interims because their official releases are infrequent and/or often outdated (including Dolphin and VBA-rr); for these emulators, interim versions are accepted.

Any important settings not saved in the movie file must be stated in the submission text

Ideally the movie file, a copy of the game and an emulated copy of the system should be everything needed. Sadly, the world isn't ideal. Please, provide all settings that may affect synchronization of your movie on different systems.

Movie file metadata must be correct

It may be easy to lose track of the exact number of rerecords, but do try to get it roughly correct. While it is not supposed to be used for judging, it is nonetheless a fact that a lot of our users pay attention to.

The movie must be properly attributed

Do what is better for the audience, not yourself. Trying to get your name on the site at all costs will not make you popular. TASVideos aims to remain a polite community, so certain offenses are regulated by rules.

Do not claim authorship for something you haven't made

Taking another user's movie and submitting it under your name is strictly forbidden. Such offense is potential grounds for a ban.
This doesn't apply to situations where a similar or identical solution is discovered and implemented independently.

A modicum of effort is required

Taking another user's movie and trimming or changing the last few frames is strongly discouraged if it doesn't make the movie reach the winning condition any sooner. Such movie will likely be rejected during the grace period on the similar grounds as above.
If there is an oversight that requires an easy fix at the end of the published movie, it is much more preferable to notify its author first, and see if they want to implement it themself. If not, it would still be preferable to attribute the new movie as co-authored. See the next paragraph for elaboration.

Crediting other users' contribution

There are no exact rules that estimate the significance of each contribution, but it's generally accepted that if you simply copy large chunks of gameplay from an earlier movie as they are, that effectively makes a new submission coauthored. Authorship isn't enforced, but the audience might become unhappy if you don't give credit where it's due. If unsure, consult with a judge.
This notion is relaxed in sub-second improvements (commonly referred to as "frame wars"), as copying large parts of gameplay from previous generations of such TAS becomes less and less avoidable with each subsequent generation.

Console specific rules

Gameboy series: Use the best mode

Some Game Boy games work in multiple modes:
Because the game can emulate differently depending on the mode, the one you choose is saved in the movie file. This can be difficult to change later, so you should always start recording in the best mode supported by the game.
It is worth mentioning that there is at least one GBC game, Shantae, that recognizes whether it is running on a GBA, and utilizes GBA's hardware features if available. Utilizing this feature is currently only available with recent revisions of lsnes and Bizhawk, and thus does not work at all with VBA-RR.
The default options that appear when starting a recording should reflect the best choices for the currently running game, so think twice before changing them.

Hourglass movies

For Hourglass, you need to provide the DxDiag log to prevent against syncfailures due to different hardware. For instructions, see the thread on the Hourglass forum.

Commodore 64

For Commodore 64 movies only, movies made using disk ROM files are preferred over movies using tape ROM files. This is due to the very slow loading times of C64 tapes, which significantly affect the watchability of such movies.
This applies also for cracked Commodore 64 disk ROMs, if no non-cracked disk ROM version is available.

Acceptable movie files

We accept key-input movies of these formats, and only these formats:

NES

Super NES

Nintendo 64

Game Boy & variants

Game Boy Advance

Nintendo DS

Sega Master System and Sega Game Gear

SG-1000 and ColecoVision

Sega Genesis/Megadrive

Sega CD

Sega Saturn

PlayStation

Arcade / Neo Geo

TurboGrafx 16 (PC Engine), PCE-CD, SuperGrafx

Neo Geo Pocket (Color), WonderSwan, Atari Lynx

Virtual Boy

Atari 2600, Atari 7800

TI-83

Gamecube & Wii

PC-DOS (x86)

MSX home computers

Windows

Technically submittable movie formats

Movies of these formats can hit the Workbench if submitted:
Unknown module submittableformats
See EmulatorResources for more information.

Multimedia files are not accepted

We do not accept multimedia files (AVI, WMV, MP4 and so on). The site wants a method of movie control, such as:
Multimedia files make the above points impossible.
There is no way to verify a multimedia file. It would be impossible to prove that a video was or was not edited.

[1] Binary .lsmv format is not accepted at the moment (not implemented yet), use the .zip-based one.

LegacyPages/MovieRules last edited by Noxxa on 7/2/2017 8:12 PM
Page History Latest diff List referrers View Source