The Guide For The Guide

so what do we need?

Tone, Language, and Style Standardization

Tone

The tone of our wiki is encyclopedic. This means a few things.

Localization

This wiki is written in formal American English. As such, American spellings are used (color, not colour), and dates are in the order MM/DD/YY.

Links

One of the goals of this wiki is to be interconnected, which means pages should link to other pages. Any article should be accessible from any other article via direct linking, and we should avoid “orphaned” articles. Article links should be specified with brackets, as in [[Once-Per-Jump Rule]]. Note that an article should never link to itself. If a specific mechanic is referenced more than once in the body of an article, it only needs to be linked the first time (although you should continue to capitalize, for clarity). Articles that are linked in the body of an article can still be linked in under “See Also”.

Vocabulary Reference Guide (say this, not that!)

On our wiki…

Article Criteria

Our wiki is intended to be a repository of gameplay mechanics and features that a developer would want to include in their game. Primarily this focuses on ways that the player can interact with the world, ways that world elements can interact with one another, and features of the world itself. When deciding whether a topic should be included in the wiki, consider the following criteria: Ultimately, if you still aren’t sure whether a page qualifies, ask the group.
While the wiki does include pages for games, they are not the focus. At the time of writing, game pages are not being added to the wiki. As the wiki develops, this will likely change to allow games mentioned in articles or all games.

Anatomy of a Mechanic Article

Mechanic articles take the following format.

Title Heading
[Description paragraph]
[Variations paragraph]
Examples heading
Game 1 – Example
Game 2 – Example
See Also heading
Article 1 – explication
Article 2 – explication

Description

This first paragraph is meant to give a clear definition of what you’re talking about. The first sentence should be the clear definition, typically in the format of “[Article Subject] is a XX defined by YY”. Subsequent sentences can make the definition more clear by mentioning other commonly used names or specifying important parts of the initial definition. This is also where the purpose of a mechanic is generally specified, whether that be from the player’s perspective (how does the player use this?) or the designer’s (what mood does this create?).

Variations

The second paragraph is meant to discuss general trends in the appearance of the mechanic – anything important enough that it bears mentioning to understand how the mechanic works, but not ubiquitous enough to be part of its defining criteria. If the mechanic’s appearances can be divided into different “schools” or types, this is where you would put that.

Examples

Examples are listed, under an “Examples” header, in a list format (no bullets). Examples are introduced as Game name – (sentence or two of explanation).
Lists of examples are not meant to be comprehensive. Examples should have the goal of showing the breadth and variety of the mechanic in-context. The following are criteria that can justify an example being listed here:
If you can’t enthusiastically answer “yes” to at least one of these criteria, that’s your sign that an example is not helpful for a given article. Tag search can be used to see every single game on our site tagged with a specific mechanic.

Note that some games may feature multiple instances of a single mechanic. For example, games like Ultrakill have a great many Advanced Movement Techniques. You only need to talk about one instance per entry, and are encouraged to stick to such.

See Also

Interconnections to other mechanic pages with some sort of relationship. Mechanics that are a subtype or supertype of the article subject should go here, as should mechanics that are frequently associated with the article subject, mechanics that are very similar to the article subject with some specific distinction, and any other mechanics that reasonably feel connected. Each listing should have a single-sentence explanation justifying the mechanic’s similarity or connectedness to the article subject. This should not be a summary of that article – what we’re aiming to communicate here is connection.

Incorporating Media

All mechanic pages should have at least one screenshot, gif, or video demonstrating the mechanic. This should be an emblematic (i.e. conventional) example, shown in real gameplay as seen by a player. The priority for choosing a screenshot or video is clearly demonstrating the mechanic.
Gifs are generally the preferred medium for UX reasons. If audio is necessary to demonstrate a mechanic, or if a mechanic demonstration is longer than 20 seconds, a video should be used instead of a gif. Screenshots should be used for a demonstration only when a gif or video is unsuitable.
Additional demonstrative media is to be used at an editor’s discretion following the following principle: if a specific functionality or type of a given mechanic is difficult to understand in article text, it should be demonstrated with media. However, media should never be a substitute for trying to explain strictly in text.
For cases where a single instance of a mechanic is notably more iconic than any others (i.e. “Wavedashing” – the most iconic appearance of such a mechanic is in Melee), that instance should be used as the example. Otherwise, no specific games are more privileged than others for showing a mechanic, so long as the game chosen is emblematic of that mechanic (subversions or unique implementations are not well-suited for this). Try to avoid games already mentioned in the Examples section and, across articles, try to show a wide variety of games.
All media should be captioned in the format [Game – Explanation], with the explanation describing what is happening in the video in the context of the mechanic. E.g. “Celeste – The player character performing an airdash.” or “The Legend of Zelda: Breath of the Wild – The player character’s stamina depleting as he climbs.” If you find yourself tempted to explain in more than a sentence or two how the mechanic shown works, you may need to consider if a more clear gif or video is possible.
When using image alt text, it should not include “image of” or “picture of”. Screen readers automatically announce an image as an image, so an alt text reading “image of a power-up” would be read aloud by a screen reader as “image, image of a power-up”.
Informative images are any images that add to the context of a page. If the content of a page would suffer if an image was removed, then that image is informative and therefore needs an alt text. The alt text needs to describe the image as concisely as possible. As a rule of thumb: avoid writing text alternatives longer than 100 characters. Having long alt text will result in a poor user experience for those using screen readers. If the image requires a lengthier description, it is better to describe the image in the content and provide a shorter alt text.