Revision (current)
Last Updated by feos on 8/2/2023 3:50 PM
----
As of May 4th, 2022, this page is in the process of being rewritten to reflect modern site rules and guidelines. Information is subject to change at any time as long as this notice is here. To suggest changes or ask for clarification, contact [user:Samsara].
For a copy of this page as it was prior to the above date, see [JudgeGuidelines/Legacy].
----
"''With great power comes great responsibility''."
This page summarizes and details the thoughts that Judges should adhere to when watching and judging submissions, and communicating with their authors.
If you're an author intending to submit a TAS, see [MovieRules] and [Guidelines].
%%TOC%%
!!! Summary
* Above all else, treat our community with care. Be kind and courteous to them, always respect their work, encourage them to continue, and use your knowledge and skill to help them improve.
** Always adapt to the needs of the community. Consider every angle of a problem, and work together with the rest of [staff] to provide the best solution.
** Collaboration and cooperation should be encouraged above all else. In cases of minor improvements found during judgement, let the author know beforehand and offer them the chance to take a second look, or the ability to collaborate with you or another community member. In cases of major improvements found during judgement, offer constructive feedback and input files to help guide the author.
* Value quality above quantity.
** Don't rush your judgements, let discussions play out. When necessary, start new discussions about the submission so users generate more feedback. Take your time and ponder everything relevant to the submission.
''The site should change to fit the community. The community should never change to fit the site.''
----
!!! Judging
!! Verify the authenticity of the input file
The input file should sync through to the end on an approved emulator. This usually means an official packaged release, though some emulators like [EmulatorResources/Dolphin|Dolphin], Citra and [EmulatorResources/Ruffle|Ruffle] are allowed to have development builds used and submitted. Ensure that all emulator settings are legitimate and that they are documented in the submission text.
All submissions must sync for someone other than the author. Ideally, they should sync for a Publisher. If you can't get the run to sync yourself, ask the author and the rest of the community for advice on how to make it sync. You should only reject a submission for sync issues, if even after research done by different people, it was impossible to get the movie to sync.
The input file must complete the game with its stated goal, i.e a "100%" submission must attain that game's definition of full completion. It should not start from reset, SaveRAM, or soft-reset unless necessary for the goal choice (such as to unlock a character, or take advantage of newgame+, for instance).
Ensure that there is no blank or unnecessary input at the end of a submission file. This artificially increases the input time and may lead to confusion or misinformation about the nature of the submission.
!! Act consistent with the message of the site
* Always treat submitters with the respect and care you would like to be treated with.
* Ensure movies consist of superior, optimal play.
* Judge movies in concordance to the [guidelines].
* [Submissions/RejectionReasons|Reject] movies that flagrantly break the [movie rules].
The goal of TASVideos is to take games to their absolute limits in unique and interesting ways. Any submission that does so should have a reasonable shot of being accepted.
----
!! Be fair
A Judge has the greatest control over the content of this website in the long run. All judges must act towards the goal of having ''an encouraging and rewarding atmosphere'' for both the players and the audience. You must be fair towards both.
Too many acceptances can send the message that we have low, or even no standards. The audience expects and wants to see high quality submissions, so some standards should be enforced in order to maintain that. However, setting the standards too high through many rejections will turn away the players out of fear of not being good enough. A fine balance must be maintained between acceptance and rejection in order to satisfy the audience's needs of high quality content, and to satisfy the TASers' needs of being able to provide that content.
Being fair means never introducing bias into your judgements. Runs should be judged on their own merits, not on the value of the TASer or even the game. You should not be making your decisions before watching runs.
----
!! Be thorough
! Ensure the movie is optimized
Judges are not expected to be familiar with every game, though they are expected to understand high-level TASing and general optimization techniques. You should be able to understand the gist of the run from watching it and reading the submission text. If there is anything that looks questionable or wrong in a movie, ask the author for clarification.
You must be reasonable when it comes to optimization. You should not be rejecting movies over some missed improvements. The optimization quality of a submission should apply to the run as a whole: If it looks good on the surface, and the movie consists of superior play which outperforms casual play and any records elsewhere, it's good enough for TASVideos. Check sites like [https://www.speedrun.com/|Speedrun.com], [https://www.youtube.com|YouTube], and [https://www.nicovideo.jp|Nicovideo] for other records, both RTA runs and other TASes to verify this.
Three good rules of thumb for judging optimization:
* Consider how many improvements there are. Are you constantly seeing suboptimal play, or is it only one section?
* Consider how obvious an improvement is. Would a casual viewer notice it, or is it something only a Judge would see?
* Consider how large an improvement is. Does it save seconds, or just frames?
Being fair on optimization is an acquired skill. Feel free to ask for a second opinion if you're unsure, whether it's from other Judges or from the community as a whole.
! Use a full range of experiences
Once again, a Judge is not expected to be familiar with every game, so don't stick to just your own experiences in any judgement. Ask others for advice, look to past judgements, and reach out to the community whenever you feel it's necessary.
However, do not discount yourself entirely. If you disagree with a judgement made in the past, talk to other Judges about it. If you disagree with a current rule, talk to the Senior Judge about possibly changing it. If you lack knowledge of a particular game, ask the community to fill you in.
Remember that there can always be change on the site, and that past precedents do not necessarily represent current methods.
! Write a great judgement
As a general rule, everything you put into researching and analyzing a submission should go into your judgement notes. Not all submissions require deep analysis, of course, but even if you only need to go surface level, you should always make notes of your discoveries. Should you need to come to a difficult conclusion with a submission, document your thought process in full. Ideally, explain every step so that no questions are left unanswered.
Talk about the game a little bit, make note of your favorite sections of a TAS, point out improvements to the author. Be welcoming to new submitters, be respectful to veterans, be encouraging to those who need more practice, and be precise and straightforward to those who break the rules.
If you mention other submissions or publications, always link to them to make things easier on whoever's reading it. This is particularly helpful with obsoletions.
----
!! Classes and goals
Take note of each of the following pages for [Class|classes], as they contain the most up-to-date information what goals are acceptable under them:
* [Standard]
* [Alternative]
* [Playground]
Currently, a Judge may only accept runs directly to [Stars] if they are improvements to Starred movies. This may change in the future.
Make sure branch labels are accurate. Ask other staff, particularly [Publishing|Publishers], for advice on this if need be. "any%" labels can be removed for redundancy.
----
!! Improvements and obsoletions
Improvements to published movies must meet the __[Movie Rules]__, even (and especially) if the published movie doesn't.
Cross-branch, and even cross-class obsoletions can happen, if the movies really are considered similar enough by the audience and the judges, and the new one is better. An improvement may also obsolete multiple movies if it achieves the primary goals of multiple branches faster than their respective published movies.
* For example, [3653M|Super Metroid any%] heavily changing its route and obsoleting both [3362M|the previous any% run] as well as [2078M|the "reverse boss order" run].
An improvement may necessitate a __new branch__ if the improvements significantly change the run.
* For example, a [4315M|"game end glitch" run] should always be a new branch, even if [2076M|the baseline run] is already heavily glitched.
A new movie may involve __emulation accuracy__ improvements. Emulation accuracy often adds extra lag, resulting in improvements that appear longer than the movie they're trying to obsolete. Always ensure the new movie has gameplay improvements. If the new timesavers can be applied to the old movie, they count as improvements.
* In some cases, published runs may use glitches that are known to rely on emulation inaccuracy. Improvements must not contain these glitches, and not using them should not be counted against the improvement.
Sometimes an improvement may result in an entire __branch getting superseded__ by a bigger branch. This occurs when a new submission fully contains the gameplay, goals, and content of a published branch, while also expanding upon it.
* For example, a run of [4637M|F-Zero that completes all leagues in one movie] obsoleting [3479M|individual] runs of [3518M|leagues].
----
!! Major skip glitches
[MovieTagGuidelines#MajorSkipGlitch|Major skip glitches] (sometimes called [Glossary#GameBreakingGlitch|game-breaking glitches]) require additional confirmation that it's actually a developer oversight, and [MovieRules#GameplayMustBeAccurateToHardware|not a cheat code or a password] that's subtly entered and looks like a glitched skip.
The most certain way to determine this is reading what programming code the game is executing, but there are some trends among cheat code scenarios that can make this detection easier:
# Input that works specifically during pause screens, menu screens, or other non-gameplay-based input
# Buttons have effects that have nothing to do with what the button normally does in gameplay or in menus
# Doing certain steps a number of times, or entering certain button combinations ("jump 10 times then press B+Select")
# Easy and consistent to replicate if you know the steps
# Increments or decrements memory values in consistent steps, especially if not related to normal gameplay functions (see also point 2)
----
!! Game completion point
! Glitched endings
Runs that incorporate "game end glitch" techniques need certain verification on whether the ending really occurs. It can be done by comparing how the game acts after it ended normally with how it acts after it was glitch-ended.
! Post-completion input
Manually ensure the game has fully ended. For example, after the game reaches some screen that does not seem to automatically fade out nor lead to the game start again, save a state and try pressing a few buttons to see if it's possible to proceed further (switch to recording if needed).
Sometimes extra input is required after the game's ending sequence has started, so it can fully proceed to the last ending screen. It is preferred to contain such input in the submitted movie, but exceptions can be made and an extended movie can be used for encoding.
----
!! Editing the submissions
Apply the [Editor Guidelines] to your editions. Specifically:
* Do not delete text written by others.
* Use clear, easy to read markup and language.
* Attribute clearly.
When you edit a submission, your markup should look something like this:
%%SRC_EMBED
----
[user:your username]: Judging!
[user:your username]: Accepting as an improvement to the [420M|published run]!
%%END_EMBED
({{420M}} (an example) stands for a link to [420M|publication 420].)
----
!! 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. Before replacing, check that the movie still satisfies its stated goals and that the movie file still syncs.
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).
----
!! Improving the submission you're judging
Sometimes a judge may come up with a complete improvement and even become a co-author. There's no hard line on how exactly to handle it, but there are two basic options:
* If you've fixed a minor issue without investing too much effort (like trimming blank input at the end, or starting the game a bit sooner), just replace the submission with your updated movie and continue judging
* If you've improved actual gameplay and it was non-trivial, you need to reset the submission to "New", post the improvement for submission replacement, and request co-autorship (or you may replace the file right away and add yourself). Another judge will handle all the rest.
----
!! Procedures
! Judging
When you're about to handle a submission, set it to ''"judging underway"'' so other judges know it is already being taken care of. If you feel strongly about judging a particular submission that someone else has claimed, ask them politely and they will most likely hand it over to you.
A submission must be in the queue for 72 hours before a verdict can be made. This allows for the audience to provide critical feedback. The audience has a say, so let them say it, and give the author a sufficient chance to respond to them. Let active conversations play out, and contribute to them with your own thoughts.
Avoid making blanket statements like "this section looks improvable". Instead, ask the author why they did that section in the way they did, or take the time to show that section __IS__ improvable. Show an existing WIP, or make a short one of your own.
If you expect some people to be unhappy about the verdict you are leaning to, communicate your thoughts and options in a post and discuss them as well. Your decision should ideally reflect a consensus and feel understandable, especially for the author(s).
! Reviews
* A [Judging#Reviewers|Reviewer] checks which submissions are unclaimed or need research, and makes a review forum post, adding themselves to [Reviews|the Reviews wiki list].
** A Reviewer can also review [Forum/Topics/22780|rejected submissions that may now be acceptable under rule changes].
* A Judge waits with the claiming before actually starting working on a submission (to let Reviewers know which submissions they are free to review), then checks the [Reviews] list and uses existing reviews for that submission in the judgment.
* In the decision, the Judge addresses which parts of the review were correct and which weren't, so Reviewers could better learn how to approach submissions, but without getting intimidated by criticism.
* Upon judging, the Judge removes the submission from [Reviews|the wiki list].
* If one wants to review a claimed movie, they just make a regular post without adding themselves into the Reviews list.
----
!! When you're done
Even after you've finished judging a movie, a judge's job doesn't necessarily stop there.
* Communicate with viewers who have questions regarding your judgment.
* Communicate with the publisher and assist them as necessary.
* Communicate with other judges who need to judge a different submission for the game if they have any questions.
* If it was revealed you made a mistake in your judgment, first of all, don't beat yourself up, everyone makes mistakes.
** Any mistake other than those which resulted in a published movie is fixable.
*** If the movie was already published, speak to the other staff, maybe someone has a creative solution. If not, it happens, revel in your ability to be human.
** Learn from your mistakes for next time.
----
!!! More reading
* For movie analysis: [Movie Rules], [Guidelines].
* For editing: [Editor guidelines], [Text formatting rules].
* For movie editing: [Movie Tag Guidelines].
If you're also a publisher, please read the [Publisher guidelines] as well.