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).