Contents

Manual Overview The Manual as Reference Writing Technique Production

Production

It is well beyond the scope of this essay to discuss game booklet production. Ideally, an experienced graphic design professional should be involved in the conceptual design of every manual. Unfortunately, there are many people who know desktop publishing software, or have a passing acquaintance with HTML, but know nothing about graphic design. A reasonably trained professional knows the difference between sans serif and serif type (Helvetica or Arial are sans serif, Times is serif), how many points in a pica (twelve), how many picas in an inch (six in the computer age, slightly more in pre-computer typesetting), the difference between a gutter and a fly (the edge of the page along the binding is the gutter, the opposite edge is the fly), and can discuss intelligently the value and uses of negative space on a page.

Hopefully graphic professionals will also protect the printed materials from disastrous gaffs like the ink and paper choices that made the Baldur's Gate manual, reference sheet, and city map at best taxing, and at worst totally illegible.

Authoring Mechanics

Word Processors vs. Desktop Publishing vs. HTML Editors: Some writers prefer to write directly with desktop publishing software, or even using HTML editors, rather than a word processor.

Using a desktop publishing program for writing is never a good idea. Any author with sufficient training to do a good job in both fields should understand the value of doing the asks separately. Keeping the manuscript within a word processor has the added advantage that a graphics professional can "import" the file into various templates, experimenting quickly and easily with various designs. It is rarely as easy to reformat a document already set to a specific format.

HTML editors are more problematic, but many desktop publisher programs still have trouble importing or exporting HTML. Even if they can, style information is often lost, making the desktop publishing job much harder. The only reason to use an HTML editor is a manual that doubles as on-line help with hot-linked references. In this case the simplification of help file construction is balance against the increased difficulty in desktop publication.

Screen Shots: Whenever possible an author should provide screen shots, and in two forms. The first file is just the screen shot, nothing more. The second is the screen shot with call-outs attached. Any art or photo editing program allows this level of editing, as well as most word processors. The call-out version is purely a guide to the graphics people, telling them which call-out goes with which on-screen object. Beauty is not important here, merely clarity. To avoid accidents where a rushed graphics staff uses your call-out version, put a big, fat strongly-colored "FPO" (For Position Only) in the middle of the call-out version. A garish lavender is a useful color for this purpose.

Production Procedures

Desktop publishing software remains the best way to set up manuals for publication. The "industrial strength" versions are capable of outputting not only files acceptable to a printer, abut also Adobe Acrobat .pdf files, or web-browser-readable HTML files. When the game transitions from full-priced boxed product to the $10 bargain bin, then goes onto a compilation CD, or is licensed to an OEM, everything is faster, easier and cheaper if an electronic version of the manual can be put onto the CD-ROM.

Electronic Formats: Acrobat was a convenient standard in the mid 90s, but eventually HTML and ultimately XML will supplant it. Another advantage of HTML and (hopefully) XML is that users won't need special readers - a web browser will suffice. Best of all, instead of building a custom help file, HTML manuals could double as help files. In this scenario, clicking on the "Help" menu fires up the browser and loads the HTML/XML manual into a window on your screen. With some modest effort the contents and/or index could act as frame navigation tools.

Production Timetables

Time Estimates: It is impossible to write a manual at the perfect time. A decent manual writer needs about one week, plus one additional week for every 25 pages, plus a couple weeks for editorial and publisher changes. Then the desktop publishing people need time for their job, which should go four to five times faster than the writing. Thus a 200-page tome might take 11 weeks to write and edit, then need three (3) more weeks for desktop production. An ace writer who is familiar with the genre, has played alphas and early beta, and has acquired any reference data might be 20 to 25% faster, saving only 2 or 3 weeks out of the 14.

Blueline Fixes: Some producers skip the manuscript editing stage, then make extensive changes in the bluelines that come from the finished desktop production. These changes are invariably more complicated to make, and usually slow down the process more than they speed it up. Wise producers don't plan on any changes in the bluelines, reserving this review for last minute emergencies.

Timelines: Most games are far from finished 14 weeks before the master date. Manual writers complain that they can't do a good manual if the software is constantly changing. The author must either guess how the software might work, or write something uselessly ambiguous and vague. On the other hand, manuals done too late are written in such haste that important things are forgotten or poorly explained. Furthermore, language itself suffers when revision and editing is hasty to non-existent.

The only real solution is to write the manual at least 16-20 weeks in advance of the finish date, including the revision and editing. In fact, some background, hint and data material can be started even earlier. Then, as new betas appear, the author rewrites appropriate sections to keep the manual "current" with new versions of the game. The bug lists and new features lists are invaluable aids here. This allows manual adjustments to match the software, reducing lead time just 3-4 weeks, for a final edit (a few days) and the desktop publishing work.

Of course, this method requires producers with nerves of steel. After all, the producer must refuse to send the manual into "completion" until the game is 3 to 4 weeks from gold master. Many producers give in to pressure or optimism. They send the manual into finalization too early. This means they paid the extra cost (in author time) for the early start strategy, then squandered most of the advantage when the game drags on large, costly blueline changes are made.

Dual Computers: The most effective way to write the operating instructions is to have two computers. One computer has the game running, while the other is used for writing. Given the crash-prone nature of software during manual writing, no experienced author wants to run buggy or destructive software on their "work" machine. Writers unwilling or unable to use this "trick" frequently work at a slower pace or produce work of lower quality.

Blind Testing: If manuals and software are ready well before release, blind testing the manual can be very helpful. This test works like a marketing focus group. The manual author is required to sit in silence while a representative sample of users try to figure out the game, using nothing but the software and the manual - just like the final customer. Upon pain of death, the author cannot provide one word of help. Instead, the writer notes how people used the manual, what frustrated them, and what they failed to find. This frequently inspires improvements ranging from more index entries to minor rewrites.

There is no one, perfect way to use the English language. Good writers always seek better ways to communicate.

Arnold Hendrick's first published game (some WWII naval miniatures rules) was in 1968. he worked extensively in paper wargames, RPGs and miniatures rules until computer gaming arrived. Beginning in 1982 he has worked as designer and producer at Coleco, MicroProse, Interactive Magic, and currently Kesmai. With rare exception, he has written the manual for every game he designed or produced, from straightforward console cartridges to 200+ page military sim tomes.

He is currently designing and producing Jet Warrior: Vietnam, Kesmai's new flight simulator. The next generagion design is simultaneously played solo from a box, and massively multiplayer when online. He plans to write the manual himself, since despite more game development experience than the entire staff of some companies, moneymen just aren't burning up his phoneline with megabuck invitations to mastermind their product lines. If you need to make a megabucks investment in gaming, or just want more information on game design, production or manuals, his permanent email address is ajhendrick@aol.com

_____________________________________________________

[Back to] Manual Overview