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.
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
- The game must be acceptable
- The game must be real
- Use the correct version
- The movie must be good
- Cheats, debugging codes, and arcade continues are not allowed
- The movie must be complete
- Obsoleting a published movie
- The movie must be reproducible
- Movie file metadata must be correct
- The movie must be properly attributed
- Console specific rules
- Acceptable movie files
- 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
- Multimedia files are not accepted
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 power-on/start", or
- if the above isn't applicable, then "Record from reset" and any check box that has "Clear SRAM" or similar must be checked.
"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
- Use a good ROM dump if available. Good dumps are commonly labeled
[!]
. - Do not use bad dumps. Bad dumps are are commonly labeled
[b]
. - Do not use an overdump ROM (labeled
[o]
) if a non-overdump ROM is available. - Do not use fan translations, cracked game versions, or otherwise hacked ROMs — translators do not want you to use obsolete versions and we prefer non-hacked games. Hacked versions are labeled
[h]
and[t]
. - Exceptions may be made for bad or cracked ROMs only if no good ROMs exist, or are not obtainable.
- Provide hash checksums of the ROMs you used.
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.
- Do not exploit emulation bugs, even if a movie you're trying to beat does so. Even if yours ends up slower but demonstrates superior gameplay, it will be preferred. If you're unsure whether a bug you're trying to abuse pertains to emulation rather than the game itself, try reproducing it on a real console or a different (preferably more accurate) emulator.
- The same goes for exploiting bugs in a bad ROM dump. We would prefer the slower version that represents a more accurate playthrough.
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.
- Arbitrary code entered into a game which allows for fastest possible progression of the game is always allowed. Often this means jumping directly to the end credits or screen.
- Using arbitrary code to complete the current level is allowed.
- It is not allowed to use arbitrary code inefficiently, creating runs which skip smaller and arbitrary portions of the game than would otherwise be possible.
Playarounds
Players can also use arbitrary code to create their own entertaining playarounds which do fun things with the game.
- Playarounds making use of arbitrary code must still appear to complete the game, showing the end credits or ending screen at the end.
- Replacing the end credits or ending screen with your own is allowed as long as it appears to fit the game.
- Arbitrary code for a game must appear to do one of the following:
- Enhance or extend the game in some way and play the modified game.
- Make use of in-game assets to create something which looks like it could be something built into the game to an uneducated viewer.
- Arbitrary code payloads which have nothing to do with the game are not allowed. TASVideos is not a place to show off your science projects.
- Adding custom content is allowed as long as your have the legal right to do so, meaning you created and/or own it, or the added content can be redistributed in accordance with fair use.
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)
- The US (
(U)
) versions are generally preferred over the Japanese ((J)
) version due to the use of English language, which is easier to understand for the general audience. However, the Japanese audience here is significant, and there is no longer a specific requirement at TASVideos to use one version over another.
Keep in mind that time gained solely through basic ROM differences will be discounted for the purpose of comparison. This includes:
- time gained through shorter cutscene text and speech boxes due to Japanese writing being more compact;
- differences in title screen, cutscenes, and menus (unless menus are the game's main control interface).
Only actual gameplay improvements will be considered. For example:
- there's a published movie made on a
(U)
ROM; - the title screen for this game takes 100 frames less on a
(J)
ROM; - a movie made on a
(J)
ROM is submitted, that is 101 frames faster than the movie made on a(U)
ROM.
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)
- Console versions of PAL games run at a lower framerate than NTSC games, running at ~50Hz compared to NTSC's ~60Hz, and the games themselves are often not modified or poorly modified to accommodate to the change in timing. Due to this, PAL versions of ROMs are generally not allowed, unless there are significant technical and/or entertainment merits to using this version. See Rygar and Blaster Master for examples of good usage of the PAL ROM.
- European versions of handheld games are allowed, but are not recommended. Use an
(U)
version if available. The same rule applies to European versions of more modern console games that support PAL 60. - The Sega Master System is an unique system in that it can officially play PAL games at NTSC frequency in PAL-M regions (Brazil). Therefore, playing PAL games with NTSC settings is allowed for SMS games, but only if the game has a known official release in Brazil. More details about PAL-M here.
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.
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.
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:
- It must beat the game (1-level movies that don't finish the game are rejected).
- It must be able to reach the credits or end screen without requiring any further interaction; all input must come solely from the input file (e.g. configuring the emulator to autofire after the end of playback is not allowed). An exception has been allowed for Rygar.
- It should end with the last input. Don't leave any blank input at the end of the movie.
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.
- If you found a shortcut that saves 30 seconds, your movie should be faster by at least 30 seconds. Losing time elsewhere for no good reason is unacceptable.
- If a published movie is notable for its entertaining idle time stunts (such as synchronizing actions to background music), you should at least try coming up with something comparably entertaining. Copying such actions from a published movie is not a problem, although in this case it will be a common courtesy to mention its author in your submission message.
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.
- If a published movie uses a bad dump, you should instead use the good one.
- If a published movie uses an inaccurate emulator and you have the choice of a more accurate one, use the latter.
- However, if a rule is broken for a specific reason and it has been allowed for the published movie, then it's usually okay. If unsure, ask a judge or admin before making the movie. (An example would be movies that start from SRAM, use passwords, etc.)
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:
- GB ― monochrome (the original Game Boy type);
- SGB ― Super Game Boy (the GB game plugged into SNES, has a graphical border and some colours);
- GBC ― Game Boy Color.
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.
- If the game supports GBC capabilities, play it in GBC mode.
- If the game does not support GBC, but does support SGB and is enhanced by it (with sound enhancements, screen palettes, or similar), play it in SGB mode.
- Only play the game in monochrome GB mode if the game does not support GBC, and does not support SGB or is not notably enhanced by it.
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
- FCEUX movie files (FM2) made with version 2.0.2 or newer;
- TAS Editor project files (FM3) made in FCEUX 2.2.0 or newer;
- BizHawk movie files (.bkm / .bk2);
- FCE-Ultra (FCEU) movie files (FCM) made with version 0.98.12 or newer (0.98.28 is the last release in the branch) (deprecated).
- Famtasia movie files (FMV) and VirtuaNES movie (VMV) files are deprecated and not accepted.
Super NES
- Snes9x movie files (SMV):
- Snes9x v1.43 movie files are deprecated and not accepted, unless a continuance is granted.
- Snes9x v1.51 movie files are supported but deprecated.
Nintendo 64
- BizHawk movie files (.bkm / .bk2) (preferred).
- Mupen64 movie files (M64) made with the rerecording version are deprecated and not accepted, unless a continuance is granted.
Game Boy & variants
- Visual Boy Advance (VBA) movie files (VBM) (deprecated)
- We do not accept movie files made with earlier versions of VBA (denoted by file types VBV and VMV).
- Read the VBA-specific rules later at this page!
Game Boy Advance
- Visual Boy Advance (VBA) movie files (VBM)
- We do not accept movie files made with earlier versions of VBA (denoted by file types VBV and VMV).
- Read the VBA-specific rules later at this page!
Nintendo DS
- DeSmuME movie files (DSM) made with DeSmuME 0.9.6 or later. Do not use interim builds, or versions prior to 0.9.6.
Sega Master System and Sega Game Gear
SG-1000 and ColecoVision
Sega Genesis/Megadrive
Sega CD
- Gens movie files (GMV)
Sega Saturn
PlayStation
- BizHawk movie files (.bk2).
- PSXjin movie files (PJM) and PCSX movie files (PXM) are deprecated and not accepted, unless a continuance is granted.
Arcade / Neo Geo
TurboGrafx 16 (PC Engine), PCE-CD, SuperGrafx
- BizHawk movie files (.bkm/.tas / .bk2) (preferred)
- Mednafen movie files (MC2) (deprecated)
- Windows users should use PCEJin which uses the same MC2 movie file.
- The old movie format (MCM) is not recommended but still technically allowed.
Neo Geo Pocket (Color), WonderSwan, Atari Lynx
- Mednafen movie files (MC2). The old movie format (MCM) is not recommended but still technically allowed.
Virtual Boy
- Mednafen movie files made with VBJin.
Atari 2600, Atari 7800
TI-83
Gamecube & Wii
- Dolphin movie files (DTM).
PC-DOS (x86)
- JRSR movie files (JRSR) made with JPC.
MSX home computers
- OMR replay files made with openMSX.
Windows
- WTF files made with Hourglass.
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:
- having a verifiable standard key-input movie;
- extracting important information about the movie directly from its header;
- creating high-quality encodes for publishing.
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.