Caves of Qud Wiki:Style Guide

From Caves of Qud Wiki
Revision as of 17:15, 15 June 2022 by Egocarib (talk | contribs) (note about multiple categories)
Jump to navigation Jump to search

The Official Caves of Qud Wiki Style Guide is a standard of editing practices and formatting styles for article contribution. Please follow these guidelines as closely as possible, but use your judgment and/or ask others if you believe a situation calls for breaking or amending them.

This is heavily based on Gamepedia's own Manual of Style.

Pages that are tagged as Category:Guides are not required to closely follow this style guide, but are still encouraged to consider following any guidelines that are useful for them to follow. In particular, it is not necessary for them to explicitly call out opinions. Such pages should also make it obvious at a glance that they are guides.

Article Layout

Page Names and Capitalization

Caves of Qud has all items and creatures titles written in all lowercase, unless the name is proper (Sparafucile vs giant centipede nest). To keep in the same spirit, all items and creatures will follow the same convention. If possible, the capitalization format of the game must be obeyed as much as possible. As an example, all mutations are capitalized in Title Case as they are in game (Multiple Legs) but cybernetics are not (cherubic visage). Concepts and mechanics that have no official name will follow standard wiki title format. The same concept applies to capitalizations of terms that appear within the text of an article.

Exceptions can be made for section titles, table headers, and similar labels - these typically are written in Title Case regardless of the terminology involved.

Examples of terms and their typical capitalization:

Terminology Capitalization Scheme Example
Mutation names Title Case Corrosive Gas Generation
Skills and powers Title Case Dual Wield
Attribute names* Capitalized Ego, Agility, Willpower
Proper names Capitalized Lake Hinnom, banner of the Holy Rhombus, Flume-Flier of the Sky-Bear
Non-proper location names Lowercase desert canyons
Most items and creatures Lowercase spaser pistol, gelatinous prism
Game mechanics terminology Lowercase critical hit, thrown weapon combat
*There is some inconsistency in whether attribute names are capitalized in in-game text, but capitalizing them seems to be the most common scenario, so we prefer to also capitalize them on the wiki.

Headings

When an article is divided into headings, start at level 2 headings, which are written in wiki code == like so ==. This makes it so that all headings in the page are "smaller" than the page title, which is itself a level 1 heading. Unless there is a good reason, don't use level 1 headings (= like this =) in articles or in templates that are meant to be transcluded into articles.

Headings should use Title Case (most words other than articles and conjunctions are capitalized).

Infoboxes

Infoboxes, boxes which summarize data relating to the article, should appear at the top-right corner of the article content. This includes item tooltips.

Infoboxes should generally summarize available information; speculation, as well as filler rows (e.g., "?", "unknown", "N/A"), should be avoided if possible. Most information required in infoboxes will be in ObjectBlueprints.xml.

Prerelease Content

All content that requires that prerelease content be enabled in order to appear in the game must be prefaced with Template:Prerelease Content.

Book Layout

Book articles should include Template:Item, which is normally generated by Qud Blueprint Explorer. Please do not alter these except through QBE, as they're required in order for QBE to function correctly. The actual contents of the book should appear under a section titled 'Contents', using {{Book Page|(your text here)}) to format each "page", with the 'exact' contents of the book's page data in the game files, including the exact whitespace used.

NPC Layout

NPC articles should include Template:Character, which is normally generated by Qud Blueprint Explorer. Please do not alter these except through QBE, as they're required in order for QBE to function correctly.

Writing

Categories

Categories should be named in their plural form when appropriate, capitalized in title case. E.g., Category:Weapons. (However, note also Category:Lore, so named because the word "lore" has no common plural form.)

You can use Wikipedia categorization guidelines as a general reference for how categorization should work. Articles should generally be placed only in the most specific applicable category. All categories should have parent categories that eventually chain up to the top-level caves of qud wiki category. For example, if an article is in Category:Chairs it shouldn't also be in Category:Furniture. It's okay to add multiple categories to an article if those categories aren't part of the same direct category hierarchy. For example, the miner's helmet page has both the Helmets and Light Sources categories.

Note that many articles have a primary category already specified in their QBE-populated template, which will look like this (example from Shale wall with agate deposits):

| categories = Gemstone Walls

This category is already applied to the article so there's no need to add the category manually by adding [[Category:Gemstone Walls]] to the page

Reliability

To ensure that all information on this wiki is verified and up to date, make sure to include Template:As Of Patch on the top of pages that required manual research or review of the game code.

Infobox updates are performed by QBE and QBE will add a game version footer to the infobox when it updates a page.

To make sure that information is correct in the first place, if it is in a difficult-to-find location (e.g., a C# class whose name is not the ID specified in the page's infobox), be sure to note which C# class you found it in by using Template:Code Reference or, if that template won't work for some reason, a <ref></ref> tag. Line numbers must not be included, because they may be inconsistent across disassemblies/versions.

Formality

Writing in the second person (referring to the reader directly with "you") usually has preferable alternatives. Consider using "the player" or "the player character" instead as appropriate, or something more suited to the context.

Any recommendations or other opinions must be presented only in sections marked with Template:Opinion, in order to help the reader distinguish verifiable fact from other additions.

Terminology

Avoid protagonist bias; many creatures besides the player character are able to use objects and mutations the same way the player does. Avoid mentioning the player character when "this creature" is more accurate to describe the possible users. Do note, for example, when a mutation's effect depends on whether it's used by a player or non-player character, such as Precognition.

“Creature”

A creature is anything with a Brain part in the game data. (Note that this is a distinct notion from having a brain susceptible to psionic attacks.)

The following are creatures:

The following are not creatures:

Depending on the context, exceptions may be made for narrative entities who aren't represented as game objects with brains, such as Ereshkigal, despite the fact that the only thing Ereshkigal has in common with most creatures in the primary sense is that she has in-game dialog attributed to her.

“Currently”

When referring to a feature of the game or some other state of affairs that is not expected to change except between game versions, the word “currently” carries an implicit expectation that the thing being described may change in the future. This is a claim that must be backed up with a source in order to be verifiable. The best way to source such a claim is to link to an issue on the public issue tracker that has been seen during a triage and not immediately closed. The easiest way to tell that this is the case is if the issue has been assigned to someone and its status is “New” or “Open”.

Instead of writing “currently” in these cases, consider “as of patch [patch]”, which provides a useful reference point for when the claim in question may have been true, and can save time for other editors if they decide to recheck the claim to see if it remains true or not. Alternatively, make sure there is an up-to-date Template:As of patch on the page.

This rule is not related to uses of the word “currently” that are about something that is expected to change within a game session. For instance, “a creature that is currently flying” does not run afoul of this rule and does not call for a citation to justify that wording.

“Monster”

Avoid the word “monster”, except as used in the game. Prefer “creature” instead, regardless of how the player or player character may feel about the creature in question.

Units

The standard unit of liquid, including water, is the "dram". Drams of water in particular (and only drams of water) may also be abbreviated with "$". E.g., "$10" means "ten drams of water".

The standard unit of weight is "#". It can also be spelled out as Lbs.(pronounced pounds); However, to avoid confusion, it should never be written as "pounds". Consider using Template:Pounds when writing out a weight.

The time between when a creature receives the opportunity to act is a "turn". The 'standard' unit of time is the "game tick", or simply "tick", which is equivalent to one turn for a creature whose quickness is 100.

"Parasang"

A parasang is, depending on context, equivalent to:

  • a world map tile
  • the 3×3 set of surface zones associated with a given world map tile
  • the 3×3×infinity set of zones associated with a given world map tile
  • the distance from one zone to any zone on an adjacent world map tile

Formatting

Links

Phrases that correspond to a relevant article on the wiki, such as the names of concepts in the game, should be linked. It is only necessary to link to any given page, or anchor within a page, once per section; avoid linking to the same page more than once per section.

As an exception to this rule, it's acceptable for automatically generated content, such as tables generated from database lookups, to link to the same thing multiple times in a section.

(See also the Colored Names section.)

Color

The wiki already has a template for the main colors found inside Caves of Qud. Do not directly format the text with html;Template:Color has all hexcodes as well as way to quickly format a line with a single color.

Colored Names

Item names such as Stopsvalinn have multicolor names in game. For ease of use, call Template:Qud text instead of manually changing each letter using the Color Template. If referring to an item or character in its page, use Template:name to automatically make the colored version of the item. If referring to other items and characters with a link, use Template:favilink.

Note that use of favilink should follow the general rules for linking.

Quoting In-Game Descriptions

When pasting descriptions from objectblueprints, call Template:Qud quote instead of Template:Quote to parse color strings and preserve single line breaks.

Wikitext

For more specific help on wikitext, check Wikipedia's own Help article. For fancier functions, check Wikipedia's Magic Words.

Dice

Format any string representing a dice roll with Template:Dice tooltip.

C# Code

C# code (which will generally only be found in the Modding namespace) should ideally be formatted the same way that Visual Studio Code with Microsoft's C# extension would format it when using the Format command from the command palette. If you need to add code to the wiki but don't have access to VS Code, do your best to follow the style of existing code on the wiki and another editor can put it into the correct format.

References

As a general principle, articles should aspire to help readers discover where to look to verify the information they present, particularly whenever it's not obvious where to look, for purposes of verification and for modding. For this reason, articles should cite in-game sources whenever it aids in this discovery.

For citations to the game's C# code, use Template:Code Reference (see the documentation on that page for a usage example).

It's not necessary to cite the object blueprint for the object that a page is about. However, if some of that object's behavior comes from a part specific to it, the part can be cited using a code reference as described.

All cases not covered by more specific advice can use <ref>ref syntax</ref>.

Whenever an article contains any citations, its very last heading should be a {{References|(game version number)}}.

Maintaining up-to-date-ness

To guarantee that the data on a page is correct, we have two main locations that we place the game version our information comes from:

  • The infobox footer, which is either automatically populated by QBE, or manually added by setting the gameversion parameter in the infobox to the game version. This is used for the infobox related data only.
  • References, added by adding {{References|(game version number)}} at the end of the article, before any navboxes. This is used for manually written information in the main body of the article.

For other pages, regular {{As Of Patch|(game version number)}} will be placed at the very top of the article, although if the page uses references, it is best to place in the references section as stated previously.

Sprite Uploading

Main article: Sprite Uploading