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 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 can 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 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 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]. - 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.
Hacked and homebrew games
Hacked games are allowed for submission. However, they go through more scrutiny than other games. This is because the hack itself also becomes a subject to judgment, so it must be a high quality hack 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.
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.
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.
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 increased by 20% for comparison, to adjust for the fact that PAL games run at 50 Hz and NTSC at 60 Hz.
This rule only comes into effect on NES games and possibly Genesis 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 above for details in general about using non-US region games.
In the case of PCSX, the region is determined by the last number in the BIOS revision,
SCPH-xxx0 or SCPH-xxx3 is Japan, SCPH-xxx1 is US and SCPH-xxx2 is PAL. (see the Wikipedia article for detailed list). SCPH-1001 is preferred for (U) versions.
Use the correct version
Due to the lower frame rate (50 Hz) and the fact that games are usually not modified in order to compensate for this, PAL versions of ROMs are generally not preferred, 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.
(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.
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 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). Using these releases is supported by TASVideos. Using interim builds compiled from SVN source is not officially supported. Always make sure your movie syncs on the official releases, use interim builds on your own risk. If it syncs on some interim build , but doesn't sync on any official release, it will be rejected.
Note that some emulators and games still require interims (development builds) to work properly (like Dolphin). Use such only if you know what you are doing. For such rare cases exceptions can be made if using interims is unavoidable TAS-wise. Otherwise stick to official releases.
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, play it in SGB mode.
- An exception may be provided if SGB mode colorization doesn't enhance the visual content in any sensible way (such as in Donkey Kong Land 3, where the whole screen is tinted with one color, effectively decreasing overall visibility).
- Only play the game in monochrome GB mode if the game does not support either GBC or SGB.
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. However, none of the available re-recording versions of VBA allow recording GBC movies in GBA mode.
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.
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);
- 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) (preferred).
- Mupen64 movie files (M64) made with the rerecording version. (deprecated)
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
- PSXjin movie files (PJM) made with PSXjin 2.0.0 or newer;
- PCSX movie files (PXM) made with PCSX-RR 0.0.6 or newer.
Arcade / Neo Geo
TurboGrafx 16 (PC Engine), PCE-CD, SuperGrafx
- BizHawk movie files (.bkm/.tas) (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.