StrategyWiki:Guide/Main game page

So, you want to start a guide? Or maybe you want to contribute to an existing guide but don't know how? This guide is here to help.

Differences from plain text guide writing
There are some differences from traditional guide writing:
 * nobody "owns" the guide, so don't act like you do
 * no closing comments sections
 * no copyright section (everything is GFDL)
 * no contact section (use the talk page for this)
 * no credits section (use per-page footnotes instead)
 * do not use attribution; all your edits are automatically attributed in the page history
 * do not use author lists in the guide itself (placing them on talk pages is fine)
 * you can use rich text formatting (bold, italic, underline, hyperlinks, etc.) using MediaWiki markup (or HTML, if necessary).
 * you can use tables
 * you can place images inline

Further tips, hints and other suggestions

 * credit information sources using ref and note. Because information (including cheat device patch codes) cannot be copyrighted or otherwise protected, you can take cheat codes or item stats from other guides as long as your wording and presentation of those details is sufficiently different.
 * Keep paragraphs short. Their size will vary depending on screen resolution and font size, but as a general rule you should start a new paragraph whenever something major takes place or it just seems like a good place. For example in an adventure game using a paragraph for each major location or location change is probably a good idea.
 * use sidebar for notes that accompany a page but are not a necessary feature of it. Using the sidebar to indicate the location of a sidequest collectible or rare vehicle or whatever will help those looking for those things while not interrupting those only interested in the core subject of the page.
 * taking notes on paper or in Notepad while playing the game is a lot easier than playing back through whole portions of the game to describe something you didn't before. You can of course refer to other guides to refresh your memory of the specifics.
 * don't bother using tabs or multiple spaces. These don't appear in the saved page. If you want to lay something out use a table instead.
 * don't use more than a single blank line between sections. Any more than one will create obvious blank space in the saved page, which generally looks bad.
 * don't use "ASCII artwork" on StrategyWiki. Decorating guides is usually unnecessary; if you absolutely think some kind of decoration is a must then please use proper images.
 * don't use any form of JIS (e.g. JIS encoding or Shift-JIS) for Japanese. Instead use normal ASCII characters (e.g. ゼルダの伝説). Modern browsers support both, but ASCII works immediately whereas JIS requires the user to first manually change the character encoding in order for the characters to display correctly.

Getting Started
Obviously, the first thing is to choose a game to write for. It's best to choose a game you like and have played enough to be able to write about it.


 * You will need some amount of motivation or ambition to work on your chosen game. If you meet another fan also interested in working on that game that's great, as this will share the workload.
 * You don't have to immediately jump into writing the walkthrough (which is often the hardest part). If you want to concentrate on an items list or boss strategies to get used to wiki guide writing that's fine.
 * Changes go live immediately. You can write as much or as little at a time as you like.
 * If you're really uncertain of how to lay out your page you can use the Sandbox. Bear in mind that it's a free-for-all workspace; if you come back later and your work is gone, check the history for the last edit beside your username. By editing this old revision you can get back what you were working on.

Begin work on the main page first. Setting up the main page for a new guide has been simplified with the use of the New game template. Place the text in the page and click save to set up the basic layout. After that, just fill in the blanks. If you can, write a summary or introduction to the game, see other guides for examples of such. This should include a few lines about the history of the game and important information about the story at the beginning. However, try to avoid any spoilers on the main page.

Types of pages
You'll need some the following types of pages. Pages other than

"Cover"
This page serves as an introduction to the game. As a rule there won't be actual guide content on this page, but things like the storyline or description of acronyms/abbreviations to be used in the subpages might be a good idea.

If the cover doesn't already exist, use  to populate it with an empty infobox and Table of Contents. You can then edit the page and fill in the details. There should be a brief introduction describing the game (much like the start of a Wikipedia article). If you want to link the the Wikipedia article, use Wikipedia, or  if the Wikipedia article has a different name.

Walkthrough
The heart of many guides is the walkthrough. For simple games, this page should include all the levels or stages needed to finish the game, covered in as much detail as necessary.

If the game is very complicated or the descriptions become very long it should instead cover only the introduction—e.g. the opening cutscene or character creation (unless that is involved enough to earn its own subpage)—or perhaps the first level of the game. The aim is to make the automatic Walkthrough link on All Game Nav as useful as possible.

Other walkthrough pages should be subpages of the main guide (e.g. Game/Level 1) rather than of the walkthrough (e.g. Game/Walkthrough/Level 1). If it has an official name you might consider using that instead a generic numbered page.

Remember to put All Game Nav at the top and Footer Nav on the bottom so that readers can easily progress through the pages.

As a general rule, if something is not necessary to complete the game ("complete" in this sense means seeing the ending if there is one) it can be considered a secret or sidequest, and should be covered elsewhere (although mentioning it with sidebar is still a good idea).

Writing aids
Over time, authors have developed many techniques to make writing the walkthrough easier:
 * two simultaneous saves: if the game supports it, have two save files ("A" and "B", or whatever). Play "A" to reach a certain point and write up that section, then play "B" to reach that point again and revise your description. Rinse, repeat.
 * multiple save files: if the game allows you to use multiple save files you might like to keep a completed one and then a second blank one for running through.
 * If the game allows savegame naming you should of course describe them appropriately for easy access
 * if the game allows infinite saves you can save at every important junction in the game, allowing you to easily go back through that section.
 * recording: if it's a console game you could consider recording the gameplay using a VCR or whatever device. You can then replay or even fast forward your way through your game play. Some PC games and most emulators support recording, and there are also many recording programs such as FRAPS that can export to a movie file for easier navigating.

Table of Contents
While the walkthrough is the heart, the Table of Contents is the veins. It should link to all the pages used in the guide to enable quick access from anywhere to anywhere else.

First of all, the ToC should be generic, simple and similar to other ToC's. For example, you should have a Getting Started (followed by basics) and Walkthrough page (an explanitory page followed by sections) and then an Appendices section with extra information. Usually controls, and background information is listed under the Getting Started section, guide areas are listed under the walkthrough sections and lists, maps and other information that wouldn't be considered one of the other sections goes in the Appendices section. Specific guides are also usually listed under Appendices (for example Mega Man 7/Boss guide).

Page links should be visually tiered, e.g.: However this is only the layout; as a general rule, the actual page locations only need to be tiered once (e.g. Game/Level 1 instead of Game/Walkthrough/Level 1). This prevents pages from having complicated titles (e.g. Game/Walkthrough/Core Missions/Ric/Bombs Away, Baby) and also makes linking easier.
 * Controls
 * Walkthrough
 * Level 1
 * Level 2
 * Items

To get you started, here are some generic ToC layouts for various genres:

Adventure RPG Racing Fighting
 * Characters
 * Commands
 * Game Overview
 * FAQs
 * Walkthrough
 * Items
 * Secrets
 * Characters
 * FAQs
 * Walkthrough
 * Sidequests
 * Enemies
 * Items
 * Weapons
 * Armor
 * Spells
 * Controls
 * Cars
 * Tracks
 * Cups
 * Controls
 * Moves
 * Tactics
 * Tips and Tricks

FAQ
A FAQ (Frequently Asked Questions) is a list of common questions players ask (or might ask). These have gone out of style in the last few years, and gamers are now in the habit of looking for answers in the appropriate section. If the game is particularly complicated or has specific information that is constantly asked (e.g. which characters are in which version, or if the existence of a nude skin is a hoax) a FAQ might still be a good idea, but as a rule any FAQ entries that could be rewritten and placed on a subpage instead should be. Because the FAQ will be read by players at any stage in the game, use spoiler for spoilers of any sort.

Basics
An important page in many guides. This may go under different names depending on the game, but will always serve the same purpose: to describe the controls, gameplay and other general features of the game. New and returning players should be able to read or even skim this page to get a general refresher on the bare minimum of what's involved. Even things covered in the manual should still be covered in case players don't have the manual for whatever reason (sometimes, rereleases don't even include a manual).

Complicated games might need to have this separated into different pages, but a non-linked "Basics" header can still be used on the Table of Contents.

Controls
This page (or section) should cover controls in the following sort of format:
 * : Jump
 * + : Super Jump
 * etc.

For lists of large but irregular numbers of buttons, consider listing the description first and the buttons second. You can also use tables to line things up better.

If no template exists for this system, or you don't know what its controls are, use  to tag it.

Optional Activities
Things that are not required for completion of the main storyline go on pages like these. Activities that are required at one point of the walkthrough but can be optionally done at other times as well should be covered in both places. If the game has a lot of sidequests you should of course split the page accordingly.

Move lists
As a rule, only fighting games and beat-'em-ups have these. Handle beat-'em-up move lists much the same way as controls pages. Fighting games, however, are handled differently. Unlike most pages, move lists are instead placed at Move Lists/Company Name/Game. Check Category:Move lists to see the ones already made; if a variant of the game you're writing for already has some moves that are performed identically you can just duplicate them from there. You will also need to create a character page in the format Move Lists/Company Name/Character. Talk to Procyon for more information regarding Move Lists standards.

Strategy
Mostly used for strategy/tactical/simulation/squad-based games, this page should provide general strategies. Mission-specific strategies should probably be covered on the page for that mission. It's also useful to spread a few handy reminders (e.g. "remember, Night Elves deal only half damage against Fell Orcs unlike the rest of their race") throughout the walkthrough.

Cheats/Codes
This section can have either title (as they are mostly synonymous). As a general guideline, if a game has only button-press and cheat device codes, call the page Codes; if the game has glitches and other sorts of non-cheat cheats call it Cheats. As a rule patch codes cannot be copyrighted, so taking them from other sites is OK as long as you describe the code's function in your own words.

Lists
Lists are very helpful, and should usually be kept separate from any other page so they can be easily accessed from anywhere via the Table of Contents. As a rule, pages with large amounts of statistics should be presented in tables. If the lists become extremely long consider splitting by type. As a general rule, use an identical layout for each entry or section, leaving parts blank that don't apply to that thing.

Foreign Language guides
At present, StrategyWiki only hosts English-language guides. If enough interest is shown in other languages, support for them can be added much like at Wikipedia.

Alternate titles
If a game is known under other names, redirect that name to the most common one and mention it there, e.g. "Grappler (known as Bad Bros in Japan) is a beat-'em-up for the Sega Genesis". To help people find it using that other name, include the game's categories on the redirect page. This will make it show up in those categories under both names. Redirecting common misspellings (e.g. Megaman instead of Mega Man) is also a good idea, but because the names are so similar they do not need categories.

Versions
If a particular version of the game has changes (such as more/fewer characters or remixed levels) this should be explained on the appropriate pages. If a feature with an identical name is different enough in particular versions that it cannot be covered on the same page, disambiguate it at the top something like this:
 * For the Game Boy Advance stage see Game/Level 1 (GBA) .

If the other version is significantly different enough that it should be covered separately, use a similar disambiguation on the cover page only and name the other guide with that system's common abbreviation.

Formatting
MediaWiki formatting is more involved than plain text, but less involved than HTML. See Help:Editing for more details.

Images
Remember the famous saying "a picture says a thousand words". If you're trying to describe a route or puzzle solution that takes a lot of words to explain, it might be easier to draw it and refer to the map.

Formats
As a general rule, "when in doubt, use PNG". The four most common formats are: There are other image formats as well, but they are not as well supported. Do not use them.
 * PNG has excellent lossless compression as well as multiple levels of transparency. Always try PNG first.
 * BMP is lossless but has no compression. Never use BMPs, use PNG instead.
 * GIF has good compression but not as good as PNG. It only supports a small palette (216/256 colors), and dithers anything outside that palette. Use PNG instead, unless you're using an animation.
 * JPEG is good for pictures with thousands of colors, but its compression method corrupts up simpler images. Use PNG unless the resulting filesize is excessive (say, over 100 kb). Avoid using Microsoft Paint's for JPEGs if at all possible as it corrupts the image far more than other programs.

Image Maps
Client-side image maps are supported. Upload the .map file. Using the same filename for the map and image will help demonstrate their association. See The Legend of Zelda: Ocarina of Time/Maps/Overworld for an example image map.

Image maps are inserted as follows:

Note that Media: is used rather than Image:.

Attribution
Like the rest of the site, do not use attribution on your image; this information instead goes on the image description page.

Can I use others' info?
Yes, but always rewrite anything you use unless the source allows to quote them (but a rewrite is still best). It's considered good form to credit the source (use ref and note for this) but it's by no means mandatory. Regardless of statements to the contrary, authors have no rights whatsoever to the information they are conveying, they only own their specific wording and presentation of that information.

What is "drivel"?
"Drivel" is defined as unnecessary information or the wrong case. Saying "this character sucks" or "I usually go with the girl" is drivel. Because guides don't have fixed authors, using first-person wording is a bad idea. You could instead try wordings like "some players recommend" or "it is recommended". Similarly, while you might think a particular character or feature is bad or good others might not; instead, try to give good reasons why that particular thing isn't good (e.g. "his attack is good, but he has too little health to survive long against bosses").

What about history pages?
No. MediaWiki keeps an automated history list, so you can enter things like "spellchecked" or "rewrote incorrect controls list" in the edit summary to easily keep a history list. As a general rule, use the talk page of the appropriate page for everything else. Such pages may not be part of the main guide nor may they be linked from them, but including one on the appropriate talk page is a useful way to find others interested in working on the game. Describing your role (e.g. "working on the food items list") will help others know what you're mainly working on.