TASVideos

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

Rules

Table of contents [expand all] [collapse all]

Rules of systems and files

We accept key-input movies (and emulators) of these formats:

For NES

  • FCEUX movie files (FM2) made with version 2.0.2 or newer.
  • FCE-Ultra (FCEU) movie files (FCM) made with version 0.98.12 or newer (0.98.28 is commonly recommended)

Famtasia movie files (FMV) and VirtuaNES movie (VMV) files are deprecated and not allowed anymore.

Note: Deprecated means that new movies should not be made with this emulator.

For Super NES

  • Snes9x movie files (SMV) made with version 1.43 or 1.51 [5]
  • ZSNES movie files (ZMV) made with version 1.42 (for now at least)

For Sega Master System

  • Dega movie files (MMV) made with Dega 1.14 or newer

For Sega Genesis/Megadrive

  • Gens movie files (GMV)

For Nintendo 64

  • Mupen64 movie files (M64) made with the rerecording version
    • We do not accept movie files made with the official recording version (REC)
    • Read the M64-specific rules later at this page!

For Game Boy & variants, and Game Boy Advance

  • Visual Boy Advance (VBA) movie files (VBM) made with the re-recording version.
    • 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!

For Nintendo DS

  • DeSmuME movie files (DSM)

For PlayStation

  • PCSX movie files (PXM) made with PCSX-RR 0.0.6 or newer

For Arcade / Neo Geo

  • Final Burn Alpha (FBA) movie files (FBM)

For TurboGrafx 16(PC Engine), Neo Geo Pocket (Color), WonderSwan, Atari Lynx

  • Mednafen movie files (MCM)
    • Currently the windows port can only support TG-16 & variants.

For PC (DOS)

There has been a DOS submission that was created using modified DOSBox emulator. However, DOSBox isn't yet made into an universal TAS-capable application, so it's likely impossible to create TASes for other games with it yet. Until then, submitting PC TAS movies isn't permitted. If you are willing to help with TAS-oriented DOSBox development or have created a TAS with it that satisfies our goals and conditions, please visit the DOSBox discussion thread or contact adelikat otherwise.

For other systems

Movies for any other systems aren't accepted.

There have been several working emulators of other systems, but some of them don't produce movies that meet all required features for us to accept, while some simply don't support recording movies at all. If you are willing to help with the developments of rerecording emulators, please visit the Emulator Development and Potential Emulators pages for more information.

See EmulatorResources/Homepages for more information about emulators and their versions.

Multimedia files (AVI, WMV and so on) aren't accepted no matter what the system is.[1]

The movie must begin from console power-on

The movie must begin from the game power-on state (no loading of saves). That is to say, you must choose ‘record from power-on/start’, not ‘record from reset/sram’ or ‘record from now/savestate’.

We do not allow save-anchored movies.[2]

Exceptions for verified saves (or for a demonstration of something fancy) can only be allowed under special permission.

The games must be real

The movie should look like it could have been played with an authentic hardware. This makes it more familiar to the audience.

This details to the following points:

Hacked and homebrew games are not allowed

Generally, we only accept hacks which only make the game playable on an emulator. We do not accept hacked games (graphics hacks, level hacks, music or sound hacks, dialog hacks and so on). [3]

This rule can only be bent by special permission ― you must ask a permission before going to submit a movie of a patched game. Currently these games have special permissions:

Do not use fan-translations for your movies ― see below for more on this. This rule is strict.

Codes that manipulate ROM or RAM directly (e.g. Game genie codes) are not allowed

The ROM must be good

Use the correct version

The PAL/NTSC settings must be correct

If you are running a 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 20% when comparing them 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 movie must be good

This details to following points:

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 of the game you play, your movie will almost certainly be rejected.

This only matters if the goals are directly comparable between the TAS and unassisted record, though.

Cheat-keys and debugging codes are not allowed

Such as the Konami Code.
If the key sequence is mentioned in the manual as a normal means of playing, it is (usually) allowed.

This rule is not strict, but its motive is the same as in 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.

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[4] but it must adhere to the following rules:

  • It must beat the game.
  • It must be able to reach the credits or end screen without the viewer needing to do anything. An exception has been allowed for Rygar.
  • It must not be needlessly long.

Under special consideration we might allow movies that play a single level only or a part of the game only.

Emulator specific rules

Do not use emulators we do not allow. See the beginning of this page again. That being said, here are the emulator-specific rules:

Visual Boy Advance: Use the best mode

Some Game Boy games work in multiple modes:
  • GB ― Monochrome (the first 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 it 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 allows recording GBC movies in GBA mode.

For Game Boy Advance games, there is no choice like this to worry about.

However, it is recommended that lag reduction mode (prefetch emulation) for GBA movies be enabled.

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.

Mupen64: Play only games that are emulated well

Nintendo 64 emulation is still far from perfect, and some games work better than others. This is really a vague rule, but because we aim to publish videos that actually look like 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.

Clarifications

[1] Multimedia files (AVI, WMV and so on) are not accepted

We do not accept multimedia files (AVI, WMV 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 AVIs for publishing.

Multimedia files make the above points impossible.

There is zero verifiability in a multimedia file. It would be impossible to prove that a video was or was not edited.

[2] In general, movies that begin from saves are not accepted

We want a standard starting point for movies (power-on). Saves are not standard, as there are many of them, and each 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 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 mode, you will need a verification movie first. Any input file that starts from power-on (for example, a previously submitted or published 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. A good example is this submission.

[3] Hacked games in general are not allowed

Hacked games in general are not allowed, because we really do not have resources to judge all of them. There are potentially infinite number of hacked versions of games, and we can not know how those games are supposed to work and what is normal and what is impressive. The authors of the hacks also release updated versions to their hacks every once in a while - who knows which version should be used?
However, we may sometimes make exceptions of this rule, but the idea has then to be discussed beforehand (to avoid unnecessary disappointments).

[4] Exact termination point

There are no other rules about when a movie should end. Assuming the above rules are met, the following are options:

  1. Ending the movie as soon as possible before beating the game but slowing game completion.
  2. Ending the movie before beating the game when the game cannot be completed faster.
  3. Ending the movie on the "last hit" or last character control.
  4. Ending the movie when no further input can prevent the game from reaching the ending.

Number 1 is not recommended, except as a surprise factor.

Where using number 1 results in a conflict of interest by timing, the movie is timed up to the last hit or other decisive action that is considered beating the game.

RSS
Rules last edited by adelikat on 2009-07-03 23:51:47
Page info and history | Latest diff | List referrers