A Reusable Scripting Engine for Automating Cinematics and Cut-Scenes in Video Games

1. A Reusable Scripting Engine for Automating Cinematics and Cut-Scenes in Video Games M. McLaughlin and M. KatchabawDepartment of Computer ScienceThe University of Western Ontario

2. Outline • Introduction • Story Scripting and Scripting Languages • Reusable Scripting Engine Design • Prototype Implementation • Results to Date • Concluding Remarks

3. Introduction • Storytelling is widely recognized as an important element of modern video games • For games that are dependent on their story elements, the level of quality required for their story at least equals the need for quality in graphics, audio, and other aspects of the games • Consequently, it is important to ensure thereare sufficient supports for storytellers to beable to effectively and efficiently tell theirstories with games

4. Introduction • The current state-of-the-art typically requires programming background or expertise to provide story elements to games • This is usually outside the realm of most storytellers • As a result, implementing stories in games tends to require storytellers to rely on programmers • Can be costly, prohibitively so in some cases • Possibility of communication and programming errors • Potential loss of direct and total control of the story, affecting the creative process and overall story quality

5. Introduction • To assist storytellers, tools and supports arenecessary to allow them to tell their stories with minimal, if any, programming required • The storytellers are given a simple and natural way of expressing their story • Automation prepares this content for presentation within the game with little or no human intervention • This is the intent of our current work, a Reusable Scripting Engine • Our current focus is on story content for cinematics or cut-scenes, as opposed to in-game story elements

6. Introduction Screen shot from Trauma Center: Under the Knife

7. Story Scripting and Scripting Languages • To automate the presentation of story elements from a story, the original story needs to be scripted in such a way that it can be easilyacted out on-screen • This scripting must identify characters, dialogue, stage directions, setting, and other elements common to traditional dramatic pieces • This scripting will also need to be precise and formal enough for it to be easily processed and understood by the software automating the presentation

8. Story Scripting and Scripting Languages • Fortunately, the Text Encoding Initiative (TEI) has developed an XML-based specification for marking up all different kinds of texts, including dramatic pieces • Since XML is not necessarily the most natural platform for storytellers writing stories, several tools have been developed according to TEI guidelines for importing existing works or writing them from scratch

9. Story Scripting and Scripting Languages • In the end, we could not completely follow TEI guidelines, and had to derive something with some modifications and extensions • TEI guidelines are incredibly detailed and require information that does not quite make sense in ourtarget application • Several elements in the TEI guidelines are not formal or precise enough yet for our purposes • We needed additional elements to link content and assets into story scripts • For example, consider the following …

10. Story Scripting and Scripting Languages <performance title="Battle of Wits"> <!--Information about the graphical elements of the play--> <header> <!--Cast of characters and props--> <castList> <character id="vizzini"> <name> Vizzini </name> <!--Character models defined for this character. The first model is designated the default model--> <availModelList> <model id="defaultViz" location="c:\performances\bow\models\vizzini\default.bmp"/> <model id="vizziniDrink" location="c:\performances\bow\models\vizzini\drinking.bmp"/> <model id="vizziniLaugh" location="c:\performances\bow\models\vizzini\laughing.bmp"/> <model id="vizziniDead" location="c:\performances\bow\models\vizzini\dead.bmp"/> </availModelList> </character> … </castList> … </header>

11. Story Scripting and Scripting Languages … <dialogue speaker="vizzini"> <line>Well, I- I could have sworn I saw something.</line> <line>No matter. First, let's drink.</line> <line>Me from my glass, and you from yours.</line> </dialogue> <stageDirection> <costumeChange characterID="vizzini" model="vizziniDrink"/> <costumeChange characterID="westley" model="westleyDrink"/> <pause duration=“3”/> <costumeChange characterID="vizzini" model="defaultViz"/> <costumeChange characterID="westley" model="defaultWest"/> </stageDirection> <dialogue speaker="westley"> <line>You guessed wrong. </line> </dialogue> <stageDirection> <costumeChange characterID="vizzini" model="vizziniLaugh"/> </stageDirection> ...

12. Reusable Scripting Engine Design Script Storyteller AuthoringTools ScriptReader User Director StageManager Display Reusable Scripting Engine

13. Reusable Scripting Engine Design • Director • Manages script reader and stage manager tooversee the entire production • Provides playback control to the user, which couldbe the application the engine is embedded in • Script Reader • Reads in the script and processes it • Verifies correctness and completeness of script • Generates a collection of stage actions from the script, creating a performance, and gives this performance to the director

14. Reusable Scripting Engine Design • Stage Manager • Responsible for generating the actual on-screenperformance of the script • It receives its direction on what to do and how to do this from the director • It also reports back to the director on the statusof the production

15. Prototype Implementation • Based on this design, a prototype has been implemented for Microsoft Windows XP, written in C++ in Microsoft Visual Studio .Net • XML processing was implemented usingMicrosoft’s XML libraries • For visual rendering of the cinematic or cut-scene, Ogre3D was used • Allows both 2D and 3D support • Chosen to support easy integration with otheron-going research projects at Western in this area

16. Results to Date • So far, we have been able to stage some simple productions using our prototype • There is still the odd glitch here and there, butthings generally work pretty well • Development is continuing … • Integration into some of the other gameprojects under way at Western is currentlyin progress

17. An Example from the Simpsons Homer: Well, time to go to work.

18. An Example from the Simpsons Little do they know I’m ducking out early to take theDuff Brewery tour …

19. An Example from the Simpsons Roll in at nine, punch out at five, that’s the plan.

20. An Example from the Simpsons Heh heh heh … They don’t suspect a thing …

21. An Example from the Simpsons

22. An Example from the Simpsons Well, off to the plant!

23. An Example from the Simpsons Then to the Duff Brewery …

24. An Example from the Simpsons Uh oh! Did I say that or just think it?

25. An Example from the Simpsons I’ve got to think of a lie fast!

26. An Example from the Simpsons Marge: Are you going to the Duff Brewery?

27. An Example from the Simpsons Homer: Ahhhh!

28. An Example from the Simpsons

29. Concluding Remarks • Storytelling is a very important aspect tomodern video games • Tools and supports are necessary to enablestorytellers to directly produce story contentfor games, without requiring programmingbackground and expertise • Our Reusable Scripting Engine provides a stepin this direction for cinematics and cut-scenes • Results to date have been quite promising

30. Concluding Remarks • Directions for future work include the following: • Support for audio, including spoken dialogue,background music that changes, and sound effects • Support for animated characters and backgroundelements and effects • 3D cinematics and cut-scenes (which would require the addition of new stage directions) • Support for dynamically generated story elements • Support for in-game storytelling sequences