Towards a Game Modelling Language

sofos
consultancy
‘let’s build your future...’ management consulting and ICT
p p.o. box 94874, 1090 gw amsterdam,
the netherlands
32nd Annual International Conference of the b b. stokvisstraat 38, 1097 hz amsterdam,
International Simulation and Gaming Association the netherlands
(ISAGA), September 2001, Bari, Italy t +31 – 20 – 694 12 22
e pvdh@sofos.nl
On the edge of the Millennium: a new foundation w www.sofos.nl
for Gaming Simulation

Towards a Game Modelling Language
Pieter van der Hijden

Sofos Consultancy
Pieter van der Hijden

Amsterdam, 3 October 2001.

postbank 4384841
kvk amsterdam 33.181.262

ISAGA 2001- Towards a Game Modelling Language ii

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.

© 2001 - Sofos Consultancy www.sofos.nl

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.

Figuur 1 - Gaming as a craft

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].



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.

Figuur 2 - Gaming as an industrial process

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.



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.



Postconditions
Installation Identity
Game Briefing
Role Allocation
Role Briefing Meta Data
Initial State
Title
Preconditions Background Information
Purpose
Game Description
Method Micro Cycles Game Process Standard
21-09-2001 - v7
Procedure Preconditions
Steps
Postconditions

Events/Triggers
Role Debriefing Game Director
Role De-allocation Game System Roles+
Game Debriefing Relations
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.

docu-
game
ment
man-
sche-
ual
me

game
role de-
inspi- authoring de- storage & selec- publishing
scrip-
ration sof tw are scrip- retrieval tion sof tw are
tion
tion

f o- list of
data
reign conversion game
base
f ormat items

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~1SofosResearch2001GamingISAGA2001gml.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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Towards a Game Modelling Language

Ähnlich wie Towards a Game Modelling Language (20)

Mehr von Pieter van der Hijden

Mehr von Pieter van der Hijden (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Towards a Game Modelling Language