Manuals:
They Can Be Good

Editor's note: This paper was originally published in the 1999 Game Developer's Conference proceedings.

Contents

Manual Overview The Manual as Reference Writing Technique Production

In a study conducted some years ago among business software firms, it was reported that the only Silicon Valley employee with lower pay and status than a secretary was the documentation writer. Those responsible for game manuals often feel the same way.

Game publishing veterans know that no game is self-explanatory, no matter how what the programmers say. In-game help, tutorials, and programmed learning are all useful, but nothing beats pausing the game to flip through the manual quickly to find the meaning of an icon, a strange symbol, or just how to save the game! Most games take over a computer and its screen so completely that the game must disappear before a help file can appear. Furthermore, during those hopefully rare food breaks, a manual is more portable than a surround-sound, subwoofed, heavily peripheraled gaming machine.

Manuals are frequently reviled as overblown, badly worded, uninformative dross that provide little or no help. Unfortunately this is sometimes true. Manuals written too early describe half-implemented software that is later changed or removed in the final rush to production. Conversely, if the manual is written too late, writers madly write, cut and paste together whatever they can find in a desperate attempt to cover most issues, somehow. Publishers assign writers whose longest prior effort was a ten page college paper, then profess surprise at their inability to handle a 100-page manual job. Then there are those manuals who actually believe the programmers' claims about self-explanatory software, allowing them to take the easy way out with a manual that contains nothing more than "background" and "color" (i.e., bad fiction).

Good manuals instruct the player, enhance the gaming experience, and explain away problems.

Every publisher bemoans the extra cost imposed by manuals. For a brief period some years ago Sierra (then Sierra On-Line) refused to include printed manuals in game boxes. Instead, the gamer just got a CD and some advertising leaflets inside a big box. The manual was in files on the CD, which could be read or printed out from your screen. This was a sales disaster. Gamers weighed and rattled the box, and judged the product wanting. Reviewers excoriated Sierra. None of these people just wanted heavier cardboard. For many, the mere presence of a weighty manual was an important feature, especially for complicated strategy, simulation or RPG games.

In other words, despite their moaning and groaning, certain gamers actually want a weighty manual, even if they don't read it first.

The Two Types of Manuals

There are two basic types of manuals.

1. The compact. Typically found in console-style action games, these manuals are designed to slip into the top of a CD jewel case. Compact manuals work well if the game has just one or two main screens, and one or two simple control sets - usually based on the buttons of a game controller. Compact manuals can appear in PC games. The Tomb Raider series is one famous example: these manuals can easily fit a 16-24 page format.

2. The tome. Normally found in complicated PC games, these manuals help the user understand a variety of cluttered screens with numerous controls. Talonsoft wargames, Interplay RPGs, or EA Jane's simulators are classic examples that all demand and receive tomes. Such complicated games require 50-100 pages just to explain all the screen graphics, controls, plus title, contents, boilerplate and an index.

Compact manuals can be expanded to greater size by adding background material such as hints, strategies, or storylines. This can quickly produce a 40-80+ page booklet -- what I call a "mid-range manual". Similarly, some games are too big for a "in the CD case" size and form factor. In both cases, the extreme brevity of the compact no longer applies. Therefore the greater rigor of a tome is used.

It is not uncommon to hope that a game's simple concept means a "compact" manual is possible. Later, of course, the multitude of controls, modes, and screens ruin these dreams. The person who decides how big a manual is necessary, and what's too much, should have written at least two compact and two tome manuals in their career. I believe that nothing matches real experience when making these decisions. Writers with experience in only one area can seriously misjudge the needs of the other. As for producers, those without the experience should seek advice from those who do have it.

Manuals & Product Sales

Most games are sold by word-of-mouth. The more people like a game, the more they "talk it up" to co-workers, on the Internet, and so on. Strong marketing may get a game into the stores, but only a good game zooms off the shelves and into customer hands.

Good manuals contribute to this success in three ways. First, they ensure that gamers can actually play the game. After all, you're never going to enjoy something you can't play! Second, a good manual can actually enhance the person's gaming experience. Third, a foresightful manual can pre-empt problems by explaining them away.

Goals of the Manual

1. Instruction. First and foremost, a manual tells the gamer how to operate the game. This is best done by designing the manual as a reference work. See "Manual as Reference" below for details.

2. Enhance the gaming experience. Manuals can illustrate and expand the player's gaming experience. A classic example was MicroProse simulations of the late 1980s. Those manuals included tons of detailed reference information about the various planes, tanks and weaponry appearing in the game. They also described real-world tactical tricks that could be used in the game to good effect.

This made gamers feel like insiders with special insights unavailable to "average" people. They learned the special tricks and appreciated the hints or strategies that helped them past difficult spots. The game made the gamers feel good about themselves. The manual played a large role in this. Compared to the difficulties of game programming and balancing, manuals are a remarkably cheap and easy way to improve the image of both a game and its publisher.

3. Explain away problems. More than once, a development team realizes that a certain feature or capability would be very nice, but there isn't enough time or money left to implement it! Almost anything beta testers demand, but can't be provided, falls in this category. A good manual will "explain" why the sensible and desirable features really aren't appropriate for the game. This can frequently minimize or even avoid bad press and internet flames.

For example, a flight simulator might reduce high-altitude visibility to maintain the frame-rate. Invoking "atmospheric haze" as an explanation sounds better than admitting the 3D hardware/software system with realistic visibility is unplayably slow.

_____________________________________________________

The Manual as Reference