|
Worst-Case Scenario
Here's
the deal: two weeks before your game hits beta, the lead designer on
your project adds some new functionality to the game. In addition, some
of the pre-rendered cinematics are changed. Nothing major, just a few
cuts and additions here and there. All this requires you, the writer,
to create some new dialogue for various characters in the game,
including the protagonist, some of the bad guys, and some allies. No
problem. You hammer out the dialogue.
Problem:
You created a new document for this additional dialogue. But you didn't
add the text to the master spreadsheet that Quality Assurance has been
using, so they cite these new lines of voice-over as bugs. Because the
producer also uses the master spreadsheet (which you didn't update),
these new lines aren't sent to the localization company, so they don't
get translated on time.
Some
of the filenames that you assigned to these new cues have already been
used in an earlier voice shoot, so there are problems when the game
tries to pull up a cue and finds itself with two conflicting WAV files
to choose from. This crashes the game.
Because
you weren't onsite to direct the voice shoot, the actors decided that
"Then just kill me!" was a tough, gritty line (not the smart-alecky
punchline you intended). They didn't have any context to work with
(other than voice notes indicating "delivered in a loud tone of
voice"), so they did the best they could, but the mood of your
cinematics is ruined, and the line has to be cut. This obviates the
lip-synch work that was already put in, but there's no way around it.
You
added some conversational lines, basically ambient noise, to a barroom
scene. But you put them at the end of the document. When the voice
actors got to these lines, they'd already delivered their death screams
and combat yells, and when they got to the new dialogue tacked on to
the end of the shoot, their voices were hoarse and nearly inaudible.
Unfortunately, all of the other conversations in this part of the game
were recorded at earlier shoots, and sound completely normal. So in the
game, when the player enters the bar, some of the patrons suddenly
sound hoarse and ragged, then normal, then hoarse again. The effect is
odd and jarring.
Could
any of this have been averted? More and more developers are formalizing
their processes in an effort to mitigate the crises that arise during
production. Game writing is a technical discipline as well as a
creative one, and it is vital for a writer on a project to focus on how
his or her work will impact the rest of the development cycle.
In
this article, we'll talk about some processes and systems that will
help a writer minimize the impact of changes during development, and
we'll discuss some of the dependencies that a writer can account for
along the way.
These
processes can help you minimize the stress and hassle of creating story
content for your game. They can also save your project time and money,
which is presumably one of your goals, if for no other reason than an
urge for self-preservation (studio saves money, you don't get laid
off). They can also protect the integrity of your storyline and
character development by ensuring that key lines and scenes are not
hacked out of your game at the last minute because of the
aforementioned issues.
Oh, By The Way
This
article is geared towards beginning or intermediate writers. If you've
been around the block a couple times, this will probably seem like old
hat, but you might find a few tips in here that'll help you out.
And as for me, I'm a writer/designer at Red Storm Entertainment, where I've worked on Ghost Recon 2, Rainbow Six: Lockdown, and Ghost Recon: Advanced Warfighter. For Lockdown, I wrote over 7,000 lines of dialogue and directed a cast of two dozen voice actors.
Development
When
writing games, it's helpful to understand the basic structure of the
development cycle, and to have an understanding of the various key
players on your team. You may or may not work with these developers --
it's possible that you'll be sitting next to the lead engineer for the
duration of the project, or that you'll be working as a contract
employee hundreds of miles from the office, communicating with the
producer via phone and email. In either case, the work that you do will
pass through the hands of designers, programmers, artists, and
producers, each of which has an agenda and a scope of work. By studying
the ways in which these team members interact with your work, you can
save them a lot of grief. Or, you can do the opposite of what I
suggest, in which case you can add to their grief. Which is cool, they
probably had it coming.
Bear in mind that each project is structured differently, and that roles and responsibilities vary from company to company.
Designers
Designers
are responsible for developing the core gameplay concept, whether it
originates with them or gets handed down by production or management.
In any case, the game designer will have some input with regard to the
storyline, setting, and level structure.
The
game designer will also have some awareness of franchise restrictions,
and will probably have some degree of input over the dialogue that you
write, which may vary from comments and suggestions to flat-out veto.
In either case, the designer may well have the most coherent vision of
the overall game's feel and concept, and can be a valuable resource.
As
the game evolves through the course of production, the game designer
may revise portions of the game, including level design, character
rosters, and the sequence of events. This will all have a serious
impact on your work as a writer. For example:
You're
working on a superhero game called “Justice Unit.” The third mission
begins in a bank vault, which your super-team is defending against the
threat of an attack. The current mission design calls for a minute-long
delay before the supervillains attack. During this time, one of the
player character's teammates fills him in on Overcharge, the evil
supervillain who's planning on attacking the bank. Overcharge is driven
by his massive ego, he thinks that he's outsmarted Justice Unit, he
won't be expecting us, blah blah blah.
Oh,
and his weakness is that his mechanized suit of armor slows him down,
but he becomes more powerful as he leeches power from the super-powered
beings around him. So, hit him hard and fast, because the longer the
fight lasts, the more dangerous he becomes. This is all mixed in with
banter from other teammates and nervous chatter from the security
guards -- the idea being that this will heighten the tension, resulting
in a nerve-wracking wait for the inevitable attack.
During
playtesting, it's decided that the bank space is too small to
accommodate a huge fight with multiple opponents. Also, the minute-long
wait isn't nerve-wracking, it's boring. So, the designer instead opts
to set the battle in the city streets, outside the bank. The fight
takes place right after the robbery, and the Justice Unit are tasked
with apprehending the bad guys. The load screen gives way to
Overcharge, thudding down the street in his armor, clutching burlap
bags with dollar signs on them.
This
invalidates all of the dialogue that's been written. No time for
banter, character development, tension, or that key piece of
information about how to win this fight. You can scrap most of this,
but the hint for the player needs to go in. But you can't just copy and
paste the text, you've got to shorten it, make it a quick burst of
information that the player hears as she's/he's diving into battle.
Designers
create gameplay, writers contextualize it. If possible, maintain close
contact with the designers on your project, as their work is most
closely tied in to your own.
Programmers
Writers
and programmers don't usually interact all that much, but there are
several key conversations that they can have, which will save time and
money in the end.
In
any game, there are various technical restrictions that must be taken
into consideration prior to writing dialogue. For example, if your
voice cues are streamed from the game disc, you need to know how many
simultaneous audio streams can play at a given time. On one console, it
may be possible to stream twenty simultaneous sounds; on another, the
system might only accommodate five sounds at one time. If you factor in
ambient room tone and music, that only leaves three tracks. Add sound
effects and the report from a gun, and suddenly there's room for just
one audio track of streamed voice.
If
you're working on a superhero game like Justice Unit, and you want to
include cries of surprise from stunned onlookers, yells from bank
robbers, and dialogue from your super-powered teammates, you need to
know what the parameters are prior to starting work. Your vision might
require adjustment based on the restrictions of your code base and
choice of platforms.
Communication
with your programmers can help resolve issues before they manifest
themselves; for example, you may employ a hierarchy of sounds based on
priority. If multiple voice cues play simultaneously, cues from the
player's team should be given first priority, as they convey useful
information. Cues from civilians on the street should be given low
priority, as they're just ambient noise to flesh out the game world. If
your programmer knows what's crucial to the story (early in the dev
cycle), it's more likely that the game will deliver the kind of audio
experience that your story requires.
If
your project is multi-platform, you need to know the parameters of each
SKU, with the understanding that you may not be able to put all the
voice cues in this version here, but on the next-gen or PC version, you
can pretty much do it all -- which means that you'll want to record
voice cues for all contingencies.
Artists
As
a writer, your interaction with artists will depend on how involved you
are with production. Three areas in which you'll probably rely on
artists for information or materials are character models, level
creation, and cinematic sequences.
If
you're involved in the character creation process, you'll no doubt have
your own opinions about the appearance of the characters in your game:
how they look, how they move, what they wear, and so on. It's best to
have a flexible vision, since you're part of a team, but any ideas you
bring with you should have some support. If it's your job to determine
what the characters look like, any reference images you can furnish
will help get the point across. If you're hoping to give an evil
character some visual impact, describing him as "menacing" just isn't
going to do it. Focus on concrete details.
During
the level creation process, you may have some input, which would be a
good opportunity to find places to work in the kind of in-game dialogue
that creates personality among your characters (if that's a design goal
for your game). The aforementioned scene in the bank didn't work out,
but doubtless another chance would have presented itself during a lull
between fights. However, the artists are more likely to give you such
opportunities if they know that you need them. For example, if the
level artist knows that you need a scene at the beginning of mission 8
to establish that Ice Queen is losing her powers (creating problems
later on down the line), then that artist can create an alleyway long
enough for all the necessary voice cues to play without interruption.
It's hard to build character and personality when the voice cues are
suddenly cut short by an explosion or gunfire.
The
creation of cinematic sequences may require storyboarding or animatics,
in which case you might find yourself partnered up with a concept
artist. While working on storyboards, it's important to know what's
possible beforehand. If you're working in-engine, you may have to work
with whatever assets have already been created -- character models,
levels from existing gameplay, vehicles, and so on. If you're hoping to
use a specific asset, such as a character model from mission 12, find
out when that is scheduled to be created. If it's not going to be ready
for a few weeks, but work has to begin on cinematics soon, then there's
no point in building your cut scene around that character. It's not
going to work out in the long run unless the character artist's
schedule is rearranged.
The
same principle applies to pre-rendered cinematics, but the limitations
may be more budgetary than anything else. It's not uncommon for
storyboards to undergo repeated revisions in order to come in under
budget. Understanding what the limitations are, then working within
them, will save you the trouble of multiple meetings. If there's no
limit on the budget, what the hell, throw in some explosions and maybe
some bullet-time stuff. Ninjas, pirates, all that stuff.
Producers
Producers
deal with budgets and schedules and submissions. Learn to speak their
language. Be organized and meticulous, and don't allow the story
process or the voice recording to become a burden on your producer. If
you want to keep valuable character-building scenes from being cut, be
flexible and understand the realities of development.
The
more organized and thorough you are, and the more contingencies you
have taken into question prior to presenting your work for approval,
the more likely you are to achieve your creative goals. For instance,
if you tell your producer that there will be 60 speaking roles in your
game, she/he sees a large, complex, and expensive process. If you say
that you've assigned multiple roles to each actor, taking line count
and accent into consideration, and you'll require 20 voice actors to
play the roles delineated in your spreadsheet, your creative vision has
a better chance of survival.
Producers
deal with ever-changing parameters. Learn to adjust accordingly. If the
team decides that cutting the bank lobby scene is going to result in a
better game, then work with that new vision. Focus on keeping the vital
information (the voice cues that tell the player how to defeat
Overcharge), and create new lines that convey this data to the player
succinctly (since you don't have the benefit of the slower-paced bank
lobby scene anymore). Then, find a way to work the banter and character
development into another scene.
Your
producer has a bird's-eye view of the project, and can often answer
questions about who to talk to, or how to resolve a technical issue. Be
cool to the producer.
|