Manuals: They Can Be Good

0
22


 


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.



Jane’s
game manuals feature a bounty of screenshots, with many callouts
indicating the function of various on-screen indicators.


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:

  1. Title
    Page
  2. Table
    of Contents
  3. Introduction


    (If the publisher demands up-front hype for the game)
  4. Tutorial


    (Ideally designed to accompany a software tutorial)
  5. Game Operation

    1. Game
      Startup & Initial Options

      (Describes what each option means or does)
    2. Game
      Action

      (Subdivide by screens or concepts as appropriate)
    3. Game
      Results

      (Especially unique post-action screens and/or options)
  6. 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)
  7. Game Data


    (Charts and tables of internal data useful to players) (Equations
    or formulae that might help players)
  8. Designer’s
    notes

    (A short history of the game’s development)
  9. Credits
  10. Legal
    Statements

    (Warranties, etc.)
  11. Glossary
  12. Index



Source link

LEAVE A REPLY

Please enter your comment!
Please enter your name here