|
 Features
Screen/Play:
Technical Narrative Design
 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).
|
|
|
|
|
Previous