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.

Clarity

Clarity is achieved through simple and concrete presentation. Through direct presentation of content, good sentence structure, and an appropriate choice of words, the game writer can create game documents whose meaning is understood immediately.

Vocabulary is important. Words such as "ecdysis", "meretricious", and "ophidian" have no place in a game design document, unless they are in some way a part of the game experience. While they no doubt serve to indicate the scope of the writer's vocabulary, they do nothing for the average reader except to extend the time and energy invested in the reading of a document.

I knew of a game studio whose design documents and story synopses were full of five-dollar words like promulgate and crepuscular. Reading these documents was certainly good for one's vocabulary, but most developers preferred to ask questions of the designers in person, rather than reading the documents. This wasted time and energy.

Clarity is also achieved through organization. Documents that are structured and legible are far more likely to be read by the developers on your team. I worked on one game whose story and design docs were available as HTML files on an intraweb. The documents were essentially raw text, and when viewed, appeared as a wall of text from one end of the monitor to the other. There were no margins, and nearly no formatting. For some reason, however, the text was smaller than the default setting. Reading the text on a computer screen induced powerful headaches, so most developers would copy and past the text into Word, then format it, then print it out, and then read it. Multiply this extra work across a couple of years, with a team of dozens of developers, and you have a great deal of effort that could have been put to better use.

Organizing the content of your manuscript effectively will also improve the chances that the developers are actually going to read it. It is important to consider the elements that make a document easy to read: good use of white space, paragraph breaks, and accentuated headings.

Consistency

It's difficult, when writing dozens of story documents, across months and months of development time, to be consistent in your documentation. However, this consistency is the hallmark of technical writing, and makes it easier to read and process the information that you're presenting.

Fonts, headings, and margins should be consistent through your document. MS Word features pre-loaded settings for headings, which can also be used to generate a table of contents at the beginning of your document. These settings can be changed, however, to accommodate a specific font choice. Beware of multiple fonts, however. If the heading is a big bolded Arial, then the sub-heading is a small italicized Garamond, and the font is a mid-sized Times New Roman, the document looks haphazard and difficult to read. It's important to use features like bolding, italics, and underlining as sparingly as possible.

"Fonts, headings, and margins should be consistent through your document."

Of course, you don't want to hand anything to your team until it's been spellchecked and proofread. However, proper nouns, such as the made-up names of your characters, magic items, and locations will not be addressed properly by built-in spellchecking software. Not unless you add these made-up names to your dictionary. In any case, be certain that the names are spelled consistently throughout the document. Refrain from abbreviation or nicknames, as this will only serve to confuse the reader.

Credibility

When documenting your story content, remember that the audience assumes your expertise from the beginning. Every mistake or misstatement will subtract some of that faith in the author, and will begin to color their confidence in the veracity of the material itself.

It is good to support all assertions with factual data, particularly if they appear to be debatable. For instance, I've seen "this will make the player feel" more times than I care to remember in story documents. The writer or story designer indicates that a certain sequence will elicit specific feelings in the player. There's no justification, no explanation of why this is so -- the assertion is made, and that's the end of it. When the player's sidekick dies, this will make the player sad. How do we know? Are we sure the player's even going to like the sidekick?

Credibility is also established by familiarity with the content, including the gameplay, the subject matter, the game's themes, the genre, and the history of the series or license (where applicable). In order to develop the necessary connection with the material, the game writer will have to perform research, which may entail reading through design documents, game reviews, articles, postmortems, and technical manuals.

Writing for the Audience

As a game writer, you may wind up writing much more than just storylines and dialogue. For example, you may be tasked with writing mission overviews, marketing copy, or technical documentation.

In all cases, the important thing to remember is that you're presenting core information to a specific audience. It's not important to share the minutiae of character development with marketing (unless they've specifically requested it, or unless it's a core component of your game's sales pitch).

Marketing

When presenting content to game marketers, be sure to convey only that information which they require. They may be interested in the core outline of your story, and in the major characters. A twenty-page document outlining the plot and characters in great detail may create additional work for them.

One approach that has served me well is the inverted pyramid of journalism. If you read the first couple of paragraphs in a newspaper article, you've got the basic facts of the story. Subsequent paragraphs add more explanation and detail, but the first lines will tell you what you need to know. This format works well when presenting content to the marketing team. A terse, fact-driven synopsis, followed by a longer document that explains the story content, will deliver all appropriate content to the marketing team in a way that's easy to read and understand.

It's also important to separate types of information. For example, some information is necessary to contextualize the game's action. This data appears on the back of the box, or in magazine articles. Lead a team of fierce adventurers into the land of the Orcs. Drive, fly, and shoot your way through a modern battlefield. And so on.

But if there's privileged information, such as spoilers, it's imperative that you label them as such. If the design documents are haphazardly furnished to the marketing department, and they're left to pick and choose which elements to emphasize in the ad campaign, the developers might not be satisfied with the decisions that are made. For instance, I know of a company whose developers were furious to learn that the marketing team had spoiled the surprise ending of their game in the marketing copy on the back of the box. But why was the information presented to the marketing team? Was it labeled as a shock ending? Did the story synopsis simply present the identity of the game's villain as a fact, or was it presented as something that was better left for the player to discover while playing?

"If there's privileged information, such as spoilers,
it's imperative that you label them as such."

Production

When presenting story content to your producer, first determine the producer's needs. Are you writing a document that's intended to motivate the team, and to contextualize the game's content for them? Or are you putting together a list of characters and locations that will be used to determine the number of artists needed to create assets for the game?

A story document intended to inform the team of your game's storyline can help get everyone on the same page, but that's only if everyone reads the documents. While working on a game a couple of years ago, I printed up a series of mission summaries for each of the levels. The summaries included the characters featured in the mission, the location, the major events, and the significance of the action in terms of the storyline. Character artists, level designers, and other developers noted that up until that point, they hadn't really been sure what the game was about. This proved to be a useful tool for inspiring the team.

But if your task is to furnish content whose focus is the determination of necessary budget and manpower, you may want to present your story documents as a series of spreadsheets indicating general locations (Swamp of Dread, Caverns of Despair) as well as specific mission areas (Lord Krygul's Palace, Lair of the Green Dragon). A similar document citing character models that will need to be created will also be useful.

Conclusion

The recurring theme in this article has been the notion of delivering content to the audience in the format that is most desirable for the reader. In this case, the craft of the writer is in great part the ability to determine what the audience needs, and to calculate how best to furnish that data.

In the next installment of Screen/Play, we're going to take a look at the process of scripted cinematics, and some of the pitfalls of this particular story delivery method. Until next time, good luck.