towards a game modelling language

Towards a Game Modelling Language

Pieter van der Hijden

Sofos Consultancy

Pieter van der Hijden

Amsterdam, 3 October 2001.

sofos consultancy

management consulting and ICT

p p.o. box 94874, 1090 gw amsterdam,

the netherlands

b b. stokvisstraat 38, 1097 hz amsterdam,

the netherlands

t +31 – 20 – 694 12 22

e [email protected]

w www.sofos.nl

‘let’s build your future...’ 32nd Annual International Conference of the International Simulation and Gaming Association (ISAGA), September 2001, Bari, Italy On the edge of the Millennium: a new foundation for Gaming Simulation

postbank 4384841

kvk amsterdam 33.181.262

ISAGA 2001- Towards a Game Modelling Language ii

© 2001 - Sofos Consultancy www.sofos.nl

Summary

1. A shift of attitude towards game development is required. The gaming community

needs to see it less as a craft and more as an industrial activity. Modern infor-

mation & communications technology (ICT) can help make this shift possible. A

new foundation for gaming simulation will then lie within reach.

2. Although computers have been used in gaming for many years, their contribution

to the game development process remains limited to word processing.

3. The game development process involves a lot of relatively simple administrative

and clerical tasks. There are many opportunities for improving efficiency in this

area.

4. A Game Description Standard can provide a model or framework for storing all

information produced during the game development process.

5. Dedicated software tools are required that can author, publish, store, retrieve and

convert game descriptions that follow this standard.

6. The XML tools that are now on the market or in the public domain can deliver the

required functionality. We suggest an XML document scheme, which requires

formal definition of the Game Description Standard.

7. An XML-based formal language, called Game Modelling Language, has been de-

veloped for game descriptions that follow the standard. It represents a significant

contribution to any new foundation for gaming simulation.

Pieter van der Hijden M.Sc.

Sofos Consultancy

Sofos Consultancy is a consulting firm specialising in general management and information &

communications technology (ICT). Founded in 1980 and based at Amsterdam in the Netherlands,

Sofos provides facilitating, diagnostic and knowledge-based services relating to organisational de-

velopment and modern ICT applications. Pieter van der Hijden M.Sc. is an experienced interim-

manager, consultant and software engineer in both the public and market sectors.

ISAGA 2001- Towards a Game Modelling Language iii


Contents

1. Introduction ..................................................................................................................................... 1

1.1. A New Foundation for Gaming Simulation? ........................................................................... 1 1.2. ICT and gaming ....................................................................................................................... 2 1.3. This Paper ................................................................................................................................ 2

2. Game Development Process ............................................................................................................ 3 3. Game Description Standard ............................................................................................................. 5 4. Required ICT tools .......................................................................................................................... 7 5. Implementation ................................................................................................................................ 8 6. Game Modelling Language ........................................................................................................... 10

Appendices ............................................................................................................................................ 12

A. References ........................................................................................................................................ 13 B. Document Scheme ............................................................................................................................ 14 C. Sample XML Document ................................................................................................................... 17

ISAGA 2001- Towards a Game Modelling Language 1


1. Introduction

1.1. A New Foundation for Gaming Simulation?

The title of this 32nd Annual International Conference of the International Simulation

and Gaming Association (ISAGA) is ‘On the edge of the new millennium: a new

foundation for gaming simulation’. The conference organisers did not make clear in

advance how they interpret their title. I have therefore allowed myself the freedom to

present an independent interpretation.

At present, the demand for gaming and games is growing. Games for entertainment

have already become a billion-dollar business. Gaming in education is developing

hand-in-hand with e-Learning. The latter is seen as an important contribution towards

solving the problem of growing numbers of people needing ever more education. The

developers of electronic course material consider games an indispensable part of their

product.

Government and business wish to raise levels of co-operation. Meetings should be

more effective and more efficient. This implies a demand for professional facilitators

and their tools: games and exercises. Games and exercises can be bought off-the-shelf,

but custom-built games usually fit the job much better. These societal changes present

new opportunities for gaming professionals [Van der Hijden, 1996].

Developing games has long been seen as a craft. Typically, the game-developer stud-

ies the problem domain, constructs a conceptual map, and then produces the game

components. Although this may be satisfying for the developers themselves, it is less

so for the customer. The current method of game development often takes too much

time and costs too much money.

An industrial method of game development implies co-operation across organisational

boundaries during the design stage. This means that the game developer will not have

to reinvent every wheel and will have access to existing components. Game develop-

ers may become architects in stead of construction workers [Alexander, 1977].

Figuur 1 - Gaming as a craft



I believe that we need to see game development shift from being a craft to being an

industrial activity. Modern information & communications technology (ICT) can help

make this possible. A new foundation for gaming simulation will then lie within reach.

1.2. ICT and gaming

Although the term ICT (Information and Communications Technology) as such is rel-

atively new, the use of computers in gaming is not. For the last 30 years computers

have been assisting game participants, game operators and game developers alike

[Van der Hijden, 1978]. In most cases they support the participants. Less often they

help the game operators. They are also frequently used as a tool by game developers.

However, the functionality of this tool has been limited.

Thirty years ago, computer assistance for game developers merely consisted of simple

word processing and, eventually, the testing of accounting modules. Today, word pro-

cessing can be quite complex and may include multimedia. Nevertheless, word pro-

cessing remains the essence of computer-supported game development. More elabo-

rate functions that have a real impact on the process itself have not yet been used.

1.3. This Paper

In this paper, we concentrate on the game development process and on its efficiency.

The improvements suggested here involve concentrating all information relating to a

given game in a Game Description and establishing a Standard for that document. The

efficient handling of this description requires specific ICT tools. A concrete proposal

for the use of these tools is given below. The result is a Game Modelling Language

that is offered here as a contribution to our new foundation for gaming simulation.

Figuur 2 - Gaming as an industrial process



2. Game Development Process

The game development process is a complex of activities that ultimately result in a

game kit. During this process the game developers transform ‘raw materials’ like re-

quirements, background information, ideas, paper, pencils and other paraphernalia into

a complete game description, plus the necessary gaming material (or instructions on

how to build or buy it). Game development is a process that depends heavily upon in-

formation. The individual game developer may store intermediate results in their head.

A development team, however, will certainly have to make any information explicit

and record it on paper or in computer files.

The statement (by Einstein, I believe) that an invention is 10% inspiration and 90%

perspiration, is equally true of game development. The development process is time-

consuming and therefore expensive, most of it consisting of simple administrative

tasks and/or the repetition of earlier work. Efficiency improvements would be very

welcome here.

So what could make the game development process more efficient?

1. The individual game developer often has to write down the same piece of infor-

mation several times. Descriptions of various roles usually have certain para-

graphs in common. The role descriptions appear not only in the game operator

manual, but also (formatted slightly differently) as a leaflet in the hands of the par-

ticipants. With word-processing you can copy and paste your text for the first ver-

sion, but later changes are extremely tedious to introduce. It would be very useful

to be able to write your source text once only and then use it in different places

without additional effort.

2. Game developers find that administrative work multiplies as soon as they embark

on producing different language editions of the same game. How are they going to

manage the source text, a translation and a proof-read translation? They apparent-

ly have to maintain three separate versions of the documents and to introduce

changes to each version separately. It would be very useful to be able to work into

a single document.

3. No topic should be missing from the game description. To achieve completeness,

developers often use an older game manual as a template or checklist. Although

this makes good practical sense, it offers no guarantee that the new game will be

completely described. It would be very useful if a comprehensive checklist could

be built into the format.

4. For a team of game developers working from different geographical locations, it is

nearly impossible to manage the exchange of information. This is especially so

when several versions of the same document are in circulation, to which only

small changes are being made. It would be very useful if all changes to the docu-

ment could be co-ordinated.

5. It is very difficult to retrieve information from a set of game descriptions. Finding

well-defined pieces of information in the game descriptions of other developers

can be almost impossible. It would be very useful if retrieval were accelerated via

a common standard.

Information is the glue that binds together all the stages of the game development pro-

cess. If we want to make the game development process more efficient, we have to



improve the ways in which game developers create, handle, store and retrieve

information.

Source text entered more than once

Language versions in separate documents

Limited completeness check

Complex coordination cooperative work

No retrieval in database

Figure 3 - Time consuming characteristics of game development process



3. Game Description Standard

If the full range of information that game developers create during the development

process is to be made manageable, it has to be structured. And if the aim is to share in-

formation with other developers in an efficient way, this structure has to be standard-

ised. I am therefore proposing a Game Description Standard that provides an empty

framework in which to store all information items created and/or updated during the

game development process. This means that no information will have to be stored

more than once. The game description does not replace the game manual. It is simply

the source text from which all game related documents can be derived, the game man-

ual being one of them.

A first version of a Game Description Standard consists of the following information

items:

1. Game Identification – Name, version and copyright notification.

2. Meta Data – Any keywords or other game characteristics that allow the retrieval

of the game in a database management system. In ‘Gaming – the Future’s Lan-

guage’ [Duke, 1974] Richard Duke presents what he calls ‘interpretative criteria’,

which in effect is an extensive list of meta-data. In practice, however, any collec-

tion of games contains examples of additional meta-data. In ‘Games of the World’

[Grunfeld, 1982], Frederic Grunfeld uses, for example, the length of preparation

time required and the indoor/outdoor character of the game. In ‘Learning through

Fun and Games’ Elyssebeth Leigh and Jeff Kinder [Leigh, 1999] present eight

use-categories ranging from ‘Trust & Change’ to ‘Energisers’.

3. Background Information – Any related documentation: for example, on the real

world issues which the game is addressing.

4. Preconditions – Any conditions that have to be fulfilled before a game session

makes sense: for example, the organisational setting, the physical setting, the type

and number of participants.

5. Game System – The components of the game and their mutual relationship: for

example, the game operator, the roles for participants, mechanisms like game

boards or computer systems - and the relationships between them.

6. Game Process – The time sequence of a game session. The macro cycle of the

game consists of installation, game introduction, role allocation, role introduction,

setting the initial state, micro cycles, generating events, role debriefing, role de-

allocation, game debriefing, de-installation. The micro cycle consists of proce-

dures for each role and processes for each mechanism. A procedure consists of a

procedure identification, preconditions, purpose, method, steps, and post-

conditions. A step can be a procedure on its own. Rob Horn’s ‘How to Write In-

formation Mapping’ [Horn, 1976] could (once again!) be a useful source of infor-

mation here.

7. Post-conditions – Possible outcomes of a game session.

The aim in presenting this first version of the Game Description Standard is primarily

to introduce the concept. Later versions would have an expanded hierarchy of infor-

mation items. It should also be possible to draw a distinction between required and op-

tional information items.



Meta Data

Background Information

Preconditions

Game System

Postconditions

Identity

Game Process

Game Description

Standard

21-09-2001 - v7

Game Director

Roles+

Relations

Installation

Game Briefing

Role Allocation

Role Briefing

Initial State

Micro Cycles

Title

Preconditions

Purpose

Method

ProcedureSteps

Postconditions

Events/Triggers

Role Debriefing

Role De-allocation

Game Debriefing

De-installation

Figure 4 - Visualisation of the Game Description Standard



4. Required ICT tools

The handling of a standardised game description requires dedicated ICT tools. These

would have to provide the following functions:

• Authoring – the creation and updating of information items according to the pre-

scribed structure of the Game Description Standard.

• Publishing – automatic formatting of predefined parts of a standardised game de-

scription, in order to prepare ‘publications’: e.g. the game designer’s documenta-

tion on paper, the game operator manual on paper, the gaming instructions for

each role on paper, a game summary for a website, a shopping list for game para-

phernalia on a WAP-phone, etc.

• Storage and Retrieval – the permanent storage and easy retrieval of the game de-

scription. A simple form is via saving and opening of files within a hierarchical

file structure. A more elaborate form is storage and retrieval within a dedicated

database management system that utilises meta-data for advanced retrieval opera-

tions.

• Conversion – the conversion of non-standard but structured game descriptions to

standardised game descriptions and vice versa. Further, the ‘upgrading’ of existing

standardised game descriptions to possible new versions of the standard.

authoring

sof tw are

game

de-

scrip-

tion

storage &

retrieval

selec-

tion

publishing

sof tw are

docu-

ment

sche-

me

data

base

game

man-

ual

role de-

scrip-

tion

list of

game

items

inspi-

ration

conversion

fo-

reign

format

Figure 5 - System view of the required ICT tools



5. Implementation

With current word processing software it is possible to author, publish, store, retrieve

and even convert information in documents. However, faced with our requirements,

the performance looks very inadequate. Given the WYSIWYG principle (‘what you

see is what you get’), you will only get what you see. Authoring and publishing are

combined. In practice, you author certain content and specify its layout in a publica-

tion (e.g. the game operator manual) at the same time. When you want to publish an-

other selection of your content in another format, you are faced with a lot of additional

clerical work.

Fortunately, far better tools are available. These tools use XML. This ‘eXtensible

Mark-up Language’ is a relatively simple standard for structured documents and mes-

sages. The standard has been set by the World Wide Web Consortium; it is thus public

and free. A growing number of computer programmes are ‘XML aware’. They include

applications that have nothing to do with the World Wide Web, but which use XML to

add structure to the content of messages and documents.

An XML document is a plain text file. Within this text, pairs of labels give the docu-

ment its formal structure. In principle, authors of XML documents are free to structure

their own documents. However, they may refer to a so-called ‘document scheme’, in

which the rules for a certain document type (e.g. the Game Description Standard!)

have been formalised. Software can validate an XML document to its corresponding

scheme. My company SOFOS has developed such a scheme for the first version of the

Game Description Standard.

Various tools are available, both on the market and in the public domain, which could

fulfil the required functionality:

• Authoring – Because XML documents are text files, a simple text editor like Mi-

crosoft Windows Notepad is sufficient to create and edit XML documents. How-

ever, the user will also require detailed knowledge of XML. The downloadable

XMLnotepad programme is free and a better tool. Once loaded with the document

scheme, it forces the user to produce and maintain a game description that con-

forms to the standard. Even more elaborate tools are available on the market. They

offer authoring environments that conceal any XML technical details from the us-

er.

• Publishing – XML is in fact a family of standards. Dedicated members of the fam-

ily take care of the specification of the selection and the transformation of compo-

nents from an XML document. Once you have set up such a specification, special

software will generate well-formatted output (rich text, web pages, WAP-stacks)

automatically. The game developer only has to author the game description. Once

this is available, various publication-dependent scripts can generate the formatted

output without further human intervention.

• Storage and Retrieval – The same storage and retrieval mechanism is available as

that used in ordinary word processing documents. Dedicated XML databases that

enable advanced search and retrieval mechanisms (such as browsing through a

whole collection of games) can be found on the market.

• Conversion – technically speaking, publishing is a dedicated form of conversion

(from source document to formatted document), so similar types of software can

be used for conversion from XML to other structured formats. There is also a



range of tools and dedicated script languages available for conversion to XML

from other formats.

The XML-tools that are now on the market and in the public domain can provide all

the necessary functionality. The only item that SOFOS has had to develop was the

XML document scheme for the Game Description Standard (see Appendices).



6. Game Modelling Language

The Game Description Standard is a model for describing games. By implementing

this model as a dedicated XML document scheme, a new formal language is defined: a

Game Modelling Language. The vocabulary of this language consists of the names of

the information items used in the Game Description Standard. Its syntax is formed by

the rules that specify which information items are essential and which optional, by the

rules governing their hierarchical organisation and by the rules for writing XML.

By applying a Game Modelling Language, game developers can improve the efficien-

cy of the game development and maintenance processes. A game described in this

language and stored in an XML database management system can be made available

for automatic searching and retrieving at component level.

Advantages of the Game Modelling Language are:

• It offers a framework for the consistent description of games. You only have to

describe every information item once and you cannot overlook any required items.

• It separates the game content from the layout of different gaming materials (flyers,

role descriptions, operator manual etc.) and therefore facilitates the distribution of

gaming materials to different media.

• It facilitates the re-use of existing game components by copying or referring to the

relevant sections in earlier game descriptions.

• It facilitates the creation of local editions. You can store translated texts in the

same place as the source texts.

• It facilitates the construction of games from standard gaming components, thus fa-

cilitating the customisation of games on a large scale.

• It facilitates the co-operative development of games. The exchange of information

can be very precise.

• When widely used, it will facilitate computer-assisted retrieval of games, meta-

data, and gaming components.

The Game Modelling Language presented here is a first and preliminary version. To

have a real impact on the gaming community, further development is necessary. How-

ever, we need to realise that many people are now involved in more-or-less analogous

activities. ICT is becoming more and more important, especially in the world of edu-

cation. Various international consortia are spending years on the development and ac-

ceptance of formal languages (based on XML) to describe educational environments.

See, for example, the Educational Modelling Language produced by the Open Univer-

sity in the Netherlands [Koper, 2000].

Although the interest of the e-Learning community extends far beyond gaming, it

would be wise to join in with their efforts. Besides, due to the structured character of

XML and the abundance of XML software tools, it will always be possible to auto-

mate the transformation of game descriptions based on our Game Modelling Language

into other structured and XML-based standards.

The Game Modelling Language has the potential to improve the efficiency of the

game development process. It provides the infrastructure for the shift from gaming as



a craft to gaming as an industrialised process. As such, it will make a significant con-

tribution to the new foundation for gaming simulation which is now being sought.



Appendices



A. References

• Alexander, Ch. et al.; A Pattern Language; Towns – Buildings – Construc-

tions; Oxford University Press, New York, 1977.

• Duke, R.; Gaming - the Future’s Language; Sage Publications, New York,

1974.

• Goldfarb, Ch. F. & P. Prescod; The XML Handbook; Charles F. Goldfarb;

Prentice-Hall PTR, Upper Saddle River, 2000.

• Grunfeld, F. V.; Games of the World; Swiss Committee for UNICEF, Zurich,

1982.

• Hijden, P. van der; Computer-assisted Gaming, in: Proceedings of the IXth

ISAGA Conference; Decision Data AB, Lund, Sweden, 1978.

• Hijden, P. van der; Changes in the environment: challenges for gaming pro-

fessionals; in: Frances Watts and Amparo García Carbonel (eds.); Simulation

Now! / Simulación ¡Ya!; Learning through experience: the challenge

of`gaming; El apprendizaje a través de la experiencia: el reto del cambio; Di-

putació de Valencia, Valencia, 1996.

• Hijden, P. van der; The TacTec Game; The Tactics of Electronic Commerce;

in: Ann Villems (ed.); Proceedings of the ISAGA 2000 Conference; Interna-

tional Simulation and Gaming Association, Tartu, Estonia (to be published).

• Horn, R. E.; How to Write Information Mapping; Information Resources Inc.,

Lexington, Mass., 1976.

• Koper, R.; From change to renewal: Educational technology foundations of

electronic learning environments; Inaugural Address; Educational Technology

Expertise Centre, Open University of The Netherlands, 2000.

• Leigh, E. & J. Kinder; Learning through Fun & Games; McGraw Hill, Syd-

ney, 1999.

• World Wide Web Consortium; XML Activity; Executive Overview; World

Wide Web Consortium; updated periodically;

http://www.w3.org/XML/Activity.

See also:

• Gaming/Simulation related references and links:

http://www.sofos.nl/library/gaming%20simulation.htm .

• XML-related references and links: http://www.sofos.nl/library/xml.htm.



B. Document Scheme



The document scheme on the preceding page has been entered by using dedicated

software (in this case XMLspy). This software generates automatically the XML defi-

nition for this document scheme (see below).

<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="http://www.sofos.nl/xml/namespace" xmlns="http://www.sofos.nl/xml/namespace" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="game"> <xs:annotation> <xs:documentation>Game Description Standard</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="identification"> <xs:complexType> <xs:sequence> <xs:element name="name" type="xs:string"/> <xs:element name="version" type="xs:string"/> <xs:element name="copyright" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="meta"> <xs:complexType> <xs:sequence> <xs:element name="basics"> <xs:complexType> <xs:sequence> <xs:element name="subject"/> <xs:element name="purpose"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="kit"> <xs:complexType> <xs:sequence> <xs:element name="cost"/> <xs:element name="portability"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="background"/> <xs:element name="preconditions"> <xs:complexType> <xs:sequence> <xs:element name="organisational" type="xs:string"/> <xs:element name="physical"/> <xs:element name="participants"> <xs:complexType> <xs:sequence> <xs:element name="prior_knowledge"/> <xs:element name="number"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="system"> <xs:complexType> <xs:sequence> <xs:element name="operator"/> <xs:element name="role" maxOccurs="unbounded"/> <xs:element name="mechanism" minOccurs="0"> <xs:complexType> <xs:sequence>



<xs:element name="board" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="computer" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="process"> <xs:complexType> <xs:sequence> <xs:element name="installation"/> <xs:element name="macro_cycle"> <xs:complexType> <xs:sequence> <xs:element name="game_briefing"/> <xs:element name="role_allocation"/> <xs:element name="role_briefing"/> <xs:element name="initial_state"/> <xs:element name="micro_cycles" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="procedure" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="identification"/> <xs:element name="preconditions"/> <xs:element name="purpose"/> <xs:element name="method"/> <xs:element name="step" maxOccurs="unbounded"> <xs:complexType> <xs:choice> <xs:element name="procedure"/> <xs:element name="text"/> </xs:choice> </xs:complexType> </xs:element> <xs:element name="postconditions"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="events" maxOccurs="unbounded"/> <xs:element name="terminal_state"/> <xs:element name="role_debriefing"/> <xs:element name="role_de-allocation"/> <xs:element name="game_debriefing"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="de-installation"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="postconditions"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>



C. Sample XML Document

The following figure shows a screenshot of an XML authoring program (in this case

XMLspy). Once this program has been loaded with the document scheme for game

descriptions, the game developer can enter all information items in a structured way.

The authoring software validates the input and generates the ultimate XML document

automatically (see below).

<?xml version="1.0" encoding="UTF-8"?>  <game xmlns="http://www.sofos.nl/xml/namespace" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.sofos.nl/xml/namespace C:\DOCUME~1\Sofos\Research\2001\Gaming\ISAGA2001\gml.xsd"> <identification> <name>TacTec</name> <version>1.0</version> <copyright>(c) 2001 - Sofos Consultancy</copyright> </identification> <meta> <basics> <subject>electronic commerce</subject> <purpose>Communication tool to generate creative input from the client organisation and to structure the development of a global implementation program.</purpose> </basics> <kit> <cost>Based on licens type</cost> <portability>OK</portability> </kit> </meta> <background>Although in the field of ICT buzzwords and hypes come and go bla bla bla.</background> <preconditions> <organisational>Organisation that wants to implement its e-commerce strategy.</organisational> <physical>Conference room to accomodate 6-10 participants, sometimes working in 2 groups.</physical> <participants> <prior_knowledge>Common knowledge on ICT, personal computer use, basic internet experi-ence.</prior_knowledge> <number>5-7</number> </participants> </preconditions> <system> <operator/> <role/> </system> <process> <installation/> <macro_cycle> <game_briefing/> <role_allocation/> <role_briefing/> <initial_state/> <micro_cycles> <procedure> <identification/> <preconditions/> <purpose/> <method/> <step> <text>tbd</text> </step> <postconditions/> </procedure> </micro_cycles> <events/> <terminal_state/> <role_debriefing/> <role_de-allocation/> <game_debriefing/> </macro_cycle> <de-installation/> </process> <postconditions/> </game>

towards a game modelling language

Technology

game development process

game description standard

game modelling languagepieter

gaming simulationtowards

gaming communityneeds

andconvert game descriptions

ict tools

new foundation w