The Guide For The Guide
so what do we need?- Tone, Language, and Style Standardization
- Standard american english, standard capitalization and punctuation. Not essay!
- Vocabulary
- Article criteria (high-priority!)
- Anatomy of an Article (high-priority!)
- Description
- Why: cause fear/stress, challenge, introduce character
- Variations
- Examples
- Comparisons
- Footer (procedural?)
- Incorporating media (videos and screenshots)
-
What makes an example important?
-
Link to games with this mechanic
Tone, Language, and Style Standardization
Tone
The tone of our wiki is encyclopedic. This means a few things.- Our goal with all written text is to be informative. Information may not all be comprehensive, but it should be true, and it should not be phrased as an argument or opinion piece.
- We are strictly descriptive about the things we talk about. We are not prescribing or making a judgement on specific mechanics, and we’re not gushing about how cool our favorite games are, we’re describing things that are observed.
- We are serious. Inane nonsense is to be kept off-site (that’s what the discord is for!), as is snark. We may write about silly things when appropriate, but the writing itself should be measured at all times.
- Our tone is reasonably formal. This has implications on formal elements – we use standard formal English grammar and punctuation conventions, and we avoid contractions – but it’s more a vibe than anything else.
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…- The “player” is the human being controlling and interacting with the game. The “player character” is the character or avatar that is controlled directly by the player in the game world. A “character” may or may not be the player character, although “player character” may be shortened as “character” in some contexts.
- When referring to a mechanic with a page, use the name of the mechanic established on that page, or another form of the same word (e.g., Jump can also be referred to as Jumps or Jumping).
- When referring to a game, use the name used in official materials for the game’s English-language release. Indicate the release year of the game in the format Game (XXXX), i.e. Celeste (2018). Games are referred to in italics and title case. In cases where release year is ambiguous, use what Wikipedia uses, using (Upcoming) for games that aren’t out yet (i.e. Ultrakill (Upcoming)) and (Canceled) for games that will never come out. Use a game’s official title, even when there is another more commonly used title (i.e. Resident Evil 4 (2023), not Resident Evil 4 Remake (2023)).
- The actions a player character can take during standard gameplay are “moves”, and a player character’s moves constitute a “move set”.
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:- Is the topic a narrative trope? If so, it’s probably not a mechanic. Consider TV Tropes instead.
- Is the topic an artistic or musical style? If so, it’s probably not a mechanic.
- How many games or series does the feature appear in? If the number is 1 or 2, consider asking for others to help find additional examples, widening the scope to include other similar features, or not creating the article at all.
- Is the feature one that a developer would deliberately program into their game? If not, it’s probably an emergent behavior or bug, which are not the subject of this wiki.
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:
- The example is in a genre or camera perspective significantly different from other items on the list (i.e. if a mechanic appears in top-down games, sidescrollers, and 3d games, it makes sense to have an example from all of those)
- The example exhibits a notable tendency or variant of the mechanic, especially things you deigned to discuss in the Variations section, not seen in other items on the list (i.e. if you said the mechanic often costs stamina, you should have an example of a game where it costs stamina)
- The example is subversive or unique in its application, purpose, or relationship with other mechanics in the game, or appears in an environment one would not expect it to
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.