GAM - Game Aided by Design: A New Method to Develop Casual Games from Petri Nets Models Gonçalves, C. H. R.1&2, Soares, J. M.2, Barroso, G.2, Lopes, L. J. T.1, Carvalho, V. V. S.2, Serra, A.1 Departamento de Teleinformática, Universidade Federal do Ceará, Fortaleza, Brasil1 Departamento de Telemática, Instituto Federal de Educação Ciência e Tecnologia do Ceará, Fortaleza, Brasil2
Corresponding author: Carlos Hairon Ribeiro Gonçalves Phones: +558533073708 / +558591972080 - FAX: +558533073711 - E-mail: hairon@gmail.com Abstract Electronic games development has been used in multidisciplinary teams to construct artifacts such as conceptual models, artistic images, sound effects, music and software that support a target game. Success of the game depends on the players enjoyment - not necessarily the construct of the game - it is more to do with imagery, sounds effects, playability and the game plot. Techniques used to minimize the complexity of software development in a game project will allow more resources to be applied in phases of conception and deveopment of features linked with plot concepts, images, sounds and music. This paper presents a new method: Games Aided by Modeling (GAM), this approach allows the construction of games without the direct intervention of professionals of software development and without using traditional programming languages. The theoretical framework of Colored Petri Nets (CPN) is the main formalism that supports the GAM method. A case study is presented whose development was performed with the use of a software architecture adhering to GAM. This architecture consists of implementation and configuration tools, which enable the development of casual games without writing source codes. Besides the ease of designing the game from a graphical model, the CPN can be formally analyzed through simulations and tests to ensure correctness and economics of resources, for the project. Fault detection occurs during the design of the target game. Key words: Games, Petri Nets and Software Development Based on Models 1.0 Introduction By the very nature of a game, the composition of its development team is multidisciplinary. Roles that are usually featured in the project development of a game are: producer (project manager), game designer, technical lead programmer, programmer, artist, musician and audio engineer. It is clearly shown that the roles related to computing are important in this process. Developers of software connect artistic pictures, sound and screenplays by building software that support the movement of sprites, transition scenarios and human-computer interaction [Jones, 2000]. In principle, the programming work can be avoided if the games generation tools provide sufficient abstract resources for the experts in art, design and script. On the other hand, it is essential that professional software development creates support for the evolution of games. These features are geared to the use of artists and designers in this field. In this context, this article presents a new method used to build games with this approach: Developing Games Based Modeling (GAM - Game Aided by Modelling). In the same manner that engineers and architects use CAD tools (Computer-Aided Design) [Burns, 1986] in a independent way, the GAM tools aim to give game designers a more independent role in relation to the software developers to design games. The concept of GAM is not linked to any framework to aid the development of games such as Sprite Kit [Apple, 2014] Corona [Corona Labs, 2014] and Unity [Unity Technologies, 2014]. GAM consists of a method that uses formal models that can express, even in the modeling phase, the structure and the dynamics of the target game
alongside of doing simulations and tests. A tool built on the GAM method is based on a formalism that can be translated into an executable code required to run the game without the intervention of programmers. Considering all the possibilities for advanced programming, this is a very ambitious goal. However, this article will only be addressing casual games running in tablets and smartphones. This type of game is intended for those who play for only a few minutes to relax or to entertain themselves while waiting for a scheduled meeting or even a doctors appointment. So, if games wield an amount of simplicity and are self-explanatory, it is considerably beneficial. Moreover, for casual games - artists and designers are still fundamental. Generally, the game users are unaware of how the characters, scenes and sounds are interconnected by software coding, their perception is fueled by subjective aesthetics or the plot of the game. To be successful, GAM architecture should provide mechanisms that support the development of games and essential characteristics common to their various kinds. According to Myers [Myers, 2009], there are four key concepts that should be present in a minimalist game: Representation (Virtual World), Rules, Opposition and Objectives. To obtain a minimalistic game, such concepts must be considered by any process of software development. Thus, the GAM method is formally described based on these four fundamental concepts. Additionally, the GAM method should provide mechanisms for simulation and testing still in the modeling phase. This will enable greater productivity, since the difficulty provided in each stage of the game can be defined and evaluated by simulations. Formal tests
ensure that the final software is correct with respect to logic, which can be further tested and validated during the modeling stage. Implementation errors can also be minimized because the code generated is based on a formal model that represents the game in question and, as mentioned above, is rigorously tested. Considering the topics discussed in this introduction, we can say that the work done by the developer of a game could be excused, at least in the preliminary stages of building games. Moreover, developers would fit the task of writing tools and libraries to characterize specific rules for the simulation of gravity and collision animations. Most importantly, a game can be easily characterized as a simulator. For this, abstractions of physical and / or chemical characteristics of the objects of the game must meet implementation needs, as the real world demands. Thus, the method may also allow GAM productivity in building a simulator relating to different types of engineering. To demonstrate the feasibility of the GAM method in building games, this paper presents the architecture GAM, with its proper implementation, based on colored Petri nets (CPN) [Jensen 2009]. The implementation of this architecture is capable of generating a very wide variety of casual games, without the need for programming. To demonstrate this fact - two example scenarios are presented : Concerns about the extinguishing of flames in a city, a firefighter races against time, fervently trying to save a neighbourhood from potential demise. The second scenario is more quite - wherein the gamer is thrust into the world of English deliberating the exacting of prepositions. The objective being, practicing the English language in a land where skeletons are to transport coffins emblazoned with expressions of the English language to designated graves. This paper is structured as follows: Section 2 presents the related works that corroborate the exposed line of thought. Section 3 presents a formal definition of CPN, and discusses how these can be useful in modeling software at high level. In Section 4 the formalization of the GAM method for definition of casual games is presented. The GAM architecture is presented in Section 5. Section 6 presents two casual games that were developed in accordance with the GAM architecture. In Section 7 the conclusions and future work are presented. 2.0 Related Work The major contribution of the work presented in this article is in fact introducing a formal alternative to developing games. The related works presented here also highlight this aspect, such as Ludocore (2.1) and Procedural Content Generation (2.2). Work Extracting NPC (Non-Player Characters) Behavior (2.3) and Test Fit and Modeling Behavior with Petri Net (2.4) relate to procedures for automatic generation of games, this aspect also having a direct relationship with the work presented in this article. 2.1. Ludocore Ludocore [Smith, 2010] is a gaming engine that uses logical formalism Event Calculus (EC) [Smith, 2010] as
the main feature. The proposal is to provide the Ludocore logical models (set of logical rules) that can express in a concise, safe and flexible semantics needed to define games. The EC was chosen to associate semantics with logical rules and thus set the engine to create the desired game. 2.2. Procedural Content Generation Lee and Cho [Lee, 2011] propose a method based on Petri Nets (PN) [Murata, 1989] to generate small missions or tasks for the main characters that represent the player in a game. In games like RPG (Role-Playing Game) there is a large number of tasks or missions that the main character of the game is assigned, and the design of these manual tasks is particularly challenging for the designers of this type of game. To reduce laboriousness, designers use a technique of developing games called PCG (Procedural Content Generation). This technique is based on pre-defined algorithms to automatically generate dynamic characteristics of scenery, NPC and tasks. The technique is widely used by the scientific community [Enden, 2010] [Ashmore, 2007]. The proposal of Lee and Cho is divided into three parts: the type of player is inferred using Baysian Networks; tasks are generated using scripts based on PN and the overall plot is generated by specific application related to the target game. The authors present a tool called PlotWizard to support the development of a plot for the game. However, the formalism based on Petri Nets (PN) supports only the specification of how the characters interact, not interfering in the graphic properties and game controls. Although the authors present a wizard for creating the plot of the game (PlotWizard), in fact, there is not an example of a game completely generated by the proposed tool. Another issue to be addressed relates to the game places (places where the characters move around) which are mapped to PN statically. This makes the proposal of Lee and Cho [Lee, 2012] limited to RPGs, because enumerable and predictable events will occur. 2.3. Extracting NPC behavior In [Fink, 2007] the application the capacity to predict the actions of NPCs is presented. (components of a game controlled by computer working for or against the human player). This application is based only in the graphical output of a game. To assist, computer vision techniques and machine learning are applied. The goal is to verify the behavior of NPCs based on script when these are interacting with a human. There is also possibility to reengineer NPCs when only the game is available, but its source codes none. Potentially, it is possible to automatically verify the behavior of the NPC and automatically modify the behavior of the NPC, therefore increasing the challenge of the game. 2.4. Test Fit and Modeling Behavior with Petri Net Santos [Santos, 2010] proposes an approach based on PN to describe the behavior of an NPC agent of a model game. The case study was the modeling of the game Pac
Man. Each agent consists of the following elements: sensors, actions, memory and rules. These elements are mapped by PN. This mapping is done automatically, with the goal of increasing the variety of NPCs and strategies providing a non-repetitive dynamic phase. Santos only shows how to use PNs to model NPCs. So, this increases the variability of NPCs behavior. However, implementation of general purpose is not presented, but only a case study of a specific game to discuss the power of PNs in game design. Similar studies presented in this section do not introduce a method in which a full game can be modeled graphically and generated automatically from the model (without needing to write a source code) and can be tested also in the modeling phase. These are the main features that the GAM method (target of this work) offers. Table 2.1 presents a comparison of the GAM method with related works. The GAM method presents a mechanism, which during the period of analysis and design any errors made by developers have the potential for expeditious remedy. Table 2.1 - Comparison of the GAM method with related works.
Feature
[Smith, [Fink, 2010] 2007]
[Lee, 2011]
[Santos, 2010]
GAM
Type Modeling
Logic
Reverse
Graphic
Graphic
Graphic
Modeling Scope
All game
A
character
A level
A level
All game
Executing Tests
Dev. 3 time
Dev. 3 time
Analysis time
Analysis time
Analysis time
Writing Source Code
Yes
Yes
Yes
Yes
No
Automatic Generation of Game
No
No
No
No
Yes
1
2
1. Modeling using formal logic; 2. Generates the model of a game already constructed using reverse engineering; 3. Development time. 3.0 Coloured Petri Nets and Modeling Systems A system must be modeled, analyzed and simulated prior to implementation and subsequent execution. To be able to do a simulation, a model of the system must be constructed to obtain prior knowledge of what will be studied and / or analyzed. A model of a system is a representation that only the essential characteristics of the problem in question are taken into account. A simple definition proposed by Booch at all is that “A model is a simplification of reality.“ [Booch, 1998]. The modeling system can be performed in several ways. Generally, modeling is accompanied by analyses and simulations.
The analysis is essential because it may elucidate structural and behavioral aspects of the system. In the modeling phase various types of analyses must be made to identify whether any problems are likely to arise from its implementation (structure) or its running (behavior). Coloured Petri Nets (CPNs) is a graphical language for constructing models of discrete-event systems and analysing their properties. CPNs are aimed at practical use, in particular because they allow the construction of compact and parametric models. The advantage of CPNs over the other Petri nets is the ability to model complex systems and to provide models with a high level of abstraction and better graphic representation (Jensen, 2009). CPNs are suitable tools for game modeling as they provide important features such as modularity, maintainability and expandability. These characteristics enable the addition of new processes to the original model, making it possible to add new functions or new processes of the system. CPN Tools (www.cpntools.org) is a tool for the editing, simulation, state space analysis, and performance analysis of CPN models. The user of CPN Tools works directly with the graphical representation of the CPN model [Jensen, 2009]. Figure 3.1 shows the CPN main structure consisting of places, transitions and arcs. With CPNs it is possible to use data types and complex data manipulation.
Figure 3.1 - Representation of a simple colored Petri net.
The places in Figure 3.1, represent the state of the modelled system. Names of the places are written inside the ellipses, and have no formal meaning – but they have huge practical importance for the readability of a CPN model. Each place can be marked with one or more tokens, and each token has a data value attached to it. This data value is called the token colour. It is the number of tokens and the token colours on the individual places which together represent the state of the system. This is called a marking of the CPN model. The tokens on a specific place constitute the marking of that place. The transitions represent the events that can take place in the system. As with places, the names of the transitions are written inside the rectangles. When a transition occurs, it removes tokens from its input places (those places that have an arc leading to the transition) and it adds tokens to its output places (those places that have an arc coming from the transition). The tokens that are removed from input places and added to output places when a transition occurs are determined by means of the arc expressions, which are the textual inscriptions
positioned next to the individual arcs. When all variables in an expression are bound to values of the correct type, the expression can be evaluated. CPN is both a graphical and mathematical tool. The theoretical framework related to CPNs defines a mathematical modeling tool, graphically formed nodes and arcs, which provides modeling and analysis of systems. From the analysis result, we can use CPNs to generate a more robust code because logical and conceptual errors can be detected by the analysis of behavioral and structural properties of CPN in question, i.e., CPNs that allow the system model to be formally validated in the analysis phase of the target system, preventing errors from propagating to advanced stages of implementation. The definitions 1.0, 1.1, 1.2 formalize CPNs and were defined in [Jensen, 2009]. Definition (1.0) - A non-hierarchical Coloured Petri Net is a nine-tuple CPN = (P,T,A,Σ,V,C,G,E,I), where: 1. P is a finite set of places. 2. T is a finite set of transitions T such that P∩ T = Ø. (definition of bipartite graph) 3. A ⊆ P × T ∪ T × P is a set of directed arcs. 4. Σ is a finite set of non-empty color sets (set of types or set of tokens). 5. V is a finite set of typed variables such that Type[v] ∈ Σ for all variable v ∈ V. 6. C : P ! Σ is a color set function that assigns a color set to each place. 7. G : T!EXPRV is a guard function that assigns a guard to each transition t such that Type[G(t)] = Bool. 8. E : A!EXPRV is an arc expression function that assigns an arc expression to each arc a such that Type[E(a)] = C(p)MS , where p is a place connected to the arc a. 9. I : P!EXPRØ is an initialization function that assigns an initialization expression to each place p such that Type[I(p)] = C(p)MS. Definition (1.1) - For a Colored Petri Net CPN = (P, T, A, Σ, V, C, G, E, I), the following concepts are defined: 1. A marking is a function M that maps each place p∈P into a multiset of tokens M(p) ∈ C (p)MS. 2. The initial marking M0 is defined by M0(p) = I(p)〈 〉 for all p∈P. 3. R(M) is the set of all markings reachable from M0. 4. The variables of a transition t are denoted by Var(t) ⊆ V and consist of free variables appearing in the guard of t and in the arc expressions connected to t. 5. A binding of a transition t is a function b that maps each variable v ∈ Var(t) into a value b(v)∈ Type[v]. The set of all bindings of a transition t is denoted by B(t). 6. A binding element is a pair (t,b) such that t ∈ T e b ∈ B(t). The set of all binding elements BE(t) for a transition t is defined by BE(t)={(t,b) | b ∈ B(t)}. The set of all binding elements in a CPN model is denoted by BE. 7. A step Y ∈ BEMS is a non-empty, finite multiset of beinding elements.
Definition (1.2) – A binding element (t,b) ∈ BE is enabled into a marking M if and only if the following two properties are satisfied: • G(t) 〈b〉 = true. • ∀ p ∈ P : E (p,t) 〈b〉 <<= M (p). When (t,b) is enabled in M, it may occur, leading to the new marking M’ defined by: • ∀ p ∈ P : M’(p) = (M(p) – – E (p,t) 〈b〉) ++ E (t,p) 〈b〉. 4.0 Game Aided by Modeling (GAM) Formalization Method Since established the formalization of a CNP (definitions 1.0, 1.1 and 1.2), following is presented the formalization of a game, in accordance with key concepts proposed by Myers [Myers, 2009]: 1. Representation: associated with the Virtual World (WO) game; 2. Rules (RUτ): players are subject to certain rules during a time interval (τ) for implementing the game; 3. Playability (PL): inherent ease or difficulty of game control elements. The rules and representation elements also apply difficulty and opposition to the player, such as objects to be captured at a particular time and place of the game. 4. Goals (GO): must be achieved so that the player can win a level or a match of game Definition (2.0) – A game G = (WO, RUτ, PL, GO) is a 4tuple such that: 2.1. WO = (I, S, FW) represents the virtual world or Pretending, such that: 2.1.1 I is a vector of image files that represents static scenarios of game; 2.1.2 S is a vector of sound files; 2.1.3 FW is an algorithm that receives a triple (PI, TS, M) where: PI = {(p,i) | p ∈ P e i ∈ I}, TS = {(t,s) | t ∈ T e s ∈ S}. Such algorithm must place images on screen and play sounds in accordance with definitions in marking M(p) ∈ C(p)MS, that represents the current marking of the CPN in an instant of τ runtime game. 2.2. RUτ represents a set of Rules that can be run in instant τ of game running. RUτ = {ruτ = t | ∀ p ∈ P : E (p,t) 〈b〉 <<= M (p). } 2.3 PL = (Ie, M, CMDτ, FP) represents Playability, such that: 2.3.1. Ie is a vector of image files that represents sprites controlled by the game player; 2.3.2. M is a marking in a particular instant τ of running game; 2.3.3. CMDτ is a set of possible commands that the player can choose in an instant τ of game running. The choice of CMDτ by player is associated with the execution of a rule RUτ. 2.3.4. Ce = Cc ∪ Cu and Ce ⊆ Σ is a set of choice tokens to represent sprites, such Cc are sprites that can be controlled by player and Cu are uncontrolled sprites (NPC – non player controller) and represent opposition elements.
2.3.4. FP is an algorithm that receives a 5-tuple (Ie, Cc, Cu, M, CMDτ) and it is responsible by user interface and animation/control of sprites. 2.4 GO ⊂ R(M) is a set of marking or states that is possible to reach from the initial marking. It represents the Goals of game. After GAM method formalization, it is necessary to define a software architecture that, once implemented, becomes concrete the construction of a complete casual game from modeling with availability of image and sound files. Thus, Section 5 presents an adherent architecture implementation to the GAM method. 5.0 Architecture GAM (Game Aided by Modeling) GAM architecture is composed by the integration of software components for developing games based on models and automatic code generation. In this architecture, software tools of self-authoring in combination with software free are interconnected. Figure 5.1 shows the components of GAM architecture in which the direction of arrows indicates the dependencies of a specific component. For example, the tool CPN Tools [CPN Tools, 2014] depends on the operating system to run. The following will be detailed all parts of GAM architecture and its first element was defined in Section 3.2 (Formalizing a Colored Petri Net).
extensions. These files provide the data needed to build a hierarchy of classes of Java language, as discussed in Section 5.2.1 Transformation of CPN in Java objects. Figure 5.2 shows a sample from a file *.cpn in which a component of type Place is represented by a tag <place> in the XML code. Tabela 5.1 - List of Petri nets tools Tool
Propose
Reference
INA
PN place-transition
[INA, 2014]
Pipe
PN place-transition
[Pipe, 2014]
Tina
PN temporal
[Tina, 2014]
CPN Tools
CPN
[CPN Tools, 2014]
Petruchio
CPN
[Petruchio, 2014]
<place id="ID1412319740"> <posattr x="-395.000000" y="249.000000"/> ... <text>house1</text> ... <type id="ID1412319741"> <posattr x="-433.000000" y="275.000000"/> ... <text tool="CPN Tools" version="3.4.0">E</text> </type> <initmark id="ID1412319742"> ... <text tool="CPN Tools" version="3.4.0">1`e</text> </initmark> </place>
Figure 5.2 - Sample of a file in XML format *.cpn generated by the tool CPN Tools.
Figure 5.1 – GAM Architecture. 5.1 CPN Tools There are several software tools of PN available to the scientific and engineering community, allowing productivity in modeling of discrete systems. We can see in Table 5.1 PN tools for different purposes. In fact, tools to development of PN have been used only to modeling systems and not in final development stages of ones. GAM architecture has adopted the CPN Tools, since it allows not only the construction, but also it offers features for analysis and simulation of CPN that modeling a game. Using a CPN developed, reviewed and validated with CPN Tools, it is possible to generate Java objects that abstract the referred CPN. The CPN Tools encode Places, Transitions, Arcs and Tokens in XML (Extensible Markup Language) files that are created with *.cpn
5.2. GAM Play Developed in Java language, the software called GAM Play was implemented according to Definition 2.0 and its class hierarchy is shown in Figure 5.3. Basically, this software joins a CPN model with images and sound to create a game. It receives as input a XML file generated by CPN Tools (file *.cpn) with CPN encoding the game. The GAM Play adds a layer of software that simulates the environment in terms of speed and movement of sprites, collisions, animations and playing sounds (Definition 2.1 and 2.3). This layer of software adds multimedia and control of sprites features to the game in a generic way, while a CPN model specifies the structure and logic of game (rules to support the Definition 2.2 implementation). The GAM Play also must receive a set of goals to recognize if player reaches victory or defeat (Definition 2.4).
Table 5.2 - Place Class Attributes
Figure 5.3. – Conceptual model of class hierarch of GAM Play application (main classes). 5.2.1 Converting CPN Model in Java Objects The translate process of a file *.cpn (CPN model) to Java objects it is made by CpnXmlReader class that reads and stores information from Places, Transitions and Arcs of the target CPN model, respectively, into classes Place, Transition and Arc. Entire *.cpn file structure is covered, using the JDOM library [JDOM, 2004] [Vidakis, 2012] [Puder, 2013], following the existing markings tree. For a better understanding on the semantics of the attributes of the major classes shown in Figure 5.3, are presented in Tables 5.2, 5.3 and 5.4, respectively, the principal attributes of the classes Place, Transition and Arc. In *.cpn file there are many information that are used to build the structure of the CPN model to special purpose of simulation and analysis by CPN Tools. In this initial approach, only essential features to the objectives of this work were analyzed and transcribed for the attributes of Java objects in question. 5.2.2 Multimedia Support and Game Interaction Elements In the class hierarchy shown in Figure 5.3, the BaseGameEntity class is responsible for the linear and angular movement of the game elements. ImageEntity just uses the class BaseGameEntity to manipulate images and to create animations. The Sprite class (subclass AnimatedSprite) abstracts the characters that move in the game. AnimationClass is the proper class that implements the software interface with users. This class receives the controls performed by players via keyboard and is also responsible for controlling of environment images and sounds. The ElementsCPN class receives data from CpnXmlReader class. This data are directly related to key elements of a NPC: Place, Transition, Arc and Token Color and are used to create objects of these elements from the respective classes of the same name (Figure 5.3). According to the Definition 2.0, the AnimationClass will do the correlation between objects of Place, Transition, Arc and Token Color with its elements of games, such as scenarios, sounds, sprites and controls. Thus, the AnimationClass will create a space vector and rules associated to the arcs and transitions that control the sprites, as the specification of the CPN moldel built with CPN Tools.
Attribute
Comment
String id
Unique identifier of CPN Tools to represent a place. Follows the regular expression pattern IDδ where δ is a digit from 0 to 9, eg, ID1412319740.
String text
Refers to text that is positioned within the component place to name it. In Figure 5.2 the term home1 is an example of this attribute.
String initmark
initial marking of the place, i.e., records associated with a specific place from that marking.
int x
Abscissa value in the CPN Tools positional coordinate system.
int y
Ordinate value in the CPN Tools positional coordinate system.
List <Token> tokens
Place dynamic marking, i.e., tokens present in place during the network simulation
List <String> type
List that represents the tuple that defines the color of the token.
Table 5.3 - Transition Class Attributes Attribute
Comment
String id
Unique identifier of CPN Tools to represent a transition. Follows the same pattern as the place id.
String text
Refers to text that is positioned within the transition component to identify him
String cond This attribute defines a condition for the transition can be executed. Table 5.4 - Arc Class Attributes. Attribute
Comment
String id
Unique identifier to represent a CPN Tools arc. Follows the same pattern as the id of the place.
String orientation
Stores two types of PtoT and TtoP values. Respectively indicates the direction of arc if it goes form place to transition (PtoT) or inversely (TtoP).
String transend
Stores the ID of the transition associated with the Arc.
String placeend
Stores the ID associated with the Arco site.
String text
Refers to text that is positioned in the transition component to identify him.
Token weight Refers weight arc.
Table 5.5 - Token Class Attributes. Attribute
Comment
int tokens
Number of tokens of a certain color.
List <String> colors
Represents a proper color as a String sequence (tuple).
5.3 Images and Sounds Images and sounds must be provided so that the game is enjoyable to the player. This is done through files that support the use of images and sounds, available in a location easily accessible to the GAM Play. The image and sound files are associated with elements of CPN modeling game: places and transition. The names of places must match the file names of images that represent the virtual world. The playing sounds, such as explosions, alerts and fire being extinguished, should be associated with specific firing of transitions. Thus, the name of the transition target must have a label identifier to indicate the proper file, e.g., "34 <Die>" means that the output transition 3rd place and 4th place entry must run die.wav sound whenever triggered. The other sound effects, such as background music for each level of the game and moving sprites can be set via a configuration file. 5.4 Configuration Tools Files and configuration tools are used to define characteristics of general nature of the game, which are not easily modelled using the resources of the CPN. Examples of this type of configuration are definition of keyboard navigation keys to control the characters in the game, background music that will be performed continuously and styles of handling the backdrop. 6.0 Case Study In this section, two games that demonstrate how several types of casual games can be developed are presented. In the first, a firefighter must extinguish the flames in a neighborhood. The second is an educational game in which a skeleton must transport coffins emblazoned with expressions of the English language to be deposited in designated graves with prepositions in, on or at. As an initial explanation, Figure 6.1 shows a sample from a CPN model that has two places (house2 and house3), four tokens (one of color (1,1,0) and three of color (0,0,1)), two transitions (23<extinguish> and 32<die>) and six arcs. In this model, the places receive tokens of a composed type of three-dimensional cartesian ordered pairs MxWxF (Firefighter, Water, Fire), corresponding, respectively, to the firefighter, water and fire dimensions. A token (1,0,0) represents only a firefighter, (2,1,0) is two firefighters with water at your disposal and (0,0,1) is just fire. This arrangement allows all combinations of firefighter, fire and water are available for modeling. Thus, in Figure 6.1, the places represent the houses, the token (1,1,0) is one firefighter carrying one water unit positioned in house2 and three tokens (0,0,1) represent three fire units positioned in house3. In the same figure, only the transition 23<extinguish> is enabled. The firing
of this transition means that the firefighter leaves the house2 fitted with water to extinguish one of the three fire units present in house3. In terms of the representation of images, the identifiers of place house2 and house3 are names of image files (house2.png and house3.png) and, in the case of the transition 23<extinguish>, a sound file called estinguish.wav plays to simulate the sound of water extinguishing the fire. The transition 32<die> can be fired if the firefighter tries to extinguish the fire of place house2 without water (token (1,0,0)). In this case, the file die.wav will be executed to represent the death of the firefighter. With this information the GAM Play (Section 5.2) will create the game presented in Figure 6.2. Figure 6.1 – Part of CPN that specifies firefighter game.
Figure 6.2 – Firefighter game defined by GAM Play application in accordance with part of CPN of Figure 6.1.
The CPN model of a complete phase of the said game is shown in Figure 6.3. Figure 6.4 shows the game after the GAM Play has interpreted and formatted the CPN model. The dynamics of how the firefighter gets water can be displayed in place water positioned in the lower right corner of Figure 6.4. Thus, the dynamics take water to extinguish the fire is established.
Figure 6.3 – CPN of firefighter game with more elements.
Text (1,1,0) (x,y,z)
2fd
(x,y,z)
23<extinguish>
(x,y,z)
fd MxWxF (x,y,z)
fd2
(x,y,z)
4fd
(x,y,z)
(x,y,z) 54
(x,y,z)
45
(x,y,z)
47
(x,y,z)
(x,y,z) 87
(x,y,z)
65
(x,y,z)
(x,y,z)
78
97
w6 (1,y,0)
(x,y,z)
8w
(x,y,z)
3`(0,1,0) water
MxWxF
(1,1,0) w8<getw>
(0,1,0) (1,0,0)
(x,y,z) 8h
MxWxF
(1,y,z) ws
(x,y,z)
(x,y,z)
(1,y,z)
6w
(x,y,z)
(x,y,z)
MxWxF
(x,y,z)
(x,y,z)
(x,y,z)
(x,y,0)
house6
house8 MxWxF
79
(x,y,z)
(x,y,z)
house7
(x,y,z)
56
85
(x,y,z) (x,y,z)
(x,y,z)
(x,y,z)
(x,y,z)
58
36
(x,y,z)
MxWxF
(x,y,z)
(x,y,z)
47
(x,y,z)
house5 MxWxF
(x,y,0)
63
(x,y,z)
house4
(x,y,z)
52
(x,y,z) (x,y,z)
(0,0,0) (x,y,z)
(x,y,z)
52
MxWxF
32<die>
(x,y,z)
(x,y,z)
fd4
3`(0,0,1) house3
(0,0,y)
MxWxF (1,0,0)
(x,y,z)
(0,0,1)
house2
(1,y,z)
1`(1,0,0) (x,y,z)
house9 MxWxF
Figure 6.4 – Firefighter game developed with GAM method using the CPN of Figure 6.3. In Figure 6.5, the place house1 on CPN model has been replaced by place fire department (fd), so its representation was modified in the construction process of game. Figure 6.5 also introduces a new element of opposition beyond the fire. It is a place where the firefighter will be trapped by the hole if he tries to cross it. Thus, various evolutions of the game can be created with different levels of difficulty just building models. Another advantage of the GAM method is the fact of having the CPN analysis tool to verify the correctness of the game as the desired semantics. According [Llorens, 2012] Petri nets are useful for the simulation and animation of specifications. They can be used to graphically animate a specification and observe the synchronization of components step by step .In this context, using CPN tools it is possible to check in modeling phase the existence of a deadlock in the CPN, as displayed in Figure 6.5 (arrow indication). Despite the deadlock, this is a required behavior for the game in question. When the hole location is reached by the firefighter he will be trapped. This is an example of opposition from the game to users. In this way CPN Tools helps the game designer to check deadlocks and adjust the level of difficulty of the game. Another example of a situation that can be validated by the analysis tool is to verify that all fire unities can really be extinguished, given the initial marking of the CPN model, indicating that the phase has in fact a solution. Figure 6.6 shows an image of the game firefighter (generated from the CPN model in Figure 6.5) where more than one element of opposition was added. In addiction to the flames, the firefighter can get stuck in the hole place if he takes the wrong path (arrow indication in Figure 6.6).
9h
(x,y,z)
(x,y,z)
hole MxWxF
1h
(x,y,z)
house1 MxWxF
Figure 6.5 – CPN model of firefighter game with two opposition elements: fire and hole. Text
Figure 6.6 – Dynamic of firefighter game in accordance with the Figure 6.5 using the GAM method.
Figure 6.7 â&#x20AC;&#x201C; CPN of specification and tests of an educational game.
Briefly, just to demonstrate productivity in games generation from the modeling of new CPNs models, Figure 6.7 shows the model of an educational game in which a skeleton must do the correlation of English idioms with prepositions in, on and at. Records of four dimensions (skeleton, in, on, at) are used in this case. There are tokens retrieved and delivered places. The tokens retrieved places mean that the skeleton can get a coffin emblazoned with a specific english expression. In the places of delivery, only the exact combination will cause the token disappears (means that the skeleton put the coffin on the grave with success). Figure 6.8 shows the dynamics of the game after the GAM Play received and interpreted the CPN model exposed in Figure 6.7. In accordance with [Zea, 2009] no doubt that educational games like this reinforces the teaching/learning process, so the importance of GAM is increased because teachers can develop similar games to teach better without needs knowing program languages. It is simple to use GAM Play to generate different games. You only need to build a CPN model with elements of image and sound associated with it and run the GAM Play. It is important to emphasize that GAM can be applied to generate different types of games, but maintains a similar style of development. Compare the names of places of CPN models of figures 6.5 and 6.7 and realize that they denote different images, which are combined and exposed respectively in Figures 6.6 and 6.8. Another important details are the sound files extinguish, die and getw of the CPN model in Figure 6.5 and in, on, at in Figure 6.7. In the firefighter game there are three main elements: the proper Firefighter, Water and Flames. In this case it is necessary a three-
Figure 6.8 â&#x20AC;&#x201C; Interpretation of CPN of Figure 6.7 using GAM play application.
dimensional record (MxWxF). In the skeleton game are required four main elements, the proper Skeleton, In, On, At (SxIxOxA). Then, tokens of four dimensions are required. Thus, using similar strategies, games with very different semantics can be constructed. 7.0 Conclusions and Future Works In this work was presented the GAM method with an implementation of an architecture for generating casual games from the processing of CPN models. This type of developing games was demonstrated with modeling two games with different semantics. Besides giving productivity to creating casual games, the use of CPN provides additional advantages over other modeling tools. It is possible to model and simulate the multiple phases of the game, as well to evaluate, in a formal and interactive way, if there is solution to the phase of the game or the adequacy of the level of difficulty to players. For example, still undergoing modeling of the target game, it is possible to check if there are valid paths that lead the firefighter to houses or traps that prevent he goes on through the scenario. Speed, collision, controls of characters and visual effects are abstracted from the game designers. Such features will be implemented under conditions established in the CPN transitions of the modeling game and depend upon software implementations that generalize different types of games, which allow a wide variety of styles of games. According to the results presented in Section 6, the game is instantiated after model processing, without needs of programming. Thus, this process allows people without
knowledge of programming languages create their own casual games, since they have a basic knowledge of CPN. Programmers will always be needed in order to evolve GAM tools that enable increasingly abstract resources controlled by CPNs. The features of modeling and testing present in CPNs are not found, e.g., in UML diagrams that are frequently used in software development. Thus, the research of tools that generate software from the GAM method is plausible for studies aimed at commercial applications of game development. Obviously, there is on the market advanced tools developed by companies of games creation [Unity, 2014] [RPG Maker, 2014] [UDK, 2014] and that offer advanced features for game development. In relation to these tools, GAM offers two improvements: ease of development and testing and validation in modeling time. In fact, such professional tools require that users to manipulate a large number of menus and control many variables. Generally, software development frameworks are specific to a certain field applications, such as information system, car racing games and RPGs. GAM also offers improvements in this aspect, its power of abstraction, based on CPN, allows generating various games of different styles. In this context, it is only necessary that extensions of Play GAM will be developed, adding specific classes for the desired purpose. Because of this extensibility feature, the other components of GAM architecture do not require changes. Also in this matter, the GAM method is intended to not only games, but also te simulators. For this, implementation of GAM Play must faithfully obey the physical laws of the simulation target object. The GAM architecture has solid and formal (CPN) theoretical foundations for automatic generation of casual games. But also practical features are present in GAM Play. Thus, other characteristics are been exploited in an CPN such as hierarchy and time constraints, so as to allow the automatic generation of more complex games, including multiplayer and automatic phase changes. Special Thanks CNPq - National Council for Scientific and Technological Development, the scientific institution very well respected in Brazilian academic milieu by its partnership in the scientific paper accomplishment.
Corona Labs., available in <http://coronalabs.com/ products/corona-sdk/>. At 04/14/2014. CPN Tools. available in <http://cpntools.org/>. At 04/14/2014. Enden, K. V., Enden, D. V., Fannes, T., Wauters, J., “Procedural generation of im-mersive game worlds using Microsoft XNA on the Xbox 360”, M.S. thesis, Advanced Master of e-Media GROUP T-Leuven Eng. College, 2010 Fink, A.; Denzinger, J.; Aycock, J., “Extracting NPC behavior from computer games using computer vision and machine learning techniques”. Proceedings of IEEE Symposium on Computational Intelligence and Games (CIG), Honolulu, p. 24-31, Apr 2007. Ina, available in < http://www2.informatik.hu-berlin.de/~ starke/ina.html >. At 04/14/2014. Jensen, K., Kristensen, L. M. Coloured Petri Nets Modelling and Validation of Concurrent Systems. Ed. Springer Dordrecht Heidelberg. ISBN 978-3-642-002830. Verlag Berlin Heidelberg, 2009, pp. 80 – 93. Jones, R. M. “Design and implementation of computer games: A capstone course for undergraduate computer science education”. In Proceedings of the 31st SIGCSE Technical Symposium on Computer Science Education, pages 260–264. ACM Press, 2000. JDOM (2004) Java DOM-API. http://www.jdom.org/ Jensen, K., and Kristensen, L.: Coloured Petri Nets: Modelling and Validation of Concurrent Systems. Springer Berlin Heidelberg. ISBN 978-3-642-00283-0, 2009. Lee, Y.S., Cho, S.b., “Context-Aware Petri Net for Dynamic Procedural Content Generation in Role-Playing Game”, Computational Intelligence Magazine, IEEE, May 2011. Lee, Y.S., Cho, S.b., “Dynamic quest plot generation using Petri net planning”. In Proceedings of the Workshop at SIGGRAPH Asia (WASA '12), Nov 2012.
References Apple, avaliable in <https://developer.apple.com/library /ios/navigation/#section=Frameworks&topic=SpriteKit>. At 10/17/2014.
Llorens, M., Oliver, J., Silva, J., Tamarit, S., “Generating a Petri net from a CSP specification: A semantics-based method”. Advances in Engineering Software, Elsevier, Vol. 50, Agu 2012, pp. 110-130.
Ashmore, C., Nitsche, M., “The quest in a generated world”, in Proc. Digital Games Research Association Conf., 2007, pp. 503–509.
Murata, T., “Petri Nets: Properties, Analysis and Applications”, Proceedings of the IEEE, Vol. 77, nº 4, Apr 1989.
Booch, G., Rumbaugh, J., Jacobson, I. The Unified Modeling Language User Guide, Addison Wesley, Ed. 1, Oct 1998, ISBN: 0-201-57168-4, 512p.
Myers, D., “In search of a minimalist game”, Breaking New Ground: Innovation in Games, Play, Practice and Theory. Proceedings of DiGRA 2009.
Burns, W. E. "Computer-Aided Design (CAD)". Industrial Education, v75 n6 p10-11 Sep 1986.
Petruchio, avaliable in <http://petruchio.informatik. uni-oldenburg.de/index.html>. At 04/14/2014.
Pipe, avaliable in <http://pipe2.sourceforge.net/>. At 04/14/2014. Puder, A., Antebi, O.; "Cross-Compiling Android Applications to iOS and Windows Phone 7", Mobile Networks and Applications, Fev 2013. RPG Maker. Avalible in <http://www.rpgmakerweb. com>. At 05/01/2014. Santos, S. D., Roque, L. G., "Ensaio de Reescrita de Comportamentos em Videojogos com Base no Ajuste e Computação de Modelos de Petri Net (Essay of Behaviors Rewrite in Videogames According to Petri Net Models)", IX SBGames, Nov 2010. Smith, A.M., Nelson, M.J., and Mateas, M., “LUDOCORE: A logical game engine for modeling videogames”, in Proceedings of the IEEE Conference on Computational Intelligence and Games, 2010, pp.91-98. Sobrinho, J. Z., “Aspectos da Tese de Church-Turing”. Instituto de Matemática, USP. Dez de 1987. Tina, avaliable in <http://projects.laas.fr/tina/> . at 04/30/2014. UDK., avaliable in <https://www.unrealengine.com/ products/udk/>. At 05/01/ 2014. Unity Technologies, avaliable in < http://unity3d.com/pt/ learn/tutorials/modules/beginner/2d/2d-overview>. At 05/01/ 2014. Vidakis, N., Akoumianakis, D., Katimeri, C.; "Articulating a 3D metaphor for displaying and exploring vacation packages", 3D Research, Mar 2012. Zea, N. P., Sánchez J. L. G., Gutiérrez, F. L., Cabrera, M. J., Paderewski, P., “Designing, modelling and implementing interactive systems”. Advances in Engineering Software, Elsevier, Vol. 40, Dec 2009, pp. 1251-1260.