Design and use of serious games pdf

(1)

(2)

(3)

International Series on

INTELLIGENT SYSTEMS, CONTROL, AND AUTOMATION:

SCIENCE AND ENGINEERING

Editor

Professor S. G. Tzafestas, National Technical University of Athens, Greece

Editorial Advisory Board

Professor P. Antsaklis, University of Notre Dame, IN, U.S.A.

Professor P. Borne, Ecole Centrale de Lille, France

Professor D. G. Caldwell, University of Salford, U.K.

Professor C. S. Chen, University of Akron, Ohio, U.S.A.

Professor T. Fukuda, Nagoya University, Japan

Professor S. Monaco, University La Sapienza, Rome, Italy

Professor G. Schmidt, Technical University of Munich, Germany

VOLUME 37

Professor S. G. Tzafestas, National Technical University of Athens, Greece

Professor F. Harashima, University of Tokyo, Japan

Professor N. K. Sinha, McMaster University, Hamilton, Ontario, Canada

Professor D. Tabak, George Mason University, Fairfax, Virginia, U.S.A.

Professor K. Valavanis, University of Southern Louisiana, Lafayette, U.S.A.

(4)

(5)

No part of this work may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, microfilming, recording or otherwise, without written permission from the Publisher, with the exception

of any material supplied specifically for the purpose of being entered

and executed on a computer system, for exclusive use by the purchaser of the work.

Printed on acid-free paper

9 8 7 6 5 4 3 2 1

springer.com

University of Jyväskylä

Research Institute for Educational Fl-40014 Jyväskylä Finland

Pekka Neittaanmäki University of Jyväskylä Dept. Mathematical Information Technology

Fl-40351 Jyväskylä Finland

Library of Congress Control Number: 2008939845

(6)

Preface

During the last few years, a new area of creative media industry, namely Serious Games, has started to emerge around the world. The term serious games has become more popular for example in the fields of education, business, welfare and safety. Despite this, there has been no single definition of serious games. A key question, what the concept itself means, has stayed unsolved though most have agreed on a with game technology and design principles for a primary purpose other than pure entertainment.

engaging, self-reinforcing context in which to motivate and educate the players. Serious games can be of any genre, use any game technology, and be developed for any platform. They can be entertaining, but usually they teach the user something. The central aim of serious games is to raise quality of life and well-being. As part of interactive media industry, the serious games field focuses on designing and using digital games for real-life purposes and for the everyday life of citizens in information societies. The field of serious games focuses on such areas as education, business, welfare, military, traffic, safety, travelling and tourism.

This book focuses on the field of serious games from various aspects. The book contains 13 papers and four aspects of serious games: game production, learning, the social point of view, and technical applications. Part I is devoted to game pro-duction and it consists of four articles. The first article presents three approaches towards teaching game production. The second article describes the design and architecture of a cave based firefighter training game. The human-centered design process of a location-based sport game Fitness Adventure is presented in the third article. In the last article of this part, children’s involvement in the design of two game-based learning environments is discussed.

Part II addresses topics related to learning: language learning and the use of com-mercial games in instruction. The first article presents a framework for development and analysis of an educational design for a platform used for teaching English as a foreign language in primary schools. The second article continues in the field of language learning. It discusses experiences from designing a role-playing game for language learning and explores competence requirements and cooperation required from the development team. The other two articles in this part strive to understand and look for the ways of using commercial games also for purposes of learning. In the third article, the attitudes and experiences of Finnish school teachers towards commercial educational games are portrayed. The fourth article examines introduction of social simulation videogame as an educational tool in classrooms. The focus is on the activities and conversations among teacher, children and resear-chers.

v

definition that serious games are games or game-like interactive systems developed

(7)

Part III is dedicated to the social point of view. This part consists of articles on playing together with the camera of a mobile device, social networks in gaming, article presents an approach to a multiplayer mobile game. It discusses how an integ-rated camera would be used to support communication and collaboration in multi-player mobile games. The second article considers social networks in gaming and describes a study on social networks built during the prerelease campaign of the AnimalClass game series. The last article of this part presents a multiplayer inter-face for a computer-augmented learning game.

Part IV is devoted to technical applications of serious games – a driving game and a game-like tool for process simulation and analysis. Firstly, a noncommercial driving game which became a serious tool in the research of driver fatigue is pre-sented. After that, the last article of the book introduces a game-like tool for visual process simulation and analysis.

Material consists of selected papers or game presentations from Serious Games conference organized by Agora Game Laboratory of University of Jyväskylä in February 2008. Additional material has been included in order to broaden the scope of the volume.

Special acknowledgements are due to Terhi Tuukkanen from University of Jyväskylä for her most constructive role in the various stages of this project. We would also like to express our gratitude to the reviewers of the papers, as well as all those involved in the publication process. Finally we want to thank Springer Publishing house for flexible and efficient collaboration.

Pekka Neittaanmäki

September 2008

Preface

and a multiplayer interface for a computer-augmented learning game. The first vi

(8)

Part I Game Production

Tuomas Mäkilä, Harri Hakonen, Jouni Smed, Andy Best

3

Design and Architecture of Sidh – a Cave Based Firefighter Training Game

Mikael Lebram, Per Backlund, Henrik Engström, Mikael Johannesson

of a Fitness Adventure Prototype

Environments: Cases Talarius and Virtual Peatland

Part II Learning

Learning – a Framework for Development and Analysis

Bente Meyer, Birgitte Holm Sørensen

Ellen Brox, Audun Heggelund, Gunn Evertsen

Educational Games

Minna Klemetti, Olli Taimisto, Paula Karppinen

Using Videogames as Educational Tools: Building Bridges Between Commercial and Serious Games

19

33

Tuula Nousiainen

49

69

83

Developing a Language Learning Game

The Attitudes of Finnish School Teachers Towards Commercial

97

107

vii

Human-Centred Design and Exercise Games: User’s Experiences Three Approaches Towards Teaching Game Production

Children’s Involvement in the Design of Game-Based Learning

Comptence Complexity and Obvious Learning: Experience from Designing Serious Games for Computer Assisted Language

(9)

Part III Social Perspective

Let’s Play Together with the Camera of Your Mobile Device

Ekaterina Kuts, Carolina Islas-Sedano, Erkki Sutinen

AnimalClass: Social Networks in Gaming

Harri Ketamo, Marko Suominen

Multiplayer Interface for a Computer-Augmented Learning Game

Ari Putkonen, Markus Forstén

Part IV Technical Applications

RACER: A Non-Commercial Driving Game which Became a Serious Tool in the Research of Driver Fatigue

Narciso González, Igor Kalyakin, Heikki Lyytinen

VIPROSA – Game-like Tool for Visual Process Simulation and Analysis

viii

127

143

155

171

185

Contents

(10)

Three Approaches Towards Teaching Game

Production

Tuomas Mäkilä1, Harri Hakonen1, Jouni Smed1 and Andy Best2

1) Department of Information Technology, University of Turku;

firstname.lastname@utu.fi

2) Digital Arts, Turku University of Applied Sciences; FI-20520 Turku, Finland firstname.lastname@turkuamk.fi

Abstract: Teaching game production benefits computer science and engineering students, because game applications are usually complex interactive real-time systems, which are non-trivial to implement. Moreover, game production has a multi-disciplinary nature, because – in addition to software development – a game production process can include areas such as commercialization issues, game design, graphics design and implementation, sound engineering, level design, and story design. This kind of project environment teaches the development team to work and communicate efficiently. Having organized a variety of game produc-tion project courses in the Department of Informaproduc-tion Technology in the Univer-sity of Turku the students have implemented complete computer games or game proto-types. Our focus has been on teaching game related algorithms, software technologies and software engineering aspects of game production. We have used three different teaching approaches to organize the courses: (1) the traditional home assignment model where the students take full responsibility of organizing the production, (2) research seminars where the teachers act as direct customers for the production, and (3) intensive courses where the teachers participate in the production as coaches and mentors. In this presentation, we describe the three differ-ent teaching approaches, presdiffer-ent them as formal process models, and compare them to commercial game production processes. Additionally, we consider the multi-disciplinary nature of game production and discuss how the issue can be taken into consideration in a study environment where the students are mainly technology oriented.

1 Introduction to Game Production

This article discusses how game production can be used as a teaching tool in

vari-© Springer Science + Business Media B.V. 2009

ous different situations and what requirements different types of course set to the

3 FI-20014 University of Turku, Finland

(11)

4 T. Mäkilä et al.

production process. The article is based on the case studies of three different course types held by the authors. All have utilized game production as a teaching tool. The qualitative aspects of the cases are analyzed and compared.

The goal of game production is to produce fully-working game products. Game production is a discipline that builds on the tradition and the methodologies of project management, software engineering and cultural productions. The game production life-cycle defines the basic activities which have to be accomplished before a game idea actualizes into a working game product. Although every game and every production team has its own ways of working, some generic models for game production life-cycle activities have been proposed (game production pro-cess, game production hand-book).

Fig. 1. Comparison between two game production models (Manninen et al. 2006) (Chandler 2006) and one software product development model (Hohmann 2003). The development phases are described on the upper half and more detailed production phase steps on the lower half.

(12)

Three Approaches Towards Teaching Game Production 5

The development and production activities are also quite similar between the game production models and the software product development model. The multidisciplinary nature of game production forms the greatest difference. While the activities in the software product development model focus solely on the soft-ware development and testing, the game production activities include the coopera-tive work of artists, animators, game designers, level designers, musicians, and programmers.

Although production modes and best practices exist, surprisingly many game production projects do not utilize well-known project management practices. Some of these productions still manage to be highly successful (Larsen 2002). This shows that there is not one right way to do or teach game production, but also that pro-duction training has its place.

2 Three Perspectives to Computer Games

Computer game research and education includes three academic perspectives depicted in Figure 2. The Humanistic perspective is concerned with how a game affects and changes the users, gaming communities, other social networks, and society at large. The Business perspective is concerned with the economics around computer games. As an example, this includes issues of competing in the market-place, productization, and investment strategies. The Construction perspective deals with the actual making of an executable computer game.

(13)

Although each of the perspectives provides essential topics for study, in this paper we focus on the construction perspective. In other words, our viewpoint is the constructional aspects of software development in the domain of computer games. This has four sub-perspectives:

1. Game design: What is the intended end-user experience and what game elements contribute to it?

2. Content creation: What are the entertainment artefacts and functionalities and how they are represented?

3. Game programming: How to implement the software mechanisms that serve the content creation so that the game design goals are achieved?

4. Software construction: How to weave the digital game components into the exe-cutable game?

These perspectives target product design and development and they categorize the main artistic and technical concerns in the making of computer games. Let us consider how the perspectives relate to one another.

Game design encapsulates the vision, intention, concept and theme of a game. For example, it includes activities for designing the back-stories, composing the opposing forces and major roles, and developing the synthetic participants, such as in-game characters, sidekicks, and deus ex machina. The game design is a creative process but it is governed by the rules of play, since we need an outcome that ful-fils the definition of a game.

Nowadays, there are high demands on the aesthetics, end-user experience, and re-playability of a game. To meet these challenges cost-effectively the game design is implemented on two fronts at the same time. Simply put, the intended features of the game can be divided into art and technology. The ‘art’ is entertainment content, which is run by the technology platform. The platform requires specialized pro-gramming effort in some form even if it is purchased. These two fronts require deep expertise, and thus they form their own profession. However, these areas of exper-tise are not disassociated in game development, instead, one of the key challenges is how to bring them together. In other words, when making a game we have to consider, for example, programming, 3-D modelling, and animation together. The game industry has pioneered finding practices and technologies for the interaction of many disciplines, such as computer science, art and design, business, manage-ment, and productization. One can argue that game development is an expertise area in itself that connects these disciplines.

Software construction involves practices and tools for integrating the art and technology assets of the game into one executable system. This is an often com-plex technical process that is automatized as far as possible.

(14)

content creation and software system issues. However, it is only seldom possible to stabilize and freeze the whole game design. Thus, there must be feedback activities that evaluate and control the possible changes to the game design. This uncertainty is intrinsic to software development and it arises from the digital nature of computer programs. Especially due to different cost structures, the making of software differs considerably from the manufacturing process for physical products.

In this article we identify challenges and opportunities that lie in the teaching of game production. Then we go through three cases based on different course for-mats we have used to teach game production. After the presentation of each of the cases we summarize the lessons learned from the course types. Lastly, we conclude our article.

3 Teaching Game Production: Opportunities and Challenges

Originally, the teaching of the game production process itself has not been our main goal in any of the courses we have taught. Our curriculum has included other game related issues, such as game algorithms, artificial intelligence, object pro-gramming patterns, interactive storytelling, game design, and co-operation between artists and programmers. Since our university does not have a degree program in making games our goal is to teach the students general skills within computer science and software engineering. Even so, we constantly end up with course for-mats where students go through the game production cycle. The reason is that using game production as an educational format creates several opportunities: • Versatile but demarcated setting. From the teachers’ point of view a game can

serve as a mixing pot for various study subjects within a curriculum. Also, the project-like form of instruction shows how to distinguish and intermix the essential activities and work products.

• Pragmatic teaching approach. It is easier for a student to understand advanced issues connected to the game content when the students actually make the games. • Higher motivation. The students are motivated by real game development;

simple tic-tac-toe assignments do not intrigue the students.

• Visible results. A working game demonstrates the acquired knowledge, e.g., have the students made rational decisions and have they fulfilled the given require-ments and specifications. Also, in a game the user features are presented more visually than in the other kinds of software products.

(15)

There are also several challenges in using game production as a teaching method: • Sufficient multidisciplinary teaching skills. To facilitate this extrapolation, the

teacher, or the group of teachers collectively, should have profound experience on the whole computer game domain, teaching methods, and project work. • Readiness to learn. The students participating in the game development courses

must be proficient at their own field of study. The digital design and art students should have traditional visual art skills as well as experience with the software tools used for digital art creation. The software developers should master pro-gramming and information system design. However, they must also be able to apply the acquired knowledge in the game domain and be ready to work in teams and to quickly learn new work practices.

• Uncertainty. It is not uncommon that in advanced education the resources are scarce, the working environment is volatile, and the planned results change over time. For this reason the students must be able to cope with uncertainty and to have confidence that the topics get more understandable later.

(16)

4 Case 1: Traditional Assignment Course

In a traditional assignment course the students form a team and solve the given pro-blem assignment as a homework exercise. The teachers observe and monitor the development but avoid partaking in the actual work. In the software development industry this kind of arrangement is called outsourcing, and the goal of the assign-ment is to impleassign-ment a complete computer system. To concentrate the students’ effort on the relevant issues the teachers lecture the theory behind the selected study topics beforehand. Hence, the assignment should demonstrate the practical applications of those theories.

Although the course concentrates on the production phase of a game project, the preceding phases must also be taken into account. To give the students ground-ing for ideas each student analyses individually some existground-ing game that fits in with the course topics. Then each student writes a game treatment that suggests the main ideas and features for the new game. These game treatment documents form the basis from where the actual game concept is developed at the beginning of the production phase. To keep project management issues simple one team con-sisting of three to five students runs the game production lifecycle. If more stu-dents have enrolled for the course the same assignment is given for each of the teams.

(17)

The main activities of the course type are illustrated in Figure 3. The project work can be divided into three phases: inception, construction, and conclusion. At first in the inception, the teachers prepare the assignment and the theory lectures. This activity begins with selecting the study topics, outlining the game concept, and determining the results of the pre-production phase. These three work pro-ducts determine the perspective and depth of the theory issues that are tackled in the project. Then, the project setting is introduced to the students in lectures where the theoretical backgrounds are taught. To support the game production aspect the lectures should include practical guidance for solving the most crucial problems. Whereas the lectures ascertain that the students’ starting levels match the pre-requirements, presentation of the actual assignment acts as a decision point where the students either commit themselves to or drop out of the course. The presentation of the assignment is one of the key activities for the successful execution of the assignment. The assignment milestones, communication mecha-nisms and practices between the teachers and the students, references to guidance and extra resources, and the grading principles should be written explicitly for the students. This focuses the students’ work on the assignment and they do not have to consider the organizational details of the assignment itself.

An the beginning of the course the students are taught and prepared for the forthcoming teamwork. Especially if the students already have experience in team-work and the assignment is extensive the teachers can advise how to divide the work into sub-teams. However, the main idea of a traditional assignment course is that the students organize their own work during the more elaborated design and creation of the game. The teachers’ role is not to control how the team operates, nor how the development conflicts become resolved, or what tactical decisions are made. Thus, this is the most demanding project course format we give to our stu-dents. The teachers act as outside customers and they follow the progress through the project milestones set in the assignment. As an example, a teacher assesses the feasibility of the work plans. The teachers also provide external support on request for the project, for example, by advising, guiding, and coaching in situations that stop the project. In extreme cases, the teachers can intervene and freeze the project until the problems are analyzed and further actions are found. It should be noted that the rationale for this kind of autonomous assignment is to teach tacit know-ledge about software development in teams. For example, the students should find out themselves how to take responsibility, communicate, and share know-how. From our experience, if the students have sufficient base competence and the pre-ceding activities are effective, they do not need extensive assistance to accomplish advanced results.

(18)

feedback from the inception and construction phases. Lastly, the teachers evaluate the results and grade the students on the team level. We prefer not to evaluate each student individually because a team should be seen as one development unit; the balancing and fairness issues must be considered during the project, not after it. In principle, a student can be expelled from a project but in our experience, situations have never escalated into this.

5 Case 2: Research Laboratory Course

In a research laboratory course the students examine a scientific problem along-side the teachers, work on a practical solution to it, and report the results of the

acquiring methods. In the software development industry similar work is carried dents learn about the newest scientific topics and they have hands-on training into scientific work. Secondly, the teachers, who are also researchers, benefit from fresh ideas and possibly new solutions to the research topic. In our case this kind of cooperation has often lead on to further studies and even to joint research.

The latest instance of this course we held focused on software technologies, architecture of a multiplayer game. When the research question is a specific and mainly technical one the influence of the preceding and succeeding phases of the game project can be reduced. This lessens the risk of failure, although the outcome of the project tends to stay unpredictable until the deadline. However, this also poses an educational problem because we are leaving out real-world problems con-cerning, for example, the launching of the project. Fortunately, the problem has adequate solutions, and as an example, it is possible to organize a separate project course without a detailed construction phase. To keep project management as simple as possible one team includes five to seven students. If more students have enrolled for the course the same problem is given for each of the teams and the teams are encouraged to balance between cooperation and friendly competition on technical and content issues. Also, if the problem turns out to have many differentiating aspects the teams can share them.

The main activities of the course type are depicted in Figure 4. The project work consists of three phases: inception, cooperative construction, and conclusion. In the inception, the teachers also conduct the whole preproduction phase. At first, the teachers prepare the assignment on their research questions and this activity determines the main concerns of the project. Then, to make the experiment repeat-able and to have case setting the teachers design the game concept and features. The game design is used for constraining the general research question; the idea is to have a nontrivial case example that is feasible to solve with the given resources. requires the participants to have pragmatic skills of collaboration and knowledge

(19)

Fig. 4. The main activities of the research laboratory course.

The assignment and the game design are presented to the students after which they commit themselves to the course. Finally, the teachers guide the students to organize the teamwork, practices, methods, and development tools. Unlike in the traditional assignment course, the inception phase can be rather informal as the research prob-lem is well-defined.

(20)

The construction phase has a strict deadline after which the project proceeds to the conclusion phase. At first, the students present the game, demonstrate its fea-tures, and discuss the project in retrospect. Unlike in the traditional assignment course the teachers should write the post-mortem document because they are more experienced in reflecting scientific issues. Then, the teachers evaluate the outcomes and grade the students. Although we consider the team as one, individual grading is also possible because the iteration work has been transparent and the game design is complex enough that it leads to clearly specialized and dedicated roles. Lastly, the teachers, preferably together with the students, analyze and report the scientific results. Often, this results in other research questions, study papers, and theses.

6 Case 3: Intensive Production Course

In an intensive production course the students and the teachers work together as one team to produce a computer game that demonstrates both digital art and soft-ware technology. The production goal is to create a functional game prototype in a short period of time. The project proceeds in intensive workdays of six to eight hours at one site with inter-connected computers. In the software development industry this is called as customer-as-expert project. Due to intensiveness each participant must attend all the workdays to be at the team-mates’ disposal and to keep up with the project pace. The educational goal of the course is to encourage students having dissimilar backgrounds, i.e., digital art and software technology, to work together. Also, we foster mutual learning and extending understanding of the multidisciplinary nature of game development.

(21)

one is the most challenging for the teachers because the schedule is tight, the workdays turn sporadically into chaos that must be managed, and in-advance and on-the-fly planning have to be balanced constantly.

The main activities of this course type are presented in Figure 5. The project work has three phases: inception, continuous construction, and conclusion. In the beginning of the inception the teachers prepare a preliminary schema for the course assignment and setup the infrastructure for the project. For example, we have had an intensive production course for a non-violent shooter game and for a humorous point-and-click game. The actual game idea and design are still left open. The inception ends with assignment presentation where the students are introduced to the project topics and facilities. Because the students have passed the applica-tion process they are already committed to the course.

The continuous construction begins with an open debate and brainstorming on the game ideas, their possibilities and the students’ interests in them. It is impor-tant that at this stage the students form a mental bond with the game, and thus, the teachers should act only as moderators. Then, the most promising ideas are refined and among them the core game idea is selected. The actual project work iterates

(22)

management and product level quality assurance. Their first activity is to organize teamwork, practices, methods, and development tools. Then, they coach and guide the students, verify art assets and software quality, resolve workflow conflicts, and plan and prioritize the creation process. In other words, the teachers act as on-site customers who are experts on the disciplines and actively participate in the deve-lopment of the game. The students are responsible for game design and its imple-mentation with digital art and software technology. In other words, they have to make decisions on the game creation from the operational level up to the strategic the game. The most difficult problems arise from where the disciplines are bound tightly together into one.

As with the other course types the construction phase has a deadline at which the conclusion phase begins. Despite the teachers participation in the project the students present the game in the final project meeting. The relaxed atmosphere fosters open retrospective discussions and the teachers can verify their understand-ing about the successes and failures before writunderstand-ing the post-mortem document. Finally, the teachers evaluate the results and grade the students. As in the tradi-tional assignment course we prefer to evaluate only the team as one unit because in this kind of intensive project individual work is subject to circumstances.

7 Lessons Learned from Cases

Previous chapters described the main activities of the three different teaching approaches and showed the differences between the approaches. In this chapter we define the common characteristics of three approaches and summarize the key lessons learned during the courses.

Lesson 1: Game production provides a natural framework for project courses. Game production provides a suitable context for project oriented courses. This is because the assignment projects done in each approach are not mock-up projects which are constructed to suite the teaching needs. Instead, game production acts as a practical framework and the pedagogical elements are injected into that. This might explain why the students are motivated to pass these courses and feel that the course setting is rather realistic.

Lesson 2: Larger team sizes have to be managed. Another characteristic of game production is that productions are usually self-organizing one team projects. This might make course organization and evaluation harder when the course size increases. We have found two methods to handle the problem: 1) Divide the stu-dents into smaller teams with their own responsibilities or 2) Divide the stustu-dents into smaller teams and give the same production task to each. With the latter method it is surprising that the teams always end up with completely different results.

the idea into a computer game. The teachers take the responsibility for project

(23)

Lesson 3: Course formats do not restrict what kind of games can be developed. During the courses presented in the case study the students have produced a wide variety of different games from 2D real time strategy games to 3D shooters. It must been admitted that none of the games would have met modern commercial standards, but with further development some of the games would well be equal to modern shareware or independent games. Since the majority of the students have been computer science and engineering students, the emphasis of the game deve-lopment has been on the technical issues of game production. Still, some of the games have also been visually appealing. During the courses some of the student groups have been experimenting with unorthodox game concepts. It can be said that the course formats presented do not set restrictions themselves on what kind of games can be produced. Of course, the timeframe of an average university course set certain limits on what can be done and how polished the resulting games will be.

Lesson 4: The assignment format can be seen as easy for the teachers but there are pitfalls to look out for. For the teachers the project courses are basically easy because the students do most of the work. Of course, the preparation of the course and the assignment have to be done well so that students can focus on the assign-ment work itself. In the research lab and the intensive course approaches the pre-paration activities can be seen as a part of the pre-production of the game and therefore these preparations directly affect the end results of the course. The teachers have to follow the students work throughout the course and coach them as needed. The success of this task depends on the activity and skills of the students.

Lesson 5: Pre-production and production steps were emphasized during the projects, but the whole production cycle was done. Although the main goal of our courses has been on teaching game production related issues, not game production itself, it is important to know which parts of game production the presented approaches teach. If we compare the workflow models of each teaching approach and generic game production models, we can see that the activities of the pre-production and pre-production phases are emphasized. However, all the most charac-teristic activities of game production models are included in the course structures in one way or another. The only significant part that was missing from our courses was the business aspect of game production. It can be said that the basic activities of a non-commercial small scale game project are the same as the activities of a large scale commercial game project. Only the scale is different. Therefore the previ-ously presented teaching approaches give students a good insight into actual game production.

(24)

Lesson 6: Game production teaches skills that can be used outside the game production domain. Yet another issue to be considered is how well the skills learned using the presented approaches can be generalized outside the domain of game production. During a game production course, software engineering students can deepen their knowledge of the software engineering issues, since the game pro-duction process resembles the general software engineering process so much. The skills obtained are also applicable to other kinds of software projects besides game production. The multidisciplinary nature of game production teaches the software engineering students that during software projects there are lots of other things to be taken into consideration other than just programming the applications.

The multidisciplinary nature also makes the game production project more challenging to manage but at the same time makes concepts like project roles and release integration more concrete for the students. From this perspective it can be said that game production assignments are good all-around project management and team work practice.

The comparison done between the game production models and the software product development model in the introductory chapter reveals that game produc-tion is actually a product development process rather than just a software engi-neering or art production process. This means that the end result of the process is a complete package which can be more easily evaluated than an individual algorithm demo or a prototype application. At the same time the starting requirements have to be set more carefully and end-user needs have to be taken into consideration throughout the process. This finding might at least partially explain other lessons presented in this chapter.

8 Conclusions

In the computer game industry a production project binds together many perspec-tives and disciplines by inventive balancing of conflicting interests. Because the balancing decisions culminate in the game product, game creation is a holistic process. In other words, it is not possible to isolate the disciplines such as digital art and software technology assets, project activities (e.g., requirement management, risk management, budgeting, resource allocation, prioritization, quality assurance, and motivation), productization, product line management (i.e., strategic business decisions on products), and marketing from each other without losing a realistic representation of the game development. However, due to time and budget limita-tions game creation education cannot take into account all of these perspectives at the same time.

(25)

focuses on technological design and implementation of a game, and the intensive production course weight collaboration among selected game disciplines (in our case digital art and software technology). These three case schemas demonstrate that it is possible to arrange game projects for students that have both educational goals and reflect the projects in the software industry in general. There are game production models as well as general software product development models that support this observation. The successful injection of the educational goals into the game projects is also well-founded; the details are discussed in (Hakonen et al. 2008).

The three game project schemas include much software technology work because computer games are always executable programs, and hence, the software platform runs the game content. We utilize this relationship to give the project adaptations concrete form and to determine the consequences. For example, there are tried practices for estimating how much time certain software implementation work takes. From a study topic aspect the reason is that we have wide know-how on how to implement the game technicalities (Smed and Hakonen 2006). However, it is a misconception to believe that the essence of a computer game comes from technological solutions. The game must have an intriguing end-user experience (entertainment, education, or of any other kind) that is only obtained by creative content and playability. Both the teachers and the students of the Digital Arts divi-sion lead the development on this front.

To sum up, the teaching of game production requires that the teachers jointly understand the practicalities of the computer game domain, education methods, software development projects in general, and the ludic values of game playing. Thus they can provide the students with an enlightening experience of, not only game production, but also general software production and modern teamworking practices.

References

Chandler, H. M. (2006). The Game Production Handbook. Game Development Series, Charles River Media.

Hakonen, H. (2006). Game Industry versus Software Industry: Similarities and Differences. In

Hakonen, H., Mäkilä, T., Smed, J., & Best, A. (2008). Learning to Make Computer Games: An Academic Approach. TUCS Technical Report 899, Turku Centre for Computer Science, Finland.

Hohmann, L. (2003). Beyond Sofware Architecture – Creating and Sustaining Winning Solu-tions. Addison-Wesley Signature Series, Addison-Wesley Professional.

Larsen, S. (2002). Playing the Game: Managing Computer Game Development. Technical Report International Edition. Version 1.1. Blackwood Interactive.

Manninen, T., Kujanpää, T., Vallius, L., Korva, T., & Koskinen, P. (2006). Game Production Process – A Preliminary Study. Technical Report v1.0. Ludocraft/ELIAS-project.

Smed, J. & Hakonen, H. (2006). Algorithms and Networking for Computer Games. UK, Chichester: John Wiley & Sons.

(26)

Design and Architecture of Sidh – a Cave Based

Firefighter Training Game

Mikael Lebram, Per Backlund, Henrik Engström and Mikael Johannesson

University of Skövde, School of Humanities and informatics P.O. Box 408, SE-54128 Skövde, Sweden

Firstname.lastname@his.se

environment developed in collaboration with the Swedish Rescue Services Agency (SRSA). The learning objectives for the game relates to training of firefighters for Breathing Apparatus Entry, and in particular to develop systematic search strategies. The hardware and software system is based on off-the-shelf computer components in combination with tailor made units. The game has been developed as a Half-Life 2 mod – extended to be played in a cave using 5 standard gaming PCs in a local area network. The game environment is a cave where the player is surrounded by four 80” screens giving a 360 degree view of a virtual world. Each screen is pro-jecting a fixed-angle view of the virtual world and the player’s orientation in the virtual world corresponds to her orientation in the real world. A novel interaction model has been developed for the game in order for it to be played in the cave. The player navigates and performs game actions using course body movements which are captured through a set of sensors.

1 Introduction

Simulator training is becoming more and more common and is used in a number of situations. Recently, there is a movement towards utilizing computer games and computer game technology to achieve adequate functionality for, e.g., training (Zyda 2005; Squire and Jenkins 2003; LoPiccolo 2004; Backlund et al. 2006). This effort is commonly referred to as serious games (Serious Games Initiative 2007). Even though serious games may have many applications training is considered to be a major one. Consider the following usage scenario.

training session. Wearing his boots, coat and air mask he enters the cave to meet his virtual instructor. Steve receives his mission via the air mask radio unit. He is instructed to search the premises and save all victims. The hallway is filled with thick smoke and Steven has to take a low position to see below it. From the crouching position he can orientate himself to see that there are three doors, one

Steve is in training to become a firefighter. He is just about to start a simulator

19

Abstract: This paper presents the architecture of a game-based training simulator

(27)

20 M. Lebram et al.

on each wall, apart from the one he just entered. Remembering his tactics he chooses to open the first door on his right and enters the bathroom. Still crouch-ing, he finds the room empty and checks that there is no one in the bathtub. Steve returns to the hallway and continues his search to the right to find the bedroom. The bed is on fire and he moves along the wall, searching behind furniture and in closets. He finds an unconscious man in the far end of the room and lowers the fogfighter nozzle to pick him up. Steve sees that the fire is increasing in strength and that his stamina is decreasing to a critical level. He has to get out quickly in order to gain health. The instructor asks him whether the search is completed. Steve remembers the third door and reenters the apartment.

After the mission Steve enters the virtual debriefing room with an information board and an overview of the apartment. The assignment is evaluated and the areas covered by the search are highlighted. Steve gets feedback from the virtual instructor and the mission is summarized on the information board.

In this paper we present the architecture and software solution for a game based firefighter simulator based on a commercial computer game and computer game technology. Our solution implements an advanced game based simulation, with a novel interaction mode, to be played on multiple screens (i.e. in a cave) which can be used for training and simulation. The utilization of standard off the shelf hard-ware has produced a cost-effective solution in a relatively short time. The game itself has been developed in close cooperation with the Swedish Rescue Services Agency in order to guarantee accurate content and relevant scenarios.

2 Background

In this section we will introduce the central concepts of serious games and some applications to the subject area of firefighter training.

2.1 Serious Games

(28)

Design and Architecture of Sidh – a Cave Based Firefighter Training Game 21

first. In our work we define serious games as games that engage the user, and con-tribute to the achievement of a defined purpose other than pure entertainment (whether or not the user is consciously aware of it). A game’s purpose may be formulated by the game’s designer or by the user her/himself, which means that also a commercial off-the-shelf (COTS) game, used for non-entertainment pur-poses, may be considered a serious game. The desired purpose, i.e. a serious game, can be achieved through a spectrum ranging from the mere utilization of game technology for non-entertainment purposes to development of specifically designed games for some non-entertainment purpose or the use and/or adaptation of com-mercial games for non-entertainment purposes. We also propose that any combi-nation of the above would constitute a feasible way to achieve the desired effect.

Serious games can be applied to a broad spectrum of application areas, e.g. military, government, educational, corporate, and healthcare. A question of inter-est concerns the claimed positive effects of such games, or of applications from related and sometimes overlapping areas such as e-learning, edutainment, game-based learning, and digital game-game-based learning. In addition to obvious advantages, like allowing learners to experience situations that are impossible in the real world for reasons of safety, cost, time, etc. (Corti 2006; Squire and Jenkins 2003), serious games, it is argued, can have positive impacts on the players’ development of certain skills. We also note that some of these positive effects of gaming are not necessarily associated with any specific training or information objectives. As dis-cussed by Mitchell and Savill-Smith (2003) analytical and spatial skills, strategic skills and insight, learning and recollection capabilities, psychomotor skills, visual selective attention, etc. may be enhanced by playing computer games. Lager and Bremberg (2006) have summarized studies of the effects of playing computer games and indicate positive effects on motor and spatial skills. More specific posi-tive impacts have been reported, e.g., by Enochsson et al. (2004), who found a positive correlation between experience in computer games and performance in endoscopic simulation by medical students. The better performance of gamers is attributed to their three-dimensional perception experience from computer gaming.

(29)

22 M. Lebram et al.

2.2 Immersive Visualization

There are several ways of visualizing virtual worlds in order to offer a more immersive experience to the viewer than can be achieved using ordinary computer displays. The choice of visualization system depends on in what purpose it shall be used and, what resources in terms of time, space and finances are available.

2.2.1 Head Mounted Displays

The term HMD is used on a category of visualization systems which presents a virtual world directly in front of the viewer’s eyes, via one or two small displays. Used with a head tracking system the viewer is able to look at different parts of the world by turning his/her head. There are many different types of HMD:s in the market, for instance helmets, goggles, and lightweight glasses. There are also a number of features which may be supported by a HMD device, such as stereo-scopic vision, semi transparent displays, et cetera. A common property of HMD:s is, however, relatively low resolution and a small field of view.

2.2.2 EVL CAVE

A CAVE is an, usually super computer based, environment for visualization of, and interaction with virtual models and worlds. The first CAVE (CAVE Auto-matic Virtual Environment) was developed by Electronic Visualization Laboratory (1991). The purpose was to build a system for scientific visualization, with high demands on performance (Cruz-Neira et al. 1993). The original CAVE had three walls, consisting of screens for rear projection, and measures 2.5 × 2.5 × 2.5 meters. On the walls and the floor stereoscopic scenes are presented for a viewer, whose head movements are tracked in order to correct the projection in real time. The viewer is also able to interact with the virtual world, for instance by using a special glove.

Several variations of CAVE have been built since 1991. One example is the six-sided VR-CUBE which was built at the Royal Institute of Technology in Stockholm in 1998 (Center for Parallel Computers 1998). Here the viewer is com-pletely surrounded by video and audio from the virtual world – in all directions.

2.3 Fire Fighter Training

(30)

rescue services staff are trained and certified by the SRSA. Breathing Apparatus Entry (BAE) is one of the tasks a firefighter has to perform. It is of crucial impor-tance that the firefighter can remain orientated with very limited or no vision in a building. Traditionally the firefighter students practice search methods with and without smoke in different physical buildings.

Training is typically organized to start without smoke where students use a mask with translucent visor. This type of training is time consuming and requires flexible buildings. The optimal training for BAE search methods would be in an environment with a great number and types of buildings. Training would also be more efficient if students could practice individually yet with professional feed-back and evaluation.

2.4 Virtual Environments for Fire Fighter Training

As firefighters have to handle extreme tasks there is a continuous need to develop training programs to prepare for such tasks (Lasky 2004). There exist a number of reports of the use of virtual environments for firefighter training in the literature.

Tate et al. (1997) present a study where a virtual environment training system was used to prepare shipboard firefighters for a mission. The virtual environment allowed users, equipped with a HMD device, to navigate in a 3D-model of the ex-USS Shadwell fire research and test ship. A group of 12 trained firefighters par-ticipated in a study where their performance in a firefighting training mission was evaluated. Half the group was offered traditional mission preparation and the other half prepared using the virtual environment. The result of the evaluation showed that the second group had a better performance than the group using traditional preparation.

In a different study, Julien and Shaw (2003) present a virtual firefighter com-to command virtual firefighters. The fire is extinguished by issuing the correct sequence of commands to the firefighters. Perdigau et al. (2003) present an appli-cation for managing virtual reality scenarios and their main scenario is a Fire-fighter Training Simulation used for crisis situations training and understanding.

There are also examples on commercial simulation software used for firefighter training. The tactical command trainer is a tool from VectorCommand Ltd. (2008) which allows users to train emergency management.

The main goal with SIDH was to develop a cave-based simulator game for training BAE. The project was carried out by expertise in game development and serious mand training environment which allows its users to inspect a house on fire and

(31)

24 M. Lebram et al.

games, in close cooperation with expertise in firefighter training from SRSA. The game is not intended to replace conventional training, but rather to be used as a complement with focus on search strategies and ability to orient in unknown premises.

The game is to resemble real world BAE in as many aspects as possible. This means that the player’s task is to completely search different premises, with higher or lower complexity of the architecture, and rescue any persons inside. It should be possible to fill the premises with smoke, which, similar to real smoke, should be thinner close to the floor than close to the roof. The player should also be exposed to heat and physical and psychological stresses, which are characteristic parts of BAE. Furthermore, in respect of the educational purpose, it is crucial to record the player’s actions during a game session for later analysis.

To reduce overhead time in the developing process, it was decided that the game was to be developed as a modification of a COTS game. In this way, the developers can focus on game content and specific features without first having to create an infrastructure from scratch. A feasibility study was committed in order to choose one of three common games - FarCry, Quake2 and Half-Life 2. All candi-dates were successfully modified to run in the cave environment. However, due to the realistic indoor environments and the ease of use of the level editor, Half-Life 2 was chosen as a platform for SIDH.

3.1 Cave Visualization

The cave is constructed from standard consumer electronics components. The purpose is to create a flexible environment for 360 degrees visualizations of for example games and films. The four walls are each 160 cm wide and 210 cm high. The upper 120 cm of the walls consists of screens for rear projection. Each screen is projected by a standard LCD projector, connected to a PC (Figure 1). These computers are interconnected in an Ethernet network together with another com-puter which acts as a server. All five comcom-puters are standard gaming PC:s with regu-with an external 5.1 sound card which delivers sound to four loudspeakers, one in each of the corners of the cave (Figure 1).

Half-Life 2 is a multiplayer game which means that there is native network functionality for distributing information about the current state of the game objects. When playing a multiplayer game, one of the computers acts as a server responsi-ble for controlling and synchronizing the progress of the game. When a server is running other computers in the network are able to connect and thereby become participating instances of the game running on the server.

(32)

Fig. 1. Schematic view of the cave.

four client computers is to visualize the game running on the server, why the clients always have to be updated about the player’s position and the state of the world. To achieve this, a native multiplayer feature called spectator mode is used. The original purpose of this feature is to make it possible for connected, but non-participating, clients to automatically follow and observe an active player. In that manner, the instances of the game running on the cave computers are observers, following the player on the server and hence showing the same view as the server without actually interacting with the game. The screens of the cave are however not to be clones of the server screen. Instead they should present the world in four different directions, one direction for each screen, with the same origin as the server player. In the implementation, the game view is defined by a camera which acts as the eyes of the player (or the spectator). The position and orientation of this camera decides what is shown on the screen. By setting the orientation of a client’s camera to a certain fixed direction, the client view will always show the world from that angle, regardless of the player orientation. Each view is thus rotated 90 degrees with respect to the adjacent screens. To produce the final 360 degree pro-jection in the cave, the FOV (field-of-view) for the cameras were adjusted to 90 degrees. This is important since two adjacent views will overlap with a greater FOV value, and with a lesser value all parts of the world will not be visible at the same time.

3.2 Interaction Model

(33)

26 M. Lebram et al.

the virtual world, crouching as well as in a raised position. Moreover, it has to be possible to pick up and drop victims and control the game-flow.

A problem about navigating in a cave environment is the lack of obvious direc-tions in terms of forward, backward, left and right. Normally when playing a first-person game, forward is defined by the center of the display, i.e. the direction in which the player is currently looking. Pressing the forward-key on the keyboard will always move the player in the desired direction since the world is rotating around the player and the keyboard. In the cave, on the other hand, it is not possi-ble to use a single forward-key since the directions are fixed to the real world. Hence, in order to decide what direction is forward for a cave player it is neces-sary for the software to keep track of the player’s current orientation. In SIDH, this problem is solved by using a GameTrak, which is an USB-device working as a joystick with a string to pull as Z-axis. The GameTrak is placed centered in the top of the cave, top down, with the string attached to the fogfighter nozzle (Figure 2). In this way, the nozzle’s position in 3D-space can be calculated. Since there may be some discrepancy between the direction expected by the player and the calcu-lated direction (due to player deviation from the center of the cave), the calcucalcu-lated forward direction is visualized as a marker on the screens.

SIDH also calculates the nozzle’s distance to the floor in order to decide whether the player is crouching (to increase the sight in smoke-filled areas) or not. Since a low position is depending of the player’s height, the crouching threshold is dynamically adapted based on the highest nozzle position recorded during a mis-sion. The information about the distance to the floor is also used to record so called markings. A marking is done by touching the floor with the nozzle, and is an action with different meanings in different phases of the game:

• To start the game in the beginning of a level. • To pick up found victims.

• To drop rescued victims.

• To confirm a completed search task.

(34)

Fig. 2. The string of the GameTrak (top right) is attached to the fogfighter nozzle (bottom right). NB, only one of the GameTrak’s two controls is used.

cave. This would result in a realistic heat distribution which would force the player to crouch in order to decrease heat exposure. However, the computers and the projectors produced enough heat to make the room uncomfortably hot. This temperature and the fact that the equipment preserved the body heat (resulting from the player’s physical effort) led to the decision that adding more heat would be a disadvantage concerning the entertaining aspects of the game.

The air mask (Figure 3) is equipped with a radio receiver through which instruc-frequencies used by SRSA, the original radio system is replaced by two budget walkie-talkies. The other walkie-talkie works as a transmitter, connected to the inter-nal sound card of the server. A slight modification of the software makes it possible to direct the voice of the instructor to this sound card, while all other sound effects are played back in the regular sound system.

3.3 Level Design

included in the Half Life 2 edition. The Hammer world editor is a powerful tool. Apart from facilities for easy creation and texturing of elementary building blocks such as walls, floors, roofs and ceilings the editor also gives access to a number of fabricated items have facilitated development work by reducing the number of specific models necessary to create for SIDH. Furthermore, the editor supports the manipulation of light, sound, smoke and fire to alter environments.

tions from the virtual instructor is presented. To avoid interfering with the radio

The levels for SIDH have been created in the Hammer world editor which is

(35)

pre-28 M. Lebram et al.

Fig. 3. Air mask with radio unit.

The game flow is controlled by timers and triggers. Triggers are invisible objects which can be used to activate other objects or events such as, e.g., a fire to flare or a new level to start. As an example, a trigger may be activated when the player approaches it. All levels in the SIDH game must have a specific set up of triggers and timers to handle the game flow. Important elements to game functionality are recycled in all levels, thus reducing the over-head when creating new tracks.

13 different levels (Table 1) have been developed in close cooperation with the SRSA. There is also a tutorial in which the player gets to learn the game and the interaction mode and two bonus levels. The game covers a variety of flats, ware-houses, shops and industry facilities to provide a relevant sample of environments for rescue personnel to train in. Each level provides new challenges with respect to size, complexity and smoke. The difficulty is also increased by shorter time limits and the degree of harm made to the player by smoke and fire. Furthermore, the game provides challenges in terms of unexpected situations, such as victims hid-den in closets, and rooms difficult to locate. Other elements of stress are alarms, sirens, screaming victims and explosions.

Each level starts with a female virtual instructor introducing the game task. The virtual instructor’s voice is personified by an instructor from the SRSA and the texture of the pre-fabricated models has been modified to resemble a real rescue personnel outfit. Each level ends in a debriefing room (Figure 4) where the player receives oral and visual feedback concerning his/her result.

(36)

Table 1. The levels of the game and their learning objectives.

Level Description Objective

0 Tutorial To handle the interaction model and game goals 1 Two-room apartment To get a first contact with the game

2 Club building To realize that time is limited

3 Garage To realize the advantage of crouching in smoke-filled areas 4 Bonus level To get a break

5 One-room apartment To look in closets

6 Youth hostel To handle large number of rooms

7 Office space To handle complex corridor architecture, closet 8 Grocery store To handle areas divided by shelves

9 Three-room apartment To handle heavy fire, closet and limited time

10 Large apartment To handle extremely limited sight in complex architecture 11 Basement storage area To handle fenced areas filled with junk

12 Four-room apartment To handle doors at unexpected positions 13 Hotel corridor To handle numerous identical doors 14 Butcher shop To handle veiled areas

15 Bonus level To finish the game

(37)

30 M. Lebram et al.

When a level is successfully completed the player will get a score based on the proportion of the facilities that has been searched, time spent on the task and whether it was the first, second or third trial. If the area covered by the search exceeds 90% the player will be awarded a star bonus which will also generate a bonus score on the following level.

4 Concluding Remarks

The main contribution with the presented work is a training simulator developed with relatively simple means. SIDH is a cost effective immersive firefighter train-ing game, which, accordtrain-ing to personnel and students of SRSA, is entertaintrain-ing as well as effective regarding learning of the intended tasks Backlund et al. (2007).

We have demonstrated the feasibility and usefulness of an architecture for a game based immersive training simulator. The novel interaction mode adds to immersion by introducing physical aspects into the game. We have also shown that inherent game functionality can be used and extended to create a variety of levels with distinct learning goals. The source code has been modified to implement required features and the specialized game flow. An example of such a modifica-tion is the player’s health level, which is constantly decreasing when acting in smoke filled areas. Furthermore, specific logging functionality concerning the state and the activities of the player has been implemented in order to facilitate after action review. The modifications and amendments made to the original sys-tem serves as an illustration of the potential of game-based simulation. We have shown that this class of systems has a sufficient capacity to form basis for a train-ing simulator.

The success with SIDH is mainly depending on two factors – the close coop-eration between SRSA and HIS and the utilization of common computer game technology. During the initial meetings the purpose of the game was discussed from different points of view. It was stated that even if it would be possible to simulate every aspect of a BAE operation, which would require a great amount of time and money, it would still be a simulation which cannot replace training in the real world. Hence, it was decided that the game should focus on search strategies and the ability to orient in unknown premises. These aspects were regarded as the ones which would gain the most from simulator training, due to the limited possi-bility of varying physical premises in the real world. Using Hammer world editor to create premises for SIDH, the architecture options are virtually unlimited.

(38)

References

Backlund, P., Engström, H., & Johannesson, M. (2006). Computer gaming and driving education. Presented at the workshop Pedagogical Design of Educational Games affiliated to the 14th

Backlund, P., Engström, H., Hammar, C., Johannesson, M., & Lebram, M. (2007). Sidh – a Game Based Firefighter Training Simulation. Presented at the 11th International Conference Center for Parallel Computers. (1998). The PDC Cube. Royal Institute of Technology.

http://www.pdc.kth.se/projects/vr-cube/. Accessed 7 February 2008.

Corti, K. (2006). Games-based learning; a serious business application. White paper. The Seri-ous Games Institute. http://www.pixelearning.com/seriSeri-ous_games-white_papers.htm. Accessed 8 February 2008.

Cruz-Neira, C., Sandin, D., & DeFanti, T. (1993). Virtual Reality: The Design and Implementa-tion of the CAVE. Presented at the SIGGRAPH 93 Computer Graphics Conference. ACM SIGGRAP,135-142.

Electronic Visualization Laboratory. (1991). CAVE Automatic Virtual Environment. University of Illinois. http://www.evl.uic.edu/core.php?mod=4&type=1&indi=161. Accessed 7 February 2008.

Enochsson, L., Isaksson, B., Tour, R., Kjellin, A., Hedman, L., Wredmark, T., & Tsai-Fellander, L. (2004). Visuospatial skills and computer game experience influence the performance of virtual endoscopy. Journal of Gastrointestinal Surgery, 8 (7), 874–880.

Julien, T. U. S. & Shaw, C. D. (2003). Firefighter command training virtual environment. In Richard Tapia Celebration of Diversity In Computing. Proceedings of the 2003 Conference on Diversity in Computing (pp. 30–33). Atlanta, Georgia, USA: ACM.

Lager, A. & Bremberg, S. (2005). Hälsoeffekter av tv- och datorspelande. En systematisk genomgång av vetenskapliga studier. Swedish National Institute of Public Health.

Lasky, R. (2004). Firefighter survival training: from reactive to proactive. Fire Engineering, June, 117–119.

Lebram, M., Engström, H., & Gustavsson, H. (2006). A driving simulator based on video game technology. Presented at SIGRAD 2006, Skövde, Sweden.

LoPiccolo, P. (2004). Serious games. Computer Graphics World, 27(2).

Mitchell, A. & Savill-Smith, C. (2003). The use of computer and video games for learning: A review of the literature. Learning and Skills Development Agency.

Perdigau, P., Torguet, E. Sanza, C., & Jessel J.-P. (2003). A distributed virtual storytelling sys-tem for firefighters training. In Proceedings of the International Conference on Virtual Story-telling (pp. 227–230). November 2003, Toulouse, France.

Sawyer, B. (2004). The serious games summit: emergent use of interactive games for solving problems is serious effort. Computers in Entertainment 2(1), 5.

Serious Games Initiative. (2007). Woodrow Wilson International Center for Scholars. http://www.seriousgames.org. Accessed 7 February 2008.

Squire, K. & Jenkins, H. (2003). Harnessing the power of games in education. Insight, 3(1), 5–33.

Swartout, W. & van Lent, M. (2003). Making a game of system design. Communications of the ACM, 46(7), 32–39.

Tate, D. L., Sibert, L., & King, T. (1997). Virtual environments for shipboard firefighter training. IEEE Computer Graphics and Applications, 17(6), 23–29.

Vector Command Ltd. (2008). http://www.vectorcommand.com. Accessed 7 February 2008. Zyda, M. (2005). From visual simulation to virtual reality to games. Computer, 38(9), 25–32.

International Conference on Computers in Education (ICCE 2006). Beijing, China.