Caves of Qud Wiki:Style Guide

From Caves of Qud Wiki
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.

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.

See also: Policy and Rules

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 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.


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, 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.



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


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.


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.


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.


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.


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 “Open”.

Making clear what game version is affected can provide a useful reference point for when the claim 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. To do this, either:

  • make sure there is an up-to-date Template:As of patch on the page;
  • or use a phrase such as “as of patch [patch]” in place of “currently”.

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.


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.


While it is an established feature of technical writing, the “indefinite the”, i.e., the use of “the” followed by a singular common noun used to refer to an entire class of thing, is dispreferred in favor of using “a”/“an” and a singular noun, or no article and a plural noun. E.g.,

  • A slugsnout is a type of swine. – Fine
  • Slugsnouts are a type of swine. – Fine
  • The slugsnout is a type of swine. – Not Preferred

The idea is partly to make it clearer when something really is unique, e.g., “the Kesil Face”.


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.


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


Any content encountered in Caves of Qud may be added to the wiki. However, in the interest of helping readers who want to avoid spoiling late-game and hidden content, pages should be marked with Template:Spoiler where appropriate, e.g.

Spoiler Warning: This article contains information normally only found in the course of advancing the main quest line.

The question of whether or not content should be marked with {{spoiler}} is left to the writer's discretion. In general, we advise adhering to the following guidelines:

  • Content that appears in the modding section of the wiki or in wiki meta-discussion pages (such as this one) does not need to include spoiler warnings.
  • Content related to non-dynamically-generated quests should include spoiler warnings, especially for quests that appear in the mid- to late-game.
  • Content related to hidden content that is not easily encountered by players, such as Tzimtzlum, should include spoiler warnings.
  • Content related to special enemies, such as the Girsh Nephilim, should include spoiler warnings.



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.)


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, you should use favilinks. There are three favilink templates available:

The differences between these favilink types can be relevant when objects or mutations share the same name, for example, the night vision implant and the Night Vision mutation. The table below shows how one might link to one page versus the other:

Page Examples
night vision (the implant)
  • {{favilink|Night Vision}}
  • {{favilink id|NightVision}}
  • {{favilink page|Night Vision (implant)}}
Night Vision (the mutation)
  • {{favilink page|Night Vision}}
  • {{favilink id|Mutation:DarkVision}}

Note that mutations linked with Template:Favilink id must be prefixed with Mutation: to distinguish them from object blueprint IDs.

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.


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


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.


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


Naming Conventions

When writing mod code for the wiki that involves unique internal identifiers, such as object blueprint names or part names, ensure that the names are prefixed with QudWiki_ in order to show good practice for avoiding name clashes.