**4. Methodology**

290 Petri Nets – Manufacturing and Computer Science

Figures 5(a)-(b).

definitions and PN terms.

**Figure 6.** Mapping a process definition onto Petri nets.

Data that flows between

**Table 3.** Mapping Workflow process onto Petri nets (PN) terms.

Workflow Perspective PN terms

tasks/case attributes Tokens Conditions Places

Task execution One or more transition Work item Transition being enabled Activity Firing of a transition

**Figure 5.** An illustration for both linear and branching narrative progressions.

of events is narrated from beginning to ending without variation or possibility of a user altering the way in which the story unfolds or ends. Some computer games use branching narrative in which there are many points in the story at where some action or decision made by the user alters the way in which a narrative unfolds or ends. Both narratives are shown in

(a) Linear Narrative Progression (b) Branching Narrative Progression

Since Petri Nets (PN) are a process modeling technique, then modeling a "workflow process definition" onto PN is straightforward: tasks, conditions, and cases are modeled by transitions, conditions and tokens respectively. Figure 6 shows how all these concepts can be mapped onto the Petri net. Table 3 shows the mapping between the workflow process Computer games are defined as an activity with some rules engaged in for an outcome. Key components of games are goals, rules, challenge, and interactivity. Games are regarded in terms of three levels of temporal design, from simulation at the lowest time scale, through the design of game moves above the simulation level, to the structure of specific narrative patterns at the highest level. The methodology in our approach is based on the study of workflow process under these levels for the structural parts of a computer games and is shown in Figure 7.

**Figure 7.** The structural parts of computer games.

The diagram in Figure 7 is composed of three parts: the "Input" peripheral devices allowing the user to enter choices. These choices are then evaluated by the rules of the "Computing" part, in order to produce a "result". This result is finally communicated to the player through the "Output" device. Computer game development is a tremendous task that requires different roles for the storyteller and audience, and a lot of resources including: storytelling elements and elemental interplay. Storytelling elements includes: narrative, plot, and story. The interplay of elements in the game environment consists of: structure, theme and metaphor. The structure describes the influence of plot on narrative. Theme is the expression of the story within the plot. Metaphor is the means by which story is encoded within the narrative. From the technical point of view, game can be seen as a client-server application connected with some data. From the conceptual point of view for game representation and according to (Salen, K., Zimmerman, E., 2003), computer games are defined as an activity with some rules engaged in for an outcome. Therefore, there is a need to develop an integrated framework for deeply combining interactivity and narrative. As a sort for achieving this goal and under the study of workflow management concept, Figure 8 shows a design of a workflow activity process for the conceptual representation of computer games.

Figure 8 shows how the conceptual representation of a game can be modeled as a series of processes, where each process consists of some activities. Activity is a description of a piece of work that forms one logical step within a process. An activity has one or multiple roles, zero or multiple rules, zero or multiple event and one or more multiple data. Partial order relationships between activities (e.g. sequential, parallel, alternative and looped) are notated with the arc, which links the activity entity to itself. The activity also contains the rule entities to describe the conditions under which the activity may be fired. The rule is used to

State of the Art in Interactive Storytelling Technology: An Approach Based on Petri Nets 293

the workflow management process of games rules and an attempt to classify them in terms of the game elements constitutes the game environment. By focusing on games as rules we means looking at games as reactive systems, both in the sense that the rules are inner structures that constitute the games and also in the sense that the rules schemas are analytic tools that mathematically dissects games. As a result, we found it is necessary for game developers to distinguish between the enabling of a task and the execution of a task. Since the enabling of a task does not imply that the task will be executed immediately, it is important to have this distinction. In order to have this distinction, we should consider triggering of tasks in the game's flow environment. A trigger is an external condition which leads to the execution of an enabled task. One way to perform this is to separate the rules of the game environment based on whether its template is direct or indirect related to the goal of the game into two parts: controllable rules, and uncontrollable rules. Controllable rules are the rules in which its template is directly related to the goal of the game, mainly as a feedback within the rule effects. In this case, the rule is characterized by a trigger based on the state of the game elements, and an effect linked to the computer game's output. The uncontrollable rules are the rules in which its template is independent from the game goal. The rule is then characterized by a trigger based on the computer game's input, and an effect targeting only the game elements. An example for the template is the one given by: "if player element collides with a hostile element, then there is a negative feedback towards the player element". The real power of separating these rules illustrates how the separation of them allow us to explicitly specify what parts of the model comprise the system and what

parts comprise the environment. For this purpose we used four types of tasks:

**Figure 9.** The triggering concept for user task called "A" workflow activity process

ii. user: a task is triggered by participant/actor; iii. Message: an external event is required, and iv. time: the task requires a time trigger.

terms of HLPN for user task "A" as shown in Figure 9.

i. automatic: a task is triggered the moment it is enabled (i.e. No trigger is required);

An awareness of a narrative's time line is an important element to focus on when creating the environment for an audience's imagination. The triggering concept can be modeled in

Since game is defined as an activity with some rules engaged in for an outcome. So, game activity can be represented now as: activity = task + case + (resource) + (trigger), where

**Figure 8.** Game workflow activity process

describe logic conditions for executing activity and always related to case "data". The "application" entity extracts software tools, by which the role completes the activity, and the "data" depicts the input and output data of the activity. Since the game engine we are going to propose in this paper executes workflows represented in terms of PN. The classical structure of a PN model is formally defined by a set of places, a set of transitions and a set of arcs connecting places to transitions and vice versa. For the purpose of this chapter we extend the classical PN with features that make them more suitable for workflow representation given in terms of High level Petri nets (HLPN) workflow (Jenson, K., 1997). An HLPN is normally represented using a graphical form which allows visualization of system dynamics (flows of data and control). By using HLPN formalism it is possible to


An HLPN can be defined by the tuple: HLPN= (P, T, Type, Pre, Post, E, G, *M*0), where


Now let us analyze the game workflow activity shown in Figure 8 in terms of HLPN and game components. Key components of games are goals, rules, challenge, and interactivity. Games takes place in a virtual universe and it is composed by several elements, where these elements are submitted to "rules", in accordance to the game. Since a workflow system is a reactive system, i.e. it is triggered by the environment. This means that, enabling of a task doesn't imply that the task will be directly executed. Therefore, the objective is to analyze the workflow management process of games rules and an attempt to classify them in terms of the game elements constitutes the game environment. By focusing on games as rules we means looking at games as reactive systems, both in the sense that the rules are inner structures that constitute the games and also in the sense that the rules schemas are analytic tools that mathematically dissects games. As a result, we found it is necessary for game developers to distinguish between the enabling of a task and the execution of a task. Since the enabling of a task does not imply that the task will be executed immediately, it is important to have this distinction. In order to have this distinction, we should consider triggering of tasks in the game's flow environment. A trigger is an external condition which leads to the execution of an enabled task. One way to perform this is to separate the rules of the game environment based on whether its template is direct or indirect related to the goal of the game into two parts: controllable rules, and uncontrollable rules. Controllable rules are the rules in which its template is directly related to the goal of the game, mainly as a feedback within the rule effects. In this case, the rule is characterized by a trigger based on the state of the game elements, and an effect linked to the computer game's output. The uncontrollable rules are the rules in which its template is independent from the game goal. The rule is then characterized by a trigger based on the computer game's input, and an effect targeting only the game elements. An example for the template is the one given by: "if player element collides with a hostile element, then there is a negative feedback towards the player element". The real power of separating these rules illustrates how the separation of them allow us to explicitly specify what parts of the model comprise the system and what parts comprise the environment. For this purpose we used four types of tasks:


292 Petri Nets – Manufacturing and Computer Science

**Figure 8.** Game workflow activity process

iii. deal with dynamic workflows.

 P is a finite set of elements called places T is a finite set of elements called transitions

of arcs from transition to places

Type(G(t))=Boolean);

i. formally represent the workflow state (and its evolution); ii. formally describe both the control and the data flow, and

"Type" is a function that assigns a type to places and expressions;

*M*0 is the initial marking: a multi-set of tokens associated with the places

describe logic conditions for executing activity and always related to case "data". The "application" entity extracts software tools, by which the role completes the activity, and the "data" depicts the input and output data of the activity. Since the game engine we are going to propose in this paper executes workflows represented in terms of PN. The classical structure of a PN model is formally defined by a set of places, a set of transitions and a set of arcs connecting places to transitions and vice versa. For the purpose of this chapter we extend the classical PN with features that make them more suitable for workflow representation given in terms of High level Petri nets (HLPN) workflow (Jenson, K., 1997). An HLPN is normally represented using a graphical form which allows visualization of system dynamics (flows of data and control). By using HLPN formalism it is possible to

An HLPN can be defined by the tuple: HLPN= (P, T, Type, Pre, Post, E, G, *M*0), where

Pr ( ) *e PT* is the subset of arcs from places to transitions and *Post T P* ( ) is the set

 E is an expression. It is defined from (Pr ) *e Post* into expressions. Expressions may comprise constants, variables (e.g. m,n) and functions (e.g. g(x)) which are types; G is the guard function, a Boolean expression inscribing a transition ( ) *t T* (where

Now let us analyze the game workflow activity shown in Figure 8 in terms of HLPN and game components. Key components of games are goals, rules, challenge, and interactivity. Games takes place in a virtual universe and it is composed by several elements, where these elements are submitted to "rules", in accordance to the game. Since a workflow system is a reactive system, i.e. it is triggered by the environment. This means that, enabling of a task doesn't imply that the task will be directly executed. Therefore, the objective is to analyze An awareness of a narrative's time line is an important element to focus on when creating the environment for an audience's imagination. The triggering concept can be modeled in terms of HLPN for user task "A" as shown in Figure 9.

**Figure 9.** The triggering concept for user task called "A" workflow activity process

Since game is defined as an activity with some rules engaged in for an outcome. So, game activity can be represented now as: activity = task + case + (resource) + (trigger), where trigger is one of the previous mentioned tasks. This activity represents the actual execution of a task for a specific case. Now let us analyze the effects of trigger concept and game rules (controllable/uncontrollable) applied to the proposed case study game "crazy ball 2". Games takes place in a virtual universe and it is composed by several elements, where these elements are submitted to "rules", in accordance to the game. For example, table 4, shows some of the universe "elements" applied for the case study game "crazy ball 2" and its uses. These elements are submitted to different rules, for instance, "if the red ball element jumps towards the player, then it explodes on touch". By analyzing this rule, we realized that it is composed of two parts: (i) the "trigger": "if the red ball element jumps towards the player,", and (ii) the "effect(s)": "then it explodes on touch". In the same logic, the goal of a game can also be described and controlled by its rules.

State of the Art in Interactive Storytelling Technology: An Approach Based on Petri Nets 295

The following flowchart summarizes the idea, where T is a set of transition instances in the given HLPN, *Tdisabled* is a subset of T with elements having status disabled, and *Tunknowns* is a

Status (try finding an enabled binding for *candidate t* , make it occur and return

**Figure 10.** Game rules as a triggers and effects.

**Figure 11.** Game workflow activity engine

**Step 1.** (Initialization)

({ } ) *T T dependents candidate*

 End if ; End while

*T T unknowns* and *count* 0

*Tdisabled*

**Step 2.** (Loop) While (*Tunknowns*

subset of T with elements having status unknown

) do

*candidate t* (random element from *Tunknowns* )

else if status=occurred Then ( *count count* 1 )

Move ( ) *T T dependents disabled* from *Tdisabled* to *Tunknowns*

occurred. Otherwise return enabling status)

if (status = disabled) Then (move *Tcandidate* from *Tunknowns* to *Tdisabled* )



Now, the question is how can we construct game rules that include game goals? The answer to this question is derived from the study of both HLPN and game workflow activity process previously mentioned. As a result, we defined the "game elements" as "a canvas of rules", a diagram to follow in order to build a rule or a group of rules in a computer games. This is done by composing the game rules by different triggers and effects as shown in Figure 10. The game workflow activity engine forr crazy ball 2 is shown in Figure 11.

**Figure 10.** Game rules as a triggers and effects.

294 Petri Nets – Manufacturing and Computer Science

also be described and controlled by its rules.

Player control

Game envirnoment

**Table 4.** Some game elements for the Crazy ball 2 game and its uses.

Game Elements Uses

trigger is one of the previous mentioned tasks. This activity represents the actual execution of a task for a specific case. Now let us analyze the effects of trigger concept and game rules (controllable/uncontrollable) applied to the proposed case study game "crazy ball 2". Games takes place in a virtual universe and it is composed by several elements, where these elements are submitted to "rules", in accordance to the game. For example, table 4, shows some of the universe "elements" applied for the case study game "crazy ball 2" and its uses. These elements are submitted to different rules, for instance, "if the red ball element jumps towards the player, then it explodes on touch". By analyzing this rule, we realized that it is composed of two parts: (i) the "trigger": "if the red ball element jumps towards the player,", and (ii) the "effect(s)": "then it explodes on touch". In the same logic, the goal of a game can

Used in the combat system to control the player using mouse and

Used as the door object in the game's stage, it has an animation that

Used as the model for the player's hit points (HP). Eight heart graphics models are used to display player's HP on the screen.

Used as the Information Signs' object. The question mark has a

also used for the render that made the Game Over screen

Used as a model for Bad Ball and Red Ball enemies.

allows the grey stone part to slide open upwards.

rotation animation that is constantly active in the game. Used for setting the sword swing power (force) display

Now, the question is how can we construct game rules that include game goals? The answer to this question is derived from the study of both HLPN and game workflow activity process previously mentioned. As a result, we defined the "game elements" as "a canvas of rules", a diagram to follow in order to build a rule or a group of rules in a computer games. This is done by composing the game rules by different triggers and effects as shown in

Figure 10. The game workflow activity engine forr crazy ball 2 is shown in Figure 11.

**Figure 11.** Game workflow activity engine

The following flowchart summarizes the idea, where T is a set of transition instances in the given HLPN, *Tdisabled* is a subset of T with elements having status disabled, and *Tunknowns* is a subset of T with elements having status unknown

**Step 1.** (Initialization)


**Step 2.** (Loop)

	- *candidate t* (random element from *Tunknowns* )
	- Status (try finding an enabled binding for *candidate t* , make it occur and return occurred. Otherwise return enabling status)
