Citation
Tell me more: adding narrative schema to the Rube simulation

Material Information

Title:
Tell me more: adding narrative schema to the Rube simulation
Creator:
Hays, John ( Author, Primary )
Place of Publication:
Gainesville, Fla.
Publisher:
University of Florida
Publication Date:
Copyright Date:
2003
Language:
English

Subjects

Subjects / Keywords:
Audiences ( jstor )
Boolean data ( jstor )
Family structure ( jstor )
Integers ( jstor )
Learning ( jstor )
Literary characters ( jstor )
Mathematical models ( jstor )
Mathematics ( jstor )
Modeling ( jstor )
Narratives ( jstor )

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright Hays, John. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Embargo Date:
9/9/1999

Downloads

This item has the following downloads:


Full Text











TELL ME MORE: ADDING NARRATIVE SCHEMA TO THE RUBE SIMULATION FRAMEWORK

















By

JOHN HAYS


A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2003





























Copyright 2003

by

John Hays






























To my parents,
Fred and Sherry Hays, And all of my friends,
Without whom none of my success would be possible
















ACKNOWLEDGMENTS

I would like to thank my thesis committee chairman, as well as digital arts and sciences graduate advisor, Dr. Paul A. Fishwick, for helping to guide me through my entire journey as a graduate student at the University of Florida. I would also like to thank Dr. Jane Yellowlees Douglas for not only being on my thesis committee, but for constantly inspiring and enlightening me in the area of interactive narrative. I also give much thanks to Dr. Joachim Hammer for his time and interest in being on my thesis committee.

My sincerest gratitude goes out to those who helped me with the technical side of my thesis. These people include Kristian DamkJer and Minho Park. Without their great devotion of time and knowledge, this thesis would not be possible.

1, of course, would like to thank my parents, Fred and Sherry Hays, for all their love and support. I would also like to thank the rest of my extended family for always believing in me. Finally, I would like to thank God for my continued existence, and for everything that has ever or will ever happen to me.
















TABLE OF CONTENTS
p42e

ACKN OW LED GM EN TS . iv

LIST OF FIGURES . vii

A B S T R A C T . v iii

CHAPTER

I INTRODU CTION . I

1 . 1 C h a lle n g e s . 1
1.2 Organization of the Thesis . 1

2 BACK GROUND . 3

2.1 Num eric Abstraction . 3
2.2 Aesthetic Com puting . 4
2.3 N arrative Schem as . 6
2.4 Creating N arrative Structure . 9
2 .5 C o n c lu sio n . 12

3 RELATED W ORK S . 13

3 .1 M u ltita lk . 1 3
3.2 Random Text Generators . 13
3.3 Papert Constructionism . 14
3 .4 P ro t6 g 6 . 1 5

4 THE PROCESS . 16

4 .1 In itia l C o n c e rn s . 1 6
4.2 D esigning the Schem a . 16
4.3 D esigning the Translator . 18
4.4 Creating a W orld with N arrative Schem a . 19

5 CON CLU SION . 22

5 .1 R e su lts . 2 2
5. 1.1 Exam ple W orld . 22


v









5.1.2 Other Possible Im plem entations . 24
5.1.3 Concrete FSM 's . 24
5.1.4 Branching FSM 's . 25
5 .2 F u tu re W o rk . 2 5
5 .2 .1 A v a ta rs . 2 5
5.2.2 Further Integration into Rube . 26
5.2.3 N arrative in G am e D esign . 26

APPENDIX

A SSM L SCHEM A . 28

B N F E X S L T . 3 1

C SSM L EX AM PLE FILE S . 32

C . I Sim plest SSM L Exam ple . 32
C .2 M ultiple Conflict/R edress Exam ple . 32
C .3 Com plex SSM L Exam ple . 33
C A Com plex Exam ple M XL Code . 34
C .5 Com plex Exam ple Javascript . 40

LIST OF REFEREN CE S . 49

BIO GR APH ICAL SK ETCH . 51
















LIST OF FIGURES

Figure p42e
4-1. SSM L Schem a Code . 17

4-2. NFE X SLT Code . . 18

4-3. Sim ple SSM L File . . 19

4-4. Rube Coding Structure . . 21

5- 1. Com plex Exam ple W orld . . 22

5 -2 . S im p le F S M . 2 3

5-3. Com plex N ested FSM . . 24















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

TELL ME MORE: ADDING NARRATIVE SCHEMA TO THE RUBE SIMULATION FRAMEWORK
By

John Hays

May, 2003


Chair: Paul A. Fishwick
Major Department: Computer and Information Science and Engineering

Aesthetic computing is a term coined by Fishwick, at the University of Florida. It is used to describe the idea of visualizing mathematical models in order that they might be more easily understood by people not already familiar with the concepts.

Stories provide another way for people to understand and share ideas in a way that is both universally understood and as old as time itself Narrative schema provides a way to analyze and provide structure for these stories. This allows stories to be defined in a scientific and ordered way.

In my research, I am attempting to map narrative schema within an aesthetic computing application environment called rube. Rube uses XML, VRML, X3D, and other languages to allow users to create a visual world with models and animations, and then add behaviors to that world which cause it to act like the mathematical model they want to visualize. My focus will be on using the structured format of narrative schema to add a new dimension to the rube format.









I have picked one particular narrative schema which is simple and straightforward. It consists of three basic types of states: initial steady state, conflict state, and redress state. These states can then be subdivided into lower levels, allowing for subplots, character motivations, and so forth.

My ultimate goal is to allow users to input the basic elements of the narrative schema for whatever particular story fits state for state onto the mathematical model they happen to be simulating. This will use my own XML story schema language, SSML, which will organize the information, combine it with X313, and feed it into the rube architecture.














CHAPTER I
INTRODUCTION

1.1 Challenges

The goal of this research is to create a mechanism that will map story structure onto formal models so that these formal models are more easily understood, remembered, and appreciated by those not familiar with formal models. The abstract idea is to think of narrative as an additional dimension, like 3D, audio, or touch, and then add it to the virtual visualization of a mathematical structure, in this case a finite state machine (FSM).

The key difference with this research and, say, simply mapping a particular story onto a particular FSM is the fact that a particular story has a fixed structure and therefore will only work with the FSM that fits that structure. This does not allow for extensibility or modularity. What this research accomplishes is to create an actual story schema from which any possible narrative can be created and then mapped onto virtually any FSM.

This research will strive to accomplish the following tasks: find or create a narrative schema that is well formed, yet flexible enough to conform to any FSM, and figure out a way to successfully map the resulting stories onto FSM's in the rube architecture.

1.2 Organization of the Thesis

Historical background on all aspects from aesthetic computing to narrative schema is discussed in Chapter 2. Chapter 3 is a brief survey of other recent attempts to connect narrative schema and computer science technologies. Chapter 4 describes the process






2


involved in creating the story schema modeling language (SSM]IL), as well as how it currently connects to rube. The schema and the extensible stylesheet language transform (XSLT) file are both discussed, along with how to create a world that includes narrative mapping with SSMIL. Chapter 5 contains the conclusion to the research, discussing results as well as future possible work.














CHAPTER 2
BACKGROUND

2.1 Numeric Abstraction

How do people represent the basic necessities of life? Looking back to early times, it is seen to be very personal, very individual. A person growing corn on a farm might want some meat for dinner, so he would attempt to trade with a man who raised cattle. This, however, proved unwieldy when it came time to discuss terms of a trade. One could not just drag cows, corn, or whatever else each person identified with everywhere he went. It was not financially feasible or physically practical.

Thus, an abstraction was made. Cows and corn became clay tokens. This was still very personal, since the tokens still represented real items. Every different token shape was unique to the object it represented. Sheep, jars of oil, and other things were all represented with their own tokens [ 14].

Sumerian tokens actually abstracted even more in that they stood for units of merchandise, meaning that each counter stood for measures of items, instead of each item individually [13]. This still was not a purely abstract numeric system, since the tokens only stood for amounts of their respective items, not amounts of any item. This idea of measurement was, however, the impetus for pure abstraction. Terms such as "decade" and "hundred" derived from measurements such as inch, foot, and yard [8]. This idea led to an actual number system, which was eventually expressed not as tokens but as ink on paper, chalk on slate. Numbers were then combined with symbols to form expressions that represented more complex ideas. By this time it was all very abstract and devoid of









personal meaning, yet this was the way it was done to conform to the economic and physical limitations of the time. It is perfectly understandable that this needed to be done, but the fact that this same way of doing things has carried on up to the present day is, when analyzed closely, quite shocking.

Today, even in high-level universities, the most complex of ideas are represented with nothing better than circles and squares drawn with chalk on slate. In an advanced computer architecture classroom, the inner workings of a personal computer are represented by two rectangles drawn on the board, one for the central processing unit and one for the arithmetical logic unit. In a simulation class, mathematical systems such as finite state machines and entity relationship diagrams are represented with circles connected by lines, once again drawn on the board. With all the technological devices available to us that enable us to visualize things in new and more immersive and engaging ways, one would think something could be done to change the way we learn, giving us back the personalization we once had.

2.2 Aesthetic Computing

In fact, attempts are being made to change all of that. One attempt, in particular, is a project called rube. Rube deals with aesthetic computing, a term coined by Fishwick at the University of Florida. Aesthetic computing is the attempt to visualize mathematical and computing concepts in order to provide a better understanding to people not educated in the area, as well as to recapture the personalization of data representation lost to us since ancient times. Fishwick's main thrust is the simple idea that, if given any physical or technological material required, as well as an extremely fast and efficient construction process so as to make the final product physically and financially feasible, how would we









then choose to represent everyday concepts currently bound to chalk on slate or pencil on paper?

The motivation behind why anyone would bother to change the way one represents mathematical data can be thought of in the way a child learns. In the very early stages of learning, an adult presents a child with three dimensional objects, such as balls and blocks. The child can touch and feel these objects, and has instant recognition of their existence and their inherent importance to the child. In this way the child learns concepts such as addition and subtraction that otherwise would be extremely difficult to get across in a purely abstract manner. By that same token, aesthetic computing is the hope that one day a child, or any person not specifically educated in the field of mathematics, can learn much more difficult and technical mathematical concepts in ways that they can instantly feel comfortable with, such as three dimensional objects, or in the case of this research, a story based on a structured and familiar schema.

The advantage of using narrative as opposed to simply using three dimensional objects is the fact that it would play to a different audience, or at least a different way for the same audience to understand. It is well known that different people have different ways of learning, and in fact most people can learn things in multiple ways. It is also obvious from the popularity of films and books that people have a fondness for stories, both for education as well as entertainment. People spend massive amounts of money on DVD's, video games, books, and so forth, which all basically start out as stories on paper and go from there. It is for this reason that adding narrative seems like the next logical step in helping someone not educated in mathematics to understand mathematical models represented visually. It is the hope that when someone is presented with a mathematical









model that has a story mapped onto it, the person can then read the story as the step through the model, and understand the structure of the model through the structure of the story.

The ability to create in this manner will push the idea of aesthetics into the forefront of model representation, with artists taking the lead on design. This idea of "aesthetic computing" will bring art and science together, with each in direct support of the other [5]. The rube project is the implementation of this idea using XML and VRML technologies to create virtual worlds that house these models. The vision of the rube project is to use as many different ways as possible to visualize data, thereby opening it up to the largest possible audience. Different genres, such as architecture, theatre, and art, have been used to visualize these models for the broadest possible audience. So far, architecture has been one of the most successful approaches used. Mathematical structures have been visualized as buildings or objects in order to make them palatable to people familiar with those various structures.

2.3 Narrative Schemas

A completely different approach being attempted in this thesis is to use narrative structures. That is, to map a mathematical or computing structure onto a story structure, thereby providing an understanding of the mathematical structure to people familiar with whatever story might be chosen or created. In order to have a better understanding of how to map a narrative structure onto a mathematical structure, it is necessary to understand some of the history surrounding the current state of narrative structures.

Shank did some early work on narrative structures, or schemes, for the area of artificial intelligence. His main concern was to understand how people processed information from other people in such a way as to correctly understand the underlying









meaning of the speaker. Shank decided that people had two types of knowledge, general and specific. General knowledge allows people to understand the basic actions of others, whereas specific knowledge allows people to interpret and participate in events that are repetitious. By forming mental structures, or schemes, of these events in our minds, we are able to reenact them at any time. For example, if you read a snippet from a larger story that simply says, "John went to a restaurant. He ordered some food. He paid the check and left." You will assume, through your own personal schema regarding restaurants, that John actually received the food that he ordered, even though it is never specified in the text.

Shank had a very specific view of how people understood each other. "Understanding is knowledge-based. The actions of others make sense only insofar as they are part of a stored pattern of actions that have been previously experienced" [12:17]. This means that the ways in which a person understands the actions of another are based on any similar actions that person might have encountered before. Shank thought that these actions formed patterns, which he called scripts.

Shank then described a second mechanism needed for understanding, a script applied, as something that fills in the gaps left out of a story by referencing a script relevant to the story. In other words, as someone is listening to a story, they are forming a causal chain of events. Once there is a break in this chain in the mind of the listener, they must apply one of their own scripts to the story to attempt to fill in the gap and continue the chain.

Now came the crucial part that gave meaning to scripts from the story telling point of view:









When someone decides to tell a story that references a script, he recognizes that he need not . . . mention every detail of his story. He can safely assume that his listener is familiar with the referenced script and will understand the story as long
as certain crucial items are mentioned [12:32].

As mentioned before when explaining the idea of schemes, this means that stories can leave out trivial details that the author assumes the reader is already familiar with. This allows a narrative mapping to fit onto a structure without having to worry about mapping unnecessary details.

Shank does a nice job summarizing the main point of using scripts in storytelling in the following manner. "Thus, while it is possible to understand a story without using a script, scripts are an important part of story understanding. What they do is let you leave out the boring details when you are talking or writing, and fill them in when you are listening or reading" [12:35]. This is a crucial step in the process of applying narrative schema to a formal model. As mentioned above, this allows the unneeded details to be left out of the mapping, leaving only those parts applicable to the model itself.

While this does a good job forming a basis as to how a person can understand a narrative that is based upon some type of schema, or script in Schank's case, it does not provide a nice high level schema with which to form these narratives. Narratives, as Douglas puts it, must obey some type of order for us to use personal scripts to understand them. "Scripts can help nudge us toward comprehension at a local level only if we can recognize individual elements as part of a larger script . what enables us to understand what we see or read, is the relative fixity of the larger script" [4:3].

This is to say, people can understand schemes on their own, separate from larger narrative structures, but in order to form any type of lengthy narrative, you must create some high level narrative schema for the entire piece. In this way, you can then call upon









that overall narrative schema for not only the main narrative plot, but also for any smaller subplots you wish to add, adding depth and interest to your story.

2.4 Creating Narrative Structure

The next major step in a good structure for creating a narrative schema comes about from Beaugrande and Colby's definition of an "interesting narrative" as "evoking a world in which the action or event which changes the initial state to the goal state is not so obvious that it would probably happen anyway in the normal course of things . there must be substantial uncertainty about state-event-state chaining if the audience is to participate actively" [2:3]. This is where we start to break away from Flanagan and Allen's vague "beginning, middle, end" definition. This definition now gears narrative toward an active audience, which is ideal for our intentions with the rube project, where the very nature of the environment is geared toward interactivity.

Beaugrande and Colby go on to provide the two basic types of characters that should be included in a narrative schema, the protagonist and antagonist. "When the various events and states are assigned values according to one character's plans and goals, that character will be the protagonist if the audience shares those values, and the antagonist if the audience rejects them" [2:4]. This emphasis on the perspective of the viewer shows the personal nature of viewing such a narrative, which is exactly what we are going for . a move away from the abstract, back to the personal. The actions of these characters are also nicely defined as a "mutual influencing and blocking of event-state pathways" [2:4]. In this way, we get the idea of choices, or forking pathways, as in an FSM structure.

Beaugrande and Colby actually formulate a possible schema out of these ideas in the following manner:









" Identify character

" Create problem state for that character

" Identify a goal state for that character

" Initiate a pathway from the problem state to the goal state " Block or postpone attainment of the goal state " Mark one state transition as a turning point " Create a terminal state that is clearly marked as matching or not matching the
goal state.

While this is a very nice model for a possible narrative schema, it is still very linear, especially with the terminal state. However, Kintsch immediately deals with this: "This rule sequence is of course recursive, so that it may generate either a minimal story or an episode in a longer story" [9:3].

The two-character, protagonist and antagonist, version is quite similar, with a few allowances made for the second character. That is, two characters are introduced instead of one; the problem state for the first character is now caused by the second character; each character's goal state is undesirable for the other character; each character's actions block the progress of the other character, either somewhat or totally; the turning point state is decisively enabling for one character, disabling for the other; the terminal state sees a goal attainment for one of the characters. The seeming weakness in this case would be the existence of only two characters. What if three or more were needed for the mapping? A modified rule is supplied for that case, where one of the characters is given comrades in an effort to better block the other character. Each of these comrades can then be treated as a character in their own right. The problem there is that each character would then seemingly need the entire set of rules applied to them. Beaugrande and Colby









afford the reader a bit of leeway in this area: "The realization of all rules for every story or episode is not obligatory ., if a given rule is not explicitly realized; an audience will infer a default realization" [2:4]. This harkens back to Schank's scripts, where the reader fills in any gaps with their own expectations of the narrative schema.

Beaugrande and Colby further the parallel between narrative and FSM's when they quote Rumelhart' s definition of a narrated world as a "progressive system in which events and actions occur and bring about changes from one state to the next" [2:3]. They use Wright's definition of actions as intentional human acts that change the state of affairs. Since finite state machines consist of states and transitions, this is a very close parallel, and should map well. Dijk reinforces the idea of sublevels by saying that discourse is composed of a subclass of actions [9]. Therefore, multiple subclasses of actions, leading from state to state, could combine into a rich narrative structure.

The key idea that Beaugrande and Colby put forth in their argument, aside from their highly useful schema structure, is the combination of ideas by Schank and Rumelhart of "well -formednes s" in a narrative schema structure. "Well -formednes s of stories depends . upon the mutual accessibility of states and actions, and upon the relevance of actions to goal attainment. The audience expects that states and actions will not be tied into sequence unless each pair is linked by a discoverable relationship of cause, reason, enablement, or purpose" [2:4]. This continues to advance the requirements of a proper narrative schema structure from the basic "beginning, middle, end" that we started out with. It also continues the early ideas of Schank, requiring the readers to infer what those reasons and purposes might be if not given explicitly in the story, as stated above.









Bruner furthers the idea that narrative needs some type of causation by saying that narrative deals with the vicissitudes of human intentions [3]. He even goes so far as to say that people see causality in everything around them. Bruner then provides a very nice, simple skeleton on which to base our narrative schema structure for mapping purposes. "Life-like narratives start with a canonical or "legitimate" steady state, which is breached, resulting in a crisis, which is terminated by a redress, with recurrence of the cycle an open possibility" [3:4]. He also deals with the ever-present problem of linearity. "The story stuff, or fabula . could be plotted in linear order, in flashbacks, or even in media res, starting virtually anywhere" [3:4].

2.5 Conclusion

Thus, by combining Bruner's schema skeleton with Beaugrande and Colby's basic rules, we can form a well-structured narrative schema useful for our mapping purposes. We should of course continue to keep in mind the underlying reasons as to how and why people are able to understand this schema, as explained by Schank and others. This will help us to avoid problems arising from careless mapping procedures that might confuse and alienate the user.

Once a successful narrative schema can be created, a mapping structure will then be coded to map the schema onto the rube architecture, allowing the user to map any narrative onto a mathematical structure such as an FSM. This will then allow a person unfamiliar with FSM's to have a better understanding of the concept through a familiar narrative structure. If this idea gains popularity, it could ultimately change the way in which people learn about many complex ideas, allowing for a re-personalization not seen for quite some time.
















CHAPTER 3
RELATED WORKS

3.1 Multitalk

Multitalk [6] is a schema for creating combinatorically flexible stories. The research was motivated by Murray's philosophy on interactive narrative, and was written for her course of the same name. The Multitalk language is object oriented, and is composed of objects that represent the various things in the world, and morphemes that represent the actions that are applied to the objects. The language uses morphemes in order to be modular, instead of the usual tree based approach for interactive programs. Morphemes require specific preconditions to occur before they activate, allowing for multiple results with each interaction.

The test case given on the website uses a grammar similar to the SSIVL schema. It is comprised of the following: possibility, frustration, resolution, and conclusion. The difference is that this language is created purely for story interaction. It does not attempt any type of mapping onto mathematical models as SSIVL does.

3.2 Random Text Generators

Random text generators, such as the Dada Engine, RMutt, and others use recursion to randomly generate text files from basic grammars. The problem with each of these is that, for one, the grammar is never rich enough to come close to replicating a real language, especially the English language, and two, a randomly generated piece by its









nature would have trouble achieving any narrative cohesion, and would do little to help further a user's understanding of mathematical models.


3.3 Papert Constructionism

Paper worked in the area of learning processes, specifically for children. He viewed the current way of teaching mathematics to be analogous to the teaching of a "dead" language. "I maintain that construction of school math is strongly influenced by what seemed to be teachable when math was taught as a "dead" subject, using the primitive, passive technologies of sticks and sand, chalk and blackboard, pencil and paper" [11:21]. Paper believed that there was a better, more natural way to learn mathematics. He believed that children can learn complicated mathematical concepts through simplistic means that they are familiar with at an early age. "If we really look at the "child as builder" we are on our way to an answer. All builders need materials to build with . In the case of formal mathematics, there is both a shortage of formal materials and a cultural block as well" [11:32]. Thus, Papert believed that there was a need for some type of personalized set of "building blocks" for children to work with in order to learn complex mathematics, just as they had used actual blocks to learn basic mathematical concepts.

Paper used the idea of metaphor to create a program that used a "turtle", which walked around and drew lines in whatever manner was coded by the user. "The idea of programming is introduced through the metaphor of teaching the Turtle a new word" [11:36]. In this way, children learned very basic programming rules through the direct visual responses of the turtle.









3.4 Protege

Protege is a piece of software used for the creation and manipulation of ontologies. Ontologies contain knowledge about a specific domain in a structured manner. They can have many uses, such as knowledge sharing and recycling. In a technical or

programming sense, ontologies can be thought of as specifications for specific ideas. Protege is a way of creating ontologies using programming methodologies. Protege also can include visualizations such as tables, diagrams, and animations to display data. It also acts as a library for access to other collections of ontologies.

While looking at Protege, I found it to be extremely useful for ordering ontological data into an object oriented structure similar to the Java programming language. It ended up, however, being more complex than what I was looking for. I did not require the type of organization that it provided. I was looking for more of a simplistic interface for the user, which lets them write a story with as little superfluous requirements as possible.














CHAPTER 4
THE PROCESS

4.1 Initial Concerns

The biggest technical issue concerning the use of narrative schema for the rube project is that it services the mathematical models, not the other way around. In other words, it would be easy enough to say, given a certain story, create an FSM for that particular story. This, however, is not what we are looking for here.

What we want is the ability to take an existing FSM, and then create a narrative that maps directly onto that FSM. To do this, we need specific mapping rules for the narrative schema that allows it to be flexible enough to accommodate the creation of a story for any F SM.

4.2 Designing the Schema

To implement the schema I had researched, I developed a language that I termed Story Schema Modeling Language, or SSML. This language was created as an XML language, with an XN11L schema definition. Any user wishing to use the narrative schema must create an XML file that obeys the SSML coding rules.

In order to maintain the particular story schema I have chosen to work with, I was forced to create a minor limitation dealing with the creations of FSM's. The narrative schema requires the following at the simplest level: steady state, conflict, redress, and an optional final steady state. Thus, any FSM that uses this particular story schema must be composed of at least three states.










This is the parent group of all states.





Figure 4-1. SSML Schema Code.

Just as in any XML language, any file written in SSML (Story Schema Modeling Language) starts and ends with the opening and closing tags. In the schema, this tag is made up of an SSMLType complex type, which references a "states" group. The states group is then made up of the sequence of states required for SSML. This includes a mandatory steady state, written as when coding a sample file, followed by a group named "conred" in the schema. The "conred" group is coded in that way because conflict must always be followed by redress, so grouping the two was a coding optimization. This forces the user to then code and states at least once following the state.

Finally, there is another reference to the steady state, this time optional, since there does not necessarily need to be a final steady state. Each of the states in the schema then reference an element called "script," which is the tag used before and after all actual string text entered into any SSML file for the story. Since a film script is where the words are stored,









Figure 4-3. Simple SSML File.

The next step is to create the VRML geometry that will be the architecture for the narrative mapping. This includes all text nodes for each narrative state. The text nodes should not include the string attribute, since the NFE XSLT will create this. The VRMIL world must then be translated to X3D in order for the NFE XSLT to function properly.









Once the world is in X3D form, the SSML file and the X3D file are combined using the NFE XSLT. The X3D file is then translated back into VRMVIL. Until a more advanced XSLT is created, the next step is to add "," to each line of text so that it wraps correctly in the resulting VRML file. At this point, the world is ready for rube implementation.

The next step is to create an MXL (Multimodel eXchange Language) file for the mathematical model structure. Using rube in its current incarnation requires an FBM to act as the root node, but soon that will not be a requirement. After the MXL file is created, the javascript must be created to add functionality to the world. Once all files are created, they may then be merged using rube software. The final step is to edit the resulting world, adding proper variable types, javascript code, and routing.

























































Figure 4-4. Rube Coding Structure.














CHAPTER 5
CONCLUSION

5.1 Results

5.1.1 Example World

The world I have created as an example uses the version of rube current at the time of my coding. This version does not allow nested FSM's, so I rooted my world in an FBM, with an FSM nested inside of it. With the current work being done on rube implementation, the updated MXL schema will support nested FSM's.


Figure 5-1. Complex Example World.

The FBM consists of three blocks: an input block, a block containing an FSM, and an output block. The input block uses a simple random number generator to provide input to the FSM. The current state number is shown visually in the first block. The









FSM was originally designed as a multimodel FSM to show how narrative schema would work in a multimodel, but has been coded as one large FSM to conform to the current version of rube as of this writing. The text wall that represents the current state changes color from blue to red in the second block. The third block displays the narrative text at the current state. Users may click through the viewpoints to familiarize themselves with the straightforward narrative structure in the FSM, and thus have a better understanding of what they see in the third output block of the FBM.

The fact that spheres and cylinder are used for the FBM might seem strange when the entire idea of rube is to get away from abstract representation, but my aesthetic focus was on the FSM representation, as opposed to the FBM representation. My original plan was to show the FSM as a complex model, but the current version of rube does not support nested FSM's, so I was forced to use the FBM as the larger model. Since an extremely similar FBM structure had already been implemented by another graduate student, I simply used the same structure. The fact that it consisted of spheres and cylinders actually ended up being mere coincidence, and does not reflect any particular aesthetic design. It is used merely as a simple shell for my FSM model.


Figure 5-2. Simple FSM.


State 1 State 2




FSM
(simple)
State 3 State 6


/A State 4
State 5









Figure 5-2 provides an example of a simple linear FSM with narrative mapped to each state, or VRMIL wall. This is how my example had to be coded using the current version of rube. Figure 5-3 shows my original intention of implementing my example as a complex nested FSM, with simple FSM's nested inside the larger complex one.


Figure 5-3. Complex Nested FSM.

5.1.2 Other Possible Implementations

Since the SSIVIL narrative mapping is used as an aesthetic addition to the scene graph, many different implementations are possible. One idea could be to map an FSM onto an architectural model, such as a house, and then map the narrative onto the house. In this idea, each room could be a state, with halls acting as edges, connecting the rooms. In a multimodel system, the rooms could be nested models, with the halls being the simple states between the complex ones.

5.1.3 Concrete FSM's

For FSM's that model real-world phenomena or objects, the narrative could then reflect the target object or phenomena. The writer would have to create a story that


State 2 State 3

FSM
(simple) FSM
(simple)
State 4

State 1 FSM

(nested) State 5

State 8
FSN4
(simple) sp"'d
HUI
State 7 /A
State 6









corresponded correctly with each state of the FSM, as well as the genre of the target object. For instance, an FSM of a light bulb could have a narrative mapping that told a story involving a light bulb in some way, with each state of the narrative having some meaning that corresponds to the current state of the light bulb. Another alternative could be to have the current narrative state become readable by the action of the corresponding state of the light bulb. For instance, when the light bulb turns on, the text for that state becomes readable, and when the light bulb turns off, the text for the on state disappears, and the text for the off state becomes readable.

5.1.4 Branching FSM's

For FSM's that are conditional, or branch for whatever reason, corresponding narratives can be created for each condition. Stories like "Choose Your Own Adventure" that have branching possibilities would be ideal for FSM's that branch to unique finite ends. For FSM's that branch back into themselves, stories that revolve around fatalistic views could work.

In other words, these would be stories that operate on the idea that, no matter which path you take in life, the end result is the same. An example of this would be the recent cinematic remake of Wells' The Time Machine, where the main character goes back in time over and over in order to prevent the death of his wife, only to realize that she will die no matter what he does.

5.2 Future Work

5.2.1 Avatars

In order to attain a higher level of personalization and realism in the VRML visualization of rube, avatars could be used to act out stories. Avatars actually have dual definitions. In VRML, an avatar is a symbolic-virtual-world representation of a real-









world person [1]. Another definition for avatars is that they are an archetype. This plays into the idea of narrative schema perfectly, in that using archetypes keeps the stories open to the widest audience possible.

Efforts are currently underway to add Blender support to the rube architecture. Blender is a 3D package, similar to 3D Max and Maya, which allows the user to create 3D models and animation in a visual manner, as opposed to the coding interface of VRML. Ultimately, users will be able to visually create a world that is visually and artistically rich, and then export it in a manner that runs it through the rube architecture, creating a VRML world that includes simulation animation. Using this interface, users could then easily create avatars for the narrative mappings onto their FSM's.

5.2.2 Further Integration into Rube

A different use of the Blender interface could allow the narrative to be included visually. Blender supports the use of text objects, similar to 3D Max and Maya. Users could conceivably type their stories directly into the Blender interface, and then wrap them in whatever manner they wish, placing them wherever they want. This would eliminate the need for the XSLT file completely.

5.2.3 Narrative in Game Design

The idea of narrative schema mapping onto mathematical models, such as FSM's, could prove to be revolutionary in the area of game design. It could be the first step in a true marriage of writers and engineers on a game design team. For example, if writers come up with a compelling story, they could then easily put it into an SSML format, allowing the engineers to see the technical structure of the story so that they can then be aware of how they need to the design the game levels as well as how many decisions






27


must be made by the Al in the game. Similarly, if the engineers design the levels and code of the gaming world, the writers can then write a narrative to match that world.

As far as online multiplayer games, users could easily create their own "stories" to correspond with the design of the world in which they are playing. This would follow the classic idea of R-PG "Dungeon Masters."














APPENDIX A SSML SCHEMA


Story Schema Markup Language (SSML) schema for rube architecture.
Copyright 2003 University of Florida. All rights reserved.
Coded by John Hays.




This is the SSML root node.










This is the actual story text.







This is the parent group of all states.














This is the steady state, which bookends all other states.







This is the conflict state.







This is the redress state.

















This is the group of conflict and redress states.
Every conflict state must be followed by a redress state.




















APPENDIX B NFE XSLT

















































APPENDIX C SSML EXAMPLE FILES


C.1 Simplest SSML Example




C.2 Multiple Conflict/Redress Example














C.3 Complex SSML Example






















































C.4 Complex Example MXL Code



















PAGE 29

20 Once the world is in X3D form, the SSML file and the X3D file are combined using the NFE XSLT. The X3D file is then translated back into VRML. Until a more advanced XSLT is created, the next step is to add “,” to each line of text so that it wraps correctly in the resulting VRML file. At this point, the world is ready for rube implementation. The next step is to create an MXL (M ultimodel eXchange Language) file for the mathematical model structure. Using rube in its current incarnation requires an FBM to act as the root node, but soon that will not be a requirement. After the MXL file is created, the javascript must be created to add functionality to the world. Once all files are created, they may then be merged using rube software. The final step is to edit the resulting world, adding proper variable t ypes, javascript code, and routing.

PAGE 30

21 Figure 4-4. Rube Coding Structure.

PAGE 31

22 CHAPTER 5 CONCLUSION 5.1 Results 5.1.1 Example World The world I have created as an example uses the version of rube current at the time of my coding. This version does not allow ne sted FSMÂ’s, so I rooted my world in an FBM, with an FSM nested inside of it. With the current work being done on rube implementation, the updated MXL schema will support nested FSMÂ’s. Figure 5-1. Complex Example World. The FBM consists of three blocks: an input block, a block containing an FSM, and an output block. The input block uses a simple random number generator to provide input to the FSM. The current state number is shown visually in the first block. The

PAGE 32

23 FSM was originally designed as a multimodel FSM to show how narrative schema would work in a multimodel, but has been coded as one large FSM to conform to the current version of rube as of this writing. The text wall that represents th e current state changes color from blue to red in the second block. The third block displays the narrative text at the current state. Users may click through th e viewpoints to familiarize themselves with the straightforward narrative structure in the FSM, and thus have a better understanding of what they see in the th ird output block of the FBM. The fact that spheres and cylinder are us ed for the FBM might seem strange when the entire idea of rube is to get away from abstract re presentation, but my aesthetic focus was on the FSM representation, as opposed to the FBM represen tation. My original plan was to show the FSM as a complex model, but the current version of rube does not support nested FSMÂ’s, so I was forced to use the FBM as the larger model. Since an extremely similar FBM structure had already been implemented by another graduate student, I simply used the same structure. The fact that it cons isted of spheres and cylinders actually ended up be ing mere coincidence, and doe s not reflect any particular aesthetic design. It is used merely as a simple shell for my FSM model. Figure 5-2. Simple FSM.

PAGE 33

24 Figure 5-2 provides an example of a simp le linear FSM with narrative mapped to each state, or VRML wall. This is how my example had to be coded using the current version of rube. Figure 5-3 shows my origin al intention of implem enting my example as a complex nested FSM, with simple FSMÂ’s nested inside the larger complex one. Figure 5-3. Complex Nested FSM. 5.1.2 Other Possible Implementations Since the SSML narrative mapping is used as an aesthetic addition to the scene graph, many different implementa tions are possible. One id ea could be to map an FSM onto an architectural model, such as a house, and then map the narrative onto the house. In this idea, each room could be a state, with halls acting as edges, connecting the rooms. In a multimodel system, the rooms could be nested models, with the halls being the simple states between the complex ones. 5.1.3 Concrete FSMÂ’s For FSMÂ’s that model real-world phenom ena or objects, the narrative could then reflect the target object or phenomena. Th e writer would have to create a story that

PAGE 34

25 corresponded correctly with each state of the FSM, as well as the genre of the target object. For instance, an FSM of a light bul b could have a narrative mapping that told a story involving a light bulb in some way, w ith each state of the narrative having some meaning that corresponds to the current state of the light bulb Another alte rnative could be to have the current narrative state become readable by the action of the corresponding state of the light bulb. For instance, when the light bulb tu rns on, the text for that state becomes readable, and when the light bulb turn s off, the text for the on state disappears, and the text for the off state becomes readable. 5.1.4 Branching FSM’s For FSM’s that are conditional, or branch for whatever reason, corresponding narratives can be created for each condition. Stories like “Choose Your Own Adventure” that have branching possibiliti es would be ideal for FSM’s th at branch to unique finite ends. For FSM’s that branch back into them selves, stories that revolve around fatalistic views could work. In other words, these would be stories that operate on the idea that, no matter which path you take in life, the end re sult is the same. An example of this would be the recent cinematic remake of Wells’ The Time Machin e, where the main character goes back in time over and over in order to pr event the death of his wife, onl y to realize that she will die no matter what he does. 5.2 Future Work 5.2.1 Avatars In order to attain a higher level of personalization and realism in the VRML visualization of rube, avatars could be used to act out stories. Avatars actually have dual definitions. In VRML, an avatar is a sym bolic-virtual-world representation of a real-

PAGE 35

26 world person [1]. Another definition for avatars is that they are an archetype. This plays into the idea of narrative schema perfectly, in that using archetypes keeps the stories open to the widest audience possible. Efforts are currently underway to add Bl ender support to the rube architecture. Blender is a 3D package, similar to 3D Max and Maya, which allows the user to create 3D models and animation in a visual manne r, as opposed to the coding interface of VRML. Ultimately, users will be able to visu ally create a world that is visually and artistically rich, and then expor t it in a manner that runs it through the rube architecture, creating a VRML world that includes simulatio n animation. Using this interface, users could then easily create avatars for th e narrative mappings onto their FSMÂ’s. 5.2.2 Further Integration into Rube A different use of the Blender interface c ould allow the narrative to be included visually. Blender supports the use of text objects, similar to 3D Max and Maya. Users could conceivably type their stories directly into the Blender interface, and then wrap them in whatever manner they wish, placing them wherever they want. This would eliminate the need for the XSLT file completely. 5.2.3 Narrative in Game Design The idea of narrative schema mapping onto mathematical models, such as FSMÂ’s, could prove to be revolutionary in the area of game design. It could be the first step in a true marriage of writers and engineers on a ga me design team. For example, if writers come up with a compelling story, they could then easily put it into an SSML format, allowing the engineers to see th e technical structure of the story so that they can then be aware of how they need to the design the game levels as well as how many decisions

PAGE 36

27 must be made by the AI in the game. Simila rly, if the engineers design the levels and code of the gaming world, the writers can th en write a narrative to match that world. As far as online multiplayer games, users c ould easily create their own “stories” to correspond with the design of the world in whic h they are playing. This would follow the classic idea of RPG “Dungeon Masters.”

PAGE 37

28 APPENDIX A SSML SCHEMA Story Schema Markup Language (SSML) schema for rube architecture. Copyright 2003 University of Florida. All rights reserved. Coded by John Hays.
This is the SSML root node. This is the actual story text. This is the parent group of all states.

PAGE 38

29
This is the steady st ate, which bookends all other states. This is the conflict state. This is the redress state.

PAGE 39

30
This is the group of conflict and redress states. Every conflict state mu st be followed by a redress state.


PAGE 40

31 APPENDIX B NFE XSLT

PAGE 41

32 APPENDIX C SSML EXAMPLE FILES C.1 Simplest SSML Example C.2 Multiple Conflict/Redress Example

PAGE 42

33 C.3 Complex SSML Example

PAGE 43

34
C.4 Complex Example MXL Code

PAGE 44

35