Close
About
FAQ
Home
Collections
Login
USC Login
Register
0
Selected
Invert selection
Deselect all
Deselect all
Click here to refresh results
Click here to refresh results
USC
/
Digital Library
/
University of Southern California Dissertations and Theses
/
Quicksilver: infinite story: procedurally generated episodic narratives for gameplay
(USC Thesis Other)
Quicksilver: infinite story: procedurally generated episodic narratives for gameplay
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
QUICKSILVER: INFINITE STORY PROCEDURALLY GENERATED EPISODIC NARRATIVES FOR GAMEPLAY by Michael J. Sennott A Thesis Presented to the FACULTY OF THE USC SCHOOL OF CINEMATIC ARTS UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree MASTER OF FINE ARTS (INTERACTIVE MEDIA) May 2012 Copyright 2012 Michael J. Sennott Acknowledgments I have received a staggering amount of support for Quicksilver over the past few years, and there are a number of people deserving of my sincerest thanks. Thanks to my thesis committee of Chris Swain and Sean Bouchard, and especially to my committee chair Peter Brinson, for guiding me through the thesis process. Thanks to professors Jeremy Gibson, Mark Bolas, and Laird Malamed, who in teaching the thesis courses gave invaluable advice about both the academic and experiential sides of the project. Thanks to all the professors in the Interactive Media Division, who have combined to provide the best interactive media education I could have hoped for. Thanks to Fox Interactive, whose generous Fox Fellowship gave me the support I needed to make Quicksilver into something special. Thanks to everyone who has contributed to Quicksilver's development. Thanks to Pat Sawyer, Marc Charles, and Brendan Conway for helping me brainstorm the idea long before I came to USC. Thanks to the entire Advanced Game Project team and everyone who pitched in towards the prototypes that would eventually become Quicksilver: Ryan Watterson, Michael Chu, Alejandro Villagomez, Ruonan Zhao, Nite Luo, Ashley Armstrong, Benjamin Brownstein, Hye You, Cameron Alston, Santiago Velez, Hung-Da Shih, Virendra Khambkar, Brandon Brissette, Howard Ming, Kyle Swinney, Alice Li, Brian Choi, Alex Arreda, Alex Kubodera, Andrew Dang, Chibi Wolk, Forrest Taber-Thomas, Katie Powell, Jean Canellas, Kyna Sherman, Shannon Sleger, Sullivan Brown, Lara Colson, and Justin Sobers. And a ii special thanks to the great team that has continued working with me this year to see Quicksilver through to the end: Samantha Vick, Teddy Diefenbach, Kyla Gorman, Bryce Walters, John Carey, Stephanie Tucker, Annick Huber, Zoey Ikemoto, and Chandra Thompson. Thanks to my parents for their inestimable and unfaltering support in both my game aspirations and my life in general. Thanks to my cohort here at USC, who continue to amaze me with their camaraderie and compassion, for being great friends and making awesome inspiring things. And thanks to Samantha Vick for making this thesis year the best year of my life. iii Table of Contents Acknowledgments ii List of Figures v Abstract vi Generating Episodic Stories 1 Narrative Generation 1 Story Morphologies 3 Creating a Story Morphology 5 The Phoenix Engine 7 Phoenix Engine Realization 10 Stories Into Gameplay 13 Original Digital Prototype 13 Major Issues Found In Playtesting 15 Improvements: Aesthetics and Framing 16 Improvements: Dramatic Pacing 19 Improvements: Integrating Story and Gameplay 21 Exploring the Potential of Episode Generation 25 Frontiers in Player Agency 25 Building a Persistent Experience 28 Interaction Within Episode Creation 31 Conclusion 32 Bibliography 33 iv List of Figures Figure 1: TALESPIN Text Output 2 Figure 2: Expressive Intelligence Studio's Prom Week 2 Figure 3: GESTER Text Output 4 Figure 4: Example animated adventure synopses 6 Figure 5: Phoenix Engine episode synopses 9 Figure 6: Phoenix Engine scene transcription 12 Figure 7: Original digital prototype screenshot 14 Figure 8: Theme song animation screenshot 18 Figure 9: Dialogue boxes vs. cartoon bubbles 19 Figure 10: Graphical display for Dramatic Pacing 20 Figure 11: Comparative charts of branching facility 26 Figure 12: Train crew prototype screenshot 29 v Abstract Quicksilver: Infinite Story is a work of interactive entertainment that algorithmically creates dynamic, playable, genre-typified stories. By taking advantage of the tropes and formulas behind the adventure cartoon genre, Quicksilver's Phoenix Engine procedurally writes recognizable episode scripts, presenting them to players through action gameplay. This paper summarizes the theory and implementation behind the Phoenix Engine and details Quicksilver's exploration of how procedural episode generation might benefit the games medium. vi Generating Episodic Stories Introduction The core of Quicksilver: Infinite Story is its narrative generation system. Extending a long tradition of computational storytelling, Quicksilver is dynamically writes complete, genre- typified stories. Its narrative engine outputs the characters, plotlines, and dialogue that the player encounters during each brief “episode” of playable experience. The gameplay and aesthetics of Quicksilver are specifically designed to bring this episodic narrative generation to the player's attention and explore its potential applications in the field of game narrative. Narrative Generation Narrative generation is the field of automating the process of narrative authorship. In simpler terms, it describes any program or system designed to construct and output a story. For many computer scientists, the ultimate goal of narrative generation is to approach human storytelling capabilities, an important step towards human-computer communication and recognizable computer intelligence in general (Smith and Witten, 1991). More immediately, narrative generation has a panoply of applications in video games and interactive media. Facade is one common example of an academic narrative system doubling as an interactive experience (Mateas and Stern, 2000). The DEFACTO and IDA systems' research into drama management (Sgouros 1999) (Magerko and Laird, 2004), in which a central intelligence triggers events towards creating tensely dramatic situations, found a commercial application in the “ AI Director” recently popularized by the Left 4 Dead series. 1 The genesis of narrative generation took place in the late 1970s, when two competing approaches arose: simulation systems and authoring systems. James Meehan's TALESPIN program first pioneered the former (Meehan 1977), in which the computer runs a simulation where individual character agents interact to generate emergent narratives. This technique has been refined and expanded by various systems over the years, most recently by Prom Week from the Expressive Intelligence Studio at the University of California Santa Cruz, a game in which the player watches and manipulates the social interactions amongst high school students. The second popular approach to narrative generation does not simulate individual characters or events, but instead simulates how a human author would write a story. These authoring systems systematically derive narrative from the abstract concept of a story by using rules of storytelling. It is this tradition that Quicksilver extends. 2 Figure 2: UCSC's Prom Week is a sophisticated modern simulation system Once upon a time George Ant lived near a patch of ground. There was a nest in an ash tree. Wilma Bird lived in the nest. There was some water in a river. Wilma knew that the water was in the river. George knew that the water was in the river. One day Wilma was very thirsty. Wilma wanted to get near some water. Wilma flew from her nest across a meadow through a valley to the river. Wilma drank the water. Wilma wasn't thirsty. Figure 1: Text output from James Meehan's TALESPIN Story Morphologies The idea of using a system of rules to describe human storytelling predates computerized alrogithms. In the mid-20 th century, folklorists Joseph Campbell and Vladimir Propp formulated the concept of a story morphology. Campbell demonstrated that countless stories and myths across history had the same recurring formula, following a hero traveling through seventeen stages on a journey through a mysterious and perilous world (Campbell 1949). Certain characters archetypes – the hero, the supernatural guardian, the temptress – always appear at the same time and do functionally similar things for similar reasons. Propp found that Russian folktales could be divided into set scenes, each of which contains a certain type of event (Propp, 1968). The characters, settings, and specifics may vary, but folktales will almost always follow the same basic sequence of scenes. For example, a scene in which the hero marries his or her love will always take place near the end of the story. These morphologies provide good frameworks for computational generating narratives: a declarative system can determine the characters, settings, and events that comprise each scene, then simply proceed to narrate them according to the morphological sequence. In an interactive system, the user can have some ability to affect the proceedings of the narrative within each scene, but the following scene will always be one predetermined by the morphology. The first attempt to algorithmically use the rules of storytelling to represent a story was the TELLTALE story grammar (Correira, 1980). A computational story grammar uses grammatical rules to break the abstract concept of a story down into its components, eventually decomposing it into concrete events and the text of the story. In other words, a 3 story grammar system builds a tree from the top down, in which the start node is an abstract story and the terminal nodes represent the narrative text. Later interactive works combined Correira's idea of a rule-based story grammar with Propp's rules of Russian folklore. Story-engine is one such morphological narrative generator (Schneider et al., 2003). It allows users to fill out the specific parameters of each scene, including its role in the Propp morphology, its setting, and various other properties that determine how the engine will represent the scene. Then, Story-engine tells the story interactively using three-dimensional graphics and a first-person viewpoint. A similar system, M., adds the feature of automatically transitioning between scenes based on various stimuli, such as the passage of time or the user's actions (Hartmann et al., 2005). 4 Charles lacked a city. As a result of hearing of Narbonne Charles wanted Narbonne. Then Aymeri agreed to help Charles. Then Charles and Aymeri rode to Narbonne. Then, Charles attacked the walls of Narbonne, currently controlled by Baufumez, helped by Aymeri. Thibaut and Clarion threw burning pitch down on Charles and Aymeri. Charles and Aymeri retreated. Then, Charles attacked the walls of Narbonne, currently controlled by Baufumez, helped by Aymeri. Thibaut and Clarion threw stones down on Charles and Aymeri. Charles and Aymeri broke into Narbonne. As a result of seeing Blancheflor Charles wanted Blancheflor. Charles succeeded in getting Narbonne. Charles praised God. Charles forgot to reward Aymeri. Charles threw Thibaut into prison. Then Charles planned to obtain Blancheflor for Charles. Then Aymeri refused to help Charles because he was not rewarded. Then Bertrand agreed to help Charles. Charles abducted Blancheflor, currently controlled by Thibaut helped by Bertrand. Because Thibaut was in prison he did not oppose Charles and Bertrand. Clarion opposed Charles and Bertrand in getting Blancheflor. Charles succeeded in getting Blancheflor. Charles praised God. Charles rewarded Bertrand. Figure 3: Text output from the GESTER story grammar system (Pemberton 1989) Story-engine and M. both rely on users to enter content before they can experience a story. Thus, while both integrate elements of procedural narrative into larger experiences, neither is a complete narrative generation system. In order for such a system to generate a story unaided by extensive user input, it would need a broad data set of possibilities to slot into each specific parameter of the morphology. Every detail that users could view – from characters' names to their diction to their environment – would have to be either generated wholesale by the narrative system or entered into the system beforehand as data. For this reason, it is relatively simple for an authoring system to generate a vague plotline for a story, but a daunting task to automatically refine that plot into a form that users can read or experience. Creating a Story Morphology Propp and Campbell established their morphologies with the aim of being as universal as possible, discovering and exposing commonalities amongst a multitude of stories and myths. The same universality that gives their work import in comparative mythology makes them less useful as bases for generative algorithms. The more general the morphology, the more levels of specificity must be entered into the narrative system's data set, meaning more work for its creator. With that in mind, Quicksilver forgoes the use of Propp or Campbell's work in favor of a new custom morphology specifically tailored to support a narrative generation program. Quicksilver uses a morphology based on the genre of animated adventure TV shows. These television shows, from Jonny Quest and Speed Racer in the 1960s to Thundercats and Batman: The Brave and the Bold today, follow a group of heroes who triumph over 5 challenging enemies each episode. This genre is highly formulaic, with many repeated conventions both between shows and amongst episodes – perfect for encoding into an algorithmic system. Because the genre is a touchstone of popular culture, there are lots of resources cataloging the rules of these cartoons. The website TVTropes.org lists thousands of archetypes for the plot, characters, and dialogue of animated adventures, complete with multiple examples of each in popular media to prove their provenance. With all that evidence, creating a cartoon morphology does not require any exhaustive research of the genre's inner workings – simply a process of organizing and refining these rules into algorithms. Furthermore, the existence of TVTropes.org proves that the genre's formulaic nature is a key element of fans' enjoyment of animated adventures. A cartoon narrative generation system could embrace its adherence to rules instead of working to mask it. Equally important is animated adventures' rather low standard of prose quality. Simplistic plots and corny dialogue are genre hallmarks. Procedurally creating those is much easier than trying to get a computer to generate an intricate mystery or approach Shakespearean 6 Mega Man Episode 2x20: “Curse of the Lion Men” When a meteor falls to Earth, the heroes run across a cursed lion man named Tar. Tar plans on using his laser eyes to turn all the people in the world into lion men! It's up to our heroes to stop him! Mighty Morphin Power Rangers 2x08: “The Power Stealer” When the heroes try to clean up the environment, they encounter a terrible monster called the Octophantom. The Octophantom wants to capture the heroes in a magic jar to drain them of their powers. Can they escape and save their friends in time? Mighty Max 2x05: “The Year of the Rat” When a historian discovers an ancient secret, he is possessed by the spirit of the Emperor of Rats. The heroes must stop him from taking over the world by solving the puzzles of the Rat Emperor's temple! Figure 4: Representative synopses from animated adventure shows in the 1990s eloquence. If the narrative generator were to create a slightly nonsensical plot or an unusual quip, it would seem less like a failed imitation of the genre and more a reflection of the absurdity found in many popular animated adventures. Animated adventures also have an ideal story structure for a narrative generation system. These shows are divided into brief stand-alone episodes. Generally, these episodes have no continuity or set chronological order. Thus, if a narrative generation system could create a single episode, it could create the entire run of a show by simply writing a variety of plots with some recurring characters and settings. In theory, if the narrative generator is loaded with sufficiently granular story elements, the player would not notice the repeating structures, at least not in an off-putting manner. For example, many television shows deal with the plot of a hero being captured by the villain multiple times in a season. By varying how he was captured, for what purpose, and what ends up happening in the end, the same basic plot can seem fresh. Similarly, two episodes that both take place in the same forest can have completely different stories. A good cartoon narrative generator would have enough modularly recombinant elements that encountering the same combination twice would be extremely unlikely. If the system contains multiple possible outcomes for each storyline, or probabilistically introduces plot twists, then it can even subvert user expectations – the player literally cannot know what will happen next. The Phoenix Engine Quicksilver's narrative generation system, the Phoenix Engine, derives episodes of an animated adventure show from rules about the genre's conventions. While describing the entire workings of the Phoenix Engine is well outside the scope of this paper, it follows the 7 basic structure of a story grammar. It begins by making high-level decisions about the structure of the episode, and then makes consequent decisions at increasingly fine levels of detail until there is a specific enough plot to tell a story. Here is a sample of some decisions the engine might make: • What is the nature of the hero's conflict with the villain in the episode? ◦ Battle – The heroes are introduced to a problem in the opening scenes, and know the villain responsible. They spend the episode trying to find and defeat this villain. • What are the stakes of this conflict? ◦ Town – The well-being of a town the heroes visit is at stake. • What is the nature of this conflict over the town? ◦ Oppression – The villain has taken over the town, and proves violently tyrannous. • Why was the villain able to do this? Why is he so dangerous? ◦ Weapon – The villain uses a mysterious artifact as a powerful weapon. After the Phoenix Engine generates enough details about the plot, it uses a similar decomposite process to decide details about the central characters and setting of the episode. This decision process is partly hierarchical and partly morphological. Some decisions about an episode are hierarchical, where each decision leads to specific subdecisions about its details. Many parameters of the episode's plot instead work as a morphology – decisions about them are made independently, and any value of one parameter can combine with any valid value of any other parameter to form a valid story. For instance, the villain's motivation for causing the episode's central problem is independent from the manner in which the heroes learn about this problem; any combination of values for the two will generate something sensible and contradiction-free. This modularity is valuable because it 8 allows reusing of the writing assets necessary to tell the story. To use the above example, if there are three possible villain motivations and the exposition stems hierarchically from them, the Phoenix Engine's data set would have to include multiple scenes specific to each motivation. Since the two are modular, the Phoenix Engine can include any number of exposition scenes and villain motivations, allowing for many more combinations with much less work. Many of the design decisions behind the Phoenix Engine were motivated by an attempt to maximize this modularity, to be as efficient as possible in recycling and recombining assets. Prototyping of the Phoenix Engine began by having the program spit out a list of the traits it decided about an episode, and seeing whether a human could parse them into a cohesive 9 “Secret of Horrifying Cultist Glin!” The heroes, frustrated by their lack of success tracking the villainous Asher Lambert, decide to hunt for clues to his whereabouts in the nearby town of Vizshire. They arrive at the town of Vizshire, but find the people there behaving very suspiciously. They take on a quest to help a young lady, but it leads them right into a trap! An evil mystic named Glin is using an artifact weapon from the Great Discord to control the minds of the townspeople, so the heroes must defeat him to free the town and save their own lives! Along the way, the heroes run into a man being chased by demons. But is this stranger as innocent as he first appears? “Story of Mysterious Dragoon Ichias!” The heroes decide to put aside their pursuit of the villain Asher Lambert for a quick vacation to Ziocfield Mountain, a famous hot springs that the Quicksilver is passig by. They have to fight their way through a dangerous swamp to reach Ziocfield Mountain, but soon reach the hot springs. When they arrive, they hear rumors that tourists are mysteriously disappearing, and resolve to keep their eyes open. Suddenly, a lord approaches the heroes in a panic, being pursued by warriors! After the heroes defeat the violent warriors, he tells them that he had been abducted with many other people by a warrior named Ichias, but had managed to escape. Ichias is causing people to become hyperviolent using a dangerous amount of stolen lyr, to cause widespread chaos and destruction! To make matters worse, Nepenta is captured by the evil warrior, who plans on using the stolen lyr to control her mind! Can the others save their friend in time? And what will happen if they don't? Figure 5: Episode synopses generated by an early prototype of the Phoenix Engine story. Once the Engine could reliably pass that test, the next prototype introduced some automatic text generation, merging those traits into an episode synopsis. An adaptation of this system remains in the current version of Quicksilver, allowing the player to preview an episode's plot before choosing to play it. Phoenix Engine Realization Once the Phoenix Engine creates the details of a story, it must translate those details into a form befitting an interactive experience. In its final form, the Engine is a code library that supports the broader Quicksilver game. The Phoenix Engine exports its plot in the form of alternating gameplay levels and cutscenes. It generates a full script for each cutscene as a series of actions and lines of dialogue. Quicksilver can also query the Phoenix Engine data to determine details about each level's gameplay and the visual representations of characters and environments. The biggest task for the Phoenix Engine in this process is creating cutscenes. Rather than attempt the herculean trial of procedurally generating plausibly amusing dialogue, the Phoenix Engine contains a number of utilities for recombining and recontextualizing human-written dialogue. First, the Phoenix Engine determines a sequence of scenes that must take place in the episode according to the plot. Each scene has a template, a generic version of its events featuring broad placeholder lines (example: “I am stating my motivation for performing a misdeed”) assigned to vague roles such as “Hero” or “Civilian 2.” At runtime, the Phoenix Engine assigns each of these roles to a specific character in the episode – for instance, assigning the “Hero” lines to the protagonist Leowin and assigning the “Civilian 2” lines to a new character it makes up for the scene. Then, it uses special 10 personality variables stored within each character to retrieve the lines of dialogue from a script file. Each script file is a simple text file containing a number of lines from the generic scene templates, overwritten in the voice of a specific character. These lines can use variables for episode-specific names and pronouns that will be filled in by the Phoenix Engine at runtime – for example, the string [VillainHim] will be replaced by “him” or “her” depending on the villain's gender. To save work, many lines are reused in multiple scene templates. A line such as “Let's go!” or “Emphatic agreement” can fit into a variety of conversational situations. If the body of a line is reusable but the details don't quite match up, it can optionally query the current episode traits to branch into multiple possible sublines. The script files are arranged hierarchically. There is a global default script for all characters, containing generic versions of every line. Then, there are default scripts for each type of character – heroes, primary villains, enemies, special guests, and other non-player characters – that overwrite only the lines relevant to that character type. Scripts overlaid on top of these defaults can overwrite any number of lines to create a reasonably unique character voice. Because of the simple rich text nature of the script files and the hierarchical nature of their arrangement, writers can easily create new characters without having to understand the Phoenix Engine or duplicate redundant work. This has proven invaluable in allowing Quicksilver's writing team to quickly produce a wide range of character voices and dialogue, towards making the text of each episode seem magically new to players instead of suspiciously similar. 11 The Phoenix Engine contains many other utilities, including ones to create random names and determine which characters must be created during each scene, that fall outside the focus of this paper. 12 The heroes are riding aboard the Quicksilver in search of Lambert, when one day... <Sound effect: Loud screech> Leowin: W-What was that? Why did we stop? Cade: Something's broken. Probably everything. I'll go take a look. <Cade: Exit Left> Kai Len: Uh oh. It'll be really bad if something's wrong with the train. Leowin: If this delays us, we might lose Lambert's trail... <Cade: Enter Left> Cade: It's no good. Drive converter is shot. We can't continue until we get a new one. Leowin: What? But that could take a really long time! Nepenta: Well, at least we stopped in an incredibly dangerous area full of wild animals and the like. Cade: Anyone see a way out of this one? No? Kai Len: Well, the sooner we find that part, the sooner we can get back on track. Leowin: Come on, guys! We're heroes, aren't we? <All: Exit Right> Figure 6: Scene transcription generated by an early Phoenix Engine prototype – the opening to an episode entitled “Mystical Dragoon Quest!” Stories Into Gameplay Introduction Though the Phoenix Engine can translate its stories into text scripts, translating them into enjoyable interactive experiences has proven to be a much more nuanced task. How best can procedurally generated adventure stories integrate into gameplay to enrich the player's experience? This section of the paper will outline the history of Quicksilver: Infinite Story as a game, summarizing the first full prototype and detailing the iterations and improvements to this prototype made after playtesting. Original Digital Prototype From its first digital iteration, Quicksilver has been an action game with a focus on stylized combat. The animated adventure genre involves frequent action scenes based around the heroes' central conflict. These action scenes are interspersed with expository conversations to contextualize them. Usually, the action and expository scenes advance the plot in roughly equal measure. Narrative generation systems such as the Phoenix Engine are very capable of outputting text and dialogue, making them well-suited for the scripting of expository or dialogue-heavy scenes. However, they are less suited to scripting exciting or visually compelling action scenes. In Quicksilver, the gameplay is designed to create these sorts of action scenes by putting the player in control of them. Because Quicksilver is based on animated television shows, it employs two-dimensional graphics, and thus the gameplay takes place on a two-dimensional plane. The gameplay of the first prototype was inspired by the arcade-style fantasy brawlers of the 1980s and 13 1990s, such as Golden Axe and Dungeons and Dragons: Tower of Doom. Since Quicksilver's cartoon style evokes nostalgia for childhood, the arcade feel of a fast-paced brawler was meant to introduce a similar nostalgia to the gameplay itself. As an added incentive to create a brawler game, the genre was experiencing a commercial resurgence thanks to downloadable console titles such as Castle Crashers and Scott Pilgrim vs. the World: the Game. Up to four players each controlled one of the Quicksilver's four central heroes and advanced through horizontally scrolling levels, encountering waves of enemies that they must defeat in combat. Inspired by the classic brawler Guardian Heroes, characters can move back and forth between three layers of depth in addition to moving freely left and right. By combining directional keys with the attack button, players could attack in different 14 Figure 7: Screenshot of original digital prototype directions to create combos and inflict extra damage. In addition, each player had two special moves, which expended points from a special meter that regenerated over time. There were a total of four levels in each episode of Quicksilver. Each episode would begin with a scene introducing the heroes' reason for traveling, and then throw them into a level where they must defeat enemies in order to reach their destination. Before the second level, another scene would provide exposition, somehow bringing a villain with an evil plan to the heroes' attention. The final level was a boss fight against that villain. Unlike the other levels, the boss fight was a confrontation against a single quick-moving enemy that used powerful attacks rather than waves of simple enemies. Exposition before the boss fight explained the boss's plan and motivations, and denouement after the fight showed the plot resolving and things going back to normal to set up the next episode. In between episodes, the players navigated a train that served as the heroes' base of operations. After completing an episode, a character from that episode would join the train, giving the a memento of that episode. By assigning these characters roles on the train (such as “ Armorer” or “Researcher”) the player could also give bonuses to the heroes' abilities. On the train, players could manage this statistic progression system, talk to the collected characters, or talk to the train's captain to start a new episode. Major Issues Found In Playtesting After extensive playtesting of this prototype, the most concerning feedback was from several playtesters who were unable to tell what the game was about. They understood the basic gameplay, and they understood the basic plot of each episode from the snippets of storyline. 15 However, they had no context for these episodic stories. Many wondered if there was some overarching goal or theme they were missing. When unfamiliar with the project and not given any preamble, playtesters were largely unable to tell that there was a generative story engine in place at all. While on some level this was a success in showing that the story engine created episodes that could have plausibly been written by humans, it was damning that the game's core defining element was imperceptible, and thus immaterial, to players. Many players ignored the story altogether. They hastily skipped by the exposition scenes to get to gameplay, assuming that the story had the low quality and importance of most brawler plots. Some players who knew about the narrative engine instead payed attention to the story, but joylessly hurried their way through the gameplay to get to those cutscenes. This feedback raised some vital questions. What was the “point” of Quicksilver: Infinite Story? What separated it from other games, especially other brawlers? What made it enjoyable, unique, and worthwhile? Perhaps most importantly, how could players immediately perceive these elements and grow to appreciate them more throughout the experience? Improvements: Aesthetics and Framing The obvious answer to the question of Quicksilver's uniqueness is episodic story generation. Quicksilver has few precedents in writing a new story with every playthrough, which at the very least should produce some fascinating replay value as players discover how the story system works and what it can do. Yet in the first prototype of Quicksilver, nothing in 16 particular brought that system to the players' attention. The first step towards leveraging episodic story generation to make a great game was letting players know it existed. One early attempt to highlight the narrative system was the implementation of a fake loading screen that displayed “Writing New Story...” whenever the story engine was creating a new episode. Later, players chose new episodes from a map screen, where they could choose multiple episodes based on their synopses instead of simply entering a story with no prelude. However, even with these improvements, players had difficulty determining what the game was “about.” The concept of episodic story generation, while interesting, does nothing to help the game thematically. Players did not have any frame to hold onto, any way to immediately contextualize their actions and the actions of the heroes. Of course, Quicksilver did have a theme all along: animated adventure shows. The Phoenix Engine runs based on the conventions of the genre, and the story's heroes and world were designed to resemble these shows. The more Quicksilver the game resembles an animated series, the more players will be able to intuitively understand the story's division into episodes and the recurring formulas between those episodes. In addition, animated adventures are inherently fun. Framing the game as a Saturday morning cartoon could introduce a bright and inviting aesthetic where the original prototype could feel sterile or self-serious. Finally, and most importantly, an animated adventure feel is the most honest answer to what Quicksilver is “about.” The Phoenix Engine is an honest attempt to capture the spirit of adventure and excitement at the heart of the animated adventure, so the game's aesthetics and gameplay should help it in that task. 17 The first aesthetic improvement was framing the episodes as actual episodes of a television show, rather than in-game missions. Every episode now begins with an animated title sequence featuring a rock song composed to be reminiscent of other memorable Saturday morning cartoon themes. Later, the train framing device was removed from episode selection entirely, in place of a simple menu. This change was meant to switch the metaphor from player-as-hero finding a new quest to player-as-viewer starting up a new episode. Similarly, the screen at the end of an episode switched from an arcade-like high score screen to a television-like end-credits screen. Another important aesthetic change was an overhaul of the user interface. The original prototype had ornate and booklike menus, with faux-Victorian patterning and a spindly serifed font. These were replaced by cleaner, more cartoonlike menus with a simpler font 18 Figure 8: A frame from Quicksilver's opening theme song animation and a more limited color palette. To represent dialogue, the original prototype used a pop- up box with a portrait of the speaking character, as is popular in the role playing game genre. The later versions of Quicksilver replaced these dialogue boxes with a simple cartoon-like speech bubble over the speaking character's head. Improvements: Dramatic Pacing The core gameplay underwent various iterations towards feeling less like a brawler and more like a televised cartoon. In most action games, including Quicksilver's original prototype, the hero wins a level by defeating or bypassing a certain number of enemies. Each character has a “life bar” or “hit points” to represent stamina, which is reduced upon being struck by an attack or obstacle. When a character's stamina is depleted, that character is knocked out and removed from combat. If the hero's stamina runs out, the player loses. This conventional game combat schema differs significantly from how combat appears on most television shows. Television shows have a compressed structure in which it would be rare to see every attack the heroes land in a fight. Instead, fights are usually represented based on key dramatic points – some significant attacks, but also significant 19 Figure 9: A comparison of the dialogue box and cartoon bubble styles of text display evasions, exhibitions of lateral thinking, or even lines of dialogue. Combat concludes not when every character has received a set number of attacks, but rather when it is dramatically appropriate for the fight to be over. With that in mind, Quicksilver introduced the “Dramatic Pacing” system of combat. Characters no longer have health bars. Instead, there are two meters at the top of the screen: the “ Awesome Bar” and the “Danger Bar.” When the player does something dramatic and successful, such as attacking the enemy or evading an attack, the Awesome Bar rises. The player can even press a one-liner button to have the hero make a clever quip relevant to the current situation, which leaves the hero momentarily vulnerable but can greatly increase the Awesome Bar. When the player is conversely bested by the enemy, such as when the enemy attacks the player, the Danger Bar rises. When the Awesome Bar fills up completely, the player wins the level. If the Danger Bar fills up first, the player loses the level. In further playtesting, players enjoyed the freedom offered by the Dramatic Pacing system. Players did not have to keep track of enemies' health, and could focus on acting as situationally appropriate rather than using that metatextual knowledge. Virtually everyone 20 Figure 10: The Dramatic Pacing system uses a double meter – the “ Awesome Bar” (left) and “Danger Bar” (right) – to represent players' progress found the ability to perform a one-liner in the midst of combat amusing, and many were able to use it in a tactically advantageous manner. Some players were even able to win levels without ever striking a single blow, by performing high-risk dodges of enemy's attacks and running away to taunt them with one-liners. However, the most important achievement of the Dramatic Pacing system was simply changing players' frame of reference for the game. When gameplay felt more like a conventional brawler, players expected the story and presentation to mirror that of a conventional brawler as well, and thus did not pay the narrative much mind. When gameplay felt more like a new take on action, players had more expectations that the rest of the game would be innovative as well, and thus were appreciably more curious about Quicksilver's narrative generation elements. Part of this change may be attributable to the change in pacing itself. The original combat system involved a lot of “button mashing,” or constant repeated presses of the same button, which may have influenced players to continue rapidly pressing that button during cutscenes to skip over dialogue. Dramatic Pacing, by emphasizing a variety of options, encourages a more thoughtful approach to combat based on situational awareness, and that rhythm of thoughtfulness may carry over to players' reactions to cutscenes. Improvements: Integrating Story and Gameplay Thematic changes and reimagining combat helped dissuade players from ignoring the story of Quicksilver's episodes. However, the fact that players were able to ignore the story at all pointed out a serious disconnect between Quicksilver's story and gameplay. The interactive medium provides an opportunity for a game's narrative and mechanical elements to enrich 21 one another, acting in constant dialogue to form an experience that neither would be able to create individually. The original prototype squandered this opportunity. Its gameplay was barely affected at all by narrative. With the exception of providing the setting and the boss's appearance, nothing in the cutscenes meaningfully informed gameplay segments. Concordantly, the gameplay felt inconsequential. The relationship between narrative and gameplay was too vague for the former to lend stakes to the player's actions. Future versions of Quicksilver sought to tighten the integration of narrative into gameplay by following a simple rule: every level must have an explicit goal. No longer could the heroes wander along fighting waves of enemies whose appearance was explicated solely by players' cognitive dissonance. Instead, at the beginning of every level, a message would appear explaining what the heroes are trying to accomplish and what obstacle stands in their way, fully explaining and contextualizing their upcoming actions. As long as every level has a specific goal, the player will always know both what they are doing in the greater context of the episode and why that matters. Early attempts to integrate this idea into Quicksilver revealed that it was difficult to express a wide range of character motivations using simple combat. Since the only acceptable framing scenarios were the heroes being suddenly attacked by enemies or having to traverse a dangerous area, every plot became a contrivance to produce these scenarios three times in a row. The results felt implausible, repetitive, or both. To solve this problem, further experiments focused on creating a wider range of gameplay scenarios than just combat. 22 After the original prototype, several rounds of rapid iteration took place to determine which scenarios would be most fun, easy to create, and narratively useful. The Dramatic Pacing system made designing these scenarios much easier, as virtually any action with a chance of success or failure could become gameplay by granting Awesome or Danger points accordingly. In the end, five were chosen: the Brawl Scene, the Villain Scene, the Chase Scene, the Defense Scene, and the Sneaking Scene. • The Brawl Scene is similar to combat in the original prototype, with the addition of the Dramatic Pacing System. Instead of forcing the player to walk to the right and scroll the screen for more enemies to appear, the combat takes place on a single screen and new enemies appear to replace ones who are knocked out. • The Villain Scene is similar to the the original prototype's boss fight, with the addition of a “turning point” in the middle to better mirror villain confrontations in television shows. Before the turning point, the player can only avoid the villain's powerful attacks and occasionally get a hit in, but after gaining enough awesome, a cutscene plays in which the hero exposes the villain's weakness, after which the player can easily defeat the villain using a flashy special attack. • In the Chase Scene, the heroes are either pursuing or being pursued by another character. They are constantly, automatically running, so the players must jump and dodge to evade obstacles and gain Awesome. • The Defense Scene sees the heroes trying to protect someone or something from invaders. The object of protection is at the center of the screen, and waves of enemies constantly appear in pursuit. It differs from the Brawl Scene in that focus is much less on combating these enemies and more on navigating the space to reach enemies before they can harm the object. 23 • In the Sneaking Scene, the heroes must sneak past a number of enemies to reach a location undetected. The screen scrolls as players advance to the right, revealing patrolling enemies along with walls to hide behind. Players gain Danger by being spotted by enemies, and gain Awesome by advancing or evading detection. Playtesting revealed that players enjoyed the variation offered by these scenarios. Not only did they make the game more replayable, they also helped differentiate episodes from one another. In addition, these scenarios proved useful tools for pacing. Varying the gameplay had the added advantage of allowing the story to dictate the tone of players' actions. Rather than having a single atmosphere of conflict, gameplay could be more high-energy and frenetic or tense and solitary depending on what the heroes are experiencing narratively. Playtesters reported feeling more connected to the narrative as a result. 24 Exploring the Potential of Episode Generation Introduction This paper has detailed the efforts and theory behind making Quicksilver: Infinite Story into a game centered around the innovation of an episodic story generator. Everything in Quicksilver's aesthetics and gameplay has been designed to support and highlight this story engine. This raises the question: what can the story engine provide for the game, and for the games industry as a whole? The story engine has valuable as a novelty, but does it have value beyond that? What advantages does it hold over a scripted story, and are those enough to make episodic narrative generation a worthwhile decision for future games? Since Quicksilver has few peers exploring episodic narrative generation, it is important for the project to offer as much insight as possible towards these questions. This section describes a variety of past, current, and planned future experiments with game features only possible with episodic generation. Frontiers in Player Agency Perhaps the most exciting possibility afforded by generative episodes is allowing the player a great deal of control over the episode's course and resolution. Most long-form video games can only offer the player a limited amount of agency over the story due to combinatorial explosion. With every new decision that the player can make, the game's developers must script two or more possible outcomes for the duration of the choice's impact. For each additional decision, each of those outcomes must in turn contain other outcomes. The amount of paths necessary increases exponentially with the player's agency, and the workload for developers quickly rises from significant to completely untenable. To 25 work around this problem, game writers often limit the scope of decisions' impacts upon the game narrative at large, often abstracting the outcome into a morality system that gauges some aspect of the player character's personality or relationships. This approach, when combined with some special cases where decisions affect later quests, is the current state of the art seen in Bioware's popular Mass Effect and Dragon Age series. In a game with episodic narrative generation, the scope of a player's decisions are inherently limited to the current episode. Purely episodic television shows, by definition, can be viewed in any order. As in the picaresque novel form, they detail a series of incidents with no real impact on one another, meant to chronicle the adventures of the central protagonists. In an episodic animated adventure, no matter how one episode ends, the next episode will always begin “back to normal,” with the heroes set up to embark on a new 26 Figure 11: By encapsulating decisions and their consequences within episodes, players can make more choices with less authored content. As an illustration, the traditional branching model on the left has 31 total nodes with four decisions (or levels of branching), while the episodic model on the right has 17 total nodes (some of which may be reused) with five decisions. adventure. In an episodic game, the player can make multiple decisions over the course of each episode that fundamentally affect its narrative and ending, with the stand-alone nature of the episodic structure preventing further combinatorial explosion. In most games, unchosen paths remain unseen unless the player replays the entire game. In a game with generative episodes, similar paths may recur in later episodes, offering players the opportunity to learn from their experiences and explore the different consequences of each decision. Quicksilver chooses to take advantage of generative episodes' branching facility by eliminating failure states. In virtually every game, including the original prototype of Quicksilver, when the player loses he must either retry a challenge or simply continue as normal with some loss of resources. In the current version of Quicksilver, the story of each episode adapts based on whether the player succeeds or fails at each level. If the player succeeds (by filling the Awesome Bar), the heroes similarly succeed at whatever their goal is for the level, and the story proceeds in that direction. If the player fails, the heroes fail and the story proceeds accordingly. Each episode has four levels, meaning four binary branches for the narrative. Though this would ordinarily mean each episode would have 2 4 or 16 different endings, Quicksilver uses some tricks of modularity and recombinance to make the actual writing workload significantly less than that may imply. The aesthetics and rhetoric of Quicksilver are also constructed to eliminate fail states. Players cannot “lose” or “fail” a level – instead they succeed at completing the level regardless of whether the Awesome or Danger Bar is filled, and simply acquire a different ending for the level depending on which is the case. In playtesting, players reported that 27 knowing there was no fail state encouraged them to take more risks than normal, and in doing so have more fun. Playtesters inexperienced with games were encouraged when their failures were met by narrative consideration rather than punishment, and reportedly stuck with the game significantly longer than they would have in a conventional game structure. One playtester who broadly disliked the action game genre for its traditional unforgiving nature reported that Quicksilver was the first time he felt comfortable playing an action game. Some players even intentionally increased the Danger Bar, either just for fun or to see what would happen narratively. Future versions of Quicksilver will introduce dynamic difficulty towards maintaining a level of challenge where players will sometimes succeed and sometimes fail. This will be reinforced by the introduction of two types of currency called Valor and Karma, which can only be earned by filling the Awesome Bar and Danger Bar respectively. In future experiments, Quicksilver will incorporate some explicit player decisions through dialogue choices. Recurring choices could be emotionally resonant opportunities for players to learn from mistakes. If decisions have nondeterministic outcomes, they could also surprise players expecting the same result from making the same decision in a different situation. Building a Persistent Experience The current version of Quicksilver: Infinite Story is a purely episodic experience. Each episode stands alone, not affecting the plot of any other episode. One promising avenue for future experiments is attempting to connect these episodes, so that players' experiences will form unique and persistent story worlds. 28 One simple way to accomplish this is with recurring characters. If a villain escaped due to the heroes' failure, that villain could return with a new evil plan in a later episode. If the heroes instead help a villain see the error of his ways, that villain could surprisingly return to help the heroes out of a dire situation in a later episode. These are just a few of the ways in which the simple reappearance of significant characters could tie otherwise distinct episodes together into surprising and affecting narratives. Quicksilver could also reintroduce the train system of storing characters. As briefly mentioned earlier, in the original prototype, after each episode a character from that episode would join the heroes' train to work on the crew. Besides serving as memorabilia for that episode, the characters served as the game's progression mechanic – players could 29 Figure 12: A prototype of Quicksilver's train crew system for using stored characters as stat progression assign them roles on the train, which would give the heroes appropriate bonuses. While this system would need to be overhauled to match the changes in Quicksilver's gameplay, it could be an intriguing way to allow players further interaction with characters to which they feel a connection. To make the crew members feel more special, perhaps one should not be gained every episode, but randomly upon certain narrative conditions being met. Alternatively or in addition, the player could spend the aforementioned Valor or Karma currency to invite characters to join the crew. Beyond recurring characters, most animated adventures tie episodes together in the form of arc plots. An arc plot is a plot that plays out over the course of a season or even the entire run of a show, gradually developing over the course of many episodes. Many shows mix episodes that advance the arc plot with stand-alone episodes. Some shows have episodes that initially seem unrelated to the arc plot, but end up introducing an important revelation. A future version of Quicksilver will attempt to integrate this style of arc plot into the narrative engine. The first episode will be a specially scripted episode to establish the arc plot, and the season finale will serve as the exciting conclusion of the plot. In between, episodes will be generated by the Phoenix Engine, but seeded with certain plot points, characters, and revelations guaranteed to occur at some point during the season. This should mirror the conventional arc plot structure by giving each episode both a self- contained plot and an important clue to the season's storyline. If this approach is successful, it would mean that a developer could write an entire new multi-episode “season” of a game featuring generative episodes by simply scripting these minimal elements. This would make it remarkably easy for a developer to author additional seasons after a game is first released 30 – players could play stand-alone episodes until the next season is ready, and then download the elements necessary for the new story arc. Interaction Within Episode Creation Quicksilver currently operates by having the Phoenix Engine generating an episode wholesale, containing all the possible branches that episode might entail. The game receives this episode as a package from the Phoenix Engine and communicates it to the player. As one possibility afforded by this setup, players could easily save favorite episodes to be replayed later. Interestingly, because Quicksilver's episodes have branching paths, the same episode played twice might turn out entirely different in two separate playthroughs. Players could use saved episodes to revisit their decisions and discover how things might have ended up differently – a non-canon parallel version of the main story, so to speak. Saved episodes could potentially be transmitted to friends online, allowing players to share their experiences. Thanks to the nonlinearity of Quicksilver's episodes, players could compare and contrast their own paths through the same episode. Another interesting experiment would be allowing players to participate in the Phoenix Engine's process of authoring stories. In this case, the Phoenix Engine would act as an expert system to help the player create a story. The player could specify as many or as few of the Engine's decisions as desired, and the Engine would automatically fill in the rest. The player could specify all the details of how the plot could progress, or simply create a guest character to appear in the episode, specifying its name, appearance, and/or personality. Much like saving episodes, this feature could be combined with a method of sharing created episodes with friends or posting them to a central community hub to be browsed and 31 downloaded by other players. The Phoenix Engine could even write out the plots as full episode scripts that players could download. There is a risk that allowing players to interact with the inner workings of the Phoenix Engine could ruin some of its apparent magic, but there is also a chance that players could find working with it rewarding or even inspiring. Conclusion Quicksilver: Infinite Story is the sole vanguard for episodic narrative generation. As such, future experiments with the game will focus on exploring the affordances of the form and assessing its potential value to the broader interactive medium. However, since Quicksilver is a game at heart, much of further development will go towards making it an enjoyable and playable experience. Quicksilver's success could raise awareness of episodic narrative generation, and potentially inspire other researchers to experiment with the form. More importantly, Quicksilver and the Phoenix Engine are fundamentally an attempt to create a renewable source of entertainment, and must in the end be judged on how much entertainment they are able to provide players. 32 Bibliography Batman: The Brave and the Bold. Cartoon Network. 2008-2011. Television. Campbell, Joseph. The Hero with a Thousand Faces. 3rd ed. Novalto, CA: New World Library, 2008. Print. Castle Crashers. Dev. The Behemoth. Microsoft Game Studios, 2008. Game, Xbox 360. Correira, Alfred. “Computing story trees.” Computational Linguistics. 6.3-4 (1980): 135-149. Print. “Curse of the Lion Men.” Mega Man. Syndicated broadcast. 20 Oct. 1995. Television. Dragon Age: Origins. Dev. BioWare. Electronic Arts, 2009. Game, Personal Computer. Dungeons & Dragons: Tower of Doom. Capcom, 1993. Game, Arcade. Golden Axe. Dev. Sega AM-1. Sega, 1989. Game, Arcade. Guardian Heroes. Dev. Treasure Co. Ltd. Sega, 1996. Game, Sega Saturn. Hartmann, Knut, Sandra Hartmann, and Matthias Feustel. “Motif Definition and Classification to Structure Non-linear Plots and to Control the Narrative Flow in Interactive Dramas.” Using Virtual Reality Technologies for Storytelling, Third International Conference. Ed. Gérard Subsol. Springer, 2005. Print. Jonny Quest. ABC. 1964-1965. Television. Left 4 Dead. Dev. Valve Corporation. Electronic Arts, 2008. Game, Xbox 360. Magerko, Brian, and John E. Laird. “Mediating the Tension Between Plot and Interaction.” AAAI Workshop Series: Challenges in Game Artificial Intelligence. San Jose, California: Association for the Advancement of Artificial Intelligence, 2004. Print. Mass Effect. Dev. BioWare. Microsoft Game Studios, 2007. Game, Xbox 360. Mateas, Michael, and Andrew Stern. “Towards Integrating Plot and Character for Interactive Drama.” Working Notes of the Social Intelligent Agents: The Human in the Loop Symposium. Menlo Park, CA: Association for the Advancement of Artificial Intelligence, 2000. Print. Meehan, James R. “TALE-SPIN, An Interactive Program that Writes Stories.” Proceedings of the Fifth International Joint Conference on Artificial Intelligence. San Francisco, CA: Morgan Kaufmann Publishers, 1977. Print. Pemberton, Lyn. “ A modular approach to story generation.” Proceedings of the Fourth 33 Conference on European Chapter of the Association For Computational Linguistics. April 10 - 12, 1989, Manchester, England. Morristown, NJ: Association for Computational Linguistics, 1989. Print. “The Power Stealer.” Mighty Morphin Power Rangers. Fox. 20 Sep. 1994. Television. Prom Week. Dev. Expressive Intelligence Studio. University of California Santa Cruz, 2011. Game, Personal Computer. Propp, Vladimir. Morphology of the Folktale. Trans. Laurence Scott. Austin, TX: University of Texas Press, 1968. Print. Schneider, Oliver, et al. “Storylining suspense: An authoring environment for structuring non-linear interactive narratives” . WSCG 2003, International Conference in Central Europe on Computer Graphics, Visualization and Computer Vision. Plzen, Czech Republic: University of West Bohemia, 2003. Print. Scott Pilgrim vs. the World: The Game. Dev. Ubisoft Montreal. Ubisoft, 2010. Game, Playstation 3. Sgouros, Nikitas. “Dynamic generation, management and resolution of interactive plots.” Artificial Intelligence 107.1 (1999): 29-62. Print. Speed Racer. CBS. 1967-1968. Television. Smith, Tony C., and Ian H. Witten. A planning mechanism for generating story text. Technical Report 1991-431-15. Calgary, Canada: Department of Computer Science, University of Calgary, 1991. Print. ThunderCats. 2nd ed. Cartoon Network. 2011-2012. Television. TV Tropes. Web. 10 Dec. 2009. <http://www.tvtropes.org>. "Year of the Rat." Mighty Max. Syndicated broadcast. 28 Sep. 1994. Television. 34
Abstract (if available)
Linked assets
University of Southern California Dissertations and Theses
Conceptually similar
PDF
The moonlighters: a narrative listening approach to videogame storytelling
PDF
Grayline: Creating shared narrative experience through interactive storytelling
PDF
Psychic - an interactive TV pilot: development of a game project for native TV platforms
PDF
Brinkmanship and the process of narrative design
PDF
Psynchrony: finding the way forward
PDF
Paralect: an example of transition focused design
PDF
Day[9]TV: How interactive Web television parallels game design
PDF
Songlines: combining music and gesture to create a mythic experience
PDF
American braves - total aesthetics: an opinion piece on game design for academics
PDF
Resurrection/Insurrection
PDF
Manjusaka
PDF
Dissonance
PDF
The tree as storied experience: an experiment in new narrative forms
PDF
The return: a case study in narrative interaction design
PDF
Everything all the time: anthological storytelling
PDF
Feel the force
PDF
Into the sunrise
PDF
Berättande
PDF
BONDS: an asymmetrical collaborative adventure game on exploring the player's emotional connection and emergent gameplay
PDF
Players play: extending the lexicon of games and designing for player interaction
Asset Metadata
Creator
Sennott, Michael J.
(author)
Core Title
Quicksilver: infinite story: procedurally generated episodic narratives for gameplay
School
School of Cinematic Arts
Degree
Master of Fine Arts
Degree Program
Interactive Media
Publication Date
05/01/2012
Defense Date
03/28/2012
Publisher
University of Southern California
(original),
University of Southern California. Libraries
(digital)
Tag
computational storytelling,game design,Interactive Media,OAI-PMH Harvest,procedural narrative,video games
Language
English
Contributor
Electronically uploaded by the author
(provenance)
Advisor
Brinson, Peter (
committee chair
), Bouchard, Sean (
committee member
), Swain, Chris (
committee member
)
Creator Email
mikesennott@gmail.com,sennott@usc.edu
Permanent Link (DOI)
https://doi.org/10.25549/usctheses-c3-21632
Unique identifier
UC11290198
Identifier
usctheses-c3-21632 (legacy record id)
Legacy Identifier
etd-SennottMic-705.pdf
Dmrecord
21632
Document Type
Thesis
Rights
Sennott, Michael J.
Type
texts
Source
University of Southern California
(contributing entity),
University of Southern California Dissertations and Theses
(collection)
Access Conditions
The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the a...
Repository Name
University of Southern California Digital Library
Repository Location
USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA
Tags
computational storytelling
game design
procedural narrative
video games