Login

Don’t Miss: A look back on the usefulness of video game manuals

<div style="margin: 5px 5% 10px 5%;"><img src="https://www.sickgaming.net/blog/wp-content/uploads/2020/05/dont-miss-a-look-back-on-the-usefulness-of-video-game-manuals.jpg" width="200" height="133" title="" alt="" /></div><div>
 Manual as Reference 
 When writing a manual, always remember that it is a reference work. Almost nobody reads the manual before they play the game. Instead, gamers play first then refer to the manual as they encounter confusing situations. Some people check the contents first, others the index, but eventually all start flipping through the pages, looking for a familiar screen shot, term or chapter heading. 
 Good manuals are designed to make reference easier. Bad manuals implicitly assume the reader will start at the beginning, read the whole manual, and then play the game. The largest cause of useless manuals is over-linear writing that buries what the gamer wants in endless pages of dense text, then demands the reader plow through it before anything is intelligible. 
 Think Visually 
 When writing the manual, imagine a gamer flipping through the booklet, looking for the specific screen, control or concept. The more visual “reference points” you provide, the faster they can “home in” and get what they need. 
 Use screen-shots with call-outs: This means a picture of the screen with each part clearly labeled. labels should be outside the picture, with lines or arrows pointing to the appropriate screen area. Labels superimposed on the picture obscure the contents underneath, and are easily mistaken for on-screen graphics! 
 For example, the frequently excellent Railroad Tycoon II manual has dozens of screen shots, but only one with a label, and that a mere four letter code inside the picture! This causes excessive verbosity in screen descriptions, as individual graphics and icons are described in painful detail. Furthermore, the lack of call-outs made it east to miss useful information, such as the Oil, Sand and Water gauges on the Instrument Panel on the train detail Screen (to retain the unfortunate capitalizations used there). Worst of all, the call-outs that did appear are meaningless letter codes, rather than immediately useful words or phrases. 
 On the other hand, Jane’s F-15, one of the most complicated flight simulators ever made, has screen shots with call-outs every second or third page. With these, mere mortals have some chance of mastering avionics far more complicated than anything in RRT2. 
<table border="0" cellspacing="0" cellpadding="6" width="166" height="148" align="center">
<tbody readability="2">
<tr align="center" bgcolor="#ffffff">
<td><img src="https://www.sickgaming.net/blog/wp-content/uploads/2020/05/dont-miss-a-look-back-on-the-usefulness-of-video-game-manuals.jpg" alt width="200" height="133"></td>
</tr>
<tr bgcolor="#ffffff" readability="4">
<td height="20">Jane’s game manuals feature a bounty of screenshots, with many callouts indicating the function of various on-screen indicators. </td>
</tr>
</tbody>
</table>
 Control illustrations: Console games with standard controllers always benefit from a “controller diagram page” with call-outs to each button and control device. Console game licensors normally provide standard versions of this illustration. Most require manuals use their standard terms for each button or control device, which promotes easy recognition and understanding. 
 PC games have a mouse and keyboard. Ideally, a well-designed Windows 9x game has every action available through mouse control. This means it can be illustrated with a menu, dialog, or button, even if a screen shot is unavailable or inappropriate. Unfortunately, many game designers are still stuck in the DOS mentality of keyboard-only inputs. Such games demand a fold-out keyboard diagram, while mouse- capable games with full compliment of keyboard shortcuts also benefit from a separate keyboard diagram. 
 Separating the Parts: Operating Instructions, Hints and Background Data 
 Gamer questions or problems frequently involve how to operate something or interpret a screen. Later and separately, devoted fans seek background or data that helps them to be more successful. Therefore, a well-organized manual should separate information into three distinct sections: operating instructions, hints & background, and finally data (usually data tables). 
 Many writers find it more convenient to place the hints, suggestions, background, and data alongside operating instructions. Unfortunately, this simply conceals important basic information amid thickets of prose. Remember, the initial questions of most gamers involve operating instructions. Keeping these in one place, uncluttered and succinct, is well worth the effort. 
 In compact manuals, placing operating instructions right at the front is often the best policy. One admirable approach in its utter simplicity was Tomb Raider II‘s one-page list of the game controls, placed right after the table of contents. The authors rightly assumed that this “cheat sheet” of controls would answer most questions. 
 In complicated game manuals (tomes), most authors can’t resist the temptation to provide background information along with the controls. They know gamers will want advice and help, and they know the developers/publishers need to rationalize certain decisions. The temptation to conveniently mix it all together can seem irresistible. Well, resist it. Such mixtures complicate a gamer’s referencing, which makes a complicated game seem that much more complex. 
 Operating instructions must be clear and to the point. Information is easier to reference when it is neatly tagged, described and categorized. For example, in a combat jet flight simulator, descriptions of the multi-mode radar system can be dauntingly complex. The best solution is screen shots with call-outs to start the operating instructions, then a description for each call-out, then a description of what each applicable control does on that screen. Even if many modes share the same control, it is best to list each applicable control so the user understands what could be done. To avoid too much redundancy, the control description could be brief, with a reference to another page for details. 
 Detailed explanations of bar scans, refresh rates, and other electronic concepts do not belong in the operating instructions. These should be placed in the background & hints section, where the player can take Radar Systems 101 at their leisure. Naturally, the operating instructions will reference this section, so the player who really wants to understand more knows where to look. 
 Finally, neither of the above is where the game should list which radars are in which type of plane, or their technical specifications. All this is found in tables within the data section. 
 One of the most perplexing problems in manual writing is where to place game rules. That is, information about how the game works inside (i.e., within the software). In general, internal operation should be left to the background & hints and data sections. Alas, sometimes internal rules change how controls work, or even disable some while invoking others. In this case, a brief mention of the rule is appropriate, often with a reference for more information. 
 For example, the following would be appropriate in a strategy wargame. “You cannot choose Fire if the unit has no ammo (see Ammo Indicator on page 21, and logistics: Ammo on page 187, and Ammo Load Tables on page 205 for details).” Notice that a screen call-out was referenced, as well as background and data tables. 
 In some cases a competent description of game operation demands a rules explanation at that point. A common example is startup and configuration options. The user wants the manual to tell him exactly what occurs in each option. It is more sensible to oblige him, rather than make the entire section a series of references to pages in a “Background & Hints” section. 
 Procedural Organization 
 Within the operating instructions part of a manual, the best way to organize the material is procedurally. That is, the screens and controls first encountered by the gamer appear first, followed by the next screens and controls, etc. Those seen last, or very infrequently, should be at the end of the operating instructions section. 
 The primary exception is compact manuals. Here the gamer may be better served by an immediate presentation of the screen with call-outs, and/or a controller with call-outs. Startup options and other esoteric details can follow. 
 Rules vs. Examples 
 A cardinal rule in operating instructions is that any example must clarify a general rule, but never be a general rule. Lazy writers often use examples to present a concept or operating procedure. Unfortunately, when the gamer looks up the concept, they must wade through the entire example, then try to infer the general truth that might apply to their case. Rule through example greatly complicates the reference task, while an inappropriate example yields nothing but a hopeless puzzle. 
 Crafting a short, clear, general-purpose explanation to each screen element and each control is a non-trivial task. Given the short time and small funds allocated to most manuals, it is surprising that so many do a good job. 
 The Indispensable Index 
 A good index is required for any good manual. Even if gamers start by flipping pages, frustration may eventually send them to the index. The best indexes are always create by humans. Furthermore, it is really quite easy. 
 To create a good index, read through the manual from start to end. Every time a game-specific term appears, write it down with the page number. Every time a game concept is described, write it down with the page number. similarly note every screen title, every significant option on every menu, and every function with a special dialog or window. When in doubt, add an entry. When you’re done, alphabetize the list and combine all entries for the same word into that word mention followed by all the page numbers. If your word processor can’t alphabetize, import the file to a spreadsheet, which can sort entries alphabetically. 
 Manual indexing can be supplemented by indexing software. If this is available, use it afterward to catch references and additional indexing terms. Unfortunately, indexing software isn’t smart enough to detect concepts as well as words, since the software isn’t trying to understand the text. For that reason, indexing software an be a false crutch if used before you create one through reading. 
 Indexes are best done after the graphic arts person or team has set up the manual using desktop publishing software. Attempts to build indexes early, with hidden links within the word processor, invariably take more time than they save. On the other had, a game-specific style guide can be a gold mine of index material (see Style Guides, below, for details). 
 Structuring Sidebars 
 A sidebar is a short, self-contained article, often accompanied by a single picture or illustration, that appears next to the outside margin of the page. On narrow pages they sometimes appear at the bottom or top, instead of along the side. Pioneered by new magazines in the 1970s, sidebars were designed to present interesting ancillary information that relieves visual boredom in long text articles. They provide both a visual and intellectual “change of pace.” Sidebars work poorly on pages with large illustrations, such as screens with call-outs. 
 In the operating instructions section, sidebars are most effective in presenting a larger example of play, especially examples accompanied by an illustration. 
 In the “Background”, “Hints” and “Data” sections, sidebars typically contain incidental bits of historical interest, odd facts, or even sections of short fiction that support the game environment. For example, an RPG manual might have a series of sidebars, each with a different entry form a fictional adventurer’s journal. The Railroad Tycoon II manual has a different, dated historical tidbit in each sidebar, with one on every page except chapter starts. 
 Boilerplate Text to Include 
 Every game must include certain legal statements regarding copyrights and trademarks. In addition, almost every reputable publisher includes a legal statement about terms of use. Often this is the infamous “warranty.” Reading the fine print, you discover its real purpose is to prevent the user from presuming that any warranty, implied or actual, really exists! 
 A good manual writer allocates appropriate locations for these materials, or actually paste in the latest text, depending on the publisher’s preference. Also remember to insert correct trademark and copyright statements in the appropriate spots, usually on the front and back of the title page. Unless specifically told, do not expect the publisher to automatically insert legal materials. Remember, if the publisher forgets, they invariably blame the author. 
 Detailed game credits should appear in the manual unless publisher policies prevent it. The best location is near the back, after any design notes and before the legal boilerplate glossary and index. Of course, certain egotistical developers and/or publishers may require the credits up front, before or immediately after the table of contents. 
 An Example of Tome Organization 
 Organizing a manual, especially a tome, is easier if you start form a well-tested pattern. The following general outline should serve most adventure, RPG, simulation and strategy games for PCs: 
<ol>
<li>Title Page </li>
<li>Table of Contents </li>
<li>Introduction (If the publisher demands up-front hype for the game) </li>
<li>Tutorial (Ideally designed to accompany a software tutorial) </li>
<li>Game Operation
<ol>
<li>Game Startup & Initial Options (Describes what each option means or does) </li>
<li>Game Action (Subdivide by screens or concepts as appropriate) </li>
<li>Game Results (Especially unique post-action screens and/or options) </li>
</ol>
</li>
<li>Background (In sections appropriate to the subject matter) (Information about various internal game rules and logic) (Hints about good play, strategies, tactics, etc.) (Historical background or fictional storylines) </li>
<li>Game Data (Charts and tables of internal data useful to players) (Equations or formulae that might help players) </li>
<li>Designer’s notes (A short history of the game’s development) </li>
<li>Credits </li>
<li>Legal Statements (Warranties, etc.) </li>
<li>Glossary </li>
<li> Index</li>
</ol>
</div>

https://www.sickgaming.net/blog/2020/05/...e-manuals/

xSicKxBot