Revision (current)
Last Updated by Darkman425 on 8/21/2023 3:40 AM
----
__This is an archive of the [Movie Rules] as it existed prior to November 27th, 2021, when the page was replaced with a completely rewritten version. This page does not reflect current rules, and is only meant for reference purposes.__
----
The English language version 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 [Subs-List|submissions].%%%
Failure to abide by these rules will result in [Forum/Subforum/24|rejection].
To learn creating TASes, read the [TASing Guide].
These rules are subject to change as the site continues to grow, and have done so many times in the past. There may be published movies that break these rules: these movies were published before the rules against them were put in place, and we do not unpublish movies for any reason. These movies should not be used as precedents for current submissions.
If your submissions ''repeatedly'' and ''flagrantly'' break movie rules, you may become a Limited User and temporarily __lose your submission privileges__. This is rare, however, and is generally only done to prevent spamming of the submission queue and to encourage the submitter to engage with the community to hone their TASing skills. A Limited User's privileges can be reinstated if they show that they are learning to produce quality TASes.
For any questions that remain after having read this page, please [Forum/Topics/19741|ask a judge].
For learning the latest changes to the rules, read the [MovieRules/History|Movie Rules History].
%%TOC%%
%%%
!!!! Rules for games
!!! The game must be acceptable
We have two sets of rules on acceptable games, varying between [Class|classes]: rules for [Standard] that contain genre and game type restrictions, and rules for [Alternative] that permit more types of games but require the submission to be entertaining. There is a third class, [Stars], but it consists of movies from Standard and Alternative picked by users and staff. Games that are acceptable in either of those classes are acceptable in Stars.
!! Standard
This class contains movies that represent tool-assisted superplay records of [#Standard_2|standardized goals]. Game choice has some limitations as seen below.
! The game must have clear achievable goals
Games consisting mainly of aimless wandering are not considered acceptable.
The gameplay needs to stand out from unassisted play, and must not be seen as trivial. Note that a game is considered trivial until proven otherwise. If getting perfect times everywhere is challenging, such a game is considered acceptable. If a game was considered trivial but a technique is found later that makes TASing it challenging, that game becomes acceptable.
* Example of a trivial (mini-)game which does not stand out is ''Desert Bus''.
Games focusing on freeform creativity are not considered acceptable.
* Examples are the main feature of ''Mario Paint'' or ''Color a Dinosaur''.
! No game hacks
[MovieTagGuidelines#UnofficialGames|Game hacks] are not eligible for Standard. We demand hacks with entertainment value, therefore they are judged by the [Alternative|Alternative class] requirements.
Custom levels are treated as ROM hacks and are not allowed for this class.
! No board games or game show games
These game genres are not eligible for Standard.
* This includes ''real-world board games'' such as [2768S|chess] and ''Monopoly''.
! Sports games are allowed under restrictions
Sports running with a fixed time, such as football, soccer, or basketball are not eligible.
* Games featuring multiple successive sports, such as track & field and Olympics, are eligible as long as one of the sports fits the criteria.
The game must have a meaningful ending point with meaningful completion criteria.
* For example, many sports games have career, storyline, tournament or season modes that end with an ending or credit sequence. These would count as meaningful endings.
* In sports that depend on a variety of environments or situations, such as golf, completion can be defined by clearing every environment or situation in the game.
* TASes that only clear a single event or several events of a larger set without reaching a meaningful ending to the game are not eligible.
Team-based sports games should provide enough control to the player to be able to competitively speedrun the game and have a meaningful record, as decided by the judge.
The run must not be seen as trivial.
* If a run consists of executing a trivial strategy where the only challenge is having to do it over the course of several rounds, it will still be judged as trivial. For example, bowling games where the player gets a strike with ten pins every time.
Sports games in the Standard class are restricted to one game per series per platform, unless gameplay is significantly different. For example, ''PGA Tour Golf III'' on the Sega Genesis may obsolete ''PGA Tour Golf II'' on the Sega Genesis. Which game obsoletes which is decided by a judge in favor of the game that makes a more technically impressive run.
* For games with different characters/groups/countries with different statistics, only the fastest run is accepted. Runs using characters known to be suboptimal are not accepted.
!! Alternative
This class has minimal restrictions on game choice, but the resulting movies must be seen as entertaining. Read the [Guidelines#Fashion|TASing guidelines on fashion] on how to accomplish this.
!! Non-official games (hacks, homebrews, etc.) and prototypes
[MovieTagGuidelines#UnofficialGames|Non-official games] are allowed for submission. However, they go through more scrutiny than other games. This is because the game itself also becomes subject to judgment, so it must meet a minimum standard of quality or notability to be eligible for publication. We look for games that can be played and completed, have some recognition or popularity, or are notable in some other ways as decided by the judge and the audience.
* If a game is infamous and notable for being too buggy to even be completable, we may allow a patched version that fixes some of the bugs and makes it completable.
__Bootlegs__ are not accepted if they are direct clones of licensed games on the same platform: we prefer official versions. Ports from other platforms are acceptable, as long as the gameplay has notable differences.
__Game hacks and custom levels__ must be accepted by the community as being entertaining enough to make it to the Alternative class, usually by showing unique gameplay or brand new content. Hacks of the same game may obsolete each other if the new hack is deemed superior, such as by showing off more unique content.
__Game hacks, custom levels, and homebrews__ must be in a finished release state; demo or beta versions of in-development games are not allowed. Homebrews, custom levels, and hacks that are not finished, but have been abandoned by their authors (explicitly as a public announcement, or implicitly as lack of updates or replies from the author for at least 5 years straight), can be considered.
__Prototype game versions__ are only accepted if there is no stable release version available on the same (or compatible) system.
* If the prototype is so different from the official release that it can be considered a different game (at least 50% of inherently unique gameplay), it is acceptable.
! No cosmetic hacks or fan translations
We don't allow hacks that only serve to change the looks of the original game. Hacks must provide unique gameplay. This rule is strict.
!! Adult-only games are not allowed
Video games [https://en.wikipedia.org/wiki/List_of_AO-rated_video_games|rated adult-only], or unrated adult video games with strong sexual content and/or extreme violence to AO-rating standards, are not allowed in any circumstance.
* For games with uncensored adult-only versions and censored versions that are rated less than AO, a movie of either version is allowed as long as no uncensored content is accessed or visible. For example, Grand Theft Auto: San Andreas is allowed as long as no Hot Coffee content is seen in it.
* A movie that takes a non-adult-rated game but still implements adult-only depictions through customization, glitches, or other such methods, may still be rejected for featuring adult-only content.
----
!!! 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 image must be good
* Use a good ROM image 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 image is available.
* Do not use fan translations, cracked game versions, or otherwise hacked ROM images — 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 ROM images only if good ROM images don't exist or aren't obtainable.
* Provide hash checksums of the ROM images you used.
If a platform supports several types of media, we allow conversion between them (to speed up the loading times, for example) only if the software itself remains unchanged, and if the platform in question natively supports transferring the software from one medium to another without any unsupported modifications to the platform itself (hardware or software), and can execute the software when transferred to the new medium.
!! The ROM image must be integral
It is not allowed to make use of images that are not intended to belong to the game being TASed. It is considered intended, if it is endorsed by the game or by its publisher (as an add-on, for example).
For games that consist of multiple images that are intended to be used in a specific order, inserting a new image is only allowed when the game explicitly prompts for it, and the intended order must be respected.
If the gameplay requires, or mainly consists of, inserting arbitrary ROM images (such as the ''Monster Rancher'' series), such images must also be inserted only when the game duly prompts. However, there are strict requirements on the nature of such arbitrary images:
# You need to use an image that's been generated specifically for the movie in question
# You need to provide clear instructions on how to recreate it
# This image has to serve the goals of your movie in a considerably optimal way
# You need to provide insight on why you consider it optimal
# The method used to create it must be free and easily accessible
!! Virtual Console and extracted games
Sometimes a game may contain another game within it. For example, copies of ''The Legend of Zelda: Ocarina of Time'' for the Nintendo GameCube contain within it a Nintendo 64 image for the original game, as well as the Master Quest edition. These are valid Nintendo 64 game images that work on a real Nintendo 64, although in-game details refer to specifics for the Nintendo GameCube instead of the Nintendo 64.
* Game images extracted in this fashion are acceptable as long as the game runs correctly.
** An extracted game image which has non-gameplay specific changes but is otherwise identical to a non-extracted ROM image is not acceptable, as the non-extracted game image should be played instead.
*** If the extracted version is the only version of the game that exists in English, but is otherwise identical to a non-extracted non-English game, it is acceptable.
* If a VC game image features the same gameplay as the original game it represents, the original game is preferred. To be published separately, the VC game should either count as a [#UseTheCorrectVersion|different game version] or as a [#GamesWithAdditionalLevelSetsOrGames|separate game mode] compared to the original game.
!! Play games that are emulated well
Emulation of several platforms such as Nintendo 64, DOS, or specific Arcade boards is still far from perfect, and some games may work worse than others on the same platform. 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.
!! No tampering with the files the game is composed of
Some systems, such as DOS, expose separate parts of the operating system and/or the game to the user. You are not allowed to manipulate these files except as is normally necessary to play the game, such as "installing" it.
MS-DOS and clones have different memory layout features such as [https://en.wikipedia.org/wiki/HIMEM.SYS|HIMEM] and [https://en.wikipedia.org/wiki/EMM386|EMM386] which support various settings which a game may require or perform better with. Configuring these built-in options, or utilizing a comparable third party tool such as [https://en.wikipedia.org/wiki/QEMM#QEMM_driver|QEMM's driver] is allowed. DOS also requires certain [https://en.wikipedia.org/wiki/DOS_extender|extenders] in order to run 32-bit applications or access [https://en.wikipedia.org/wiki/DOS_Protected_Mode_Interface|protected mode]. Using an extender included with a game, or a compatible third-party one which does not alter the gameplay is allowed.
That means no renaming/copying/deleting/replacing/editing files that affect gameplay. However, editing environment settings or utilizing standard third-party tools in order to get a game to load is allowed as long as the game runs as it's supposed to.
!! 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 them to a real hack or don't use them at all.
!! No questionable emulator settings
The emulator should be set to emulate the system as accurately 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 [/HomePages/Nach/MemoryInit|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.
* Choosing an unverified custom initial RAM state which is identical to the state used by default for another accepted emulator for the same platform is frowned upon, but is allowed for compatibility reasons.
! 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 custom 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 [https://en.wikipedia.org/wiki/PlayStation_models#Comparison_of_models|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.
!! PC game environment must be legitimate
PC games don't support an infinite variety of hardware and software combinations. Each game usually targets some known specifications and is expected to work correctly only within a certain range of those. Specifications outside that range may be totally incompatible with a given game, and on some variations it can glitch out and not be fully playable.
In-game settings and environment parameters used in the movie must be legitimate and intended. This includes in-game options, console commands, launch arguments, in-game codes, host hardware and software tweaks, etc.
* Means of improving the game's appearance, sound, and alike, without affecting the gameplay, are allowed.
* In-game settings and environment parameters that are explicitly supported and intended for normal play are allowed.
** This means there are limited options the game was designed to work with, for example a few speed variants. Explicit support can be proven by in-game options, official instructions and PC spec recommendations, release notes, source code logic and comments, etc. Burden of proof is on the TAS author here. If this information is completely unavailable for a given game, rely on the environment specs that were common and popular around the game's release time.
* In-game settings and environment parameters that are not intended for normal play and don't belong to point 1 should be left at default values. Deviations from those are disallowed from Standard.
** For example, if [https://en.wikipedia.org/wiki/Overclocking|overclocking] a CPU beyond intended specs affects gameplay, use of unintended CPU speed can not belong to [fastest completion] (any%) or to the definition of a [#FullCompletionRules|full completion] goal.
----
!!! Use the correct version
If there are significant in-game differences between different versions of a game, movies which take advantage of such differences can be published side by side. This can include things like different weapons or routes available to the player, different levels being present, or different bosses fought. If a particular version introduces a mechanic which can significantly alter how the game is played (such as where player characters respawn immediately when they die instead of being brought back to a nearest checkpoint), a movie utilizing such mechanic can be published side by side with one that doesn't.
However, different versions of a game usually don't diverge much. For when they're mostly the same, the considerations are as follows:
!! (J) vs (U)
The US ({{(U)}}) versions are generally preferred over the Japanese ({{(J)}}) versions 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 [PlatformFramerates|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 them. See [29G|Rygar] and [82G|Blaster Master] for examples of such merits.
PAL versions of the following games are __allowed but not recommended__. Use a {{(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 (there's no easily identifiable or verifiable region information on C64 game versions, so [Bizhawk/C64#RegionNtscVsPal|run them in PAL mode] if they don't work correctly in NTSC mode)
The Sega Master System is a unique system in that it can officially play PAL games at NTSC frequency in [https://en.wikipedia.org/wiki/PAL-M|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. Additionally, if it is known that the game has been officially released in South Korea, we allow to run the Korean ROM in the NTSC mode, provided the Korean BIOS is used.
Another exception is games developed in PAL Asia for [https://en.wikipedia.org/wiki/Nintendo_Entertainment_System_hardware_clone|Famiclones]. They are fully compatible with Famicom (NTSC), but can also work on the PAL speed if the console uses a hybrid PAL-NTSC mode. Such games can be recorded in the Hybrid/Dendy mode if it is proven that they indeed originate from PAL Asia.
!! General notes
There are several schools of thought that dictate the game version to pick for a TAS.
* One option is to prefer the __original__ version (chronologically first to be released) for its indisputable authenticity.
* Another is to prefer the __most popular__ version for its wider recognition among the audience and better compatibility with existing records.
* Finally, there is an option to prefer the __superior__ version (one having expanded content, better graphics or music, more glitches, less lag or shorter loading times) for the potentially better watching experience and/or opportunities for creative time-saving. Though, of course, superiority can be disputed in this case.
Consider these carefully when making the final decision. If still unsure, [Forum/Topics/19741|ask a judge].
!!!! Rules for movies
!!! 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 section on save-anchored movies).
! 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 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 the game in question) and creates the exact circumstances for your submission to sync will do.
Note that you don't have to optimize the verification movie: it only serves as a save/SRAM generator that makes it possible to claim the legitimacy of your effort. [2113S|This submission] is a good example.
In any case, ensure your run of an unlocked mode provides meaningful difference compared to a run of a fresh game. For example, if the unlocked mode features some new levels or bosses but your run triggers the endgame sequence before reaching 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 demonstrate how quickly a game could be beaten if the player had superhuman abilities; skipping major sections of it with a password defeats the purpose.
!! We allow playing unlockable content using in-game passwords
Using in-game codes[#1] or passwords at the start of a game is allowed if it uses a built-in hard mode or if it makes cosmetic changes to the game, as long as parts of the game are not skipped.
Using in-game codes or passwords at the start of a game to unlock a special game mode, character, level sets, or otherwise play the game in some unusual way is allowed.
----
!!! 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.
** Single-level movies that don't finish the game are rejected.
** Where applicable, the movie must reach an ending screen that positively signifies a game is finished successfully. Reaching a game-over screen is not considered beating the game. If a game shows the same ending screen regardless of success or failure, reaching it is not considered successful completion.
** Reaching an easter egg that by itself ends the game is not considered beating the game.
* 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).
* It should end with the last input. Don't leave any blank input at the end of the movie.
** DOOM internal relay files (LMP) are no exception, we only accept those without blank frames at the end. But for the purpose of encoding, we use extended versions of LMP movies that also include full ending.
!! Post-completion input
Some games acknowledge the game has been completed, and then require additional input to show the rest of the ending sequence. We always prefer full movies, but for the purposes of speed records, you may stop the movie when the initial ending sequence is guaranteed to ''begin'', without including extra input to process the entire ending. The following conditions must be met in this case:
* Extra input is trivial to execute for anyone replaying the movie
* Extra input does not change the resulting ending
* An extended movie is provided that contains this extra input, executed optimally, for publishers to use for encoding
Examples of situations that require additional post-completion input:
* Dialog boxes appearing during the ending sequence
* Additional ending screens only showing up after some button is pressed
* High score screens asking for name input
In any case, if there is additional input required to process the full ending, and it's not included in your movie, __always__ mention that in the submission comments, as well as the reasons for not including it.
!! Games without clear ending
Games that loop endlessly without some kind of ending can still have a definite ending point which can be any of the following:
* The game unavoidably reaches a point which prevents progression, often referred to as a [https://en.wikipedia.org/wiki/Glossary_of_video_game_terms#kill_screen|kill screen].
** Examples of kill screens: corruption of gameplay elements, graphics, sound, or controls that makes further progress impossible or incomprehensible.
* The game reaches a point where no new content is left to complete. If the game allows to choose which levels to visit, all such levels need to be completed. If variations of some content type change randomly, only the fastest variation is required; however, playing through all variations is also allowed.
** Examples of unique content: unique level layouts, enemy types, items, obstacles, game mechanics.
* All unique content and the hardest difficulty loop have been completed. This option has the same value as playing regular games on the higher difficulty, according to [Guidelines#SelectYourDifficultyWell|our guideline on difficulty choice].
** Examples of difficulty factors: speed of gameplay and enemies, amount and behavior of enemies, enemy and player health.
Movies that pick farther ending options will obsolete ones that play less — even if they are longer.
!! Games with additional level sets or games
Games which consist of multiple full games available immediately via a menu, such as separate level sets, often referred to as episodes in DOS games, or the individual games in Super Mario All-Stars, may be played and submitted individually. Playing a single episode or individual game to completion, or all episodes or games, are both considered game completion. Playing multiple, but not all, episodes or games is not considered completion. Multi-games should be avoided if all the games they contain exist separately on the platform; play the individual ones instead.
If additional games or level sets only become available as prior ones are completed, completion of the unlocked material requires that all games or episodes must be completed in a single movie. This does not apply if all the unlocked material can be accessed via some kind of in-game password system[#1].
----
!!! The movie must be reproducible
It is not enough that you did it once — we need to be able to run the movie 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 [EmulatorResources|officially supported TAS emulator] has a repository to host official releases obtainable as a package (like binaries). These releases are supported by TASVideos. Using custom or interim emulator builds compiled from 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 on a case-by-case basis. If you are considering using such an emulator version, [Forum/Topics/19741|confirm with a judge] whether it is justified in your case. If it is clear that there is no other way to TAS your game, permission will be granted.
!! 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.
----
!!! 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 [Subs-List|submission queue] or on the [Forum|forums].
Check places such as [http://youtube.com/|YouTube] or [http://nicovideo.jp/|NicoVideo] for speedruns; tool-assisted or otherwise.
Failure to beat existing records 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.
!! The movie should not be painful to watch
If a movie contains aspects detrimental to entertainment, such as sickening camera angles, seizure-inducing activity, grating sounds, etc., prominently enough to elicit major complaints, these aspects may make the movie ineligible for any class. If they can be avoided, they should; if they cannot, [Forum/Topics/19741|ask a judge] in advance.
----
!!! Movie goals
There can be all sorts of [MovieTagGuidelines|goals for movies], the most traditional ones are [fastest completion] (often referred to as "any%") and full completion (such as "100%", "all levels", "best ending"). There are also additional goals that may greatly diverse from those ("playaround", "pacifist", "newgame+", "maximum kills", and so on). We have certain restrictions that determine which goals can be published. These restrictions are different for each class.
!! Standard
The Standard class hosts movie goals that are the most common, the least subjective, and serve as tool-assisted superplay records. This is currently limited to [fastest completion] time (any%), full-completion (such as 100% or all levels), and forgoing major skip glitches.
The movie goals eligible for standard are subject to additions in the near future. We'll be placing those goals under intense scrutiny to create consistent rules for them.
! Forgoing major skip glitch
For games with a [MovieTagGuidelines#MajorSkipGlitch|major skip glitch], we allow one branch in Standard that forgoes that skip (or skips if there are several), but otherwise aims for [fastest completion]. Exact definition of the glitched skip may depend on the game and is subject to discussion.
! In-game time
Movies that [MovieTagGuidelines#AimsForInGameTimeInsteadOfRealTime|aim for in-game time instead of real-time] are only allowed for Standard if that goal makes gameplay shorter. If optimizing for the in-game time makes actual gameplay longer, such a movie is not eligible for Standard.
! Save-anchored movies
Movies that start from an [#WeDoNotAllowSaveAnchoredMovies|in-game save file] are not eligible for this class.
! In-game codes
A movie that uses codes[#1] (even secret ones) to play an unlockable level set, use a built-in hard mode, or enable cosmetic changes improving the game, is eligible for this class. Other unlockable content not present from the game start is disallowed, unless it is required for full-completion.
! PC environment
Using [#PcGameEnvironmentMustBeLegitimate|unintended PC environment] is not allowed for Standard.
! Independent game modes
[#GamesWithAdditionalLevelSetsOrGames|Independent game modes] are treated as separate games, and are allowed for Standard as separate movies. Independent mode is defined as a one that inherently offers more than 50% of unique gameplay (for example, more than a half of unique bosses or unique levels). This includes character choice and other in-game options.
! Secondary playthroughs
If the game has [MovieTagGuidelines#SecondQuestPostGameCompletion|additional challenges] after the first playthrough (often called quest or loop), and the secondary playthrough is not an independent game mode (as described above), the rules are as follows:
* Completing only the primary quest is always allowed for Standard.
** Completing only the secondary quest can be preferred for Standard if it's a [#WeAllowPlayingUnlockableContentUsingInGamePasswords|built-in hard mode].
* If the game has unique gameplay in the secondary quest, it needs to be included in the primary movie.
!! Alternative
The Alternative class hosts movies whose goals do not belong to Standard. In order to get published, such movies need to be entertaining to the general audience.
* The goal choices should clearly communicate what needs to be accomplished in order to obsolete it.
* Goal choices need to offer new TAS material to be accepted. Choices which have no goal other than to create a new game branch are rejected.
!! Full completion rules
This section talks about all classes.
! A clear consensus is required on what constitutes full completion.
* Some games reward the player for something internally defined as maximum completion goal.
* Sometime full completion requirements are explicitly mentioned in the game instructions.
* Full completion can only consist of optional one-time, irreversible, or otherwise strictly limited accomplishments that can be objectively measured and maximized.
* Conditions that are imposed unofficially by players are only eligible if they originate from fundamental gameplay features.
* Community agreement is required when defining newly invented full completion goals, or if existing definitions need to be revised.
! Full completion criteria must be reached through in-game actions only.
* [ArbitraryCodeExecutionHowTo|Arbitrary code execution (ACE)] is not allowed for any full-completion category for Standard. Arbitrary code execution of ROM data and memory corruption tricks to write arbitrary values to memory are also not allowed.
* If a game has a progress counter, it must be incremented by gameplay means intended to do so. Modifying the progress counter through ACE or memory corruption is not allowed.
** Cases where a collectable item is put into the player's inventory automatically via regular in-game means or a programming oversight are allowed as long as the above rule is observed. An example of this is the automatic collection of Varia Suit in ''Metroid: Zero Mission'' which is considered collected by the game upon killing one of the bosses (the corresponding collectable item is removed from its usual location at the same time).
* If full completion is counted by obtaining a set of items, these items must be collected through in-game methods. Using memory corruption to place items into inventory is not counted towards full completion.
* If full completion is counted by fulfilling a set of conditions (i.e. state flags in game memory), these conditions must be met through in-game mechanisms. Using memory corruption to set completion state flags is not allowed.
* If a progress counter is incremented by collecting a set of items or fulfilling a set of conditions, all individual components of this set must be collected or fulfilled. Inflating the progress counter by collecting or fulfilling the same component multiple times is not counted towards full completion.
! Maximum points
Maximum points or score is allowed as a full-completion category under the following conditions:
* There is no other way to define full completion for the game due to the lack of meaningful secondary objectives or collectable items not necessary for the fastest completion.
** If a way to define full completion is discovered later on, a movie that achieves it is eligible to obsolete the existing "max score" publication.
* If a certain technique can be repeated indefinitely to delay game completion and score points until saturation (maxing out the counter, "counterstop") or [https://en.wikipedia.org/wiki/Integer_overflow|overflow] (dropping from high value to zero or negative), this technique should not be used. If such a technique is required to complete the game, that game is ineligible for this category.
** ''Examples'': Backwards warps, farming extra lives and dying, "Clock stopping glitch" in NES Punch-out.
* If a game automatically resets the score as you progress (for example, in every level), "max score" must be reached in every such segment.
* A "max score" movie must [#MovieMustBeComplete|complete the game]. Playing beyond the defined completion point is not allowed.
----
!!! Arbitrary code execution
Entering arbitrary code into a game via an exploit is allowed as long as some additional conditions are met.
!! ACE exploit should not be caused by an emulator bug
Due research will be made to ensure your "arbitrary code execution" movie is valid in terms of emulation accuracy. If the exploit that enables ACE relies on an emulator bug, a movie containing such an exploit will be rejected.
However, if the emulation inaccuracy only slightly changes the outcome compared to the actual console, but the exploit is legit in principle, such a movie is acceptable. To consider an ACE exploit legit, it should be proven that the same results are achievable on the real console without a significant change in the ACE setup.
!! Usage in speedruns
Players can use arbitrary code to quickly complete games, skipping large portions of them.
* Using arbitrary code for the purpose of fastest possible progression of the game is always allowed. This typically means jumping directly to the [#MovieMustBeComplete|ending].
* 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.
* [#FullCompletionRules|See above] for restrictions on arbitrary code execution techniques for cases when they are used in a full completion speedrun.
!! Usage in playarounds
Players can also use arbitrary code to create their own entertaining playarounds which do fun things with the game.
* Quality of the playaround is important. Modifications made to the game as part of the playaround are judged the same way as the quality of a hack. Mediocre or minor changes will be rejected.
* ACE playaround should be entertaining on its own merits and be eligible for the [Alternative] class.
** A new technique or technically novel approach in ACE payload programming do not qualify for entertainment on their own.
** Being the first exploit or a new kind of exploit found in a game does not qualify for entertainment either.
** ACE playarounds need to receive very good feedback to the extent that hacks would require.
* 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 the game's assets to replace or reframe the game's original narrative in a creative manner or trick the viewer into believing they're witnessing some undocumented features of the game.
* The arbitrary code [https://en.wikipedia.org/wiki/Payload_%28computing%29|payload] must be contextually connected to the game and be part of one cohesive narrative within the playaround.
** If a new movie uses the same payload as an existing one, the new movie should be more optimal in how it reaches the ACE exploit. However it should not remove parts of the gameplay that the payload's narrative relies upon.
* Adding custom content is allowed as long as you have the legal right to do so, meaning you created and/or own it, or the added content can be redistributed in accordance with [/HomePages/Nach/FairUse|fair use].
----
!!! Cheats, debugging codes, and Arcade continues are not allowed
This includes any in-game codes[#1], input sequences such as the [http://en.wikipedia.org/wiki/Konami_Code|Konami Code], as well as immediately accessible hidden menus.
Note that if the feature in question is suggested explicitly by the game itself or 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. If the code is not used but the features it provides are accessed directly using a glitch, it is also allowed.
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 concept of a TAS. In many cases such games actively punish the player for continuing by resetting their score or preventing them from reaching some of the endgame content, which may interfere with other goals.
These rules are not strict, but are motivated by the same concept as the [guidelines|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!
----
!!! Obsoleting a published movie
A submission may obsolete a published movie by improving or surpassing it upon its stated goal. For example, if the goal of the published movie is fastest time, the submission must be faster; a slower or tied movie will be rejected. For movies of games without a definite ending, a movie which chooses a later ending point can obsolete one which chose an earlier ending point if the rest of the content is matched between the two.
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've found a shortcut that saves 30 seconds, it is expected that your movie will be faster by at least that much. Sloppy play will not be excused by major timesavers.
* 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.
When comparing against a prior movie for faster time, the faster time must come from improved play in the actual gameplay segments. For example, gaining time by switching to another version which loads faster or has shorter cutscenes is not counted as an actual time improvement. A submission which doesn't have any actual gameplay improvements over the published movie it intends to replace will not be accepted.
If time is gained from using a more accurate emulator, but gameplay hasn't been improved, such a movie will be rejected. However, if improved emulation introduces more lag, extends the cutscenes, or slows down gameplay in some way, yet the actual gameplay has improved, such a movie will be considered a valid improvement.
Site rules still apply even if a 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.
* An exception can be made if a rule is broken for a specific reason and it has been explicitly allowed for a published movie; this is usually reflected in its judgment notes. If unsure, ask a judge or admin before making a new TAS. (An example would be movies that start from SRAM, use passwords, etc.)
Movies for all games or episodes inside a multi-game or multi-episode game can obsolete individual movies that only play a single game or episode within the game. This is assuming that the combined movie surpasses each of the individual movies that it is trying to obsolete.
----
!!! 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 something 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 may be canceled during the three-day 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 by themself. If not, it would still be preferable to attribute the new movie as co-authored. See the next section for elaboration.
! Crediting other users' contribution
Movie files uploaded to the site are shared under the [https://creativecommons.org/licenses/by/2.0/|Creative Commons Attribution 2.0] license, which means that in general, when someone's work is being reused, they should be credited as co-authors of the derived work ([https://creativecommons.org/licenses/by/2.0/legalcode|4.b]).
When optimal gameplay results in little to no variation in input sequences, matching others' work becomes unavoidable, so co-authorship is not required. However when you copy someone else's artistic choices, the original author should be duly credited. Note that this includes cases when the movie you are reusing does not come from TASVideos.
There is no strict authorship rule for cases when research or development was contributed instead of actual movie input, or for the so-called "frame wars" (series of minor competitive improvements from different participants), so such cases are left to the judge's discretion.
!!!! Rules for systems
!!! libTAS movies
!! Use stable versioned releases of games, dependencies, and of libTAS itself
Install everything from versioned packages. We don't want dependency hell to spoil Linux TASing.
libTAS version 1.3.1 or later is preferred.
If official stable releases aren't enforced, movies may abuse some bug that's been fixed the next day, or a feature that's not supposed to be there. Installing a particular commit may also be a nightmare.
!! Use common Linux distributions
We want configuration to be common, because it increases accessibility and simplifies installation. Compiling Linux from the source should not be involved.
We only allow distros that offer a live CD, have a simple and straightforward installation process, have a GUI, have easy steps to install packages with no hassle, and are among the more popular ones. The version must be a stable release.
Allowed distributions:
* CentOS
* Debian
* Fedora
* Mint
* OpenSuSE
* Ubuntu
Allowed architectures:
* i386 / i486 / i586 / i686 / x86-32
* AMD64 / x86-64
! Use movie annotations to provide installation instructions
* List all the extra dependencies, their versions, and full installation steps, as well as the exact Linux distro and kernel version used.
** Example: %%% {{Debian Stretch AMD64, Linux 4.15.0-1-amd64}}
** Execute this command in the terminal to get the OS information: %%% {{uname -a && lsb_release -a}}
* List all the non-default libTAS configuration settings required to make the movie replay and synchronize.
* If the libTAS version you are using does not allow annotations in movies, make sure to post all the relevant information to the submission text.
Providing links for everything is also preferred.
!! Windows games are disallowed
Games for Windows that can be TASed in libTAS using Wine aren't allowed for submission. Note that for future purposes, testing this workflow is still encouraged.
!! DOS
We allow libTAS to [EmulatorResources/PCem/DOS#UsingWithLibtas|run PCem as a DOS machine emulator]. Only [https://github.com/TASEmulators/pcem/releases|TASVideos releases] of PCem are allowed. Such releases are marked {{st}} to indicate single-threading - modification required for determinism, not available in the original PCem.
Closely follow the guides linked in this section to prevent desyncs!
* Synchronization of your movie depends on the following file types: {{.img}}, {{.nvr}}, {{.cfg}}, and {{flash.bin}}.
* If ''Runtime -> Prevent writing to disk'' is unchecked in libTAS, PCem will change your files, which will cause desyncs.
* If you change those files yourself outside of libTAS and PCem, it will also cause desyncs.
* Use .ltm annotations to document which machine ROM files your movie ''requires'', along with their hashsums. PCem logs to the terminal which ROMs it's loading.
! Emulate compatible machine
PCem can emulate variety of machines, but the only system currently allowed for libTAS+PCem submissions is DOS. It is further limited to [EmulatorResources/PCem/DOS#PremadeConfigurations|3 machine configurations], each representing an era of DOS games based on release date and system requirements.
* Late '80s package - for games released until 1989-12-31.
* Early '90s package - for games released from 1990-01-01 to 1994-12-31.
* Late '90s package - for games released after 1995-01-01.
If the game you're TASing doesn't work properly on either of these 3 setups, you can modify the one that's closest to intended specs, to make your game work well. Keep in mind though that [#PcGameEnvironmentMustBeLegitimate|PC game environment must be legitimate]. If your modifications are beyond tweaking the {{.cfg}} files, you will need to record a libTAS movie of you setting up your config, similar to how [EmulatorResources/PCem/DOS/Configurations|our setups were recorded], including meticulous documentation of the process. Explain what and why you're changing too.
! Game installation
[EmulatorResources/PCem/DOS#InstallingYourGame|Game installation] should be a part of your main movie. This part of the movie shouldn't waste time for no reason, but still configure your game to look and sound best.
The only exception is games that take several minutes to install, in which case you may [EmulatorResources/PCem/DOS#InstallingFromOriginalMedia|record game installation in a separate movie] and provide it as a verification. Optimizing this movie is not required.
----
!!! Game Boy series: Use the best mode
Some Game Boy/Game Boy Color games work in multiple modes, depending on the device you run them on:
* GB ― monochrome (the original Game Boy type)
* SGB ― Super Game Boy (the GB game plugged into SNES, has a graphical border and some colors)
* GBC ― Game Boy Color
* GBA — Game Boy Advance
Because the game can work 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.
The default options that appear when starting a recording should often reflect the device the game was specifically released for, and newer device modes may cause glitches, so think twice before changing them.
* If glitches that are caused by a newer mode are obvious to unassisted eye/ear in normal viewing conditions, or hinder gameplay, that mode is not allowed.
* If glitches that are caused by a newer mode can't be easily noticed and don't hinder gameplay, the newer mode is allowed for the sake of console verification.
* If a newer mode doesn't cause any glitches at all, it's allowed.
Important note: SGB mode in VBA-rr is disallowed entirely due to poor sound emulation. To use SGB, lsnes or BizHawk must be used.
----
!!! Dolphin movies
Game images in the NKit format are not allowed.
----
!!! JPC-RR movies (DOS): CPU frequency restrictions
[EmulatorResources/JPC/PCSettings#CpuFreqDivider|CPU frequency] [EmulatorResources/JPC#AssemblingTheVirtualSystem|settings] may be restricted or not, depending on the game.
* If changing the CPU frequency introduces gameplay differences (for example, if it affects movement speed, game mechanics, glitches, etc.), set the CPU frequency divider to emulate the CPU speed [#PcGameEnvironmentMustBeLegitimate|intended for this game].
* If gameplay is not affected but higher CPU frequency reduces lag, speeds up the loading times, or otherwise helps avoid unnecessary delays, the CPU frequency may be maximized by setting CPU frequency divider to 1 (emulating a 1GHz CPU).
----
!!! Hourglass movies
For Hourglass, you need to provide the DxDiag log to prevent sync failures due to different hardware. For instructions, see [Forum/Posts/316546|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 also applies to cracked Commodore 64 disk ROMs if no non-cracked disk ROM version is available.
----
!!! DeSmuME movies
If your movie makes use of DS microphone audio input, all the required audio data must be embedded into the movie. For that purpose, use [https://github.com/TASEmulators/desmume/releases/tag/release_0_9_9a|DeSmuME version 0.9.9a]. The steps required to embed .wav files into the movie are provided on the release page.
!!!! Movie formats
!!! Acceptable movie files
We accept key-input movies of these formats, and __only__ these formats:
!! Arcade / CPS / Neo Geo
* [EmulatorResources/Fba|Final Burn Alpha Rerecording (FBA-rr)] movie files ([EmulatorResources/Fbarr/FBM|FBM]). The older format, [EmulatorResources/Fba/FRFormat|FR], is __not__ allowed.
* [EmulatorResources/Mamerr|MAME-Rerecording] movie files ([EmulatorResources/Mamerr/MAR|MAR]).
!! Atari 2600, Atari 7800
* [BizHawk] movie files ([Bizhawk/BK2Format|.bk2]).[#3]
!! DOOM
* DOOM internal replay files (LMP).
!! DOS
* JRSR movie files ([EmulatorResources/JPC/JRSRFormat|JRSR]) made with JPC.
!! Game Boy & variants
* [BizHawk] movie files ([Bizhawk/BK2Format|.bk2]).[#3]
* lsnes movie files ([EmulatorResources/Lsnes/LSMV|LSMV]).[#1]
** Game Boy and Game Boy Color only.
* [Emulator Resources / VBA|Visual Boy Advance (VBA)] movie files ([Emulator Resources / VBA / VBM|VBM]) (deprecated).
** We do __not__ accept movie files made with earlier versions of VBA (denoted by file types VBV and [OtherEmulators/VMV|VMV]).
** Read the VBA-specific rules [#GameBoySeriesUseTheBestMode|earlier on this page]!
!! Game Boy Advance
* [BizHawk] movie files ([Bizhawk/BK2Format|.bk2]).[#3]
* [Emulator Resources / VBA|Visual Boy Advance (VBA)] movie files ([Emulator Resources / VBA / VBM|VBM]).
** We do __not__ accept movie files made with earlier versions of VBA (denoted by file types VBV and [OtherEmulators/VMV|VMV]).
** Read the VBA-specific rules [#GameBoySeriesUseTheBestMode|earlier on this page]!
!! Gamecube & Wii
* Dolphin movie files ([EmulatorResources/DTM|DTM]).
!! Linux
* [EmulatorResources/LibTAS|libTAS] movie files ([EmulatorResources/LibTAS/LTMFormat|LTM]).
!! MSX home computers
* OMR replay files made with openMSX.
!! NES
* FCEUX movie files ([http://fceux.com/web/FM2.html|FM2]) made with version 2.0.2 or newer.
* TAS Editor project files ([http://fceux.com/web/help/taseditor/FM3format.html|FM3]) made in FCEUX 2.2.0 or newer.
* [BizHawk] movie files ([Bizhawk/BK2Format|.bk2]).[#3]
* [EmulatorResources/FCEU|FCE-Ultra (FCEU)] movie files ([Emulator Resources / FCEU / FCM|FCM]) made with version 0.98.12 or newer (0.98.28 is the last release in the branch) (deprecated).
* Famtasia movie files ([EmulatorResources/Famtasia/FMV|FMV]) and VirtuaNES movie ([OtherEmulators/VMV|VMV]) files are ''[http://en.wikipedia.org/wiki/Deprecation|deprecated]'' and __not__ accepted.
!! Neo Geo Pocket (Color), WonderSwan, Atari Lynx
* [BizHawk] movie files ([Bizhawk/BK2Format|.bk2]).[#3]
* [Emulator Resources / Mednafen|Mednafen] movie files ([Emulator Resources / Mednafen / MC2|MC2]) and ([Emulator Resources / Mednafen / MCM|MCM]) are ''[http://en.wikipedia.org/wiki/Deprecation|deprecated]'' and __not__ accepted, unless a [/HomePages/Nach/Continuances|continuance] is granted.
!! Nintendo 64
* [BizHawk] movie files ([Bizhawk/BK2Format|.bk2]).[#3]
* [Emulator Resources / Mupen|Mupen64] movie files ([Emulator Resources / Mupen / M64|M64]) made with the ''rerecording'' version are ''[http://en.wikipedia.org/wiki/Deprecation|deprecated]'' and __not__ accepted, unless a [/HomePages/Nach/Continuances|continuance] is granted.
!! Nintendo DS
* DeSmuME movie files ([EmulatorResources/Desmume/DSM|DSM]) made with DeSmuME 0.9.6 or later. Do not use interim builds, or versions prior to 0.9.6.
!! PlayStation
* [BizHawk] movie files ([Bizhawk/BK2Format|.bk2]).[#3]
* [Emulator Resources / PSXjin|PSXjin] movie files ([Emulator Resources / PSXjin / PJM|PJM]) and [Emulator Resources / PCSX|PCSX] movie files ([Emulator Resources / PCSX / PXM|PXM]) are ''[http://en.wikipedia.org/wiki/Deprecation|deprecated]'' and __not__ accepted, unless a [/HomePages/Nach/Continuances|continuance] is granted.
!! SG-1000 and ColecoVision
* [BizHawk] movie files ([Bizhawk/BK2Format|.bk2]) (preferred).[#3]
!! Sega CD
* [BizHawk] movie files ([Bizhawk/BK2Format|.bk2]) (preferred).[#3]
* [Emulator Resources / Gens|Gens] movie files ([Emulator Resources / Gens / GMV|GMV]).
!! Sega Genesis/Megadrive
* [BizHawk] movie files ([Bizhawk/BK2Format|.bk2]) (preferred).[#3]
* [Emulator Resources / Gens|Gens] movie files ([Emulator Resources / Gens / GMV|GMV]).
!! Sega Master System and Sega Game Gear
* [BizHawk] movie files ([Bizhawk/BK2Format|.bk2]).[#3]
* Dega movie files ([EmulatorResources/MMV|MMV]) are ''[http://en.wikipedia.org/wiki/Deprecation|deprecated]'' and __not__ accepted, unless a [/HomePages/Nach/Continuances|continuance] is granted.
!! Sega Saturn
* [BizHawk] movie files ([Bizhawk/BK2Format|.bk2]).[#3]
* [Emulator Resources / Yabause|Yabause] movie files ([Emulator Resources / Yabause / YMV|YMV]) are ''[http://en.wikipedia.org/wiki/Deprecation|deprecated]'' and __not__ accepted, unless a [/HomePages/Nach/Continuances|continuance] is granted.
!! Super NES
* [BizHawk] movie files ([Bizhawk/BK2Format|.bk2]).[#3]
* [EmulatorResources/Lsnes|lsnes] movie files ([EmulatorResources/Lsnes/LSMV|LSMV]).[#2]
* [Emulator Resources / Snes9x|Snes9x] movie files ([Emulator Resources / Snes9x / SMV|SMV]):
** Snes9x v1.43 movie files are ''[http://en.wikipedia.org/wiki/Deprecation|deprecated]'' and __not__ accepted, unless a [/HomePages/Nach/Continuances|continuance] is granted.
** Snes9x v1.51 movie files are supported but [http://en.wikipedia.org/wiki/Deprecation|deprecated].
!! TI-83
* [BizHawk] movie files ([Bizhawk/BK2Format|.bk2]).[#3]
!! TurboGrafx 16 (PC Engine), PCE-CD, SuperGrafx
* [BizHawk] movie files ([Bizhawk/BK2Format|.bk2]).[#3]
* [Emulator Resources / Mednafen|Mednafen] movie files ([Emulator Resources / Mednafen / MC2|MC2]) and ([Emulator Resources / Mednafen / MCM|MCM]) are ''[http://en.wikipedia.org/wiki/Deprecation|deprecated]'' and __not__ accepted, unless a [/HomePages/Nach/Continuances|continuance] is granted.
!! Virtual Boy
* [BizHawk] movie files ([Bizhawk/BK2Format|.bk2]).[#3]
* [Emulator Resources / Mednafen|Mednafen] movie files made with [Emulator Resources / V Bjin|VBJin] are ''[http://en.wikipedia.org/wiki/Deprecation|deprecated]'' and __not__ accepted, unless a [/HomePages/Nach/Continuances|continuance] is granted.
!! Windows
* [Emulator Resources / Hourglass / WTF|WTF] files made with [Emulator Resources / Hourglass|Hourglass].
----
!!! Multimedia files are not accepted
We do not accept multimedia files (AVI, MKV, 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] When we speak about codes that are part of a game that we allow for use in certain scenarios, we are talking about passwords that can be entered in a menu, pressing some buttons on the title screen, passing execution parameters or setting environment variables for DOS games, or anything of a similar nature. This excludes things like Game Genie codes or emulator cheating tools. Codes are considered secret if the game never tells them to the player: neither through official documentation nor during gameplay.
[2] Binary .lsmv format is not accepted at the moment (not implemented yet), use the .zip-based one (the default one).
[3] Legacy BizHawk [Bizhawk/BKMFormat|.bkm] format is deprecated but still submittable (for now).