Sponsored By

Red Storm writer/designer Rafael Chandler (Rainbow Six: Lockdown) discusses processes and systems that will help a game writer minimize dialogue change during production, and analyzes some of the dependencies that a writer can account for along the way.

Rafael Chandler, Blogger

November 18, 2005

26 Min Read

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.


rainbow-6-lockdown.jpg

Ubisoft's Rainbow Six: Lockdown

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.

Passive Format

Well, enough about them, let's talk about us.

Much game content is written in what I term the "passive format" (because it works best in situations where the player is a passive spectator, such as when watching cinematics), which resembles the format used by movies and television shows. This script is formatted in such a way that it streamlines the filmmaking process -- Courier New font, wide margins, use of all-caps, lots of white space -- it's easy to mark up during filming. See Fig.1 for an example. Script supervisors use the margins and white space to make necessary adjustments, and the large font and capitalized words make it easy to locate content in a hurry. This is a result of the way that movies are made.


fig1-passive.JPG

Figure 1. Passive Format

In the game industry, the use of the passive format is less appropriate. Most games are nonlinear enough to render the passive format inappropriate. If we rely on the Hollywood rule of thumb that one page of script equals one minute of screen time, then theoretically, a twenty-hour game would require a script 1,200 pages long -- at which point a sane person says, “Hell no.” On the other hand, if the passive format is used to create non-interactive content, such as in-engine or pre-rendered cinematics, the passive format still seems like a bad idea. The pre-rendered cinematic isn't filmed in real-time, it's created over days or weeks, usually by a number of people including artists, animators, and at least one producer or designer. Therefore, a format created to facilitate rapid changes on the fly just doesn't fit the process of cinematic creation. The white space, the large font -- these serve no discernable purpose in this context.

However, if the intention is to create a text-based narrative (as opposed to a visual narrative structure, such as the use of sequential storyboards), then a modified version of the passive format can be of some use. By removing all of the marginal formatting, and by using a more efficient font (like 10-point Times New Roman), this format can be useful. See Fig. 2 for an example.


fig2-passive-revised.JPG

Figure 2. Passive Format Revised

Active Format

Oddly enough, an accounting spreadsheet can be a writer's most effective tool. I use Excel to keep track of my dialogue, as do many writers. It's particularly useful when preparing "active format" dialogue (any dialogue taking place in-game, where multiple variables can make it a challenge to keep track of all possible dialogue threads).

Taking into consideration all of the aforementioned dependencies and relationships, as well as the limitations that I've encountered when using passive format, I've come to rely on the following structure (see Fig. 3 for details):


fig3-active.JPG

Figure 3. Active Format

Before I address the individual headings and content, a few notes about the format:

I always highlight all cells with data and create a visible grid around them. If you're new to Excel, note that the cells with no text inside them feature a faint gray grid. This is visible when using the program, but doesn't appear when the document is printed (making it harder to read). This is the default setting, so you'll want to create the grid around any cells with content. See Fig. 4 for details.


fig4-grid.JPG

Figure 4. Grid

By highlighting the cells across the top (Actor, Cue, etc.) and selecting Data-->Filter-->Autofilter from the menu, you can add filters to your headings. This will enable you to select specific kinds of data from the fields. See Fig. 5 for an example.


fig5-actor-filter.JPG

Figure 5. Actor Filter

If, as in the above example, your spreadsheet is arranged chronologically, it will feature various actors talking to one another. But if you want to isolate a single actor, you simply click on the small gray box in the Actor field and select that character's name. The same functionality can be applied to the other fields.

It's best to use the landscape format when setting up your page. This way, rather than print each row on multiple pages (Actor/Cue/Context/Inflection on page 1, Location/Area/Effect/Filename on page 2), you get the whole row across a single page. You can set this up by selecting File-->Page Setup/ Page-->Landscape. You'll see in the example below (Fig. 6) that the dotted lines indicate that the page will still be cut off at the end, and the spreadsheet will bleed over onto a second page. I'll need to adjust some of the row widths in order to get the spreadsheet to print on a single page.


fig6-landscape.JPG

Figure 6. Landscape

Headings

Now, onto the individual headings.

ACTOR: In this area, list the speaker. It's best to keep this as terse as possible -- don't abbreviate to the point of being incomprehensible, but a last name will suffice, if one's available. Make sure that you maintain consistency throughout the document. If you refer to a character as Jason in mission 2, don't start referring to him as Jason Caldwell or Mr. Caldwell in mission 4. You want to be meticulous in your search for typos in this field. If you misspell a name, then try to use the filter to select all of Jason's lines, it's not going to include “Jasson” in that search -- and any dialogue attached to that typo won't appear in the filtered search.

CUE: In this field, you type the actual spoken text. Keep the parenthetical notations out of this field, if possible. Save them for the context field. Here, the actor wants to see raw text, not text accompanied by "(sadly)" or "(yelling)."

CONTEXT: Here, you indicate the context for the line to the person reading the dialogue. It's best to keep this as terse as possible; chances are, the reader knows the basic setup (superheroes under attack in a bank lobby). The situation immediately preceding or prompting the dialogue is the issue at hand, and that's what you want to convey in this field. A.I. responses may also work in this column. For example, if your game plays a death scream when the “player_dead” A.I. state is invoked, then you may want to put "player_dead" in this column, along with a note for the voice actor who will be doing the screaming. Or, you may want to split this into two columns: one for the actors, and one for the developers who will be integrating these assets into the game (scripters, programmers, and so on).

INFLECTION: In this field, you indicate the emotional state to the actor. The primary use of this field (other than the obvious) is to keep the volume level consistent across the various cues. Voice actors can read over 200 lines in a single session, and that can take its toll on the vocal chords. If you want to get the most out of your voice-over, and if you want to do your voice actors a favor by making their jobs easier, you can group cues together by volume. For example, start with whispers, then have the actor deliver all conversational tones, then proceed to any yelling or death screams (it's always fun/creepy to hear a grown man shriek like he's being eaten by sharks). It's best to keep an eye on the number of individual Inflections. You don't need to get creative with your adjectives; "angry" is good, you don't have to describe the next cue as "furious" or "enraged" in order to avoid repetition. In fact, repetition is good, in that it's easier to use the Sort function (Data-->Sort) to lump all the "whispered" cues together, then the "normal" cues, then the "angry" cues. Just picture yourself as an actor, trying to guess the developer's intentions. Unless you're going to direct the voice acting yourself, do your best to give the voice actor a specific emotional state for the inflection. Any additional material should go in the Context field.

LOCATION: Here, indicate where in the game, the dialogue is taking place. This will vary, depending on what type of game you're working on. For example, in a wide-open game like Morrowind or GTA, you might indicate a type of environment (indoor shop). For a more structured game, like a mission-based shooter, you might indicate Mission 2, Tenement Building.

AREA: For the Area field, I always enter a number that can be sorted easily, or arranged chronologically without too much fuss. It makes it easier to answer questions if someone asks how many voice cues Character X has in mission 3. But, again, it depends on what kind of game you're working on, and how rigidly structured the game experience is. You may find the Area field to be superfluous, or you may add more fields to the spreadsheet. If your game is split up into multiple areas and levels and sections, additional columns may be necessary.

EFFECT: Here, I indicate any effects that need to be applied to the voice cue. This includes radio futz, echoes, distortion, and so on. It's something that can be filtered at the end of the process, and handed off to the sound designer or programmer, in order to streamline the process for him/her. It can also be used by QA to ensure that all applicable effects have been added to the game. And it's also good for voice actors, because there's a difference between yelling across a freeway at someone, and yelling into a radio. The additional contextualization can help during the recording session.

FILENAME: Once you've got a handle on how many voice cues you're going to be working with (dozens, hundreds, thousands), you can start to plan your naming convention. If you're lucky, there's a convention in place. Otherwise, you may be the person responsible for creating one. I've found that the best process is to create a convention that A) is easily sorted in chronological order, B) tells the reader where the cue appears in-game, and C) leaves room for the additional cues that inevitably get recorded in pick-up sessions.

The single biggest advantage to this process is that it accounts for the nonlinearity that drives pretty much all gameplay. The passive format reads like a movie script, and is suited to a linear experience such as a cinematic, but it's just not well-suited to in-game dialogue.

Conclusion

There's not much left to say except that the driving principle behind all of these examples is: communicate, learn, plan, organize, and execute. By familiarizing yourself with all the moving parts, you're more likely to create the emotional, story-driven experience that we're all aiming for. In order to protect the integrity of your story and characters, you need to anticipate the myriad complications that arise during development, and you must be flexible and creative in your solutions to these issues.

Best of luck.

______________________________________________________

 

Read more about:

Features

About the Author(s)

Rafael Chandler

Blogger

Freelance game writer Rafael Chandler has worked for Sony, Sega, Ubisoft, Electronic Arts, Zipper Interactive, Slant Six Games, Edge of Reality, SouthPeak Games, and 1C Company. His games include Cipher Complex, MAG: Massive Action Game, SOCOM: Confrontation, Ghost Recon 2, Rainbow Six: Lockdown, Ghost Recon: Advanced Warfighter, and three unannounced projects currently in development. He also writes comic books, tabletop role-playing games, and horror fiction. His book, The Game Writing Handbook, was a finalist for the 2007 Game Developer Front Line Awards. For more information, please visit www.rafaelchandler.com.

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like