Guidelines for judges

Sum-up

• Quantity is not quality.
  • Keep the number of different branches per game minimal. A run for a proposed new branch for a game should offer compelling differences relative to previously published runs of that game.
  • Avoid making decisions that undermine this guideline (or other guidelines) now or in the future. For example, don't publish an arbitrarily rule-restricted movie just because there are too few movies for that game; doing so may lead to impossible-to-solve "why A but not B" debates later.
• Hard work should have a reasonable chance of being published. More on this below.
• Satisfy the audience's expectations.

Judging

Watch the entire movie from the input file!

Act consistent with the message of the site

• Reject movies that break the movie rules.
• Judge movies in concordance to the guidelines.

Managing game versions/ports on multiple platforms

• 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.
  • There are cases when a submission aspires to a goal only feasible in versions with altered or expanded content. Examples include using Maria which is only present in the Saturn port of Symphony of the Night, and warpless SMB2j movie made on the SNES All-Stars conversion because the later levels are accessible without beating the game multiple times there.

Be fair

• Too many bad publications turn the audience away.
• Too few publications turn the audience away (and possibly the players too).

• Don't demand them do laboursome optimizations that can't actually be noticed under normal viewing conditions ^[1]. For example, if a jump performed one frame late still moves the character along its purported trajectory with no interruptions, it is a negligible flaw. If, however, a late jump bumps the character into an obstacle, thus interrupting its movement, it's an easily noticeable mistake.
• For rejected submissions, refer to the relevant guidelines that would improve their chances of being accepted the next time. If possible, point out some specific mistakes.

Tiers and goals

• Read the thread, determine the ratio of viewers that enjoyed the movie. See to what extent viewers liked or disliked a movie.
• Factor in the submission votes. The Moons tier can only be used if the feedback is positive by a strong majority. Nach and adelikat suggest that 80% yes votes is generally a strong majority.
• Watch the movie yourself and compare to the current Moons and Vault residents.

Branches

• Something the game directly suggests as an option (warp usage, player amount, character).
• Something the player invents himself (exact completion percent, pacifist, certain glitch set).

Trunk

Labels

• If it is that common, we don't label runs that do it the common way, and label runs that don't, if there are counterpart runs of the same game.
• If it's not that common, we label each approach, if there are counterpart runs of the same game.

Improvements and obsoletions

• Avoid meaningless publications. It may turn the audience away when a large improvement is possible, yet each small incremental change with no visible differences in gameplay finds its way onto the main page.
  • Small improvements have and will be published, but only in a situation where it seems reasonable that only those small optimizations are left. If larger known improvements aren't implemented, it may be grounds for rejection.
• For improvements to published movies, game choice is no longer a factor for judgment (generally).
• However, if the submitted movie is clearly improvable as well, it should (usually) be rejected.
  • While it is expected that the new run should use all tricks and techniques known at the time, it is not uncommon for new time-saving techniques to be found during the later stages of making a run. Ideally, the run should be restarted or edited to allow for inclusion of these new discoveries, however, if restarting will be especially time consuming, exceptions can be made to this rule per judge's discretion.
• Improvements to published movies should meet the site's standards, even if the published movie doesn't (such as use of correct ROM, cheat codes, etc.).
• Sometimes what is claimed to be an improvement may necessitate a new branch, such as when a huge time-saving glitch is involved (see SMW2), or unusual goal choice is exhibited (as in Princess-only SMB2 run, whose first iteration beat then-current any%).
• Sometimes an improvement necessitates a double obsoletion.
  • This may occur when a new submission aims for a goal in a certain branch (for instance, any%) but also achieves primary goals of other branches (such as low% or 100%) better than their respective published movies (see Super Metroid glitched any%). Another notable example is when a 2-player movie, generally considered to be more entertaining than a 1-player version, also outperforms it time-wise (see Contra).
• Cross-branch, and even cross-tier obsoletions can happen, if the movies really are considered similar enough by the audience and the judges, and the new one is better.
  • Cross-platform obsoletions, on the other hand, are not done unless it's about deliberately identical ports (as happens with modern console games).

Game completion point

Glitched endings

Input length

• Minimize input length, the game should reach a stage where it complete itself, no matter how long it takes.
• Game must be brought to a certain completion state as soon as possible, after which no normal game input can prevent the game from completing, even when this lengthens the movie file length considerably.

Hacks

• A hack must be judged for its entertainment value as its own separate game but also in context to the original game.
• Too many hacks of the same game engine causes the same issues as too many categories of the same game.
• Quality of the hack should come into play as well. Hacks where only sprites are altered do not make for quality hacks. By contrast, a good hack alters the levels, the physics, the sprites, expands the overall game play, and even combines elements of other games to the point it doesn't feel like the same game engine.
• Popularity of the hack needs to be considered.

Arbitrary Code

Playarounds

• Quality of the playaround is important. View what modifications it makes to the game as part of the playaround the same way as judging a hack. Mediocre or minor changes should be rejected.
• Ensure the run is entertaining on its own merits.
  • 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.
  • These playarounds need to receive very good feedback to the extent that hacks would require. Nach suggests that >90% yes votes is considered very good feedback in absence of posts providing such feedback.
• Ensure that the game appears to be completed in some visual sense.
• Too many playarounds of the same game engine causes the same issues as too many categories of the same game.
• Payloads must be unique to a game, and somehow connected to it. A payload which would work just as well contextually if executed on any other game for the platform must be rejected.
  • 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 should be rejected, unless the newly submitted run can be considered to obsolete the currently published run.
• Ensure that TASVideos can legally distribute any content a playaround adds to a game.

Speedruns

• Ensure the arbitrary code used is optimal in terms of how much it skips. Reject runs which skip portions of the game arbitrarily.
• For games which have no defined ending, typically the run must progress the game to the point there is no new content and the difficulty no longer increases. This still applies to games making use of arbitrary code, and must be seen to objectively and obviously reach this point.

Be open

Collect opinions

• If nobody says anything, try to ignite discussion.
  • This is especially important if the submission does something which could be controversial once people realize it.
• If someone offers an interesting viewpoint regarding a submission, try to cultivate it.
• Minority opinions in a discussion are important too, and should be weighed according to their validity.

Be impartial

• Judge movies, not players.

Be verbose

Editing the submissions

• Apply the Editor Guidelines to your editions. Specifically:
  • Do not delete text written by others. (But you can reformat it for readability.)
  • Use clear, easy to read markup and language.
  • Attribute clearly.

-
[user:your username]: Rejected in favor of a [828S|faster movie].

Replacing submission files

• Judges have the ability to replace a submission file.
• This can be done when the submitter finds a small improvement to their submission; it is usually better to incorporate it immediately rather than cancel and submit a new movie.
• Check that the movie still satisfies its stated goals and that the movie file is good.
• Use this feature only for small improvements and not major changes. Anything that could possibly invalidate the voting results should definitely be a new submission (such as a controversial trick, a major improvement, or anything that might affect the entertainment value of the movie).

Procedures

• There is a minimum time a submission can be in queue before a verdict can be made (currently 72 hours). Prior to this time a submission can be set to "judging underway" or "needs more info".
• Use the "judging underway" feature, and use it sooner rather than later. If you decide to handle a submission set this first so other judges know it is already being taken care of.
• Let the conversation play out. The audience has a say, so let them say it. If a thread is very active still (many posts in a short time period), let it sit until the conversation dies down a bit.
• Give a chance for rebuttal. Try to indicate the verdict you are leaning to in a post, or ask questions rather than make statements ("Why did you do x?" instead of "x looks improvable"). Give the author a sufficient chance to respond to assumption made about the movie.
• Avoid saying it "looks" improvable. Instead, take the time to show that it IS improvable. Show an existing WIP, or make a short one of your own. Document some specifics rather than making blanket statements impossible to prove.

More reading

• For movie analysis: Movie Rules, Guidelines.
• For editing: Editor guidelines, Text formatting rules.
• For movie editing: Movie Class Guidelines.