modular design of game levels: a case in serious games€¦ · the game has been developed by...

Modular Design of Game Levels: A Case inSerious Games

Master in Game and Media Technology,Utrecht University,

Department of Information and Computing Sciences

Author:Enrico Ribelli

Supervisor:Dr. Fabiano Dalpiaz

Abstract. Developing a serious game, which creates awareness aboutDoctor of Philosophy (PhD) students, is the task fulfilled in this project.The game has been developed by getting advantage of a modular design,which allows the creation of game-levels through the definition of a levelconfiguration file. We researched how modularity approaches bring ben-efits in building a game and we found out that such techniques can beused in several and different fields of the development process. Applyingthis design to our game provided us with the possibility to create ourown game levels. In fact, we exploited such modularity and built twomission examples regarding the PhD student life.

1 Introduction

With technology improvement having turned into a continuous process that leadsthe game companies in developing attracting games, creating software whosecapability is to provide high amusement to the players has become a covetedaspiration. This task can be accomplished in several ways. One of those is bymaking use of those new high-quality components that the fast-paced technol-ogy research provides us with. Unfortunately, it is common practice, especiallyfor those who are just getting started into the game field, to create new andunique components (assets, pieces of code, etc.) that cannot be reused, even inslightly different contexts. It shows: all too often, chunks of games are discardedinstead of intelligently reapplied. A useful and wise technique would consist indesigning a method which allows to create modules, suitable to be reused duringthe development process.

The aforementioned principle is considered the base concept of a modulardesign. Epic games gives the following definition of modularity:

”modular design is concerned with making lots of high-quality chunks oflevels and reusing those chunks intelligently” [9].

However, this concept is not limited to high-level contents like textures, mod-els or, in general, assets. In fact, it can be used and extended to any level ofdepth during the game development process, starting from the first program-ming step until the last texture inserted in the scene. In software engineering,indeed, Crnkovic and Larsson [4] denounce the continuous rise in complexity andsize of software programs. In order to cope with such phenomenon, flexibility andadaptability become fundamental features of a software. In [4] the emerging ap-proach described is called Component-Based Development (CBD). Componentsare the base part of a software, they get developed in such a way they can beintegrated, assembled and reused in accordance with the same modular designadopted in our game.

1.1 Problem to be solved

The aim of this project consists in creating a prototype of a serious game whichprovides the user with the capability to build his own game level, by using ourmodular framework and without touching any line of code. This software can beused by anyone, where the gamer can also be the level designer and distinctionbetween the two kind of users might not be necessary.We chose to develop a serious game because we wanted to focus on both creatingawareness and targeting some software engineering aspects. This comes at theexpense of creativeness and amusement. We want the player to earn somethingwhich is not only mere entertainment but also knowledge, in this specific case,about PhD students life.Our first step was based on finding a mechanism/technology which gives thegamer this kind of power. Numerous compromises were needed before and es-pecially during the development process in order to understand which level offreedom should have been given to the user. In other words, finding and devel-oping the modules that the gamer would have been able to orchestrate was oneof our main tasks.

1.2 Challenges

Coding means using a programming language that has a high level of expressionand therefore a remarkable flexibility. By coding, any aspect – or almost – thatthe programmer wants to pursue and show through his game, can be achieved.We cannot give the user such power for a reason: the game has to adhere tocertain criteria and seek after a specific purpose. Moreover, one of the mainaspects of our project is that we want to achieve modularity without coding.What we want to provide the user with is not the possibility to code but amodular and code-less approach. This implies less freedom and manageability ifcompared with the opportunity to code.Furthermore, two factors are affected by this decision: attractiveness and targetaudience. About the former, a remarkable challenge consisted in finding a trade-off between flexibility and expressiveness. In fact, our aim was to create anappealing game capable to divulge the message that the user wants to show. In

addiction, the target audience that we want to approach is composed by peoplewho have no clue on how to code. This involves a difficulty in making this modeleasy to be used by that range of users.At last, we wanted to focus our attention on choosing a modular design suitableto create missions. Those, or levels if we want to consider them as steps thatconstitute a PhD job, represent the facet of the game that we wanted to makemodular, in such a way that several and different scenarios can be created.

1.3 Running example: PhD game

We can define this prototype as a serious game based on the Doctor of Philosophy(PhD) life. As explained before, anyone can be both player and game designer.However, it would be more reasonable to let a PhD student use it in order torepresent his working life (game designer) and allow someone out of the field(player) grasping what the game wants to teach.

The game-play takes place in a built-in scenario. The environment is com-posed by areas and assets where the player is able to interact with BOT’s andobjects, necessary to complete the level missions.

It is necessary to remind and underline that this is not a normal game buta serious game. Indeed, a challenge behind this experiment was describing andgiving an idea of what a PhD student is. What we tried to implement wasa way to demonstrate and explain how a PhD conduces his life inside of hisworking field, the way he leads his job, the tasks he receives, the way he has tofulfill them, the obstacles he faces and the plan behind his research. Differencesbetween kind of PhDs, diversities in tasks and procedures for each Universitycan be also shown through the use of this software by creating missions that arecoherent with the working style of that PhD student.

The most significant aspect, which is key to our work, is that the user is theone who is able to choose how to demonstrate the points above, by defining themissions that the player has to accomplish. Another remarkable facet is thatmultiple story paths can be built in the same level, depending on the choicesthat the user takes. Further explanations will be given later.

It is now necessary to explain the approach chosen to make people aware ofa PhD life. Two aspects are fundamental:

– game design

– learning pattern

The game design that we chose, efficient for our purpose, is based on a lev-el/story structure where progression in missions drives the user to make a praise-worthy work. The resulting learning pattern expresses how the freedom of choiceis therefore important, since the user is led to take decisions and learn from hismistakes.

2 Related work

In our application we face an approach that can be seen and defined as mis-sion/level modularity. Unfortunately, there is a lack of literature about this topic.However, despite we may think it only refers to high-level concepts, deep-leveldeveloping decisions were needed to make this possible.Game Engines are an example of modular framework used to develop a game.

”In today’s modularly constructed games, the game’s engine refers tothat collection of modules of simulation code that do not directly specifythe game’s behavior (game logic) or game’s environment (level data).The engine includes modules handling input, output (3D rendering, 2Ddrawing, sound), and generic physics/dynamics for game worlds. ”[7]

The overall structure is shown in the picture below:

Fig. 1. Game Engine modular structure [7].

We are now going to face a few scenarios where modularity approaches areconsidered during the development of a game.

2.1 Creating modular assets

Bethke [1] defines the following as game assets: 2D sprites, 3D models, missions,levels, areas, voice, key framing, motion capture, sound effects, music and specialeffects. Above all, most of the attractiveness of a game is often based on thegraphical content. Nowadays AAA games are leading the market and such gamesare expected to be containing amazing design and graphics.[3]

”The modular level design solution arose from the need to have great-looking, high-detail levels without having to build and texture every nookand cranny of the environment.”[11]

A resource-saving economy is one of the main concerns and advantages ofany modular technique. Creating a non-modular component might be faster andeasier than creating a modular one. However, if later in the process furtherinstances of the mentioned object need to be used, it will come easier havingreusable parts instead of creating new ones every time [9].A further benefit is that focusing on details requires to be done just once, sincethe improvements will be received by all the instances.Similarly, small changes on a modular chunk are easily applied to any instanceof the mentioned, saving time and resources.On the contrary, Epic Games says:

”If you are just making one room, then a non-modular room may bemuch faster to create than making separate pieces.”[9]

This is worth and reasonable when we deal with unique and singular piecesthat will not be reused later during the development process.Programmed planning sessions are also needed to understand what the gamerequires the developers to create, choosing which components have to be modularaccordingly. In fact, in order to have a reusable component, this needs to beadaptive to different or, at least, similar circumstances. Achieving this behaviorrequires brainstorming sessions, aimed to grasp and find out the key features,the unique aspects and, in general, the kind of environment which defines thelevels. Inaccurate methods, whose aim is to have a piece ready to be used assoon as possible, often result to be expensive in terms of resources.

According to Perry[11] a planning session has to investigate through thefollowing points:

– ”Leave the specialized pieces aside, focusing on the meat of the en-vironments, the areas where players will spend the majority of theirtime”

– ”Which key modular components are needed and plan out the generaluse of those pieces”

– ”Make a shopping list of components needed for a flexible base set”– ”Plan out how to blend one theme into another ”– ”Note which structures may need capping off, and give a thought to

how that should be done”

Hence, creating modular assets is not an easy task. Perry[11], like also PaulMader [10], provides us with a checklist involving well defined points that it isgood practice to adhere, like for example choosing and working with a definedgrid.Drawbacks and flaws have to be equally considered:

– further communication levels have to be established between the roles work-ing behind a game. Some points may require the intervention of other people.

”Because the work is now solidly split between artists and level de-signers, there may be additional layers of communication that needto be established”[9]

– If a module contains a flaw, all its instances will have it as well.– If a chunk is modified during the development, it may bring problems for

bad interactions with other parts of the game

Moreover, Epic Games [9] states that: even though the workflow receives aspeed up thanks the reuse, it may still be a restrictive approach, especially forartists who have to adhere to certain standards. However Perry[11] likes to refutethis point underlining that:

”With intelligent planning, modularity is not as restrictive as you mightthink. Indeed, modularity can be implemented on many scales. [...] Thiscan generally be determined by the scope of your environments. If you’regoing to be shoving a player through entire cities in a Porsche, you’llwant to break everything down into chunks of geometry as large as entirecity blocks. If you’re going to be creeping a single player through thenarrow, abandoned corridors of a derelict spacecraft, you’ll want to workat a very fine detail level with layers of components interacting in acomplex fashion. ”[11]

As last drawback, we face the monotony that reusable contents may causedue to a negligent reuse.

”A major concern with making modular pieces is the fear that the playerwill be able to see the reuse of the chunks ”[9]

For example, the following three screenshots are taken from separate Obliviondungeons and it is noticeable how the three scenes look like each other:

Fig. 2. Similarity of Dungeons in Oblivion [2].

In [2] the repeatedly use of assets is defined as ”Art Fatigue” but can besolved by minimizing needless repetitions. Moreover, it is possible to break thesense of monotony felt by the gamer by using small and costless stratagems. Forexample Scott Jones [12] talks in his paper about how a different use of lights can

change the gamer perception and mask the reuse of the same objects. Anotherapproach suggested by Scott consists in a smart use of the height:

”If a player changes height they know they are going to a new location,instead, if the player goes through a series of paths and come to an areathat is similar looking depending on the paths it may seem as if they havebeen there before and possibly causing confusion. ”[12]

Hence, some considerations have to be taken before creating assets througha modular approach.

2.2 Modularity in Artificial Intelligence

Designing AI results often being a complex process due to the fact that intelli-gences are most of the times written from scratch [5]. Those beneficial aspectsof modularity that we faced above can be likewise used in this field. Wastingdevelopment time and resources can be avoided reusing those elementary behav-iors that can be common for many basic AI. Efforts can be in this way be spentin creating more complex, interesting and unique behaviors. Another advantagelies on the fact that reusing modules and combining them can give as result largesets of AI.However, an obstacle consists in defining an AI formalism. Despite in other fields,like Computer Graphics where primitives object (e.g a triangle) are consideredbasic units, there is nothing similar in AI.The approach proposed by Dragert, Kienzle and Verbrugge [5] consists in alayer-based separation of Statechart-based AI-modules where each statechart isa modular component, with an independent role, representing a behavioral con-cern. As we know, a typical AI is game-events driven. Therefore the first layerin the structure has the aim of grasping the game-state and its events. Otherlayers will have the role of memorizing the relative data, some others will takethe decisions that have to be performed and some will execute those decisions.It is clear that each state acts on its own but communication between layersis required. That is why each Statechart can interact with the layer above andbelow.

Fig. 3. The Layered AI Model Architecture [5].

It is now clear how each layer has its own duties:

”Due to the clear demarcation of duties, the components are ideal forreuse.[...] Designing a new AI through the reuse of existing AI modulesis a process of selecting behaviors described by existing modules, and thenlinking them together to form a working system.”[5]

Another approach is the one proposed by Florez-Puga and Dıaz-Agudo [6].As common in describing an AI, they make use of FSMs in order to defineeach behavior. Aiming to make the decomposition of complex behaviors easier,they use a particular kind of FSM: Hierarchical Finite State Machines (HFSMs).Generally, a drawback of FSMs consists in having a large number of states, whichmakes the machine truly complex. Through HFSMs this scenario can be avoideddecomposing states in sub-FSMs. In the picture below we give an example thatshows how the ”Attack” state of the left FMS is defined with the right FSM.

Fig. 4. Example of HFSM [6].

Moreover, a graphical interface is adopted to design new behaviors. The ideabehind this concept is close to the one pursued in our project: users are providedwith the ability to modularly create or modify an aspect of the game withoutknowing any technical knowledge of it. In the method proposed by Florez-Pugaand Dıaz-Agudo [6] there is a real interface where users can build new AIs by

just drawing them. Conversely, we do not have a graphic interface for drawing,but the concept is that our users can create new levels in the same modular way.

Different is the method followed by Lim & co. [8], where modularity is dif-ferently exploited in order to create new AIs. Their appealing way consists inusing behavior trees instead of FSMs. In contrast with Florez-Puga and Dıaz-Agudo[6], they sustain the idea that HSFMs are not enough when an AI becomestoo complex. Each tree is composed by sub-behaviors (branches) and has its owngoal to pursue and achieve. They can also be combined in order to create morecomposite AIs and the leaves of a tree are used to define the low level actions.

2.3 Use of modularity in Game Companies

Considering only the technical aspects of modularity may hide some of the rea-sons why game companies take advantage of it. We may reasonably believe thatmost of the companies using modular approaches are serious game ones. This isjustifiable with the fact that the resources owned by these are much lower thanthose held by AAA game companies. Joel Burgess[2] both sustains and confutesthis idea stating:

”Let’s begin with a pretty simple observation: our games are big. Ifyou’ve played or read about Skyrim, Fallout 3 or any of our other open-world games, scope is a big part of them. ” and more, talking specificallyabout Skyrim: ”There’s a massive amount of world-building to be donein Skyrim, and not having to specifically create and export every fencepost and doorway becomes very important to us. We try to be smart aboutwhere we spend our time and attention, reusing art where it makes sense,and investing time where we want something more unique.”[2]

Therefore, AAA game companies seems having a great need of a modular design.This is no less important for smaller companies because the Joel’s modularapproach can be applied to any size of development team:

”modular approach helps if your team has a low ratio of artists to de-signers.”[2]

In fact, he takes into account the specific case of the Skyrim developing team,explaining the double benefit of using modularity in a small group. In the caseof Skyrim, 8 out of 10 people were the level designers while the remaining twowere the full-time kit art team. The latter generated 7 kits which have been usedby the former group to create 400 cells. Therefore, the first benefit consists inthe fact that a small group can support a much larger team.

The second and less obvious advantage is that, while such a small group (10people in total) was working on the whole dungeon component of the game,the remaining part of the team (80 people) could focus on plenty of other tasksinherent to the creation of a game.

Hence, it is not possible to draw a general conclusion to decide which categoryof game companies has more necessity to create modular components becauseboth types take advantage of this approach.

3 Solution Design

3.1 System architecture

We want now to present a conceptual description of the architecture at the baseof our application. This prototype has been created by using a game enginewhich exploits some data provided by a level interpreter built on the top. Thementioned interpreter takes the level input, specified by the user, reads thecontent, interprets it and passes the result to the game engine, which creates theresulting missions.

Two kind of inputs are provided by the user:

– Mission file– Dialog file

In the Mission file are described both the possible actions that the player canexecute and the sequence of tasks that he has to perform in order to attain therelative mission. On the other hand, in the Dialog file all the possible dialogs arewritten down. In both cases a strict formalism, that we will explain later, has tobe followed.

Fig. 5. System Architecture

The Interpreter loads both files at runtime. We opted for this solution be-cause it is useful not to consider them as part of the scene and allowing forinterchangeable game content. Both assets are then parsed and relative instruc-tions are sent to the Game Engine which will elaborate and associate them -where necessary - to the game content.

3.2 Conceptual view of the XML

Both the Mission and Dialog files are written in XML. In this section we proposea conceptual view of these files that the user has under his control.

Before going into detail, it is necessary to understand how a typical scenario isstructured. In our prototype, a level is composed by actions and dialogs. Thoseare not independent from each other, and hereby we propose a class diagramwhich shows the relation between these two objects:

Fig. 6. XML Class Diagram.

We are now going to give a brief explanation of the diagram above. OurMissions are defined as Objectives where each Objective can be accomplishedby completing the Actions (at least one) that are part of that mission. Thoseare tasks that can be of two different kinds: Static Actions or Dynamic Actions.The former are actions already implemented in the game. However, they still canbe modularly modeled according to the goal we want to achieve. The latter areactions defined and created by the user. In fact, he has the capability to createall the tasks that he considers as constituent steps of a mission. Although StaticActions are already associated to specific assets contained in the game environ-ment, by using a Dynamic Action it is possible to choose which BOT/object theplayer wants to interact with. Nevertheless, only some components, within a list

that we will provide later, can be used for this purpose. Moreover, in order toprovide higher flexibility and modularity, we give the possibility to associate adialog to any Dynamic Action.

Another fundamental component of the gameplay is a Stat. The characteris characterized by bars, created and managed by the user, representing anycharacteristic of the player: moods, self-esteem, physiological needs, money, re-sources etc.. Both actions and dialogs can affect these Stats and it is possible todefine as many of these bars as the user desires. Dialogs are defined in their ownXML file, distinct from the XML file where the objectives, stats and actions aredefined. Those are composed by at least one Conversation Object which can beof different types:

– Message: simple message– YesOrNoAnswer: question that accepts as answer Yes or No.– MultipleChoice: message that offers different possibilities, all shown on the

screen– Effects: special node which has no independent value but has to be used in

concordance with the MultipleChoice object– End: declares the end of a dialog

Each of the above nodes will be taken into account and explained later.

4 Implementation

Unity is the game engine used to develop this project. Hereby we are going topresent a documentation and guide lines to help the user in designing his ownlevel. Only those implementation details, that are required to be explained inorder to give a clear view of how a mission should be designed, will be presented.Moreover, we developed two XSD schemes, proposed in the Appendix, which canbe used to validate both the XML files. The schemes have been implementedusing XSD 1.1 and XPath, and can be validated by using Oxygen’s validationtool (http://www.oxygenxml.com/).You can find all the code developed in the following link: https://www.dropbox.com/s/6dkolx4gh3hcjme/Scripts.rar?dl=0

4.1 Mission XML

This file is a normal XML file, therefore it starts with the usual declaration:

<?xml version="1.0" encoding="utf-8" ?>

From this point on, everything is placed inside the initialization tag:

<initialization>

...

</initialization>

The first sequence of elements that we define are the Stats:

<stat name="" range="" init="" tickValue="" colorR="" colorG="" colorB=""/>

...

<tick tickTime = ""/>

A Stat contains some basic info like: the name (string), the range of points(integer), its initialization value (integer) and the color that we want to use tovisualize the corresponding name on the screen. The color attributes requirea value between zero and 255. Moreover, we give the possibility, through thetickValue parameter, to decrease/increase the value of a Stat as time goes by.For example, in a realistic scenario we would like to have a Physiological barwhich slowly decreases during the time. The amount of points defined in thetick attribute gets added (if positive numbers are used) or subtracted (negativenumbers) every amount of seconds defined in the tick tag (integer) that wespecify right after the Stats. At the end, as many Stats as the user wants can beadded to the game.

The second set of elements described in this XML contains Static Actions.Those are declared and defined inside the staticAction tag as shown below:

<staticAction name="" >

...

</staticAction>

The attribute name (string) is required to give a name to the task. Withinthe action field we have to name all the stats that we defined before. This is doneby following certain criteria and it is needed to understand which are the Statsthat are modified by the accomplishment of that specific action. All of themhave to be listed in the same order that we defined them before by using the”Stat” tag. This is necessary because our framework modifies the correspondingbars by using an indexing method. The way to declare it is the following:

<nameStat reqPoints="" gainedPoints="" />

The reqPoints (integer) attribute defines how many points of that specificbar are required to complete the action. Similarly, the gainedPoints (integer)attribute states how many points of that bar are gained (or lost, in case of anegative number) when that action is accomplished. Once that all the Statsare listed like just explained, it is necessary to specify the RequiredAction andSuccessLikelihood tag.

<RequiredAction action="" cardinality=""/>

<SuccessLikelihood likelihood="" />

The former tag clarifies whether another action is required to be alreadyperformed before the current one can be accomplished. For example, beforeaccepting a paper a PhD student has to talk with his supervisor. One of themost interesting points of our framework is that multiple story paths can bebuilt in the same level. Depending on what the user chooses to do, the relativestory track will be pursued. For example we are going to explain that multiplepossibilities can be offered during a dialog. Different paths are created and thisoption gives a further level of freedom to the user. As a consequence, we need

to face the possibility of specifying more than a single action as requirement.Again, a practical example can better explain the concept: depending on thetopic that the supervisor offers to the PhD student, this can whether be positivelyaccepted, if it fits the student expectations, or not. In one case a possible actioncalled ”AcceptPaperPositively” will be completed and in the other a possibleone called ”AcceptPaperNegatively”. Afterwards, a PhD student may have thenecessity to run an experiment for his project in both cases. Therefore, in theRequiredAction field we have the need to specify more than one action throughan OR ( || ) condition. For example:

<RequiredAction action="AcceptPaperNegatively||AcceptPaperPositively" cardinality=""/>

The AND condition has not be implemented so far.Furthermore, an action can be completed more than once. Again with a

practical example: a PhD student may need to convince more than once studentto join his experiment. Through the cardinality (integer) attribute we can sethow many times a possible action like ”ConvinceStudentToJoinTheExperiment”has to be completed.

The SuccessLikelihood tag simply specifies the probability to successfullycomplete that action. Even though all the requirements are satisfied, if the like-lihood of that task is set to zero, we will not be able to complete it.

Afterwards, it is time to describe the Dynamic Actions. The difference be-tween the two kinds is that defining the static actions is mandatory. Those arealready implemented within the game and consist in some basic activity inter-acting with the environment. A list of those is hereby provided:

– UseTheToilet– PlayPool– PlayPiano– PlayVideoGames– Study

On the contrary, dynamic actions are created by the user, depending on whatthe steps composing a mission are. Those are defined through the action tag.

<action name="" dialog="" actor="">

...

</action>

Similarly to Static Actions, we need to give them a name by using the nameattribute. Nevertheless, one of the peculiarities of these is that they can be usedto interact with the BOTs and some of the objects that are placed in the scene.A list of those is given below:

– Computer1– Computer2– Computer3– Computer4– TV

– Pool– Piano– Toilet1– Toilet2– Toilet3– PresentationTable– TeachingDesk– Desk1– Desk2– Desk3– Kitchen– Supervisor– Susanne– Mario– LabManager

Any of the listed objects can be specified in the actor (string) attribute.Furthermore, more than one can be used at the same time, giving the possibilityto perform that same action with different items.Only one dialog (string) can be specified for an action. However, we give thepossibility to have more dialogs with the same interactable asset. In fact, if moreactions use the same object for a conversation, interacting with it will show onscreen a list of all the dialogs that it is possible to begin. In the particular casethat the requiredAction for that specific action has not been accomplished yet,the relative dialog - in case it exists - will not appear as possible choice.

Similarly to what we explained for the Static Action, we need now to specifythe same features like: the list of the stats, the RequiredAction and the Suc-cessLikelihood tag.

At the end of this file, we place the objective tag, used to list all the actionsthat need to be performed to complete the relative objective/mission.

<objective name="">

...

</objective>

A name (string) is needed to univocally identify an objective, giving thepossibility to define more and distinct objectives on the same level. Within thistag are expressed the steps that is necessary to complete if we want to finish themission. These are defined through the task tag and need to be named in thetask attribute.

<task task="" />

However, each mission is independent from any other, and no temporal con-nection or sequence has been developed yet. When an action is performed, itwill result fulfilled for any of those objectives that contain that specific task inits list.The OR condition can also be used here since, as explained above, it is possibleto follow different story paths. To state such case we use again the || symbol.For example:

<objective name="">

<task task="AcceptPaperNegatively || AcceptPaperPositively" />

</objective>

One of the flaws of our framework is that no distinction is made betweenactions of the same type. Let’s consider the following scenario:

<objective name="Try">

A1 || A2

A3

A3 || A4

</objective>

In case we accomplish the action A3, it will be considered completed in boththe 2nd and 3rd row.

4.2 Dialog XML

The Dialog XML file is separated from the Mission XML for a developmentchoice, where it is easier and more elegant to keep different concepts distin-guished, and because this separation supports better the idea of reuse. In fact,if only a Mission XML file has to be changed, the Dialog XML can remain thesame.Akin to the Mission XML file, this document is also a normal XML and theusual starting declaration is needed:


From this point on, it is necessary to open the dialogs tag, where we will beable to define each dialog by using the dialog tag.

<dialogs>

<dialog>

...

</dialog>

</dialogs>

The first element that we need to declare is the name of the conversation.Each dialog is built by using a Tree data structure and memorized in a Dictio-nary. Each tree is therefore associated to its key: the name of the dialog. That iswhy, to store and pick the right dialog, we need to declare its name in the XMLfile.

<name> string </name>

The user has the ability to create any kind of speech by using the specialmessages that we provide and allow to use. Hereby we are going to analyze themall. However, we first need to clarify some aspects that are common to any kindof message. As mentioned above, we are able to affect the player’s Stats throughthe use of dialogs. This aspect can be accomplished with each single sentenceof the conversation. For example: if the Supervisor affirms that the player did

not do a good enough work, the latter will be upset and a possible ’mood’ Statwould be affected. We may refer about these messages as Conversation Objects,as defined in the implementation of our framework.

The simplest one is, indeed, called through the message tag.

<message actor="" bar="" points=""> message(string) </message>

As explained above, the attribute bar (string) selects which is the Stat andby how many points (int) it has to be modified. If those attributes are empty,nothing will be affected. It is clear that the string inside the bar field has toperfectly match (capital letters included) with the name of the Stats defined inthe other XML file.Another aspect which is common to any Conversation Object considers the actor(string) attribute. The mentioned is independent from the BOT that the playeris interacting with in the game. In fact, in order to start a conversation the playerhas to approach one of the BOTs already existing but what is actually shownon screen depends on the following possibilities:If the player is the one who is speaking, the actor attribute has to contain thekeyword ’Me’.

<message actor="Me" bar="" points=""> Hello Supervisor, how are you? </message>

Fig. 7. Message example with Actor = ”Me”.

If that field is left empty, the game will use the name of BOT that the playeris talking with.

<message actor="" bar="" points=""> Hello Supervisor, how are you? </message>

Fig. 8. Message example with Actor = ””.

If anything else is inserted, the used string will be shown on screen, likesomeone else out of the conversation is speaking.

<message actor="SomeoneElse" bar="" points=""> Hello Supervisor, how are you? </message>

Fig. 9. Message example with Actor = ”SomeoneElse”.

The above differentiation of the three cases takes particular meaning in thenext node: the yesOrNoAnswer message. It represents a question where thepossible answers are just ”yes” or ”no”.

<yesOrNoAnswer actor="" bar="Social" points="" percentage=""> message (string)

It can be used on both player and BOT side. The framework acts in such away that:

– if the actor is not specified, the BOT is speaking. Therefore he is the oneasking the question and the player has to answer. The Yes and No buttonwill appear and a choice has to be taken.

– If the actor is different from the keyword ’Me’, it means that someone out ofthe conversation is asking the question, but again the player has to answereither Yes or No.

– If inside the actor we use the keyword ’Me’, it means that the player is askingthe question. Since on the other side of the talk there is a BOT, we need tospecify through the attribute percentage what is the chance that he/she/itanswers Yes to our question.

Reminding that a dialog is built on a Tree data structure, this kind of Con-versation Object creates two branches. It is mandatory that both are specifiedin the XML. Which means:

<yesOrNoAnswer actor="" bar="" points="" percentage=""> ...

<yes>

...

</yes>

<no>

...

</no>

</yesOrNoAnswer>

The Yes branch has to to be placed before the branch No and both aremandatory, even if their content is empty.

Inside a branch we can find any other Conversation Objects, both the ones thatwe already explained and those that we are going to explain. Nesting is possiblein as many levels of depth as we want.

When multiple choices are allowed we can use the multipleChoice node.

<multipleChoice actor="" bar="" points="" numberOfChoices="" percentage="">

The peculiarity of this node lies on the possibility to choose different choices,which are not expressed in this node itself. However, this stage is needed to makeclear how many possible options are going to be offered. In fact, the frameworkwill be looking for as many possibilities as defined in this node. Again, it ispossible to use this object for both player and BOT side. Therefore:

– if the actor attribute is empty or with something different from ’Me’, we areasked to make a choice and all the possibilities will be shown on screen.

– on the other way around, if the actor is ’Me’, we have to specify a percentageto lead the BOT choosing an answer. For example, if we ask someone tomake a choice amongst four possibilities, the percentage attribute has containfour percentages (integers), one for each possible way. Going into a concreteexample, if we state that ”percentage= 25 25 25 25” it means that eachchoice has the 25% to be chosen by the BOT. It is clear that the sum of thesingle percentages has to be 100% and there have to be as many of them asthe number of choices specified in the numberOfChoices attribute.

The possible choices are defined within the tag choice but before giving apractical example we need to explain the next node.

The node Effect is directly related to the multipleChoice. As explained, we justspecify the number of possible choices so far, but we do not state what they are.Indeed, this information is contained in the attribute name of the Effect node(besides the usual bar and points attribute). Two more special attributes arehere contained: action and likelihood. In the moment that one of the option ischosen, we access the action defined by its action attribute and we assign theprobability, defined through the likelihood, that this task can be accomplished.A practical example on how to nest those nodes is provided below:

<multipleChoice actor="" bar="" points="" numberOfChoices="2" percentage="">

<choice>

<effects name="" bar="" points="" action="WritePaper" likelihood="80" />

</choice>

<choice>

<effects name="" bar="" points="" action="WritePaper" likelihood="50" />

</choice>

</multipleChoice>

Concluding this section, we present the End node, which signs the end of aconversation.

<END completedMission="" retry="" />

This node can be placed at any point of the dialog. Moreover, since conver-sations can be used within an actions in order to, indeed, complete actions, wespecify whether one of those has been finished through the completedMissiontag. It is also possible to accomplish more actions at once within the same Endnode.

We also give the possibility to choose whether a discussion can be repeatedor not. For example if the player leaves the conversation because he has notenough points to accomplish the action, we need to give the possibility to startagain the same speech. On the other hand, if a dialog ends normally we need todeny the possibility to repeat it. Both situations can be accomplished throughthe retry tag.As last guideline, we make clear that wherever two objects/actors/completedactions are named in the same field, they do not require to be separated bya single blank character. Therefore as many blank spaces as we want can beused as string separators. Moreover, not all the integers in the XML files canbe omitted. For example the color, range and init value of a Stat are alwaysrequired. Likewise for the successLikelihood, gainedPoints and requiredPoints ofan action. To this purpose, the XSD Schema makes sure that all the requirementsare satisfied.

5 Illustration of the PhD Game

As explained above, the gameplay takes place in a scenario containing variousareas and assets where the player is able to interact with BOT’s and objects.Some of those are showed in the images below, represented by good qualityrendered pictures. Moreover, in the last one we can find a gameplay screenshot.

Fig. 10. Kitchen

Fig. 11. Supervisor’s office

Fig. 12. Gameplay screenshot

Furthermore, two full examples have been implemented to both test and givepractical illustration of the game. In both cases the Dialog and Mission XMLfiles can be found in the Appendix.

5.1 Example 1

The first example represents an ordinary task of a PhD student: writing a paper.The whole objective is composed by some steps that we tried to make as muchrealistic as possible. In fact, in order to accomplish this mission the student hasto:

– Talk with the supervisor and decide an argument– Convince some students to join the experiment– Book the laboratory where the experiment will take place

– Conduce the experiment

– Write the paper

– Deliver it to the supervisor

All the above points are mandatory to succeed in the mission and can beattained by using both the Static Actions and the Dynamic ones that we createdto complete, indeed, this specific assignment.

Several Stats have been added as well according to our idea of a realisticgameplay:

– Self Actualization

– Social

– Physiological

– Coins

Restrictions and requirements have been properly applied. For example it isnot possible to convince any student to join the experiment if a topic has notbeen chosen yet. Similarly, it is not possible to conduce the experiment if thelaboratory has not been booked before. Other restrictions have to be handledas well, for example before being able to terminate the paper, some hours ofstudy are necessary. Moreover, Stats have to be considered to accomplish anytask. Convincing a student to join an experiment is not possible with a low levelof Social stat. In the same way, Studying (one of the Static Actions) cannot becompleted with poor levels of Self Actualization or Physiological welfare.The combination of all these aspects allowed us to have a full built level, readyto be used.

5.2 Example 2

The second example shows how a PhD student takes a course. The steps usedfor this task are the following:

– Talk to the supervisor to pick the course

– Follow some lessons

– Prepare a corresponding presentation

– Give a presentation

– Confirm with the supervisor that the course has been successfully passed

The Stats used keep being the same of the Example 1 and again restrictionsare properly applied. For example it is not possible to prepare the final presenta-tion before a certain number of lessons have been followed. This can be achievedby both having a certain Cardinality of lessons followed or by using some Stats.The Coin Stat suits perfectly this purpose. This shows how requirements makeActions and Stats strictly related to each other.

6 Future Directions

Some flaws faced in our project brought us to think about possible solutions andthe way they might be implemented. Unfortunately, because of lack of time wecould not directly work on them. However, they can be considered as interestinghints for future works:

– user interface: instead of leading the player through the use of specific files,it might be easier and less challenging to create a specific interface whichallows him to reach the same goal.

– modifiable environment: giving the possibility to create customized levelsand environments with the same modular approach we used for the missionswas one of our first ideas.

– AND condition for the RequiredAction in the Mission file.– contacting PhD students would provide us with enough material to develop

realistic levels.– connection amongst missions: each mission is independent from each other

and no chronological sequence has been developed. Hence, a remarkable pointwould consist in creating a dependency between objectives.

– listing all the stats in each Action defined in the Mission XML: this is alimitation not considered during the development. Indeed our frameworkworks by using indexes to access the Stats, which means that all of them haveto be specified and in the same order they have been named at the beginningof the file. A smart and more elegant solution would consist in listing onlythose Stats actually modified by that action, which is more reasonable thanspecifying them all every time.

References

1. Erik Bethke. Game Development and Production. Wordware Publishing, 2003.Chapter 8.

2. Joel Burgess. Skyrim’s modular approach to level design, 2013. Accessed: 2015-05-1.

3. Josh Bycer. Are aaa studios doa?, 2012. Accessed: 2015-05-1.4. Ivica Crnkovic and Magnus Peter Henrik Larsson. Building reliable component-

based software systems. Artech House, 2002.5. Verbrugge Dragert, Kienzle. Toward high-level reuse of statechart-based ai in

computer games, 2011. Accessed: 2015-05-1.6. Dıaz-Agudo Florez-Puga. Semiautomatic edition of behaviours in videogames,

2010. Accessed: 2015-05-1.7. Jacobson Lewis. Game engines in scientific research, 2002. Accessed: 2015-05-1.8. Colton Lim, Baumgarten. Evolving behaviour trees for the commercial game def-

con, 2010. Accessed: 2015-05-1.9. Lin. Using workflow techniques and modularity, 2001. Accessed: 2015-05-1.

10. Paul Mader. Creating modular game art for fast level design, 2005. Accessed:2015-05-1.

11. Lee Perry. Modular level and component design, 2002. Accessed: 2015-05-1.12. Jones Scott. Investigation into modular design within computer games, 2011.

Accessed: 2015-05-1.

Appendix A Full scheme

A.1 Dialog XML scheme

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning" vc:minVersion="1.1">

<xs:element name="dialogs">

<xs:complexType>

<xs:choice minOccurs="0" maxOccurs="unbounded">

<xs:element name="dialog" type="ConversationObjects" />

</xs:choice>

</xs:complexType>

</xs:element>

<xs:complexType name="ConversationObjects">

<xs:sequence>

<xs:element minOccurs="1" maxOccurs="1" ref="name"/>


<xs:element ref="yesOrNoAnswer"/>

<xs:element ref="END"/>

<xs:element ref="message"/>

<xs:element ref="multipleChoice"/>

</xs:choice>

</xs:sequence>

</xs:complexType>

<xs:element name="name" type="xs:string"/>

<xs:element name="message" type="messageType"/>

<xs:complexType name="messageType" >

<xs:simpleContent>

<xs:extension base="xs:string">

<xs:attribute name="actor" type="xs:string" use="required"/>

<xs:attribute name="bar" type="xs:string" use="required"/>

<xs:attribute name="points" type="emptyInt" use="required"/>

</xs:extension>

</xs:simpleContent>

</xs:complexType>



<xs:simpleType name="emptyInt">

<xs:union>

<xs:simpleType>

<xs:restriction base=’xs:string’>

<xs:length value="0"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType>

<xs:restriction base=’xs:integer’>

</xs:restriction>

</xs:simpleType>

</xs:union>

</xs:simpleType>

<xs:element name="yesOrNoAnswer" type="YesOrNoAnswerType"/>

<xs:complexType name="YesOrNoAnswerType" mixed="true">

<xs:sequence>

<xs:element name="yes" type="yesOrNoType"/>

<xs:element name="no" type="yesOrNoType"/>

</xs:sequence>




<xs:attribute name="percentage" type="emptyInt" use="required"/>

</xs:complexType>

<xs:complexType name="yesOrNoType" mixed="true">






</xs:choice>

</xs:complexType>

<xs:element name="END" type="EndType"/>

<xs:complexType name="EndType" >

<xs:attribute name="completedMission" type="xs:string" use="required"/>

<xs:attribute name="retry" type="xs:boolean" use="required"/>

</xs:complexType>

<xs:element name="effects" type="EffectType"/>

<xs:complexType name="EffectType" >

<xs:attribute name="name" type="xs:string" use="required"/>



<xs:attribute name="action" type="xs:string" use="required"/>

<xs:attribute name="likelihood" type="emptyInt" use="required"/>

</xs:complexType>

<xs:element name="choice" type="ChoiceType"/>

<xs:complexType name="ChoiceType" mixed="true">

<xs:sequence>

<xs:element minOccurs="1" maxOccurs="1" ref="effects"/>

</xs:choice>

</xs:sequence>

</xs:complexType>

<xs:element name="multipleChoice" type="MultipleChoiceType"/>

<xs:complexType name="MultipleChoiceType" mixed="true">

<xs:sequence>

<xs:element minOccurs="0" maxOccurs="unbounded" ref="choice"/>

</xs:sequence>




<xs:attribute name="numberOfChoices" type="emptyInt" use="required"/>

<xs:attribute name="percentage" use="required">

<xs:simpleType>

<xs:list itemType="xs:integer"/>

</xs:simpleType>

</xs:attribute>



<xs:assert test="count(./choice) = @numberOfChoices" />



<xs:assert test="if (@actor = ’Me’) then (sum(data(@percentage)) = 100 and

count(data(@percentage)) = @numberOfChoices) else true()"/>

</xs:complexType>

</xs:schema>

A.2 Mission XML scheme


<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning" vc:minVersion="1.1">

<xs:element name="initialization" type="initializationType" />

<xs:complexType name="initializationType">

<xs:sequence>

<xs:element minOccurs="0" maxOccurs="unbounded" ref="stat"/>

<xs:element minOccurs="1" maxOccurs="1" ref="tick"/>

<xs:element minOccurs="5" maxOccurs="5" ref="staticAction"/>

<xs:element minOccurs="0" maxOccurs="unbounded" ref="action"/>

<xs:element minOccurs="0" maxOccurs="unbounded" ref="objective"/>

</xs:sequence>



<xs:assert test="count(./staticAction[@name=’UseTheToilet’]) = 1 "/>

<xs:assert test="count(./staticAction[@name=’PlayPool’]) = 1 "/>

<xs:assert test="count(./staticAction[@name=’PlayPiano’]) = 1 "/>

<xs:assert test="count(./staticAction[@name=’PlayVideoGames’]) = 1 "/>

<xs:assert test="count(./staticAction[@name=’Study’]) = 1 "/>



<xs:assert test="every $staticAction in ./staticAction satisfies

$staticAction/@name = (’UseTheToilet’, ’PlayPool’, ’PlayPiano’, ’PlayVideoGames’, ’Study’) "/>



<xs:assert test="every $staticAction in ./staticAction satisfies

deep-equal(data($staticAction/*[position() <= (count(../*)-2)]/name()),

data(./stat/@name)) "/>



<xs:assert test="every $action in ./action satisfies

deep-equal(data($action/*[position() <= (count(../*)-2)]/name()), data(./stat/@name)) "/>



<xs:assert test="every $task in ./objective/task satisfies

(every $simpleTask in tokenize(data($task/@task), ’\|\|’) satisfies

normalize-space($simpleTask) = data(./staticAction/@name | ./action/@name))" />



<xs:assert test="every $task in ./staticAction/RequiredAction satisfies

(every $simpleTask in tokenize(data($task/@action), ’\|\|’) satisfies




<xs:assert test="every $task in ./action/RequiredAction satisfies

(every $simpleTask in tokenize(data($task/@action), ’\|\|’) satisfies


</xs:complexType>



<xs:simpleType name="emptyInt">

<xs:union>

<xs:simpleType>

<xs:restriction base=’xs:string’>

<xs:length value="0"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType>

<xs:restriction base=’xs:integer’>

</xs:restriction>

</xs:simpleType>

</xs:union>

</xs:simpleType>

<xs:element name="tick" type="tickTipe" />

<xs:complexType name="tickTipe">

<xs:attribute name="tickTime" type="emptyInt" use="required"/>

</xs:complexType>

<xs:element name="stat" type="statType" />

<xs:complexType name="statType">


<xs:attribute name="range" type="xs:integer" use="required"/>

<xs:attribute name="init" type="xs:integer" use="required"/>

<xs:attribute name="tickValue" type="xs:integer" use="required"/>

<xs:attribute name="colorR" type="colorValue" use="required"/>

<xs:attribute name="colorG" type="colorValue" use="required"/>

<xs:attribute name="colorB" type="colorValue" use="required"/>

</xs:complexType>

<xs:simpleType name="colorValue">

<xs:restriction base="xs:integer">

<xs:minInclusive value="0"/>

<xs:maxInclusive value="255"/>

</xs:restriction>

</xs:simpleType>

<xs:element name="staticAction" type="StaticActionType"/>

<xs:complexType name="StaticActionType">

<xs:sequence>

<xs:any maxOccurs="unbounded" minOccurs="0" processContents="skip"/>

<xs:element ref="RequiredAction"/>

<xs:element ref="SuccessLikelihood"/>

</xs:sequence>

<xs:attribute name="name" type="xs:string"/>



<xs:assert test="every $element in ./*[position() <= (count(../*)-2)] satisfies

($element[

matches(@reqPoints, ’^[+-]?\d+$’) and

matches(@gainedPoints, ’^[+-]?\d+$’) and

count(@*=2)])"/>

</xs:complexType>

<xs:element name="action" type="actionType"/>

<xs:complexType name="actionType">

<xs:sequence>

<xs:any maxOccurs="unbounded" minOccurs="0" processContents="skip"/>

<xs:element ref="RequiredAction"/>

<xs:element ref="SuccessLikelihood"/>

</xs:sequence>

<xs:attribute name="name" type="xs:string"/>

<xs:attribute name="dialog" type="xs:string"/>

<xs:attribute name="actor" type="xs:string"/>

<xs:assert test="every $element in ./*[position() <= (count(../*)-2)] satisfies

($element[

matches(@reqPoints, ’^[+-]?\d+$’) and

matches(@gainedPoints, ’^[+-]?\d+$’) and

count(@*=2)])"/>

</xs:complexType>

<xs:element name="RequiredAction" type="RequiredActionType"/>

<xs:complexType name="RequiredActionType" >

<xs:attribute name="action" type="xs:string" use="required"/>

<xs:attribute name="cardinality" type="xs:integer" use="required"/>

</xs:complexType>

<xs:element name="SuccessLikelihood" type="SuccessLikelihoodType"/>

<xs:complexType name="SuccessLikelihoodType" >

<xs:attribute name="likelihood" type="xs:integer" use="required"/>

</xs:complexType>

<xs:element name="objective " type="objectiveType"/>

<xs:complexType name="objectiveType">

<xs:sequence>

<xs:element minOccurs="0" maxOccurs="unbounded" ref="task"/>

</xs:sequence>


</xs:complexType>

<xs:element name="task " type="taskType"/>

<xs:complexType name="taskType">

<xs:attribute name="task" type="xs:string" use="required"/>

</xs:complexType>

</xs:schema>

Appendix B Example1

B.1 Dialog XML

<dialogs>

<dialog>

<name>DialogWithSupervisor</name>

<message actor="SomeoneElse" bar="" points="">Hello Supervisor, how are you?</message>

<yesOrNoAnswer actor="" bar="Social" points="" percentage=""> I am fine, thanks. Are you ok?

<yes>

<message actor="" bar="" points="">Glad to hear that!</message>

</yes>

<no>

<message actor="" bar="" points="">Anything wrong?</message>

<message actor="Me" bar="" points="">No, I am just overstressed</message>

<yesOrNoAnswer actor="" bar="Social" points="" percentage=""> Are you ready to start then?

<yes>

<yesOrNoAnswer actor="Me" bar="" points="" percentage="100">Yes I am! And, are you ready?

<yes>

<message actor="" bar="" points=""> Yes I am! We can start then! </message>

</yes>

<no>

<message actor="" bar="" points=""> Mmmm, I do not feel so good today..</message>

<message actor="Me" bar="" points="">Ok, I will come back later</message>

<END completedMission="" retry="true" />

</no>

</yesOrNoAnswer>

</yes>

<no>

<message actor="" bar="" points="">Ok, come back when you are ready then</message>


</no>

</yesOrNoAnswer>

</no>

</yesOrNoAnswer>

<message actor="Me" bar="" points="">Which are the possible topics?</message>

<multipleChoice actor="" bar="" points="" numberOfChoices="3" percentage="">

you can choose between:

<choice>

<effects name="Physics" bar="SelfActualization" points="5" action="WritePaper"

likelihood="80" />

<message actor="" bar="" points="">Glad for your choice. Good luck!</message>

<END completedMission="TalkToSupervisor AcceptPaperPositively" retry="false"

/>

</choice>

<choice>

<effects name="Biology" bar="SelfActualization" points="-30" action="WritePaper"

likelihood="50" />

<message actor="" bar="" points="">I am sure you will find the right way</message>

<END completedMission="TalkToSupervisor AcceptPaperNegatively" retry="false"

/>

</choice>

<choice>

<effects name="Math" bar="SelfActualization" points="10" action="WritePaper"

likelihood="100" />

<message actor="" bar="" points="">It fits your expectations! Good luck!</message>

<END completedMission="TalkToSupervisor AcceptPaperPositively" retry="false"

/>

</choice>

</multipleChoice>

</dialog>


<name>DialogStudent</name>

<message actor="Me" bar="" points="">Hey man, how are you doing?</message>

<yesOrNoAnswer actor="" bar="" points="" percentage=""> I am fine, thanks. Are you ok?

<yes>

<message actor="Me" bar="Social" points="5">Everything fine, thanks for asking!</message>

</yes>

<no>

<message actor="Me" bar="Social" points="5">Mmmm.. it could be better

but no worries!</message>

</no>

</yesOrNoAnswer>

<yesOrNoAnswer actor="Me" bar="" points="" percentage="100"> Would you like to join

my experiment?

<yes>

<message actor="" bar="SelfActualization" points="5">Yeah, why not!</message>

</yes>

<no>

<message actor="" bar="SelfActualization" points="-15">I cannot at the moment,

sorry..!</message>

<yesOrNoAnswer actor="Me" bar="" points="" percentage="50"> Are you busy?

<yes>

<message actor="" bar="" points="">Yeah I am in this period.. I am sorry!!</message>

<message actor="Me" bar="" points="">No problem! see you!</message>

<END completedMission="" retry="false" />

</yes>

<no>

<message actor="" bar="" points="">Mmmm no that much.. ok I will join you!</message>

</no>

</yesOrNoAnswer>

</no>

</yesOrNoAnswer>

<multipleChoice actor="Me" bar="" points="" numberOfChoices="2" percentage="50 50">

you can choose between Listening and Speaking

<choice>

<effects name="Listening" bar="" points="" action="" likelihood="" />

<message actor="" bar="" points="">I will go for Listening!</message>

<yesOrNoAnswer actor="Me" bar="" points="" percentage="50"> Glad for your choice.

Did you enjoy it?

<yes>

<message actor="" bar="SelfActualization" points="5">Yeah, it was really

interesting!</message>

<message actor="Me" bar="" points="">Glad to hear that! Thanks! Goodbye!</message>

<END completedMission="ConvinceStudentForExperiment" retry="false"/>

</yes>

<no>

<message actor="" bar="SelfActualization" points="-15">Yeah.. I would have adjusted

some points but it is fine</message>

<message actor="Me" bar="" points="">Ok sorry maybe something went wrong..

Thanks anyway!</message>


</no>

</yesOrNoAnswer>

</choice>

<choice>

<effects name="Speaking" bar="" points="" action="" likelihood="" />

<message actor="" bar="" points="">I will go for Speaking!</message>

<message actor="Me" bar="" points=""> Good choice! I hope you enjoyed it..

goodbye!</message>


</choice>

</multipleChoice>

</dialog>


<name>WritingPaper</name>

<yesOrNoAnswer actor="" bar="" points="" percentage="50"> Do you want to write the paper?

<yes>

<message actor="" bar="" points="">Ok lets do it!</message>

<END completedMission="WritePaper" retry="false" />

</yes>

<no>

<message actor="" bar="" points="">You need to do it sooner or later..</message>


</no>

</yesOrNoAnswer>

</dialog>


<name>BookLab</name>

<message actor="" bar="" points=""> Hi, how can I help you?</message>

<yesOrNoAnswer actor="Me" bar="" points="" percentage="50">Hi, I would like to book the lab..

is it possible?

<yes>

<message actor="" bar="" points="">Yes! I will write you down

on the reservation book</message>

<message actor="Me" bar="" points="">Thanks! See you later..</message>

<END completedMission="BookLaboratory" retry="false" />

</yes>

<no>

<message actor="" bar="" points="">Sorry, not now.. come back later..</message>


</no>

</yesOrNoAnswer>

</dialog>


<name>Experiment</name>

<yesOrNoAnswer actor="" bar="" points="" percentage="50"> Do you want to conduce

the experiment?

<yes>


<END completedMission="ConduceExperiment" retry="false" />

</yes>

<no>



</no>

</yesOrNoAnswer>

</dialog>


<name>DeliverToSupervisor</name>

<message actor="" bar="" points="">Hey, how can I help you?</message>

<yesOrNoAnswer actor="Me" bar="" points="" percentage="100"> I would like to deliver my paper

.. is it possible?

<yes>

<message actor="" bar="" points="">Of course it! Let me check it out..</message>

<message actor="" bar="" points="">(Mmmm..)</message>

<message actor="" bar="" points="">Well done! </message>

<END completedMission="DeliverPaper" retry="false" />

</yes>

<no>

<message actor="" bar="" points="">Come back later please,

I am a bit busy at the moment..</message>


</no>

</yesOrNoAnswer>

</dialog>


<name>Just talk</name>

<message actor="" bar="" points="">Hey, how can I help you?</message>

<yesOrNoAnswer actor="Me" bar="" points="" percentage="100"> I would just like to conversate

a bit.. shall we?

<yes>

<message actor="" bar="" points="">Of course!</message>

<message actor="Both.." bar="" points="">(Bla.. bla.. bla..)</message>

<message actor="" bar="" points="">It was nice to speak with you! </message>

<END completedMission="JustTalk" retry="true" />

</yes>

<no>

<message actor="" bar="" points="">Come back later please, I am a bit busy

at the moment..</message>


</no>

</yesOrNoAnswer>

</dialog>

</dialogs>

B.2 Action XML


<initialization>

<stat name="SelfActualization" range="100" init="20" tickValue="0" colorR="255" colorG="0"

colorB="0"/>

<stat name="Social" range="100" init="30" tickValue="0" colorR="0" colorG="255"

colorB="0"/>

<stat name="Physiological" range="100" init="50" tickValue="-1" colorR="255" colorG="255"

colorB="255"/>

<stat name="Coins" range="100" init="0" tickValue="0" colorR="255" colorG="255"

colorB="0"/>

<tick tickTime = "1"/>

<staticAction name="UseTheToilet" >

<SelfActualization reqPoints="0" gainedPoints="0" />

<Social reqPoints="0" gainedPoints="0" />

<Physiological reqPoints="0" gainedPoints="25" />

<Coins reqPoints="0" gainedPoints="0" />


<SuccessLikelihood likelihood="100" />

</staticAction>

<staticAction name="PlayPool" >

<SelfActualization reqPoints="0" gainedPoints="-2" />






</staticAction>

<staticAction name="PlayPiano" >







</staticAction>

<staticAction name="PlayVideoGames" >



<Physiological reqPoints="0" gainedPoints="-2" />




</staticAction>

<staticAction name="Study" >


<Social reqPoints="0" gainedPoints="-5" />





</staticAction>

<action name="TalkToSupervisor" dialog="DialogWithSupervisor" actor="Supervisor">







</action>

<action name="JustTalk" dialog="Just talk" actor="Supervisor Susanne Mario LabManager">







</action>

<action name="AcceptPaperPositively" dialog="" actor="">





<RequiredAction action="TalkToSupervisor" cardinality=""/>


</action>



<RequiredAction action="WritePaper" cardinality=""/>


</action>

<objective name="WriteYourPaper">

<task task="TalkToSupervisor" />

<task task="AcceptPaperNegatively || AcceptPaperPositively" />

<task task="ConvinceStudentForExperiment" />

<task task="ConvinceStudentForExperiment" />

<task task="BookLaboratory" />

<task task="ConduceExperiment" />

<task task="WritePaper" />

<task task="DeliverPaper" />

</objective>

</initialization>

Appendix C Example2

C.1 Dialog XML


<dialogs>


<name>Decide The Course</name>

<message actor="Me" bar="" points="">Hello Supervisor, how are you?</message>

<yesOrNoAnswer actor="" bar="Social" points="" percentage=""> I am fine, thanks. Are you

here for the courses?

<yes>

<message actor="Me" bar="" points="">Yes I am!</message>

</yes>

<no>

<message actor="Me" bar="" points="">Mmm.. no sorry, I am not ready yet!</message>

<message actor="" bar="" points="">Oh no problem, come back when you are ready</message>


</no>

</yesOrNoAnswer>

<yesOrNoAnswer actor="" bar="Social" points="" percentage=""> Good! But first, how are you?

Everything fine?

<yes>

<message actor="" bar="" points="">Glad to hear that!</message>

</yes>

<no>

<message actor="" bar="" points="">Anything wrong?</message>

<message actor="Me" bar="" points="">No, I am just overstressed</message>

<yesOrNoAnswer actor="" bar="Social" points="" percentage=""> Are you ready to start then?

<yes>

<yesOrNoAnswer actor="Me" bar="" points="" percentage="100">Yes I am! And, are you ready?

<yes>

<message actor="" bar="" points=""> Yes I am! We can start then! </message>

</yes>

<no>

<message actor="" bar="" points=""> Mmmm, I do not feel so good today.. </message>

<message actor="Me" bar="" points="">Ok, I will come back later</message>


</no>

</yesOrNoAnswer>

</yes>

<no>

<message actor="" bar="" points="">Ok, come back when you are ready then</message>


</no>

</yesOrNoAnswer>

</no>

</yesOrNoAnswer>

<message actor="Me" bar="" points="">Which are the possible courses I can take?</message>

<multipleChoice actor="" bar="" points="" numberOfChoices="2" percentage=""> actually you

have only 2 choices:

<choice>

<effects name="Math" bar="SelfActualization" points="5" action="GivePresentation"

likelihood="80" />

<message actor="" bar="" points="">Glad for your choice. Good luck!</message>

<END completedMission="TalkToSupervisorForCourse AcceptCourse" retry="false"

/>

</choice>

<choice>

<effects name="Advanced Geometry" bar="SelfActualization" points="-30"

action="GivePresentation" likelihood="50" />

<message actor="" bar="" points="">I am sure you will find the right way</message>

<END completedMission="TalkToSupervisorForCourse AcceptCourse" retry="false"

/>

</choice>

</multipleChoice>

</dialog>


<name>FollowLessons</name>

<yesOrNoAnswer actor="Lecturer" bar="" points="" percentage="100"> Do you want follow

the lesson?

<yes>

<message actor="Lecturer" bar="" points="">Ok lets do it!</message>

<END completedMission="FollowLessons" retry="true" />

</yes>

<no>

<message actor="Lecturer" bar="" points="">You need to do it sooner or later..</message>


</no>

</yesOrNoAnswer>

</dialog>


<name>PrepareThePresentation</name>

<yesOrNoAnswer actor="" bar="" points="" percentage="100"> Do you want to prepare

the presentation?

<yes>


<END completedMission="PrepareThePresentation" retry="false" />

</yes>

<no>



</no>

</yesOrNoAnswer>

</dialog>


<name>GivePresentation</name>

<yesOrNoAnswer actor="" bar="" points="" percentage="100"> Do you want to present?

<yes>


<END completedMission="GivePresentation" retry="false" />

</yes>

<no>



</no>

</yesOrNoAnswer>

</dialog>


<name>ConfirmCourse</name>

<message actor="Me" bar="" points="">Hello, I am back</message>

<message actor="" bar="" points="">Hey, I heard the presentation was a success</message>

<yesOrNoAnswer actor="Me" bar="" points="" percentage="100"> Yes it was! Does it mean that

I passed the course?

<yes>

<message actor="" bar="" points="">Yes it does! Congratulations.. now back to work..

</message>

<END completedMission="ConfirmCourse" retry="false" />

</yes>

<no>

</no>

</yesOrNoAnswer>

</dialog>

</dialogs>

C.2 Mission XML


<initialization>

<stat name="SelfActualization" range="100" init="20" tickValue="0" colorR="255" colorG="0"

colorB="0"/>

<stat name="Social" range="100" init="30" tickValue="0" colorR="0" colorG="255"

colorB="0"/>

<stat name="Physiological" range="100" init="50" tickValue="-1" colorR="255" colorG="255"

colorB="255"/>

<stat name="Coins" range="100" init="0" tickValue="0" colorR="255" colorG="255"

colorB="0"/>

<tick tickTime = "1"/>

<staticAction name="UseTheToilet" >







</staticAction>

<staticAction name="PlayPool" >







</staticAction>

<staticAction name="PlayPiano" >







</staticAction>

<staticAction name="PlayVideoGames" >







</staticAction>

modular design of game levels: a case in serious games€¦ · the game has been developed by...

Documents