sofos                                                    consultancy‘let’s build your future...’                        ma...
ISAGA 2001- Towards a Game Modelling Language                                                          iiSummary          ...
ISAGA 2001- Towards a Game Modelling Language                                                                             ...
ISAGA 2001- Towards a Game Modelling Language                                                     11. Introduction1.1.    ...
ISAGA 2001- Towards a Game Modelling Language                                                     2              I believe...
ISAGA 2001- Towards a Game Modelling Language                                                        32. Game Development ...
ISAGA 2001- Towards a Game Modelling Language                                                 4              improve the w...
ISAGA 2001- Towards a Game Modelling Language                                                       53. Game Description S...
ISAGA 2001- Towards a Game Modelling Language                                                                 6           ...
ISAGA 2001- Towards a Game Modelling Language                                                          74. Required ICT to...
ISAGA 2001- Towards a Game Modelling Language                                                       85. Implementation    ...
ISAGA 2001- Towards a Game Modelling Language                                                     9                  range...
ISAGA 2001- Towards a Game Modelling Language                                                            106. Game Modelli...
ISAGA 2001- Towards a Game Modelling Language                                                       11              a craf...
ISAGA 2001- Towards a Game Modelling Language            12Appendices© 2001 - Sofos Consultancy                      www.s...
ISAGA 2001- Towards a Game Modelling Language                                                     13A. References         ...
ISAGA 2001- Towards a Game Modelling Language            14B. Document Scheme© 2001 - Sofos Consultancy                   ...
ISAGA 2001- Towards a Game Modelling Language                                                                15           ...
ISAGA 2001- Towards a Game Modelling Language                                                                    16       ...
ISAGA 2001- Towards a Game Modelling Language                                                     17C. Sample XML Document...
ISAGA 2001- Towards a Game Modelling Language                                                                            1...
Upcoming SlideShare
Loading in …5
×

Towards a Game Modelling Language

461 views
417 views

Published on

Towards a Game Modelling Language; Pieter van der Hijden; in: Proceedings of the ISAGA 2001 Conference; International Simulation and Gaming Association, Bari, Italy, 2001.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
461
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Towards a Game Modelling Language

  1. 1. sofos consultancy‘let’s build your future...’ management consulting and ICT p p.o. box 94874, 1090 gw amsterdam, the netherlands32nd 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.nlOn the edge of the Millennium: a new foundation w www.sofos.nlfor Gaming SimulationTowards a Game Modelling LanguagePieter van der HijdenSofos ConsultancyPieter van der HijdenAmsterdam, 3 October 2001. postbank 4384841 kvk amsterdam 33.181.262
  2. 2. ISAGA 2001- Towards a Game Modelling Language iiSummary 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
  3. 3. ISAGA 2001- Towards a Game Modelling Language iiiContents1. Introduction ..................................................................................................................................... 1 1.1. A New Foundation for Gaming Simulation?........................................................................... 1 1.2. ICT and gaming ....................................................................................................................... 2 1.3. This Paper ................................................................................................................................ 22. Game Development Process ............................................................................................................ 33. Game Description Standard............................................................................................................. 54. Required ICT tools .......................................................................................................................... 75. Implementation................................................................................................................................ 86. Game Modelling Language ........................................................................................................... 10Appendices ............................................................................................................................................ 12A. References ........................................................................................................................................ 13B. Document Scheme ............................................................................................................................ 14C. Sample XML Document ................................................................................................................... 17© 2001 - Sofos Consultancy www.sofos.nl
  4. 4. ISAGA 2001- Towards a Game Modelling Language 11. Introduction1.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].© 2001 - Sofos Consultancy www.sofos.nl
  5. 5. ISAGA 2001- Towards a Game Modelling Language 2 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 process1.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.© 2001 - Sofos Consultancy www.sofos.nl
  6. 6. ISAGA 2001- Towards a Game Modelling Language 32. 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© 2001 - Sofos Consultancy www.sofos.nl
  7. 7. ISAGA 2001- Towards a Game Modelling Language 4 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© 2001 - Sofos Consultancy www.sofos.nl
  8. 8. ISAGA 2001- Towards a Game Modelling Language 53. 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.© 2001 - Sofos Consultancy www.sofos.nl
  9. 9. ISAGA 2001- Towards a Game Modelling Language 6 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 PreconditionsSteps 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 © 2001 - Sofos Consultancy www.sofos.nl
  10. 10. ISAGA 2001- Towards a Game Modelling Language 74. 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 basef ormat items Figure 5 - System view of the required ICT tools© 2001 - Sofos Consultancy www.sofos.nl
  11. 11. ISAGA 2001- Towards a Game Modelling Language 85. 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© 2001 - Sofos Consultancy www.sofos.nl
  12. 12. ISAGA 2001- Towards a Game Modelling Language 9 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).© 2001 - Sofos Consultancy www.sofos.nl
  13. 13. ISAGA 2001- Towards a Game Modelling Language 106. 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© 2001 - Sofos Consultancy www.sofos.nl
  14. 14. ISAGA 2001- Towards a Game Modelling Language 11 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.© 2001 - Sofos Consultancy www.sofos.nl
  15. 15. ISAGA 2001- Towards a Game Modelling Language 12Appendices© 2001 - Sofos Consultancy www.sofos.nl
  16. 16. ISAGA 2001- Towards a Game Modelling Language 13A. 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.© 2001 - Sofos Consultancy www.sofos.nl
  17. 17. ISAGA 2001- Towards a Game Modelling Language 14B. Document Scheme© 2001 - Sofos Consultancy www.sofos.nl
  18. 18. ISAGA 2001- Towards a Game Modelling Language 15 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>© 2001 - Sofos Consultancy www.sofos.nl
  19. 19. ISAGA 2001- Towards a Game Modelling Language 16 <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>© 2001 - Sofos Consultancy www.sofos.nl
  20. 20. ISAGA 2001- Towards a Game Modelling Language 17C. 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.© 2001 - Sofos Consultancy www.sofos.nl
  21. 21. ISAGA 2001- Towards a Game Modelling Language 18 The authoring software validates the input and generates the ultimate XML document automatically (see below).<?xml version="1.0" encoding="UTF-8"?><!-- edited with XML Spy v4.0 U (http://www.xmlspy.com) by Pieter van der Hijden (Sofos Consultancy) --><game xmlns="http://www.sofos.nl/xml/namespace" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://www.sofos.nl/xml/namespaceC: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 thedevelopment 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>© 2001 - Sofos Consultancy www.sofos.nl

×