APPLYING MDA TO GAME SOFTWARE DEVELOPMENT

Takashi Inoue and Yoshiyuki Shinkawa

Graduate School of Science & Technology, Ryukoku University, 1-5 Seta Oe-cho Yokotani, Otsu, Shiga, Japan

Keywords:

Game software, Modeling, MDA, UML.

Abstract:

Game software becomes more and more complex, according as the game platforms are improved or the re-

quirements of game users become sophisticated, and so does the development of game software. However,

there are few established development methodologies for game software development, and it decreases the

productivity of the development. One of the solutions for this problem is to apply modeling technologies

to it as we do to other application areas, and through modeling we can anticipate productivity improvement.

This paper evaluates the applicability and suitability of MDA (Model driven Architecture) to game software

development, along with establishing a UML modeling process for typical game categories.

1 INTRODUCTION

Since Atari released VCS (Video Computer System)

in 1970’s, many game platforms and games that run

on them have emerged. These games are usually im-

plemented as software, and the scale and complex-

ity of the game software have increased year by year,

according as the game platforms are improved with

higher performance CPUs, higher speed graphic en-

gines, and larger size memories, or as the require-

ments to the games become sophisticated.

In many software application domains which in-

clude ﬁnance systems, insurance systems, plant con-

trol systems, and embedded systems, object oriented

and model driven approaches won great success in

software developments. However, there are no es-

tablished methodologies in game software develop-

ment, including object orientation and modeling. One

of the difﬁculties in creating a standard methodol-

ogy for game software development is that each game

presents its unique appearance, behavior, and func-

tionality, or in other words, they are too different from

each other.

The lack of established methodologies would de-

crease the productivity of game software develop-

ment, and makes it difﬁcult to reuse software assets.

The introduction of the above object oriented and

model driven approaches into game software develop-

ment seems to improve the productivity and reusabil-

ity. These approaches would improve them especially

in the large scale game software development, in the

following points.

• Each project member can commonly understand

the system to be developed

• The resultant system can be rigorously veriﬁed to

the requirements

• The system conﬁgurations can be validated in

early phases of development

• The scale of development can be predicted

In this paper we discuss the applicability of object

orientation and modeling technologies to game soft-

ware development, along with a modeling process.

As a modeling framework, we focus on MDA (Model

Driven Architecture) which is one of the state-of-the-

art modeling technologies, and as a object oriented

modeling language, we use UML (Uniﬁed Model-

ing Language), which is one of the industry-standard

modeling languages.

The paper is organized as follows. In section 2, we

discuss the scope of modeling, in which the applica-

bility of the above technologies is examined. Section

3 deﬁnes a classiﬁcation of games, in order to view

the games at more abstract level for modeling. Sec-

tion 4 presents a detailed modeling process in game

software development.

454

Inoue T. and Shinkawa Y. (2008).

APPLYING MDA TO GAME SOFTWARE DEVELOPMENT.

In Proceedings of the Tenth International Conference on Enterprise Information Systems - ISAS, pages 454-459

DOI: 10.5220/0001726604540459

 SciTePress

2 MODEL DRIVEN GAME

SOFTWARE DEVELOPMENT

MDA is a development approach which focuses on

modeling of target domains or systems. MDA deﬁnes

two different kinds of models, namely PIM (Plat-

form Independent Model) and PSM (Platform Spec-

ify Model).The former represents the models that are

independent to the platforms, which represent a tar-

get problem domain at higher abstract level, in order

to depict and understand what it essentially is. On

the other hand, the latter represents the models which

show how the domain is implemented on a speciﬁc

platform. PSM could automatically be transformed

from PIM using some tools in MDA (Frankel, 2003).

We mainly focus on the analysis and high-leveldesign

phases in game software development. Therefore, this

paper deals with only PIM, that is, the models inde-

pendent from platforms, in order to evaluate whether

we can model game software based on MDA.

Up to now, we have been designing game soft-

ware in programming-oriented style, mainly using

script languages, which is relatively old-fashioned in

comparison with modern model oriented approaches

(Nishimori and Kuno, 2003). This old-fashioned style

often decreases the productivity of game software de-

velopment. If we can apply MDA to game soft-

ware development, we would anticipate the improve-

ment of productivity, since there are many advantages

of modeling to the above old-fashioned development

style, as stated in the previous section.

In general, there are two orthogonal aspects in

software modeling. One is “static” or “structural” as-

pect, and the other is “dynamic” or “behavioral” as-

pect. Most games implemented as software show very

dynamic appearances. They are composed of many

game elements, namely characters including the pro-

tagonists, vehicles, weapons, animals, ﬂowers, and so

on. Each game consists of the complicated combina-

tion of the behavior of these game elements along the

timeline. Therefore the dynamic aspect seems more

important in game software than the static aspect, and

we mainly focus on the dynamic aspect of the games

in order to evaluate whether we can express them as

the models in terms of MDA.

We use UML as modeling tool, since UML is one

of the industry standard modeling languages in ob-

ject orientation (Miles and Hamilton, 2006). We ﬁrst

take the following ﬁve diagrams into account, that is,

“use case”, “activity”, “sequence”, “state machine”,

and “timing” diagrams, which represent the behav-

ioral aspects in various ways.

3 THE CLASSIFICATION OF

GAME SOFTWARE AND THE

SCOPE OF MODELING

There havebeen released numerousnumber of games.

Each of them has unique characteristics and very dif-

ferent from each other, in its behavior, appearance,

construction of the game, and operation. This unique-

ness is important to make each game competitive in

the market, however it makes it difﬁcult to view the

games from common viewpoints in order to express

and analyze them through modeling. From modeling

viewpoints, it is important to view the games at more

abstract levels. One of the approaches to abstraction is

classiﬁcation using criteria. There are several possi-

ble criteria such as genres, platforms, prices, degrees

of difﬁculty, and purposes.

Among the above criteria, genres are suitable for

abstraction to model the games, since the games in

the same genre would show the similar behavior. The

typical genres of video games and computer games

are as follows (Laird and Lent, 2000) (Fairclough and

Cunningham, 2001).

• Action games: A human player controls a char-

acter in a virtual environment. These games

emphasize combat against enemies using various

weapons.

• Role playing games: A human player may select a

favorite character from different types of charac-

ters, such as a warrior, a magician, or a thief. The

player goes on quest, trading items, ﬁghting with

monsters, or changing the capabilities.

• Adventure games: A human player solves puz-

zles and interacts with other characters, as he/she

progresses through an unfolding adventure. These

games emphasize story, plot and puzzle solving.

In addition to the above three genres, there are

other game genres of strategy games, god games,

team sports games, board games, table games, sim-

ulation games, shooting games, and so on.

Even though there are many game genres, recent

market trends show the majority of games can be cate-

gorized into one of the three major genres, namely ac-

tion games, role playing games, and adventure games.

Therefore, this paper discusses the adaptability of

modeling technologies to the games in these three

genres. We abbreviate action games as ACT, role

playing games as RPG, and adventure games as ADV

henceforth.

In these kinds of games, a human player and game

software mainly interact through a input device and

display. The input device is often called a game con-

troller. The player can take various operations using

APPLYING MDA TO GAME SOFTWARE DEVELOPMENT

455

Figure 1: Classiﬁcation of game operations.

the game controller, which affect the game progress.

These operations can be divided into two different

types. One is an asynchronous operation which the

player can take at any time in a game stream, and the

game proceeds without this operation. The other is a

synchronous operation which is taken in order to re-

sume a paused game stream, and is taken in the form

of selection or answer. Since the former often occurs

in action games, and the latter often occurs in adven-

ture games, we refer the former as an action oriented

operation, and the latter as an adventure oriented op-

eration. Figure 1 shows the above classiﬁcation of

player operations and Figure 2 shows a classiﬁcation

of these games based on the above two operations.

Figure 2: Classiﬁcation of games.

As shown in Figure 2, RPG fully include ADV

from these two operational viewpoints. Therefore, we

deal with only ACT and RPG. In order to evaluate the

adaptability of modeling technology to the above two

games, namely ACT and RPG, we assume the typ-

ical scenes and actions in above games as shown in

Table 1 and Table 2. The brief descriptions of these

games are as follows (Onder, 2002)(Taylor and Bas-

kett, 2006).

[ACT]

1. Characters horizontally move with jumping ac-

tions.

Table 1: Components of ACT.

Scene Component Action

Battle Player Move

Jump

Attack

Weapon change

Change the target at

which the weapon aims

Enemy Move

Jump

Attack

Change the target at

which the weapon aims

Bullet Move forward

Barricade -

Table 2: Components of RPG.

Scene Component Action

Town Player Move

Talk to

Open the Menu

Inspect

Construction -

(Houses etc)

Fixture -

(Doors etc)

Inhabitants -

(Merchants etc)

Prompt Player Select

(Shopping, decide

Conversation, Advance the

Selection Menu) Messages

2. A player may engage with enemies using

weapons.

3. A game exits when a player lose all the HPs (hit

points) which he/she obtained.

4. Attack items, e.g. bullets, arrows, spears or ﬁre-

balls disappear after timeouts.

[RPG]

1. A player can change the atmosphere. (go to the

next room etc)

2. A player can talk with inhabitants. If there mer-

chants, he/she can trade with them.

3. A player can buy items such as weapons, protec-

tors, tools.

ICEIS 2008 - International Conference on Enterprise Information Systems

456

4 APPLYING UML TO GAME

SOFTWARE DEVELOPMENT

In this section, we discuss how UML is applied to

ACT and RPG based on the game components and

speciﬁcations stated in the previous section. Figure

3 shows the modeling process we use, which is com-

plied with use case driven development, e.g. I. Jacob-

son’s OOSE (Object-Oriented Software Engineering)

(Jacobson, 2000).

Figure 3: A modeling process for games.

In this process, use case diagrams are ﬁrstly cre-

ated through requirement analysis, then each step is

consecutively performed, following the directed ar-

rows, and ﬁnally we obtain state-machine diagrams

with optional timing diagrams. However, the paper

mainly aims at the applicability of UML to game soft-

ware development from behavioral or dynamic view-

points, and therefore we do not discuss the step for

class diagrams in Figure 3, but we assume appropri-

ate class diagrams are derived.

Figure 4: Modeling view points of UML diagrams.

The ﬁve kinds of UML diagrams to be created,

excluding class diagrams, are classiﬁed as shown in

Fig 4, from two orthogonal viewpoints, namely “part-

whole” and “internal-external”. The paper focuses

on partial-order relationships between actions in the

games and we do not deal with real time based con-

straints, as script design languages currently used do

not. Therefore, timing diagrams are not discussed

henceforth in this paper. Detailed modeling processes

for ACT and RPG are presented in the following sub-

sections.

4.1 Use Case Diagrams

[ACT Modeling]

Possible actions in ACT shown in Table 1 are ag-

gregated into three action groups of “Player ac-

tions through input devices”, “Background object ac-

tions”, and “Object collisions”, from player view-

points. These three groups are represented by use case

diagrams in the following way.

1. Player actions through input devices

Each player operation through input devices is ex-

pressed as a use case. These use cases charac-

terize the game software from operational view-

points, since the game requires rapid player reac-

tions through the devices.

2. Background object actions

Each action performed by objects except the

player, e.g. a background object movement or an

enemy attack, is expressed as a use case. A player

takes an appropriate action through the devices,

reacting these object actions.

3. Object collisions

Each event that occurs by an object collision is

expressed as a use case. Such events include ex-

plosions, vanishment, or splits of the objects. In

ACT, a player could be affected by these events,

e.g. he obtains score points when the bullets hit

enemies. There are enormous numbers of object

collisions to be considered, however most colli-

sions do not affect the player, for example, even if

a collision between the player and a wall occurs,

it only affects his movement, and is expressed as a

use case in “background object actions”. We only

deal with the collisions that affect the player seri-

ously.

[RPG Modeling]

RPG include much more adventure based operations

than action based ones, therefore we mainly make ef-

fort to model the adventure based operations. As for

action based operations, we can follow the same pro-

cess for ACT. The use case modeling process for ad-

venture based operations is as follows.

1. An adventure based operation can be represented

as a series of decisions which are made by select-

ing from option lists. Each option in the list is

regarded as a use case, and it composes a decision

tree, the nodes of which are use cases. Such a tree

APPLYING MDA TO GAME SOFTWARE DEVELOPMENT

457

structure of use cases clearly describes the rela-

tionships between use cases, and makes the use

case diagrams understandable.

2. The option lists that are dealt with in the above

step are limited to those with a ﬁxed number of

predeﬁned options, in order to make the modeling

simpliﬁed. The lists with a variable number of

options, or variable kinds of options are dealt with

in use case scenarios.

4.2 Activity Diagram

[ACT Modeling]

Numerous object collisions could occur in ACT, and it

seems important to model these collisions in activity

modeling for ACT. In order to handle these collisions

easily, we assume a collision monitoring component

is included in ACT software (Rocker, 2002). The ac-

tivity modeling process for ACT is as follows.

1. ACT usually include very complicated game

ﬂows according to player actions and object colli-

sions. Therefore, it is not practical to include all

the game ﬂows from the beginning to the end of

ACT in a single activity diagram. Instead, we take

a time slice out of the whole duration of the game,

and build an iterative activity model with possible

concurrent actions, which are consolidated into a

collision detection mechanism. The collision de-

tection is performed at the end of each time slice

in order to reduce complexity. The game may exit

from any times slices discussed above, based on

exit conditions. In order to simplify the activity

diagrams, the actions are hierarchically decom-

posed, and so are the activity diagrams.

2. Complete all the activity diagrams at every lev-

els of the above action hierarchy. In above each

time slice, the game player may or may not take

an action through an input devices, therefore two

different situations could occur according to the

player’s choice. This choice expressed as a deci-

sion node of UML activity diagrams. If there are

multiple objects other than the player controlled

character in the time slice, they are expressed as

an input collection of an expansion region. Using

expansion regions could simplify the complicated

multiple object behavior, which may be depicted

with similar actions of multiple objects.

3. If the abovecollision detection mechanism detects

collisions, complete the activity diagrams which

represent the resultant effects caused by the col-

lisions. These diagrams can be built in a similar

way to the diagrams discussed in item 1 and 2.

[RPG Modeling]

In RPG, activity modeling is performed based on the

combination of action oriented operations and adven-

ture oriented operations. The modeling procedure is

as follows.

1. Action oriented operations in RPG can be repre-

sented similarly to ACT. However, RPG allows

a game player to change action scenes and ad-

venture scenes bidirectionally, and all the action

scenes must be resumed from the interruptions.

In order to resume the scenes, all the states at

the interaction points must be stored in any way.

For this purpose, we use history pseudo-states in

UML state machine diagrams to store the states.

Even though it is not a standard notation of a UML

activity diagram, we expand UML activity dia-

grams using these pseudo-states to express the re-

sumption of the scenes.

2. Adventure oriented operations are decomposed

based on the selections in adventure scenes, and

as a result, activity diagrams for the operations are

expressed hierarchical activity diagrams. This no-

tation can simplify each activity diagram, in com-

parison to a huge activity diagram which includes

all the selection.

4.3 Sequence Diagram

In our approach, a sequence diagram is basically cre-

ated for each activity diagram.

[ACT Modeling]

A sequence diagram of an ACT is composed of a sin-

gle loop fragment, since each activity diagram for a

time slice or referenced diagrams from it is expressed

as a loop. The creation rules for sequence diagrams

are as follows.

1. The behavior of each object that occurs in the

above loop fragment is depicted in a par fragment

resides in the loop fragment, followed by an opt

fragment which deal with the collisions of the ob-

jects. This structure reﬂects the above mentioned

collision detection mechanism.

2. If there are ref fragments in the above diagram,

break it down into another sequence diagram.

3. Similarly, each ref fragment in the opt fragment

for object collisions is broken down into another

sequence diagram.

[RPG Modeling]

In RPG, additional modeling efforts are needed for

adventure oriented operations.

ICEIS 2008 - International Conference on Enterprise Information Systems

458

1. Depict an opt fragment for scene switching, suc-

ceeded by the per fragments that reside in the

above discussed loop fragment. This fragment

includes ref fragments which represent scene

switching operations.

2. The rest of the loop fragments are identical to

ACT.

3. Depict the object behavior that is represented by

the ref fragments in item 1 in the form of sequence

diagrams.

4.4 State Machine Diagram

State machine diagrams for ACT and RPG are ex-

pressed as the hierarchies of composite states in our

approach.

[ACT Modeling]

1. At the top of the hierarchy of state machine dia-

gram, crate a state machine diagram represent the

whole game. This state machine diagram includes

other diagrams, each of which represents more de-

tailed level game operations.

2. If there are multiple state transitions within an ob-

ject, these transitions are depicted by the regions

in a composite state.

[RPG Modeling]

In RPG, in addition to the hierarchical descriptions for

action oriented operations, adventure oriented opera-

tions are also described hierarchically. The following

shows the basic rules for modeling.

1. Action oriented operations are modeled in the

same way to ACT.

2. As for adventure oriented operations, possible se-

ries of player’s decisions for selection items are

hierarchically expressed as composite state ma-

chines. Each player’s choice represented as a

choice pseudo-state.

5 CONCLUSIONS AND FUTURE

WORK

In this paper, we proposed a model based approach to

developing game software. We adopted MDA (Model

Driven Architecture) as a modeling framework and

UML as a notational tool. Among various game cat-

egories, we selected three game categories, that is,

ACT (ACTion games), ADV (ADVenture games) and

RPG (Role Playing Games), for modeling, since these

categories are seemed to dominate today’s game mar-

ketplace.

We characterize the games from two orthogonal

game player operations, namely adventure oriented

operations and action oriented operations. From these

view points, RPG include ADV, therefore the target

categories of our modeling are limited to ACT and

RPG. We proposed a systematic way to model the

above games for each UML diagram type and game

player operation type. These UML diagrams include

use case diagrams, activity diagrams, sequence di-

agrams and state machine diagrams. By applying

our approach to modeling typical game situations, we

conclude the modeling approach to ACT and RPG to

be feasible. Our modeling approach makes the de-

velopment of game software identical to other tradi-

tional software developmentlike business software, in

which modeling technologies are effectively used.

In order to deal with real time constraint of the

games, timing diagrams would be needed. In addi-

tion, static diagrams like class diagrams, deployment

diagrams or component diagrams are also needed to

determine the game software structure.

REFERENCES

Fairclough, C, F. M. N. B. and Cunningham, P. (2001). Re-

search directions for ai in computer games. In Pro-

ceedings of the Twelfth Irish Conference on Artiﬁcial

Intelligence and Cognitive Science PP.333-344.

Frankel, D. (2003). Model Driven Architecture: Applying

MDA to Enterprise Computing. Wiley.

Jacobson, I. e. (2000). Object-Oriented Software Engineer-

ing. ADDISON-WESLEY.

Laird, J. and Lent, M. (2000). Human-level ai’s killer ap-

plication:interactive computer games. In AAAI/IAAI

PP.1171-1178.

Miles, R. and Hamilton, K. (2006). Learning UML 2.0.

O’REILLY.

Nishimori, T. and Kuno, Y. (2003). Action game-oriented

programming language. In ISSN Vol.44th PP.35-46.

Onder, B. e. (2002). GAME DESIGN PRESPECTIVES.

Charles River Media.

Rocker, R. (2002). Engineering and Computer Games.

Addison-Wesley.

Taylor, M.J, G. D. and Baskett, M. (2006). Computer game-

ﬂow design. In ACM Computers in Entertainment

Vol.4,No.1 PP.1-9.

APPLYING MDA TO GAME SOFTWARE DEVELOPMENT

459