Screen/Play: Documenting Voice Assets

Introduction

Screen/Play is a regular feature that discusses best practices for storytelling in games. This article, the first in the series, is a continuation of ideas presented in an article I wrote last year ("Organizing And Formatting Game Dialogue", November 2005).

The article presented a format for in-game dialogue, intended to streamline the process of formatting story-related content. I call the method Screen/Play, for two reasons. Number one, you play games on a screen. Number two, it's easier to refer to story documentation as a screenplay -- I've found that if you call it a script, there's invariably some confusion about whether you're talking about scripting dialogue or the scripting of gameplay through an editor.

Future installments of Screen/Play will discuss other challenges and solutions for the working game writer.

Documenting Dialogue

The process of recording dialogue is a complicated one, consisting of numerous moving pieces: writer, designer, director, sound designer, sound programmer, producer, and voice actor. There is also the question of a shifting storyline, which is a given (unless your project is immune to changes to level design and character roster). Due to the sheer number of changes that transpire between project alpha and ship date, it's inevitable that changes to the story content will also occur, often at the last minute. This can result in re-shoots, which means wasted time and money.

Some of these complications can be ameliorated through careful documentation. This article discusses ways to organize your voice assets prior to, during, and after your voice shoot. The document format is an Excel spreadsheet, delineated below.

This article will furnish a quick overview of the Screen/Play layout, and will then cover some additional fields, formatting options, and issues with implementation.

Layout

Figure 1 shows the original spreadsheet layout presented in "Organizing and Formatting Game Dialogue".

ACTOR: The speaker (the character, not the voice actor).
CUE: The actual spoken text.
CONTEXT: The situation immediately preceding or prompting the dialogue.
INFLECTION: The character's emotional state or delivery.
LOCATION: Where in the game the dialogue is taking place.
AREA: A sub-field of location.
EFFECT: Any effects that need to be applied to the voice cue.
FILENAME: Unique name for the voice cue.

Voice Actor and Character Fields

When preparing for the voice shoot, it may prove beneficial to reformat the column that refers to the speaker. By renaming the Actor column to Character, and adding a Voice Actor column, you may be able to streamline the process of getting content into the voice actor's hands. Figure 2 shows the new field.

Here, we've added the Voice Actor and Character fields. Note that two different characters are played by the same voice actor. By using the drop-down menu for the Voice Actor, you can filter out all characters voiced by other actors. Filtering the list in this way can make it easier to estimate line counts, and to verify the number of roles voiced by a single actor (depending on the arrangements, you may find that your voice actor can only voice a certain number of roles for a given fee).

In addition, by filtering the list, you can print out all speaking parts from a given voice actor at one time. It's useful for the voice director to have all dialogue in hand, but an actor generally only needs his or her lines. Admittedly, it's good to know what the other characters are saying in a conversation, but that leads us to the Trigger field.

Context and Trigger Fields

Depending on the complexity of your game's narrative, you may want to divide the Context field into two fields: Context and Trigger. As delineated above, Context establishes the situation for the voice actor. By adding the Trigger field, you can use the Context field to describe what's going on, then use the Trigger field to indicate exactly what's prompted the character to speak.

For example, see Figure 3.

In the above examples, the Context field indicates the general situation (firefight), which tells the voice actor that the overall tone and mood of this scene is hectic and loud. The Trigger field describes a series of specific situations that fluctuate in intensity. One's a panicked exclamation, one's a sarcastic aside, and one's a battlefield command. By outlining the individual Triggers, you convey just a little more information to your voice actors, further improving your chances of getting the delivery that you want.

Line Choice Field

Once you're in the studio and the voice actors are recording their lines, you're probably going to have to choose between numerous takes. Your actors will probably record at least two or three takes for each line of dialogue, just to ensure that you get one that really fits with your game's vision.

Depending on how many people are involved (writers, designers, producers, directors), you may wind up with conflicting ideas about which particular take was the best. There are numerous conflict-resolution scenarios that you can employ, which I leave to you (although I personally favor "Two men enter, one man leaves"). First, you'll want to know which takes were favored.

In the Line Choice field, you allot a small amount of space for handwritten picks. Figure 4 shows the Line Choice field.

Unnecessary Fields

This brings us to the idea of unnecessary fields. Not everyone involved with voice recording is going to need access to all of the fields. For example, voice actors don't really need to see the Filename field, or the Line Choice field. These aren't relevant to their work. So, once you've got a master list, and you're ready to begin the recording process, you may want to create customized printouts for your principal players.

For voice actors, I've found that the CHARACTER/ CUE/ CONTEXT/ TRIGGER/ INFLECTION layout, illustrated in Figure 5, works best:

The Character field is important, because a single voice actor can perform numerous roles at a single voice shoot. The Cue is the line of dialogue that's being spoken, so that's obviously vital. Context and Trigger explain the scenario, and Inflection guides the actual performance.

For game designers or sound designers who implement the audio files into the game's editing tool, I've found that the CHARACTER/ CUE/ TRIGGER/ LOCATION/ AREA/ EFFECT/ FILENAME layout, illustrated in Figure 6, works well:

In any case, you want to base the customized spreadsheet on the needs of the person in question. Otherwise, you deliver a great deal of useless information that clutters up the spreadsheet, robbing it of its usefulness.

However, it's crucial that you establish strong and inflexible naming conventions for your spreadsheet's file name. You do not want to accidentally copy over the master spreadsheet with one of your customized variants. Ensure that the master version, with all information and fields, is given a name clearly indicating that it's the master (voice-cues-final_master.xls). All role-specific variants should be labeled as such (voice-cues-final_voice-actors.xls, or voice-cues-final_sound-designer.xls, or whatever).

This is the kind of information that needs to be communicated to all team members involved in the voice-recording process. It's also important to establish rules regarding modifications to the spreadsheet. Changing a single line of dialogue can create a ripple effect of confusion later down the line. Any changes made must be made to the master list first, and then to all role-specific variants. You do it the other way, you get chaos, anarchy, dogs and cats living together, etc.

Formatting Text Size

You may want to adjust your text font, depending on who's going to be using the spreadsheet. For your master copy, it's likely that you'll use a smaller text size, because if it's being read on a monitor, the reader can always zoom in, and if it's being printed out, you want all the columns to appear on a single page. So, a font size of 8 or 9 is advisable.

For voice actors, you should use a larger font size. For one thing, you've got fewer columns, so you can get away with larger text. Furthermore, your voice actors are going to be reading text off a page, typically while getting into character. I've seen voice actors close their eyes, hunch over, gesture, and recoil while speaking. It adds a lot to the performance, and it's easier to do when they can look down, glance at the line of dialogue, and immediately commit it to memory. You can facilitate this process, and get a better delivery, by using large, easy-to-read text.

After you've highlighted the text you want to format, you can right-click on a cell and select Format Cells, then click on the Font tab, or you can use the drop-down menu (Format --> Cells --> Font).

I've seen spreadsheets in which the text in cells was scalable, shrinking to fit the cell in question (done with Format Cells --> Alignment --> Shrink to fit). The idea here is, you can fit more information onto a page, which can save your company dozens of dollars in paper costs a year. See Figure 8 for an example of scaled text.

Not a great idea. But it can be done.

Paper Size

You can change the paper size to accommodate additional columns, or larger font size. Click on File --> Page Setup --> Paper Size and select Legal to switch to 11"x14". Don't forget to set the page to Landscape layout (File --> Page Setup --> Landscape). Legal size paper can be particularly useful when printing the master list. For example, if you want to go over all story content with all involved members of the dev team (designers, sound designers, sound programmers, producers, and so forth), you may want to use the Legal size.

Recasting On Short Notice

You may decide to recast some of the characters. If you need to change the Actor field, or any other field, there's a shortcut that can save some time. First, you delete one of the values in a field, and add the new value. You copy the new value to the clipboard. Then you highlight all instances of the given value, and you paste.

For example, you're replacing Jack Smith with Joe Schmoe. So, first you delete Jack from one of the fields, and type Joe Schmoe. Then, you highlight Joe Schmoe and select copy (Ctrl-C). You then highlight all instances of Jack Smith, and paste (Ctrl-V). Done.

Filename Issues

When creating filenames, you want to come up with something that's easy to recognize visually. It should be concise, and it should reflect your game's level structure.

For instance, King Arthur Up In This Piece employes the following filenames:
m01-a02-art01
m01-a02-lan01
m01-a02-art02
m01-a02-gue01
m01-a02-art03
m01-a02-mor01
m01-a02-art04

Let's check out the naming convention here.

First, the game consists of a series of missions, each segmented into areas (two or three areas per mission). There are numerous speakers in each mission.

So, the above filenames indicate that they're taking place in Mission 1 (m01), Area 2 (a02), and then each filename ends with an indication of who's talking (Arthur, Lancelot, Guenevere, Morded). Since each character has less than 100 speaking parts in a given section, but more than 9, a two-digit number next to the three-letter identifier is necessary. The game's parameters dictate the naming convention, more or less.

Locating and choosing alternates

Depending on how your voice data is going to be processed, you may wind up with alternates. For example, during the recording of King Arthur Up In This Piece, we recorded the line "What's up?" three times. We went with the first take, but kept the other two just in case. The first take was named m01-a02-lan01. The alternates were m01-a02-lan01A and m01-a02-lan01B.

During playtesting, it was decided that the first take, though it sounded great in the studio, didn't sound good while playing the game. It was just flat, and didn't deliver the necessary tension. Or whatever. So we decided to plug in one of the alternates -- m01-a02-lan01B.

The two ways to resolve this scenario are:

1. Rename m01-a02-lan01B to m01-a02-lan01 -- basically, drop the B -- and copy over the first take. This is probably your best bet, provided that you keep a backup of the first take -- don't just copy over it and consign it to the abyss. You never know, you might change your mind again, and you always want to keep your options open. It could turn out that your two alternates had the emotion you wanted, but sound bad because the speaker was mumbling.

2. Keep the filename for m01-a02-lan01B, but make sure that your scripting tool and your documentation reflect the change -- the addition of the letter B. This requires meticulous attention to detail, because if your documentation doesn't reflect the change, QA might flag it as a bug. If you don't make the change in your scripting tool, then the game pulls up the wrong file, ignoring the alternate.

Outro

It's easy to overdo it by adding too many columns, or by creating too many sub-variants of the spreadsheet -- one for the producer, one for the designers, one for the testers, and so on. Rule of thumb -- if you've got so many columns that you can't print out a legible page on 11"x14", you overdid it. Scale it back. And as for the spreadsheets, you may want to employ multiple tabs on a single spreadsheet. That way, you've only got one actual file to keep track of.

Speaking of keeping track of the document, it's crucial that the document versions are controlled through a program like SourceSafe. Also, it's a good idea to appoint a single person in charge of making sure that the document is updated with all necessary changes.

Best of luck.