Screen/Play: Documenting Voice Assets
June 8, 2006 Page 1 of 2
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.
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.
Figure 1 shows the original spreadsheet layout presented in "Organizing and Formatting Game Dialogue".
|Fig. 1: Spreadsheet Layout|
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.
|Fig. 2: Voice Actor and Character|
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.
|Fig. 3: Context and Trigger|
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.
|Fig. 4: Line Choice field|
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:
|Fig. 5: Voice Actor Layout|
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:
|Fig. 6: Designer Layout|
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.
Page 1 of 2