Style Guide

This document outlines the formatting and writing conventions used throughout the wiki to maintain consistency, clarity, and accessibility. All contributors should follow these guidelines when editing or creating pages.

General Writing Guidelines

• Tone: Keep a friendly, informative tone. Articles should be accessible to both new and experienced players. Avoid unnecessary jargon and assume readers may not be familiar with every system.
• Perspective: Use third person (“Players can…” rather than “You can…”), unless describing direct commands or dialogue where second person is more natural.
• Clarity: Write short, direct sentences. Avoid redundancy and filler.
• Spelling: Use American English (e.g., “color” instead of “colour”).
• Punctuation: Use Oxford commas for lists, and keep punctuation outside of wiki links (e.g., "BadWolfMC Wiki," not "BadWolfMC Wiki,".

Command Formatting

Commands should always follow a consistent structure and visual style to improve readability.

In-line commands

Use the Computer Code format (Ctrl+Shift+6) for any command mentioned within a sentence.

Example: Type /spawn to return to the main world.

Single-line or block commands

Use the Preformatted Paragraph style (Ctrl+7) for any command displayed on its own line or as a group.

Example:

/res create [name]

Command syntax format for variable arguments

Use /command [required_argument] (optional_argument) to denote structure with variables.

• Square brackets [] indicate required variable arguments.
• Parentheses () indicate optional variable arguments.
• Exceptions to this format include provided non-variable arguments which are being explained, such as options that might follow /res set as opposed to simply /res. In this example "set" is not considered a variable and does not require punctuation indicating such. However, if one were explaining the variables associated with the root /res command, then the ensuing arguments would be considered variables.

Example: /res set [resname] (flagname) (true|false|removed)

Linking and Cross-References

• Always link the first mention of a topic to its relevant wiki page.
• Use descriptive link text, not “click here.” Example: See the Residence Guide for details.
• Avoid overlinking the same term multiple times on one page.

Visual Formatting

• Use Headings (Ctrl+1 through Ctrl+6) to create clear hierarchy.
  • Heading 2 for major sections
  • Heading 3 for subsections
• Avoid excessive bold or italics. Use them sparingly for emphasis.
• Lists (bulleted or numbered) are encouraged for clarity, especially in how-to or procedural pages.
• Tables should be used only where data benefits from structured comparison (e.g., price charts, flag lists).

Item and Plugin Names

• Minecraft item names should match their in-game capitalization (e.g., Diamond Pickaxe, Golden Apple).
• Plugin names should be capitalized as their developers do (e.g., VeinMiner, DynMap).
• Custom items or tools unique to BadWolfMC should be italicized and capitalized consistently (e.g., Sonic Shimmer, Key of Rassilon).

Page Layout

• Each article should begin with a brief overview paragraph describing what the page covers.
• For guides, follow this logical flow:
  1. Overview / Purpose
  2. Prerequisites or Requirements
  3. Step-by-Step Instructions
  4. Tips or Notes
  5. Related Pages

Template Usage

• Use existing templates (e.g., {{Command}}, {{Warning}}, {{Note}}) wherever applicable.
• If a new type of formatting appears often, consider creating a reusable template or module to maintain consistency.

Tone and Conduct

Remember: the wiki represents the BadWolfMC community.

• Keep language inclusive and non-judgmental.
• Avoid personal opinions or editorial comments (“This plugin is annoying”).
• If something is uncertain or subject to change, mark it clearly with {{Needs Verification}} or {{Outdated}} if such templates exist.

Future Additions (Suggested Topics)

You can expand the guide over time to include:

• Image usage and file naming conventions
• Category tagging and navigation boxes
• How to write lore entries vs. technical guides
• Formatting changelogs or version histories
• Markdown vs. Wikitext do’s and don’ts