Design and use of serious games pdf

  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

  Marja Kankaanranta Pekka Neittaanmäki University of Jyväskylä University of Jyväskylä

Institute for Educational Research Dept. Mathematical Information

Fl-40014 Jyväskylä Technology Finland Fl-40351 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 9 8 7 6 5 4 3 2 1 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 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 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 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.

  Jyväskylä, Marja Kankaanranta September 2008 Pekka Neittaanmäki

  Contents

  Part I Game Production Three Approaches Towards Teaching Game Production

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

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

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

  Human-Centred Design and Exercise Games: User’s Experiences of a Fitness Adventure Prototype

  33 Antti Väätänen, Jaana Leikas

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

  49 Tuula Nousiainen

  Part II Learning Designing Serious Games for Computer Assisted Language Learning – a Framework for Development and Analysis

  69 Bente Meyer, Birgitte Holm Sørensen

  Comptence Complexity and Obvious Learning: Experience from

  83 Developing a Language Learning Game

  Ellen Brox, Audun Heggelund, Gunn Evertsen The Attitudes of Finnish School Teachers Towards Commercial Educational Games

  97 Minna Klemetti, Olli Taimisto, Paula Karppinen

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

  Pilar Lacasa, Laura Méndez, Rut Martínez

  vii viii Contents

  Part III Social Perspective Let’s Play Together with the Camera of Your Mobile Device

  127

  Ekaterina Kuts, Carolina Islas-Sedano, Erkki Sutinen

AnimalClass: Social Networks in Gaming 143

  Harri Ketamo, Marko Suominen Multiplayer Interface for a Computer-Augmented Learning Game

  155

  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 171

Narciso González, Igor Kalyakin, Heikki Lyytinen VIPROSA – Game-like Tool for Visual Process Simulation and Analysis

  185

  Tapani N. Liukkonen

  Three Approaches Towards Teaching Game Production

  1

  1

  1

  2 Tuomas Mäkilä , Harri Hakonen , Jouni Smed and Andy Best 1) Department of Information Technology, University of Turku; FI-20014 University of Turku, Finland 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 Information 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, present 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- ous 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.

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.

  If we compare game production models to the generic software product develop- ment 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 post- release 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 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.

  

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

  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 gradu- ally, 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 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.

• • General applicability. We claim that computer game development is one of the

  most challenging software product domains, and thus students also learn bene- ficial 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 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.

• • Controlled simplification. Over-simplification of complicated and intertwined

  topics can lead to misconceptions and conceptual distortions that ruin the learn- ing 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 require- ments 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 deve- lopment. 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 communi- cation 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 con- figured 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 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 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 ground- ing 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 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.

  

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

  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 docu- ment 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 along- side 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 stu- 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, 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 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.

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 prob- lem is well-defined.

  The construction phase of the pre-made game design is realized in several itera- tions 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 stu- dents 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 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.

  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 techno- logical 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 collabora- tion 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 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

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 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 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 understand- ing about the successes and failures before writing 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 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 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 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.

  In addition to the production phases, the taught production disciplines are another important factor to be considered. As mentioned before, basically all acti- vities 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 soft- ware 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 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.