Tool-assisted game movies
When human skills are just not enough

Movie Rules

>> ES | Español
>> FR | Français
>> IT | Italiano
>> JA | 日本語
>> RU | Русский

The English language version of these rules supersedes all translated versions of these rules. Translations of these rules into other languages are provided for informational purposes only.

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 [expand all] [collapse all]

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.

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:

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 hack or homebrew must be a finished release version; demo or beta versions of in-development games are not allowed. 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.


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.


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.

Real-time clock (RTC) settings

For systems that support a configurable real-time clock, any timestamp supported by the system may be set as a starting point for a run if the game makes use of it, e.g. for RNG seeding reasons.

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.
  • PAL versions of the following games are allowed, but are not recommended. Use an (U) version if available.
    • Any game for a handheld game console that does not directly connect to a television (e.g. Game Boy)
    • Any modern console game that supports PAL 60 (e.g. many GameCube games)
    • Commodore 64 games (regarding region settings, not game versions, as C64 games have no easily identifiable or verifiable region information)
  • 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 not faster 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

A submission may obsolete a published movie by improving or surpassing it upon its stated goal. A submission that follows the same goals as a published movie must beat it in its intended goal. For example, if the goal of a movie is fastest time, the submission must be faster; a slower or tied movie will be rejected.

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

Game Boy series: Use the best mode

Some Game Boy/Game Boy Color 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
  • GBA - Game Boy Advance

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 neither Super Game Boy enhancements nor Game Boy Color's full-color graphics are supported, Game Boy mode should be used.
  • If Game Boy Color's full-color graphics are not supported, but Super Game Boy enhancements are available in the game (i.e. borders, dynamic palette changes, and/or other exclusive features within the game), then either Game Boy mode or Super Game Boy mode can be used. Both are accepted, but movies of the same game and category can obsolete one another based on whichever has the shortest in-game run time based on frame count.
  • If the game has full-color graphics for Game Boy Color, Game Boy Color mode should be used. If the Super Game Boy mode also unlocks notable exclusive gameplay features, then SGB mode may also be accepted for a movie that makes use of said exclusive features.
  • For Game Boy Color games, Game Boy Advance mode can also be used. Like Super Game Boy for Game Boy games, either method is accepted, but movies of the same game and category can obsolete one another based on whichever has the shortest in-game run time based on frame count.

The default options that appear when starting a recording should often reflect the best choices for the currently running game, so think twice before changing them.

Important note: SGB mode in VBA-rr is disallowed entirely due to poor and hacky emulation. To use SGB, lsnes or BizHawk must be used.

DOS movies (JPC-rr)

CPU frequency restrictions

CPU frequency settings may be restricted or not, depending on the game.

  • If a game's speed is limited to real-world time or screen refresh, CPU frequency may be maximized by setting CPU frequency divider to 1 (emulating a 1GHz CPU).
  • If a game's speed is limited only by CPU frequency or clock speed, CPU frequency may be set no faster than JPC-rr's default of 50 (emulating a 20MHz CPU). In other words, the CPU frequency divider settings may not be set any lower than 50. This limit may be stretched if proof can be provided that the game was designed to run on faster systems than the 20MHz default.

In other words, if increasing the CPU clock speed affects and speeds up all normal gameplay, it must be capped at most to the emulator's default setting, or to a frequency the game is proven to be designed for. If increasing the CPU clock speed only affects lag or loading times and does not otherwise speed up gameplay to any significant extent, it may be set to the emulator's maximum.

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:


  • 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):

Nintendo 64

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


Arcade / Neo Geo

  • Final Burn Alpha Rerecording(FBA-rr) movie files (FBM). The older format, FR, is not allowed.

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

  • BizHawk movie files (.bkm/.tas / .bk2) (preferred).
  • Mednafen movie files (MC2) (deprecated). The old movie format (MCM) is not recommended but still technically allowed.

Virtual Boy

Atari 2600, Atari 7800


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.


  • WTF files made with Hourglass.

Technically submittable movie formats

Movies of these formats can hit the Workbench if submitted:

  • BizHawk Movie (.bk2)
  • Bizhawk movie (.bkm)
  • DeSmuME movie (.dsm)
  • Dolphin movie (.dtm)
  • Final Burn Alpha movie (.fbm)
  • FCEUX movie (.fm2)
  • FCEUX movie (.fm3)
  • Gens movie (.gmv)
  • JPC-RR movie (.jrsr)
  • DooM demo (.lmp)
  • lsnes movie (.lsmv)
  • MAME-rr movie (.mar)
  • Mednafen/PCEjin movie (.mc2)
  • Mednafen movie (.mcm)
  • openMSX replay (.omr)
  • snes9x movie (.smv)
  • VBA movie (.vbm)
  • Hourglass movie (.wtf)

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.

Combined RSS Feed
MovieRules last edited by Mothrayas on 2018-03-18 23:25:04
Page info and history | Latest diff | List referrers | View Source