TODO: This needs updated. Since February 5, 2022, the technical rating and entertainment were combined into a single rating that the user provides instead (announcement post).
This page gives guidelines on how to effectively rate movies and vote on submissions. The guidelines are intended to maximize effectiveness of one's vote and to (with submissions) maximize the help towards a judge's decisions.
Submissions
- Don't just vote yes because the video looks "well made". We want entertaining movies. Good movies for the site are ones that demonstrate the art of TASing in a good way. (See the mission statement at Welcome To TASVideos.)
- Post your opinion. Judges weigh thoughtful posts far more than silent votes.
- Post constructive criticism. If you think something is improvable, suggest it or ask why the author did/didn't do what they did. Avoid wording that sounds absolute unless you have tested it yourself.
- If the movie entertained you try to mention what aspects in particular you found entertaining.
- If the movie failed to entertain you, again mention why.
In summary, judges prefer details. Try to be as informative as possible.
Ratings
Entertainment
While the entertainment level of a TAS is somewhat subjective, there are a few principles that most of our players and viewers have agreed upon that make for runs with high entertainment.
An entertaining run should:
- Be fast-paced. If it takes five minutes for anything to happen, nobody will want to watch your run. Games with fast characters are well-suited for this.
- Be varied. Watching a character do little more than run to the right and jump occasionally is not entertaining. Generally, the more possibilities for what your character can do at any given time, and the more of them that are used, the better.
- Do the unexpected. Abuse of glitches and otherwise causing the game to perform in unexpected ways makes for far more interesting gameplay.
- Have lots of action. The more that is going on at the same time the more impressive the result will be. Just don't overdo it to the point where it is impossible to follow the gameplay.
Often the entertainment level of a TAS is directly related to the entertainment level of a game itself; that having been said, sufficiently advanced runs of games can easily reach the point of repetition and boredom, and conversely a game with awful gameplay can produce surprisingly worthwhile runs.
Technical
The technical rating of a TAS should reflect a number of technical qualities about the run itself and how it has been made. It's important to understand that there is no one single feature which determines the technical quality, but that it's the sum of many different aspects. A common misconception is to think that "technical quality" is a synonym for "frame perfection" (in other words, how optimal the run is). This is not so. Frame perfection is part of what constitutes the technical quality of a run, but only a part.
These are things which should be considered when rating a TAS for its technical quality (note that this list is not comprehensive, and every TAS should be evaluated on a case-by-case basis):
- Frame perfection: How frame-perfect is it? Are there known improvements or obvious flaws?
- Technique: What kind of TASing techniques does the author use in their run? For example, does he manipulate luck heavily, abuse bugs or level design flaws in the game for shortcuts, use close approach collision abuse, maneuvers that reduce lag, etc?
- Tools: What kind of tools did the author use? Did he use eg. Lua scripting for something useful? Memory watching? Decompiling the game ROM? Did the author perhaps even write their own tools, such as bots?
- Amount of work: How much work was necessary to make the TAS? For example, was a considerable amount of background research (such as route planning or extensive RNG reverse engineering) necessary before even starting the run?
Note that not all games are suitable for a TAS with perfect technical rating, similarly to how not all games are suitable for a perfect entertainment rating. Some games simply don't lend themselves for extensive technical achievements (eg. if they are too simple or straightforward, with no route planning, exploitable bugs, etc.).