TASVideos

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.

For any questions that remain after having read this page, please ask a judge.

Table of contents [expand all] [collapse all]

Rules for games

The game must be acceptable

We have two sets of rules on acceptable games, varying between tiers: rules for Moons that match the general rules and guidelines, and rules for Vault that have additional restrictions. There is a third tier, Stars, but it is filled manually by cherry-picking the best runs. Its rules are the same as for Moons.

Moons

This tier contains entertainment-based movies that may or may not be speed-oriented. The game must be one that facilitates entertainment value when tool-assistance is applied in accordance with the TASing guidelines on fashion.

Vault

This tier contains speed-based movies that don't have much entertainment value, but still represent meaningful tool-assisted speedrun records. Game choice is tightly limited. Vault rules filter out games that don't hold much weight when tool-assistance is applied in accordance with the TASing guidelines on optimization. Vault needs clear cuts, so whenever something can not be clearly distinguished, such a movie gets rejected.

Must be clearly definable as a game, which has achievable goals

A game which is simply about wandering aimlessly is not a proper game.

The gameplay needs to standout from non-assisted play

  • Example of a (mini)game which does not is Desert Bus.

A game which is about free form creativity is not a proper game.

  • Examples are the main feature of Mario Paint or Color a Dinosaur.

If a game consists of presenting a story, with little to no user creativity altering the game in any way, then it is unacceptable.

This includes games which are overwhelmingly made up of cut scenes, with little to no user interaction anywhere.

  • For example, Super Adventure Rockman.

Games which are of a Choose Your Own Adventure story book variety, where the user has no creative control beyond choosing between predefined choices.

Unofficial games are allowed under restrictions

Hacks (defined as being an unofficial modification of an existing eligible game, released primarily in a downloadable format - usually a patch file) are not eligible for this category. We demand hacks with entertainment value, therefore they are judged by the Moon tier requirements.

Unlicensed and homebrew games are eligible but may be judged on a game-by-game basis based on their notability.

No board games, game show games, or primarily educational games

These game genres are not defined as a serious game.
  • Examples of unacceptable board games for this tier are Chess and Monopoly.
  • Examples of unacceptable education games for this tier are Sesame Street: Elmo's 123s and ABCs.

A serious game where educational elements only occupy small portions of the game is eligible. If educational elements are scattered throughout the whole game, and most of the game can be completed casually without having to perform many educational activities, education is considered a secondary part of game-play, and such a game is eligible. A game which requires the player to be able to read in the game's native language is not a disqualification. If parts of a game require certain knowledge and details in order to complete it, which is educational, but all that knowledge is provided in-game during the course of otherwise normal play, learning and using such knowledge is not a disqualification.

Sports games are allowed under restrictions

Team-based sports and sports running with a fixed time, such as baseball, 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 without reaching a meaningful ending to the game are not eligible.

The run must not be seen as trivial.

  • If a run consists of doing a trivial strategy, made only nontrivial by 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 Vault are restricted to one game per series per platform. 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 which game makes a more technically impressive run, as decided by a judge.

  • For games with different characters/groups/countries with different statistics, only the fastest run is accepted. Runs using suboptimal characters are not accepted.

Adult-only games are not allowed

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-only 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 [!] by some software.
  • Do not use bad dumps. Bad dumps are are commonly labeled [b] by some software.
  • 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 no good ROM images exist, or are not obtainable.
  • Provide hash checksums of the ROM images you used.

If there are several medium types that the platform supports, we allow conversion between them (to speed up the loading times, for example) only if the software itself remains the same, and if 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 game-play requires, or mainly consists of, inserting arbitrary images, such images must also be inserted only when the game duly prompts. However, there are strict requirements on the nature of such arbitrary images:

  1. You need to use an image that's been generated specifically for the movie in question
  2. You need to provide clear instructions on how to recreate it
  3. This image has to serve the goals of your movie in a considerably optimal way
  4. You need to provide insight on why you consider it optimal
  5. The method used to create it must be free and easily accessible

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.

Play games that are emulated well

Emulation of several platforms such as Nintendo 64, DOS, Arcades 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...) and prototypes

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 game 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. Homebrews and hacks that are not finished, but have been abandoned by their authors, can be considered based on their quality and notability.

Prototype game versions are only accepted if there is no stable release version available.

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 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 HIMEM and 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 QEMM's driver is allowed. DOS also requires certain extenders in order to run 32-bit applications or access protected mode. Using an extender included with a game, or a compatible third party one which does not alter the game-play is allowed.

That means no renaming/copying/deleting/replacing/editing files that affect game-play. 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 it to a real hack or don't use it at all.

No questionable emulator settings

The emulator should be set to emulate the system as closely as possible while still allowing the game to be played. You should not depend on a particular emulator hack to gain speed.

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

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 alter how the game is played, such as where players re-spawn when they die, and this mechanic can significantly alter how the game is played, movies which utilize these changes can be published side by side.

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)) 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 a 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.

Another exception is games developed in PAL Asia for 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

When making the final decision on what game version to actually use for a TAS, consider the following aspects,represented by different schools of thought on the matter:
  • The first dictates that the original (chronologically first to be released) version should be preferred.
    • Advantages: indisputable authenticity.
  • The second dictates that the more popular (more widely spread and/or recognized among the audience) version should be preferred.
    • Advantages: easier and better recognition, better compatibility with existing records.
  • The third dictates that the superior (such as having expanded content, better graphics or music, more glitches, less lag or shorter loading times) version should be preferred.
    • Advantages: potentially better watching experience, potentially more opportunities for creative timesavers. Superiority in this case can be disputed.

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 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.

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). An exception has been allowed for Rygar.
  • It should end with the last input. Don't leave any blank input at the end of the movie.
    • 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.

Games without clear ending

Games that loop endlessly without some kind of ending can still have a defined ending point, which can be any of the following:
  • The game unavoidably reaches a point which prevents progression often referred to as a kill screen:
    • The game reaches a point where it presents a blank or garbled screen of some kind and viewable play can no longer continue.
    • The game reaches a point where the controls stop functioning correctly.
    • The game reaches a point where it becomes impossible to complete the current round.
    • The game reaches a point where the sound it outputs irreversibly becomes too annoying for a majority of the audience to listen to.
  • The game reaches a point where difficulty stops increasing and no new content is left to complete.
    • If the game allows to choose which levels to visit, all such levels need to be visited to establish that no new content will appear anymore.
  • The game consists of multiple rounds with new content appearing, and difficulty increases until it resets (overflows). For this the game must reach a point where no new content is left to complete.

Games with additional level sets or games

Games which consist of multiple full games available immediately in a menu, such as separate level sets, often referred to as episodes in DOS games, or the individual games in Super Mario All-Stars, they may be played and submitted individually. Playing a single episode or individual game to completion, or all episodes or games, is 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 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. However 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 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 on a case-by-case basis. If you are considering using such an emulator version, ask a judge if 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 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.


Movie goals

There can be all sorts of 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"). We have certain restrictions that determine which goals can be published. These restrictions are different for each tier.

Moons

Goal choice is not too important in this tier: esoteric and unorthodox goals are acceptable, but only as long as they make for entertaining movies.
  • The goal choices should be clear, so it's understood what needs to be accomplished in order to obsolete it.
  • Arbitrary 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.

Vault

Goal choice is limited to fastest completion time (any%) and full-completion (such as 100% or best ending). Other goal choices are not eligible for this tier.

Goal choice criteria must be clear, non-controversial, and objectively verifiable. Vault requires clear cuts, so a movie with unclear goals that can not be agreed upon will be rejected.

Save-anchored movies are not eligible for this tier.

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 tier. Other unlockable content not present from the game start is disallowed, unless it is required for full-completion.

Full completion rules

This section talks about all tiers.

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 game-play 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.

  • Arbitrary code execution (ACE) is not allowed for any full-completion category for the Vault. Arbitrary code execution of ROM data, and memory corruption tricks to write to arbitrary memory are also not allowed.
  • If a game has a progress counter, it must be filled by actions that increment the counter in gameplay. Modifying the progress counter through ACE or memory corruption is not allowed.
  • 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 an inventory is not counted towards full completion.
  • If full completion is counted by fulfilling a set of flags, these flags must be set through in-game mechanisms. Using memory corruption to set completion state flags is not allowed.
  • If a progress counter is filled by collecting a set of items or fulfilling a set of flags, all individual components of this set must be collected or fulfilled. Collecting or fulfilling the same component multiple times to inflate the progress counter is not counted towards full completion.

Maximum points or score is allowed as a full-completion category, provided that:

  • There is no better way of defining full completion in the game.
  • The maximum score is easily defined and absolute - it must not be possible to gain a higher score, even theoretically. It must be definable without being dependent on precise time, speed, or similar requirements.
  • The maximum score is limited by not being able to gain any more points, not by hitting a score cap or overflow. If it is possible to score points infinitely, score cannot be used to define full completion.


Arbitrary code execution

Entering arbitrary code into a game via an exploit is allowed as long as some additional qualifications are adhered to.

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 is related to an emulator bug and relies on it, 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 in principle legit, such a movie is acceptable. To consider an ACE exploit legit, it should be proven that slight changes in the setup will still lead to the exact same ACE possibilities on the real console.

Speedruns

Players can use arbitrary code to quickly complete games, skipping large portions of them.

  • Arbitrary code entered into a game which allows for fastest possible progression of the game is always allowed. Often this means jumping directly to the ending.
  • 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.
  • See above for restrictions on arbitrary code execution techniques for cases when they are used in a full completion speedrun.

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 the quality a hack. Mediocre or minor changes will be rejected.
  • ACE playaround should be entertaining on its own merits and be eligible for the Moons tier
    • A run using a new technique or technically novel approach in its payload programming does not qualify for entertainment on its 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 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. A payload which would work just as well contextually if executed on any other game for the platform will be rejected. TASVideos is not a place to show off your science projects.
    • Different variants of the same game such as Pokémon Blue and Red are still considered the same game for this purpose. So a payload on a run for Blue which would also work contextually if applied to Red is not a disqualification. However, it is always better if the player tailors their payload to the specific game variant.
      • A payload for a particular game which was already published as part of a run for another game variant will be rejected, unless the newly submitted run can be considered to obsolete the currently published run.
  • 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.


Cheats, debugging codes, and arcade continues are not allowed

This includes any in-game codes[1], input sequences such as the Konami Code, as well as immediately accessible hidden menus.

Note that, if the feature accessible in that way 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, and the features it provides are accessed directly using game glitches, it is also 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!


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. For movies of a game which never really ends, a movie which chooses a later ending point can obsolete one which chose an earlier ending point, if it overlaps in content.

When obsoleting a published movie that aims for fastest time, the goal should be to adhere to its playing standard in both technical and entertainment aspects.

  • If you found a shortcut that saves 30 seconds, your movie should be faster by at least 30 seconds. Losing time elsewhere for no good reason is unacceptable.
  • If a published movie is notable for its entertaining idle time stunts (such as synchronizing actions to background music), you should at least try coming up with something comparably entertaining. Copying such actions from a published movie is not a problem, although in this case it will be a common courtesy to mention its author in your submission message.

When comparing against a prior movie for faster time, the faster time must come from improved play in the actual game-play segments. For example, gaining time by switching to another version which loads faster, has shorter cut-scenes, or by more optimized usage of the title screen menus is not counted as an actual time improvement. A movie which doesn't have any actual in-game game-play improvements over its published predecessor will not be accepted.

If time is gained from using a more accurate emulator, but game-play hasn't been improved, such a movie will be rejected. However, if improved emulation introduces more lag, extends the cut-scenes, or slows down game-play in some way, yet the actual game-play has improved, such a movie will be considered a valid improvement.

Site rules still apply even if the published movie breaks them. We make mistakes sometimes, but that doesn't provide a green light for you to break the rules.

  • If a published movie uses a bad dump, you should instead use the good one.
  • If a published movie uses an inaccurate emulator and you have the choice of a more accurate one, use the latter.
  • However, if a rule is broken for a specific reason and it has been allowed for the published movie, then it's usually okay. If unsure, ask a judge or admin before making the movie. (An example would be movies that start from SRAM, use passwords, etc.)

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 all 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 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.

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 straight forward 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
  • 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.


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.

Movie formats

Acceptable movie files

We accept key-input movies of these formats, and only these formats:

Arcade / CPS / Neo Geo

Atari 2600, Atari 7800

DOOM

  • DOOM internal replay files (LMP).

DOS

  • JRSR movie files (JRSR) made with JPC.

Game Boy & variants

Game Boy Advance

Gamecube & Wii

  • Dolphin movie files (DTM).

Linux

MSX home computers

  • OMR replay files made with openMSX.

NES

  • FCEUX movie files (FM2) made with version 2.0.2 or newer;
  • TAS Editor project files (FM3) made in FCEUX 2.2.0 or newer;
  • BizHawk movie files (.bkm / .bk2);
  • FCE-Ultra (FCEU) movie files (FCM) made with version 0.98.12 or newer (0.98.28 is the last release in the branch) (deprecated).

  • Famtasia movie files (FMV) and VirtuaNES movie (VMV) files are deprecated and not accepted.

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.

Nintendo 64

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.

PlayStation

SG-1000 and ColecoVision

Sega CD

Sega Genesis/Megadrive

Sega Master System and Sega Game Gear

Sega Saturn

Super NES

TI-83

TurboGrafx 16 (PC Engine), PCE-CD, SuperGrafx

  • BizHawk movie files (.bkm/.tas / .bk2) (preferred)
  • Mednafen movie files (MC2) (deprecated)
    • Windows users may use PCEJin which uses the same MC2 movie file.
    • The old movie format (MCM) is not recommended but still technically allowed.

Virtual Boy

Windows


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] 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 instructions nor during gameplay.

[2] Binary .lsmv format is not accepted at the moment (not implemented yet), use the .zip-based one.



Combined RSS Feed
MovieRules last edited by feos on 2018-09-23 08:29:44
Page info and history | Latest diff | List referrers | View Source