Design and use of serious games

Design and Use of Serious Games


International Series on

INTELLIGENT SYSTEMS, CONTROL, AND AUTOMATION:
SCIENCE AND ENGINEERING
VOLUME 37

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 F. Harashima, University of Tokyo, Japan
Professor S. Monaco, University La Sapienza, Rome, Italy
Professor G. Schmidt, Technical University of Munich, Germany
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.
Professor S. G. Tzafestas, National Technical University of Athens, Greece

For other titles published in this series, go to
www.springer.com/series/6259

Marja Kankaanranta • Pekka Neittaanmäki

Design and Use of Serious Games


Pekka Neittaanmäki
University of Jyväskylä
Dept. Mathematical Information
Technology
Fl-40351 Jyväskylä
Finland

Marja Kankaanranta
University of Jyväskylä
Institute for Educational Research
Fl-40014 Jyväskylä
Finland

ISBN: 978-1-4020-9495-8

e-ISBN: 978-1-4020-9496-5

Library of Congress Control Number: 2008939845
© Springer Science+Business Media, B.V. 2009
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

987654321
springer.com


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
definition that serious games are games or game-like interactive systems developed
with game technology and design principles for a primary purpose other than pure
entertainment.
In this book, serious games are understood as games which aim at providing an
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 production 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 commercial 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 researchers.
v


vi

Preface

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,
and a multiplayer interface for a computer-augmented learning game. The first
article presents an approach to a multiplayer mobile game. It discusses how an integrated camera would be used to support communication and collaboration in multiplayer 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 interface 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 presented. 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.
Jyväskylä,
September 2008

Marja Kankaanranta
Pekka Neittaanmäki


Contents

Part I Game Production
Three Approaches Towards Teaching 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

19

Human-Centred Design and Exercise Games: User’s Experiences

of a Fitness Adventure Prototype
Antti Väätänen, Jaana Leikas

33

Children’s Involvement in the Design of Game-Based Learning
Environments: Cases Talarius and Virtual Peatland
Tuula Nousiainen

49

Part II Learning
Designing Serious Games for Computer Assisted Language
Learning – a Framework for Development and Analysis
Bente Meyer, Birgitte Holm Sørensen

69

Comptence Complexity and Obvious Learning: Experience from
Developing a Language Learning Game
Ellen Brox, Audun Heggelund, Gunn Evertsen

83

The Attitudes of Finnish School Teachers Towards Commercial
Educational Games
Minna Klemetti, Olli Taimisto, Paula Karppinen

97

Using Videogames as Educational Tools: Building Bridges Between
Commercial and Serious Games
Pilar Lacasa, Laura Méndez, Rut Martínez

vii

107


viii Contents

Part III Social Perspective
Let’s Play Together with the Camera of Your Mobile Device
Ekaterina Kuts, Carolina Islas-Sedano, Erkki Sutinen

127

AnimalClass: Social Networks in Gaming
Harri Ketamo, Marko Suominen

143

Multiplayer Interface for a Computer-Augmented Learning Game
Ari Putkonen, Markus Forstén

155

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

171

VIPROSA – Game-like Tool for Visual Process Simulation
and Analysis
Tapani N. Liukkonen

185


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;
FI-20014 University of Turku, Finland

2) Digital Arts, Turku University of Applied Sciences; FI-20520 Turku, Finland


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 production project courses in the Department of Information Technology in the University 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 different teaching approaches, present them as formal process models, and compare them
to commercial game production processes. Additionally, we consider the multidisciplinary 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 various different situations and what requirements different types of course set to the
3
M. Kankaanranta and P. Neittaanmäki (eds.), Design and Use of Serious Games, 3–18.
© Springer Science + Business Media B.V. 2009


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 process, 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.

If we compare game production models to the generic software product development model we find notable similarities (Figure 1). All models have a starting or
a pre-production phase when a (game) product idea is defined and its feasibility is
evaluated from the production and business viewpoint, a production phase when
the actual product is developed, a quality assurance phase when the final quality of
the product is tested, and a release phase when the project is wrapped up and the
product is released to the customer. Manninen et al. (2006) address the postrelease activities, e.g. bug-fixes and user support, which are a natural part of the
product life-cycle.


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 software development and testing, the game production activities include the cooperative 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 production 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 marketplace, productization, and investment strategies. The Construction perspective deals
with the actual making of an executable computer game.

Fig. 2. Three perspectives that affect the game production process.


6

T. Mäkilä et al.

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 executable 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 fulfils 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 programming 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 expertise 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, management, 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 complex technical process that is automatized as far as possible.
Because all these perspectives are present at the same time in a game, they are
often developed in parallel: at first the emphasis is on the game design and gradually, as the game attributes and features become fixed, the focus moves towards


Three Approaches Towards Teaching Game Production

7

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 formats 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 programming 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 formats 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 requirements and specifications. Also, in a game the user features are presented more

visually than in the other kinds of software products.
General applicability. We claim that computer game development is one of the
most challenging software product domains, and thus students also learn beneficial practices used throughout the software industry (Hakonen 2006) and in
the multimedia industry in general.


8

T. Mäkilä et al.

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 programming 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.
• Controlled simplification. Over-simplification of complicated and intertwined
topics can lead to misconceptions and conceptual distortions that ruin the learning experience. However, to keep the project feasible and manageable we have
to reduce the requirements for the teaching. Apart from getting rid of irrelevant
details, we recommend that the inherent complexity of the domain knowledge is
preserved. We claim that injecting more assumptions, i.e. non-volatile requirements and forces, into real-world project carries out the actual simplification.
•

When game production is taught within a concrete software development project
we have to know how to actually configure the project. In general, the setting of
the project configuration is as follows. Before starting the project the teacher must
determine what are the educational goals to be demonstrated with respect to the
actual real world issues. Next, the teacher establishes the perspectives from where
the selected study topics are to be approached. Then, by using hands-on experience
and imagination, the teacher collects the simplifying assumptions so that the project
becomes feasible without loosing the intention and the central aspects of the real
world work. In our case, we select and abstract topics within computer game development. For example, the goal can be an introduction to multiplayer gaming via a
local area network (LAN) and the perspective can be a construction of communication technology. From this sub-domain we can select the topic, for example, the
implementation of proper balance between consistency and responsiveness for a
given game. To simplify the project, we can stipulate the LAN connections are
slow and have narrow bandwidth, the self-steering software team is located into
one room, and the customers only want to see the alpha-release of the game with
just the placeholder graphics in place. Note that although the project can be configured to be simple, the inherent complexity can be kept: the project, product, and
process issues can be presented together by adjusting their balance intentionally
(Hakonen et al. 2008). Consequently, the students recognize all the key expertise
fields and interest groups that are concerned with game production.


Three Approaches Towards Teaching Game Production

9

4 Case 1: Traditional Assignment Course
In a traditional assignment course the students form a team and solve the given problem 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 assignment is to implement 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 grounding for ideas each student analyses individually some existing 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 consisting of three to five students runs the game production lifecycle. If more students have enrolled for the course the same assignment is given for each of the
teams.

Fig. 3. The main activities of the traditional assignment course.


10

T. Mäkilä et al.

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 products 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 mechanisms 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 teamwork 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 students. 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 knowledge 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 preceding activities are effective, they do not need extensive assistance to accomplish
advanced results.
As with the projects in general, the assignment has a strict deadline after which
the students present the game, demonstrate its features and write a post-mortem
document about the project. The writing of a post-mortem from a game project is
a retrospective practice where the participants list and analyze the most influential
successes and failures. In addition to ending discussions the post-mortem document sums up the tactical and strategic lessons learned and it provides the teachers


Three Approaches Towards Teaching Game Production

11

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 alongside the teachers, work on a practical solution to it, and report the results of the
work to the whole class. Usually, the course is at an advanced level because it
requires the participants to have pragmatic skills of collaboration and knowledge
acquiring methods. In the software development industry similar work is carried
out in customer-on-site projects. This course format has two goals. Firstly, the students 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,
and especially, how certain object-oriented design patterns affect the software
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 concerning, 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 repeatable 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.


12

T. Mäkilä et al.

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 problem is well-defined.
The construction phase of the pre-made game design is realized in several iterations where the teachers and the students work alongside each other. The students
make decisions and construct the game mainly at the operational and tactical levels.
They are responsible for software and game level design, iteration planning, system
and content development, and unit testing. To aid the construction the teachers can
also operate at the tactical level but they should avoid affecting the results. Instead
of giving ready solutions the teachers reveal on a need-to-know basis what aspects
and alternatives the students should consider. In other words, the teachers act as
on-site customers who are interested in outcomes, not means. This puts the students into a situation where they have to think out proper questions and possibly
find out unforeseen answers. The teachers control the strategic work by organizing
frequent follow-up meetings where they verify the progress, prioritize the game
features, and guide the forthcoming tasks.

Three Approaches Towards Teaching Game Production

13

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 features, 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 software 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.
The main focus of the course is collaboration between the different disciplines
resulting in a working computer game. This approach gives us leeway to adjust
what we want to emphasize in the course without changing its format. For example,

if all the participants are already familiar with the development tools of their own
expertise area and skilled in versioning tools, more content creation and technological challenges can be tackled in the course. On the other hand, it is possible to
emphasize the challenges in multimedia design and art by selecting ready-made
technology platforms with uncomplicated scripting languages. Thus, the teachers
can put the students in such a situation where they keep motivated: the students
have meaningful tasks from their own discipline, but at the same time they have to
understand their impact on the whole. The latter is not possible without collaboration over discipline boundaries. As with the other course types, we prefer one-team
co-located projects because we want simple communication practices. Because the
project has many disciplines and the teachers also work as team members, each
team has a number of members with various skill-sets. To keep the number of
participants between ten and twenty the students apply to the course with curriculum
vitae. This also allows the teachers to plan the course adjustments, possible
sub-teams, and role descriptions beforehand. From these three course types this


14

T. Mäkilä et al.

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 application 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 important 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

Fig. 5. The main activities of the intensive production course.


Three Approaches Towards Teaching Game Production

15

the idea into a computer game. The teachers take the responsibility for project
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 development of the game. The students are responsible for game design and its implementation 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
level. For example, a level designer must look after the playability and immersion of
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 understanding about the successes and failures before writing the post-mortem document.
Finally, the teachers evaluate the results and grade the students. As in the traditional 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 students into smaller teams with their own responsibilities or 2) Divide the students 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.


16

T. Mäkilä et al.

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 development 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 assignment work itself. In the research lab and the intensive course approaches the preparation 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 preproduction and production phases are emphasized. However, all the most characteristic 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 previously presented teaching approaches give students a good insight into actual game
production.
In addition to the production phases, the taught production disciplines are
another important factor to be considered. As mentioned before, basically all activities of a game production have been done in a small scale during the courses and
therefore all disciplines of game production are covered, from digital arts to software technologies. The emphasis between the disciplines is adjustable via the course
objectives and needs. Alas, the teachers have to set the main focus of the course
and understand that the student may not have excellent skills in each necessary
discipline.

Three Approaches Towards Teaching Game Production

17

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 production 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 production is actually a product development process rather than just a software engineering 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 perspectives 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 limitations game creation education cannot take into account all of these perspectives at
the same time.
Instead of being content with mock-up projects where some of the production
perspectives are just ignored, we have identified three project schemas used in the
software development industry that also suit to student projects. The traditional
assignment course emphasizes game production work, the research laboratory course


18

T. Mäkilä et al.

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 division 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
A. Tuominen (Ed.), New Exploratory Technologies 2006 (pp. 124–132). Salo.
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 Solutions. 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.