Game writer Rafael Chandler (MAG: Massive Action Game, Ghost Recon series) introduces the concept of 'narrative postpartum', mapping out a post-ship look at your game's narrative.
[Veteran game writer Rafael Chandler (Cipher Complex, MAG: Massive Action Game) continues his Screen/Play series by introducing a new concept, the Narrative Postpartum. Designed to help development teams evaluate the success of their storytelling in games and improve it moving forward, the postpartum resembles a postmortem -- but with its own important nuances.]
Finally, your game has shipped. All the hard work has paid off. You've confronted obstacles, resolved them, established lines of communication with your fellow developers, hit your milestones, and put in the long hours. Soon, your game will be available for purchase. Your creation will join the ranks of all the games that entertained and delighted you over the years.
Naturally, you want to compare your a game to a corpse that awaits dissection.
Wait, what?
The postmortem can be defined as the analysis which follows the conclusion of a process; in our case, it refers to the discussion of a shipped title. The term is obviously quite ghoulish, drawing a connection between the evaluation of your development process and the examination of dead body to determine the cause of death.
However, the term isn't really appropriate. After all, we're collaborating to bring an experience into the world. Our creations live on, frequently surviving the very companies that brought them into being. Consequently, it's more logical to use the term postpartum -- which refers to the first few weeks following birth.
The narrative postpartum is a discussion which involves all members of the team who contributed to the creation of a game's story design. The meeting can include writers, designers, creative directors, audio team, producers, programmers, and artists. Anyone involved with the production of cinematics, dialogue, casting/directing voice actors, or mission/scenario design should attend.
Like all productive meetings, the narrative postpartum should be led by one person, armed with a specific agenda and a list of discussion topics. Ideally, this should take place after the game has been released.
At this point, it's understandable that developers will want to focus on the next project, but a successful postpartum can result in dramatic improvements in your process -- improvements that will remove many obstacles from your team's path.
The discussion topics should be approached objectively. It's not necessary to point the finger of blame, or to praise individuals.
The point of the discussion is to establish facts and data, and it's therefore recommended that you focus on roles instead of personnel. It's a good idea to phrase commentary in the passive voice.
Instead of pointing out that "certain artists weren't able to finish their single-player maps on time, resulting in changes to the story," it's better to say that "the single-player maps weren't completed in time, resulting in changes to the story." This removes the sting of accusation, and makes it easier to just lay facts on the table and move forward, rather than debating the party at fault.
The postpartum should commence with an analysis of the game itself, using empirical evidence (such as reviews, articles, and user comments) whenever possible. Next, the team should examine the development process, with a focus on team interaction. Finally, a list of action items should be drafted.
The postpartum analysis should focus on the way that your game turned out. Before the meeting, you'll want to gather data from multiple sources, including reviews, customer reviews, and message board posts.
Reviews, both online and print, are an excellent source of feedback. Though you may have mixed feeling about a particular magazine or web site, if the overwhelming majority of reviews dinged your game for lackluster voice acting, then it's worth paying attention.
User reviews, posted at sites like Amazon, can also give you man-on-the-street perspective of a typical customer.
Again, while an individual post can be dismissed, if the vast majority of comments indicate that the story was below (or above) expectations, it's worth collating the data and bringing it to the meeting.
Message board discussions are sometimes worth investigating. It's likely that your studio or publisher offers forums where users can heap praises upon you (or vent their limitless fury); there may also be fan sites, though a lack of formal moderation may render such message boards unusable for your purposes.
If a purported fan site is in actuality a piranha-infested pit of vitriol, skip it. You're looking for constructive feedback, not abuse.
At this point, it is important to note that the aggregated review information you're gathering is not to be treated as a road map for the development of future games; it is instead to be considered a starting point for the discussion that will ensue.
Key areas to consider include: storyline, dialogue, cinematics, voice acting, and character development.
Once the data has been assembled, it's important to collate and organize it into digestible chunks. If the meeting begins with a group of developers fumbling through a long printout of various comments, the postpartum analysis will be derailed before any progress has been made.
The data should include essential metrics: percentage of reviews that cited cinematics (followed by a breakdown of positive mentions versus negative), percentage of reviews that cited voice acting, and story, and so forth.
If there are quotes that you can pull from various reviews in order to support the analysis, so much the better, but it's best to focus on positive quotes.
The combination of nerd rage and a well-placed bon mot can do much to demoralize a team, particularly after the rigors of crunch mode have exacted their toll on the team. Keep it focused, keep it positive. After all, if the voice acting was really all that bad, chances are everyone knows it already.
These are a few of the key questions that should be addressed and discussed before moving on to a discussion of the development process:
How was the story received?
Did the cinematics achieve the intended goals?
Were the characters well-received?
Did the players understand the story?
Was there any kind of emotional response to the game's narrative content?
How did the players enjoy the voice acting?
What was the response to the dialogue?
Did the cinematics propel the story forward?
Not all of these questions will be applicable, depending on the type of game that was developed, but this is a decent starting point.
During this stage, you'll discuss the process of story development, from concept to recording. Essentially, this is a list of questions, or topics of discussion. Again, brutal honesty is called for, but finger-pointing will only serve to impede the conversation.
Rambling discussion, or the dissection of trivial minutiae (such as the effect of a single line of dialogue) will also do little to advance your cause.
Focused and impartial moderation is essential in order to keep the meeting moving forward in a constructive manner. If one such topic hits a nerve, consider tabling it for a follow-up meeting and proceeding with the matter at hand.
These are only five possible areas of discussion, but each project will have its own list of questions. Consider these a starting point for your postpartum:
Story design: developing the storyline, characters, and concept
Screenplay: writing and evaluating dialogue
Documentation: the way that story documents were presented to the team
Cinematics: creating and integrating non-interactive sequences
Voice acting: casting and recording voice actors
Story design
How successful was the narrative within the context of the brand or series parameters? If this was a new IP, was the game successful in firmly establishing the core concept? Was there sufficient time during pre-production to evaluate and improve on the core storyline?
Did the game's plot mesh well with the overall feel of the gameplay? How integrated were audio and design? Was there sufficient contact between the writer(s) and the audio team? Was the plot coherent? Did everyone on the development team know what the game was about?
Screenplay
What were the overall goals for the game's screenplay? For example, was it supposed to be funny? How closely did the final draft of the screenplay resemble the stated goals? Was the screenplay successful in eliciting the desired emotions?
Was there a frame of reference for the screenplay? For example, a game of medieval fantasy might have established the Lord of the Rings trilogy as a frame of reference for dialogue. Did the game measure up to the frame of reference?
Often, during development, lines of dialogue must be cut because of design changes, necessitating the use of alternate lines, which are often more generic or vague (to make them more utilitarian during those hectic last days of production).
For example, the line "We need to attack the wizard! He's casting a spell on us!" would be obviated if the wizard were removed from the game (which could be the result of a design decision, or of the character artist being unable to complete the character model in time, or of some other factor). If the wizard were replaced with a group of trolls, then in an ideal situation, there would be an alternate line that specifically referenced those trolls.
But in all likelihood, no such alternate was recorded, because the writer couldn't foresee those changes when the screenplay was written. Instead, it's more likely that a generic line like "Attack!" was written. So -- were enough alternates created?
Was there enough variety in the alternates? Did the design team present the writer with various risk scenarios, providing the writer with enough information to come up with a robust list of alternate lines?
What was the feedback process like? When the writer submitted deliverables, were they reviewed in a timely fashion? Did everyone on the team know who would be responsible for providing feedback?
Was someone in charge of moving the review process forward and getting the feedback to the writer? Was the feedback explicit and framed as a series of action items, or was it vague and subject to interpretation?
Documentation
Was the story documentation thorough? Did all necessary parties know where to find it? Was it easily accessed in some central location? Was it updated in a timely fashion?
Was it coherent, or was it presented as a series of half-finished documents? How was version control handled? Who was responsible for updating story documentation?
Cinematics
Were the cinematics developed internally or externally? How did this approach work out? What was the quality of the final cinematic sequences? Did they convey the necessary story/character/emotional elements? How were assets (screenplays, storyboards) delivered to the cinematic team?
Did the writer have any connection with the cinematic process? How were the cinematics reviewed? How did the team determine whether the cinematics were exactly what the developers wanted? Did the cinematic artists understand the game's story and concept? What was the approval process for the cinematics?
Voice acting
What was the casting process like? Was the development team sufficiently involved in the process? How were the casting documents written? Was there adequate documentation in the casting docs? How much of the game's screenplay was made available during the casting process?
During the voice recording sessions, was anyone from the development studio present? Were any of those developers directly involved in the story creation process? Was there enough time at the beginning of each session for the developers to explain the core story and character information to the voice actor? How much input did the developers have during the direction of the voice actors? How was the voice director chosen?
After the postpartum discussion, it is critical that you document the resulting action items. If the discussion ends without a plan for action, then the meeting will amount to little more than an airing of grievances, serving no actual purpose.
The list of action items needs to include the necessary action, the role of the developer, and the justification or desired result of the action item.
The necessary action must consist of a demonstrable action, written as a concrete noun-and-verb directive. If the action item begins with "Explore the possibilities of...", then the action item is worthless.
It's impossible to say whether someone has explored something adequately, and this sort of action item only hampers the development process. A successful action item is something that can be measured or demonstrated, such as:
Work with audio team to create new format for screenplay documentation
Serve as sole point of contact for feedback to cinematic team
Supervise development of casting docs and voice acting auditions
Next, the action item needs to be assigned to a role. Assigning the action item to a specific person is risky, as the developer in question may leave the company, or be promoted, or move to another position on the next project.
Instead of assigning the action item to Jimmy, assign it to the Story Designer. It's important that each action item be assigned to a specific role, so that it's known in advance that someone is going to be accountable for making sure that it's taken care of.
Finally, the justification or desired result needs to be specified, even if it seems perfectly obvious. The justification serves as an explanation to anyone who wasn't present at the postpartum, such as new hires. For example:
Serve as sole point of contact for feedback to cinematic team (prevents confusion, saves time, and makes it easier to establish clear lines of communication)
Once the action items have been drafted, they need to be documented and archived, because all future games at the studio can benefit from this kind of information.
After that, the documents should be forwarded to the producer of the studio's next game, so that he or she can disseminate the action items to the developers, once people have been assigned to the various roles.
This is no easy task. It requires objectivity, and it is a time-consuming process. However, it empowers future development teams, and ensures that past mistakes will remain in the past, where they belong.
---
Photos by Gabor Cselle and ArtemFinland, used under Creative Commons license.
Read more about:
FeaturesYou May Also Like
