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.
Ubisoft's Rainbow Six: Lockdown
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 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.
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.
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 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.