Introduction

When you write dialogue, or story materials for a game, you make an effort to write content that's entertaining and well-written. The last thing you want to do is bore your audience by listing facts in a clumsy exposition sequence.

However, when documenting the story content for your game, the reverse is often true. Of course, you still don't want to bore your audience (your fellow game developers). However, the best way to keep your writing from becoming tedious is to stifle your creative urges, and instead approach story documentation as a form of technical writing.

Technical Writing

For the sake of discussion, let's define technical writing as nonfiction that explains or describes. The technical writer breaks down complex ideas and presents them in straightforward terms, with the intention of recording or communicating data. Technical writing doesn't entertain or impress or captivate; it merely presents information. In addition, it is written with a specific audience in mind.

Technical writing is precise. It presents content briefly and accurately. It is impersonal, because the writer is communicating data, not observations or commentary. Technical writing is clear, employing a suitable organizational style and vocabulary. Since the audience may not be familiar with the content, the presentation is consistent, both in terms of content and format. Furthermore, in order to be trustworthy, the writer must be credible, presenting information that has been researched thoroughly. These concepts will be explored in more depth in the following section.

The applications of technical writing are many. Technical writers document software packages, working closely with the programmers to learn the tools and terminology before writing user manuals, help files, and troubleshooting guides.

Game design documentation meets all of the aforementioned criteria. The game writer breaks down complex ideas such as plot, character development, location, and game world, and presents these ideas in straightforward terms. The audience is the development team, a specific audience requiring information.

Let's examine the characteristics of technical writing, and consider how they apply to the documentation of story and narrative in games.

Precision

It's important that all content be verified for accuracy, since any misunderstandings will result in additional work for the development team.

For example, if one segment of the game features a scripted scene where one character climbs up a ladder, an animation artist may create a ladder-climbing sequence for that scene. Later, it may be discovered that the scene actually begins with the character crouching near the manhole. The ladder-climbing actually was supposed to take place off-camera, because there was no time to create a vertical shaft. So, in this instance, a little more time dedicated to verifying the exact content of that cut scene would have saved time and effort.

Ubisoft's Rainbow Six: Lockdown

Game writing should also be brief, omitting any extraneous content. It is sometimes difficult to resist the temptation to imbue story documents with drama or humor. The idea is that if the game developers want to create a thrilling game, or a fun game, then the documentation should match that sentiment. However, this is a mistake. While it is necessary to document the clever jokes and gut-wrenching drama, as well as the techniques for eliciting these emotions, it is not necessary for the presentation itself to be exciting or irreverent or dramatic. In fact, these extraneous elements can slow the reader down and create frustration. There's no need to write "well", either. Technical writing is straightforward and direct, not flowery or poetic. The audience isn't reading a game document in search of entertainment or diversion or spiritual edification; the audience is looking for specific content.

A final note about jokes: I've heard it said that humor makes it easier to read a document. Experienced game developers have made this assertion, and I'm always baffled by it. After all, is your average comedy still funny the third or fourth time you watch it? And bear in mind that the writers of funny movies are professionals -- they get paid to write funny things. But even professionals can't always write dialogue that's humorous enough for a laugh the first time, let alone after twenty viewings. How will your design documents be any different? Generally, design documents are read more than once, particularly by those who work directly on content creation. Even if the jokes are funny the first time, they're going to be tedious by the third or fourth reading, and unbearable after that.

Impersonality

Technical writing emphasizes facts and data. Game writing should be no different. When writing a character bio, or a story synopsis, or a breakdown of missions in a game, the writer should be presenting content with the audience in mind. This means that there is no room for intrusions, observations, or opinions in the document.

For example, you may have encountered the writer who must remind you of his or her presence: "As the humble writer, I propose that the main character should..." The use of passive voice goes a long way towards removing author intrusion from technical documents, as does abstinence from the use of first-person pronouns. In addition, the writer should examine a technical document thoroughly for any inadvertent opinions that may have entered the document.