Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Get the latest Education e-news
 
  • Book Excerpt: Game Writing Handbook

    [07.10.07]
    - Rafael Chandler
  •  [The following excerpt is Chapter 11 - Integrating Dialogue of the Game Writing Handbook from Course PTR. Rafael Chandler is a multimedia writer with over seven years of game industry experience. The complete book includes Figures* from Chapter 11, found at Course PTR.]

    Integration

    Once the voice assets have been recorded and delivered, the development team must begin the process of integrating those cues into the game content. This process can take up much of the production stage of development, during which time other priorities will make their demands on the team. The writer must understand the scope of the integration process in order to effectively direct the flow of narrative content in the game. In this chapter we’ll discuss how dialogue is scripted into the game, and we’ll examine some of the things a writer can do to ensure a cleaner scripting process. Then, we’ll look at game localization and explore the preparations that must be made beforehand.

    Scripting

    During the scripting process the writer needs to work closely with the scripting team to ensure that they have all the resources they need to integrate the dialogue into the game. Though every studio’s methods are different, the core principles are the same. The writer should be aware of the basic functions of his project’s scripting tools and should be able to converse with scripters on the subject.

    Scripting is, fundamentally, the process of placing objects in a game world and assigning them behaviors. While AI may govern some aspects of general behavior, individual instances are governed by scripting. For example, in Rise of Merlin, all ogres will attack the player on sight. However, in level 4, the Ogre Chieftan will challenge the player to single combat and will then walk through the Iron Gates toward the player. This is not the behavior exhibited by the other ogres in the game; it was something that a designer indicated in a design document, and it was accompanied by recorded dialogue created by a writer and performed by an actor. The dialogue was placed in the game by a scripter, along with the animations for “taunt” and “walk.” The end result is an individual instance of a specific sequence of events.

    Scripting editors vary in terms of functionality and interface, but in general, they are programs that allow game designers to quickly assign behaviors to objects in-game without having to code by hand. The interface may consist of drop-down menus, or it may require the scripter to know a particular language (such as Lua), but in either case it streamlines the process of placing objects and assigning them characteristics or behaviors.

    The designer needs to consider the following aspects of the scripting process:

    Scripting team

    Scripting schedule

    Scripting tools

    Documentation

    Dialogue prioritization

    Voice cues and animation

    Triggered cues

    False awareness

    Dependent cues

    Scripting Team

    The scripting team needs to have clear, accessible information about the expected user experience. The documentation should outline precisely when and where the voice cue plays and under what circumstances. Using the screenplay, the scripters should be able to distinguish the speaker from the audience. This information can appear as part of the design documentation or in a separate document. If the data is presented in two different documents, it should be carefully aligned, because there’s a substantial margin of error if the scripters are working off of multiple documents.

    For example, in Rise of Merlin, while scripting the Dismal Forest level, the scripters are populating the map and setting behaviors from the design documentation, which was written by the lead designer. The ogres go here, the spider-gaunts go there, and the wyverns are going to attack from the north when the player enters the Holy Glade. However, when the scripters are placing dialogue cues in the game, they’re going to be working off of the story design documentation, and it’s not 100% up to date with the design documents.

    This means the writer was still working under the impression that the Dragon Queen would be waiting for the player at the glade and that the player would have to defend her from attack. Furthermore, the scripters are confused, because the voice cues coming from Merlin’s sidekick, Talerios, indicate that the wyverns are attacking from the south. This is because the wyverns originally were supposed to do so, but this was changed when the lead
    ­designer moved the Crimson Citadel to the north side of the map so that it would be visible throughout the level. This series of complications means the scripters will have to arrive at some kind of resolution on the matter; first, though, the lead ­designer and the writer must hash out the details, which might take a little time. Compromises will be made and solutions will be concocted. During this time, of course, the dialogue scripting for the Dismal Forest level will come to a halt, and the scripters will have to tackle other work. If there is none, valuable time is lost until the issue is resolved.

    To do the best possible work, the scripting team needs a cohesive and integrated document to work from. Any gray areas should be delineated in advance and should not have significant impact on the project. That means it is permissible to leave content in the hands of the scripters, but they should not be held accountable for its interpretation at that stage.

    For example, in Rise of Merlin the documentation may indicate that a group of ogres attacks a village, eliciting cries of panic from the villagers. Since the documentation doesn’t specifically indicate which lines should be playing, the scripters should be able to use any of the “panic” voice cues that were recorded for the ­villagers. If the writer wants one of the villagers to mention that her child is trapped inside their home and needs to be rescued, the writer should indicate this in the document, as opposed to assuming that the scripters will just know what to do. Scripters generally have a lot to consider during the game design process and shouldn’t be expected to anticipate story design decisions, regardless of how obvious they may seem to a writer. If it’s worth putting in the game, it’s worth noting in the design documentation.

    The documentation itself can take many forms, but if it is a text document, the writer may want to include top-down maps of key areas to clarify the location of specific conversations. The top-down map, if available, can easily be added to a Word document and can help make the details more concrete. By indicating locations of trigger zones and characters with dotted lines and Xs, the writer can help pinpoint the locations of voice cues in-game. This helps the scripters figure out where content goes, and it allows the scripter to correct the writer when necessary. If a map has changed, or if there are alternate routes that the writer is not familiar with, the scripters may be able to bring this information to his attention, giving him enough time to make revisions or adjustments to the document.

Comments

comments powered by Disqus