Facilitating the Education of Game Development

Otto-von-Guericke University Magdeburg

Department of Computer Science

Institute for Simulation and Graphics

Games Group

Diplomarbeit

Facilitating the Education of Game Development

Lennart Nacke

Otto-von-Guericke Universität Magdeburg Fakultät für Informatik Institut für Simulation und Graﬁk Arbeitsgruppe Graﬁsche und Interaktive Methoden für Computerspiele

Diplomarbeit

Facilitating the Education of Game Development

LENNART NACKE Matrikel-Nr. 159745

Date of Submission: November 04, 2005

Examiner: Prof. Dr.-Ing. MAIC MASUCH

Dr.-Ing. KNUT HARTMANN

Supervisor: Prof. Dr.-Ing. MAIC MASUCH

Processing Period: May 23 – November 04, 2005

Diplomstudiengang Computervisualistik

Otto-von-Guericke Universität Magdeburg Fakultät für Informatik Universitätsplatz 2, D-39106 Magdeburg Pronouns and Glossary Terms

In this thesis the author uses “she” when referring to indeﬁnite people. This can be the “programmer” or the “DEVELOPER”. This is because of the lack of a gender-neutral pronoun that is applicable to a human being in the English language. The decision for using “she” was made, because the author would like to see more women to join into playing and especially in developing computer games.

Some computer science or game development specific technical terms are explained in the Glossary. You can find these words like IGDA printed in bold with small capitals, when they are first used in the thesis. This style always references a glossary word. If there is a longer or more suitable description than that in the glossary, it usually references to the chapter that discusses the term in detail.

This thesis focusses on game development and educational beneﬁts gained from teaching games to university students. First, it sketches the complex pipeline of tasks inherent in game development with focus on used tools. Classifying the many diverse tools used by different kinds of game developers helps to identify areas of employment within game development.

A discussion of educational facilities and the speciﬁc niches of game development that they focus on, allows the conclusion that many games created there only reach up to a prototypic level. Thus, requirements for a game prototyping tool are derived. The author then provides estimated solutions for these needs with an extraordinary focus on the usefulness for computer science students.

This leads to an implementation of a game prototyping tool, which brings the applications of the multimedia environment SQUEAK into play. After showing the educational beneﬁts of Squeak, one can ﬁnd out about some examples of educational game development with its help. This brings further information on the game engine that was used as an essential part of the prototyping tool created for this thesis.

Finally, an analysis of advantages and disadvantages of using Squeak for educational game development is done. Also, prospects and possibilities for extending the prototyping tool are discussed.

Revolutions come from standing on the shoulders of giants and facing in a better direction. ALAN KAY

Acknowledgements

First, a huge thank you to the many fantastic friends that gave their time, moral support, ideas, expertise, and cheers during the writing of this thesis. Without you, I could not have ﬁnished this. Another big thanks to the game industry veterans Bob Bates, Bruce Shelley, Jochen Hamma, David A. Smith, and lecturer Prof. Mark Overmars of Utrecht University that took time off their busy schedules to answer my questions and helped me get further insights into a few core secrets of game development.

I was delighted by the supervision of Prof. Maic Masuch, who has positively helped me with criticism, motivation, and ideas for my research. I was always proud to be a part of his Games Group at the Institute for Simulation and Graphics. Also, the time I spent working with Squeak at the impara GmbH has extended my view on programming, and I enjoyed working with everyone of them.

Many friends contributed to this thesis in special ways: Stefan Carl-McGrath and his wife Stacy gave me crucial tips for my writing style and proof-read this thesis twice. André Miede was so kind to get me started with his LATEX template. Thanks to Ivonne Drube, who created the graphics for the demo prototype.

Alexander Opel, Christian Hansen, Aidan Fraser, and Simon McCallum all proof- read my alpha versions of this thesis and helped me improving it. They also con- sistently cheered me up - a job, which was also done well by Jan Fietz and Patty Gadegast, with whom I worked together in the past years, especially during the GCDC and who have become close friends.

Thanks to Nadin Koch for giving me an industry-insider’s view on some things from time to time, and for letting me use her SpeedTree research. Also, many thanks to Ralf Armin Böttcher, who helped in deﬁning software defects in the quality assurance workﬂow.

Finally, of course, thanks to my family especially my parents, Wolfgang and Anne Nacke, for their incredible moral support, love and encouragement - and my girl- friend Ellen Zacher, who supported me during the writing of this thesis in every possible way. Thank you.

Lennart Nacke, November 2005

Contents

1 Introduction 1 1.1 Motivation ...... 2 1.2 Research Objectives ...... 3 1.3 Structure of This Thesis ...... 6

2 Basics of Game Development 9 2.1 The Game Development Process ...... 9 2.1.1 Concept ...... 12 2.1.2 Pre-Production ...... 13 2.1.3 Prototyping ...... 16 2.1.4 Full Production ...... 19 2.2 Traditional Software Development vs. Game Development ...... 24 2.3 Game Prototypes in Iterative Development ...... 27 2.4 Summary ...... 29

3 Game Development Tools 31 3.1 More Than a Collection of Middleware: The Game Engine ...... 31 3.2 General Deﬁnition of Middleware ...... 34 3.3 Game Development Suites ...... 38 3.3.1 Macromedia Flash ...... 39 3.3.2 Game Maker ...... 40 3.3.3 Vision SDK ...... 41 3.3.4 Important Aspects of Development Tools ...... 42 3.4 Deﬁning Classes for Game Development Tools ...... 44 3.5 Progress and Future Game Development Strategies ...... 46 3.6 Summary ...... 49

4 Developing a Concept for an Educational Prototyping Tool 51 4.1 Game design vs. Game development ...... 51 4.2 Adequate Education for Jobs in Game Development ...... 52 4.3 Teaching Focussed on Developer Tasks ...... 55 4.3.1 Game Designer ...... 56 4.3.2 Producer ...... 57 4.3.3 Game Programmers ...... 57 4.3.4 Game Artists and Animators ...... 58 4.3.5 Conclusion for Education ...... 58 4.3.6 Advice from Professionals ...... 59 4.4 Game Development Tools used to Facilitate Game Education ...... 61 4.5 Towards an Educational Game Prototyping Tool ...... 62

vii viii Contents

4.5.1 Requirements Analysis for a Game Prototyping Tool ...... 63 4.5.2 A Proposal for an Architecture of a Prototyping Tool ...... 68 4.6 Conclusion for the Implementation of a Prototyping Tool ...... 69 4.6.1 Summary ...... 70

5 Implementation of a Game Prototyping Tool 71 5.1 Game Development in Smalltalk ...... 71 5.2 The Development Environment ...... 73 5.2.1 Squeak ...... 73 5.2.2 Tweak ...... 77 5.2.3 The iEngine ...... 79 5.3 LeGaCy - A Tool for Rapid Game Prototyping ...... 81 5.3.1 User Interfaces in LeGaCy ...... 82 5.3.2 The Features of LeGaCy ...... 84 5.4 A Game Prototyping Example ...... 89 5.4.1 The Game Idea ...... 89 5.4.2 Demonstration ...... 91 5.5 Summary ...... 91

6 Summary and Conclusion 93 6.1 Results of This Research ...... 93 6.2 Discussion ...... 95 6.2.1 Critical Review ...... 96 6.2.2 Advantages and Disadvantages of Game Development with Squeak ...... 96 6.3 Future Work Perspectives ...... 97 6.4 Personal Remarks ...... 98 6.5 Conclusion ...... 99

Glossary 101

References 105

A Interviews 115 A.1 Interview with Mark Overmars ...... 115 A.2 Five Questions for Four Game Industry Veterans ...... 122 A.2.1 Interview with Bob Bates ...... 122 A.2.2 Interview with Jochen Hamma ...... 125 A.2.3 Interview with Bruce Shelley ...... 128 A.2.4 Interview with David A. Smith ...... 130

B Figures and Tables 133 B.1 Middleware and Tools ...... 133 B.2 The Game Development Pipeline ...... 134 B.3 Game Engine Overview ...... 135 B.4 Mini Games ...... 136 B.5 Common Development Tools ...... 137

Index 139 1 Introduction

The only legitimate use of a computer is to play games.

(EUGENE JARVIS)

Although people have played games since the beginning of humankind, it was not until in 1958, when the physicist William A. Higinbotham developed TENNISFOR TWO that games would ﬁnd their way into computers [8BitMuseum05]. It took more than ten further years for games to conquer the amusement arcades around the world, when the PONG-phenomenon spawned the global video game mass-market in 1972 [Mertens02, Lischka02]. Figure 1.1 shows a screenshot of PONG.

Today, an increasing number of the living pop- ulation grows up with video games. Thus, the interest for understanding this new medium among young people is strong. The subject also became more interesting for educators. Most students are eager to analyse and recreate games in an academic context. Not only does the intrinsic motivation to keep playing fasci- nate scientists, but the educational contexts of some games are also useful. This especially applies for computer science, because game Figure 1.1: One of the ﬁrst video development incorporates almost every aspect games in history: PONG. of it.

This thesis will look into using game development as a subject for teaching certain aspects of computer science, especially object-oriented design. We will also look into possibilities of teaching game design to non-professional users with a strong interest in the academic side of game development.

1 2 1 Introduction

1.1 Motivation

Developing a professional computer game has become an incredibly complex task over the years. In the 1980s, a single person was able to create a computer game by herself - usually a programmer - that designed, programmed and delivered the game all on her own. The art was usually homespun, because of the graphic capacities of the hardware and the target group consisted of technology interested people only.

However, things changed fast. Over the past decades, the complexity and quality of game graphics became the biggest selling point in this competitive market. Therefore, the programmers had to team up with artists and management people.

After the great success of id Software’s DOOM [IdSoftware05], game DEVELOPERs and PUBLISHERs discovered the Internet as a distribution and marketing medium [Kushner03]. Even today the distribution and safety protection of computer games via the In- ternet are reaching new heights with the release of HALF-LIFE 2 and its accompanying software “Steam” by Valve1[Hodgson03]. The software is shown in Figure 1.2.

This novel approach has the potential to change game Figure 1.2: A screenshot of the games panel publishing forever. The classic role of publishers as in Valve’s Steam. the powerful controlling instance over marketing and distribution might become obsolete in the future, and the developers might possibly retain more rights over their intellectual property. Royalty share could also become more attractive for publishers.

Teams and budget sizes have exploded continually over the last years. For recent entertainment software titles, a team of at least 40 to 400 developers, not counting the contractors and freelancers needed in special phases (e.g. shortly before completion), spends two years of development time. The cost and the risk of developing a successful title over this long time-span have also increased.

This has resulted in publishers being careful, and producing less innovative titles, which often results in narrowing the target group for a game towards hardcore players. The more a game costs, the fewer titles the publishers produce. This causes more development studios to go bankrupt. However, the distribution on the internet that was mentioned above could provide solutions for this problem.

1 Valve Software is one of the most successful PC game development studios. 1.2 Research Objectives 3

Professional game development itself has become a complex, interdisciplinary, and collaborative procedure. To begin with, it is interesting to analyse the implicitly known development process, and then teach it to students. This way they get a basic understanding of how the industry works and what methods apply when developing a large software project in a team.

Games can also be researched on a more diverse scale, including serious games and academic approaches towards using games as a meta-medium for teaching certain areas of languages, arts, mathematics, physics, and chemistry, or computer science. Developing game projects in short time-spans in a team of students without professional aid often leads to unpleasant results, and games that are of miserable quality. This could be due to an educational goal that many academic games have [Overmars04a].

Player freedom and intended player experience denote a common control-conﬂict in game design. This is a challenge game designers need to face, when they want to transport a message to the players. The player wants complete control over the game, but the game developer cannot grant her this, as it might ruin the game experience. A psychological trick is to let the player think that she has complete control over the game world, while guiding her in the right direction of the story or the educational goal.

One has to also keep in mind that there are different approaches to developing computer games, according to the target groups. Thus, a next-generation console title has a different requirement-speciﬁcation than a casual game developed by non-professional programmers.

After prior reﬂections on teaching game design in university courses [Nacke04, Masuch04b], obviously, a wide variety of skills is needed for creating computer games. All the different aspects of game development teach the students a broad knowledge of programming, design, team management, and communication that is unique in education.

A challenge of game design in an educational context is the complexity of the task. Simplifying this complexity of the game creation process by creating a tool that assists in conceptual game design is a goal of this thesis.

1.2 Research Objectives

This thesis aims at showing how games and education supplement and connect to each other. Computer games do not only serve as attractive motivational sources that challenge students to spent more time on thinking about algorithms and mathematics, but they are visually comprehensive for non-professional people, too. 4 1 Introduction

This comprehensiveness makes them also the perfect tool for learning - not only, but especially - computer science related matters. Thus, creating games and playing them complement each other so ideally that it is only a matter of time until playful teaching becomes the standard, enforcing better learning results in the future.

The research in this thesis focusses on the analysis of game development, compares it to software development with a focus on similarities in the processes, and gathers ideas from past experiences [Masuch04b]. The curriculum developed in [Nacke04] lacked the right support for the chosen tools2.

This was making it hard to concentrate fully on one basic aspect of designing games,

Figure 1.3: The students of a game design course at the Otto-von-Guericke University of Magdeburg. They gather together for analysing video games, which will later help them producing a game in a team project. and often lead to problems in supporting the needs of particular students. These obstacles, however, can probably never be erased, because many different students with different skill sets usually come together for the courses (Figure 1.3 shows the students of a game design course at the Otto-von-Guericke University of Magde- burg). This resembles “real” game development in a way.

2 Chosen tools in this case refers to software that is made for a game development course, taught to people with little or no game development or programming experience. 1.2 Research Objectives 5

Nevertheless, the primary goal is the academic education of game development rather than producing a professional product 3. A nice secondary side-effect is the mediation of diverse knowledge from other areas of computer science. There can be other teaching goals as well, but the emphasis needs to be on understanding game development as a complex process.

Therefore, the ideal way of approaching game development is to focus on one part of it and try to teach decent knowledge of the other parts. In a computer-science environment, the focus naturally is technical-related. An important area of programming is object-orientation, a principle that becomes more popular among computer scientists.

Object-oriented design is an intuitive method for learning programming, so the aim of this thesis is to develop software that allows for understanding object-orientation, as well as game design. My hypothesis is that object orientation is a natural approach to game design. It does not help to grasp the subject, but it introduces structured and abstract thinking to computer scientists.

Here, the focus of a tool has to be on creating small comprehensive game prototypes that show functionalities of the gameplay rather than polished graphics or ﬁnal games. Creating such game prototypes can also serve as a quality analysis for tools, since the games are typical “ﬁrst” game projects that many non-professional game-programmers choose as a starting point for game development.

In conclusion, the educational advantages of computer games are plentiful and important beneﬁts are:

• Computer games are great motivators for learning almost any subject

• Games always train skills, enforcing learning-by-doing4

• Collaboration is an essential part of game development

• Object-oriented design can be used to teach game design

This thesis will underline the importance of teaching game development as part of computer science. Not only because it is a hands-on area of applied computer science, but also because it positively enforces learning. The entertainment value that has kept science separate will help those who embrace the subject to reach much better results in the future.

3 This means producing a shrink-wrap PC game sold at computer stores. This would be a bottomless pit of producing media assets (like sounds, graphics, text, and basically anything that is presented to the player). 4 This is also true for developing games. 6 1 Introduction

1.3 Structure of This Thesis

After reading this introduction, one should be curious enough to read about the basics of developing games that chapter 2 describes. The chapter gives a review of game development and consequently subdivides it into different stages, which are explained in more detail to highlight the iterative nature of the game development process.

Subsequently, a comparison of game and software development follows, which will explain the distinct features that make game development so interesting and complex. Eventually, the chapter ends with a discussion of different forms of prototypes and their use in game development

Next, in chapter 3, the standard tools of the game industry are highlighted and classiﬁed. The use of MIDDLEWARE and how it can be distinguished from a GAME ENGINE both receive special consideration.

Following a discussion of the tools is the detailed explanation of the classiﬁcation made to differentiate between them. The ﬁnal section describes the progress and direction of game development, and the use of tools within game development.

This leads to an analysis of game development education, and the institutions that offer it, in chapter 4. First, a deﬁnition clariﬁes the terms game design and game development. An analysis of academic education opportunities for jobs in computer game development follows. A comparison of different academic facilities and their approaches towards a game-centred education shows different demands for different jobs.

Knowing the job positions the educational institutions would like their graduates to ﬁll, a description of the most important jobs in game development follows. The subsequent paragraphs depict some experiences of teaching towards these proﬁles.

Next, the software used in game development education is portrayed. Consequently, the requirements for a prototyping tool aimed at teaching game development are gathered. Discussing possible solutions helps to sketch an outline of desired features of the prototyping software for the use in game development education. Fi- nally, a software architecture based on the requirements is proposed.

Chapter 5 begins with an introduction towards the object-oriented environment and programming language Squeak [Squeak05], where some historic details and an outline of its functionalities lead to a discussion of the beneﬁts of its different interface-toolkits. 1.3 Structure of This Thesis 7

Next, an outline of implemented classes of the prototyping tool LEGACY5 is given. It discusses thoughts on the interface, introduces details of the program library, and shows how to extend or reuse them. Before ﬁnishing, the functionalities of LeGaCy are explained with the help of a prototyping example.

Finally, the summary outlines all the previous work with a special look at the achieved results in chapter 6. A discussion of the results follows with regard to the academic context. Here, the advantages and disadvantages of Squeak for computer game programming are evaluated. Personal remarks and future prospects conclude the thesis.

5 The name stems from the developer’s ﬁrst name, for details see glossary.

2 Basics of Game Development

You have to learn the rules of the game. And then you have to play better than anyone else.

(ALBERT EINSTEIN)

This chapter gives the basic foundation for further analysis in this thesis. First, the iterative cycles of game development show how the industry works and how the development groups interact. Section 2.1 outlines game development in stages of conception, pre-production, prototyping, and full production.

This approach should be taken with the usual reserve. Other views of game development do exist, and they can be true as well. To understand how to teach game development in academia, we need to structure and classify its parts to fully grasp the process as a whole. A development pipeline is sketched in the ﬁrst section and can be seen completely in Figure B.2. The pipeline bases on ideas from Masuch, Electronic Arts, and Fullerton et al. [Masuch05, ElectronicArts05, Fullerton04].

Section 2.2 discusses the differences that exist between game and software development. This is much of an outsider’s view, but these points are based on multiple discussions with software developers in forums and conventions. The last part in Section 2.3 talks about the meaning and different types of prototypes, which will become important for the implementation later.

2.1 The Game Development Process

This section explains what game development consists of. It is important to identify it as a pipeline of iterative processes, with each phase describing a certain process or stage of development. In real life, the process is much more complex, but for a theoretic overview, we can simplify its units. Every unit represents a stage of game development.

9 10 2 Basics of Game Development

" Concept The game idea is the initial spark that comes to mind and then matures into a more complex combination of ideas. It defines the core theme of a game that is fleshed out in the concept. Ideally, the first game ideas are independently developed. However, the truth is that often potential funding mainly influences and depends on the theme of a game.

! Forming an Idea ! Designing the Idea to get Funding

" Pre-Production Small and less professional game development studios sometimes start directly from here: Programming the prototype, as the idea and gameplay develops in their head. However, this stage should really involve careful gameplay testing and exact planning.

! Gameplay Prototyping ! Pitching1 the Prototype ! Planning the Production ! Writing a Design Document

" Prototyping Several prototypes are produced in a collaborative effort. The designers produce a framework, around which the game will be built. The prototypes are reﬁned until they reach a mature stage (e.g. a stable organisation of features) where full production starts.

! Artwork and Sound Creation ! Engineering Developers ! Production and Management ! Game Design ! Tool Programming ! Quality Assurance

" Full Production This is the ﬁnal development stage, before the game is ﬁnished and the gold master2 is handed over to marketing and distribution. The focus is on reaching several milestones and avoiding critical bugs.

! Art Focus ! Production Focus ! Programming Focus ! Level Design Focus

1 see glossary: PITCH 2 A term for the completed game that will ship to stores. 2.1 The Game Development Process 11

The process of game development is usually carried out in an iterative manner during all of its phases [Mencher03, ElectronicArts05]. There is no common agreement or universally valid deﬁnition of what the phases and their content are. However, the formal description of the iterative game design process as described in [Fullerton04] (which can be seen in Fig- ure 2.1) mix very well with the abstract outline given in [Masuch05] and the more informal workﬂow sketched by [ElectronicArts05].

Figure B.2 in the Appendix B shows a workﬂow diagram of the incremental development phases that are subsequently discussed in more detail. The pipeline has a strong focus on these lay- Figure 2.1: An outline of itera- ers of production that each contain iterative re- tive development as sketched by visions of the ideas and prototypes generated [Fullerton04]. within them. The stages are described, however, without any claim for completeness.

Although the speciﬁc development processes may slightly vary, depending on budget, team-size, and the development platform, the basic principles should be understood. Things like iterative development cycles (the incremental reﬁnement of the game), collaborative, interdisciplinary teamwork and economy-focused production constraints will be highlighted as essential parts of the following phases.

Concept Phase Money Acquisition Gathering Ideas Theme Funding

Pre-Production Phase

Figure 2.2: The concept phase is the start of every game project 12 2 Basics of Game Development

2.1.1 Concept

Getting a concept is the starting phase of game production. Here, game designers form ideas and evaluate their potential, to decide whether they should spent time and money on producing a core gameplay prototype out of it (see Figure 2.2).

Gathering Ideas Some developers view producing ideas as the most enjoyable part in production, and many players reach a stage at one time or another, where they have an idea for a game. However, not all ideas are useful, and many are not worth investing time and money in. Usually, teams produce game ideas in a group, which later develops the game as well. Often, there is no need for hiring external people to create ideas. Producing innovative ideas and special gameplay is a unique selling point, but also a big risk that most publishers are not willing to take.

Nevertheless, the industry needs to find good ways to improve idea generation. The authors Schnetzler [Schnetzler04] and de Bono [DeBono04] formalise idea generation with engineering methods, which can be applied whenever the need for specific ideas arises. De Bono gives several useful advice on techniques that let one form ideas, give them a direction, and a way to filter and refine them towards a needed goal [DeBono85].

After the idea is found, the designer has to identify her audience, and modify the idea, so that it works with that audience. The intended audience is also included when designing the ﬁrst look and feel of the game. During the later design stages, there will also be a point, where some of the game features possibly need to be cut back. This is all part of iterative development, and the designer should not fear, but know about the consequences when sketching out the game.

Funding The transition from the initial game idea to the ﬁrst game design is fuzzy, as some development studios prefer to ﬁrst sketch a rough concept, while others prefer a formal design treatment that can then be made into a full design document.

However, this process does usually not involve a publisher, but is carried out independently by a developer. Only after the creation of a design document or a software prototype, the game is pitched to a publisher to enter production planning. Before the pitch, the developer has to plan ahead how to fund his resources well enough, so pre-production will be reached. This might also include altering the theme and setting of the game to be more attractive for a certain publisher portfolio. It is a sad reality that games are usually developed towards publishers’ requirements rather than focussing on players’ wishes3. 2.1 The Game Development Process 13

2.1.2 Pre-Production

During pre-production, game designers commonly test ideas in prototyping cycles, before integrating them in the design document, and moving on to planning the production from there. Two stages are possible (compare [Fullerton04] and [Salen03]).

The ﬁrst stage omits the use of computers and lets the game designer produce her ideas with the help of pen and paper, up to a stage, where she presents the game prototype to the development team. Eventually, an investor can also be a part of this presentation, if the developer has a good connection to a publisher. Then, they decide, if they want to develop the game further by writing a software prototype, or they do not approve the idea. This way, the developer avoids producing dreadful games at this early stage.

Management can use iterative checks on the state of a game to avoid draining

Pre-Production Phase

Game Design Prototyping Publisher Physical Prototype A Q

g Financial Plan n

i Presentation t s e t ay l

P Software Prototype Production Planning

Design Document ● Task Breakdown ● Story ● Priorities ● Gameplay/Mechanics ● Milestones ● Characters ● Scheduling ● Levels ● Resource Management

Figure 2.3: The pre-production phase, where the game design document and the production plan merge to reach the actual prototype creation. money and workforce into a product, which the team will never ﬁnish. This is important, because a game has to make its expenses in the end. Therefore, publishers often take control of production at this stage (for an outline of this phase, see Figure 2.3). They direct the ideas of the development team so that the product will suit the market demands.

3 Nevertheless, publishers analyse the market to ﬁnd out features that a majority of people want in a game. This is the reason why many PC game titles focus on this mainstream gusto. 14 2 Basics of Game Development

The publishers’ focus on market demands and sales deadlines is also responsible for a decrease of innovative games and much pressure, which is put on developers for meeting the Christmas deadline4. The developer community currently discusses intellectual property thoroughly, and the International Game Developers Associ- ation (IGDA) hosted “Quality of Life”-panels at the Game Developers Conference (GDC) in 2005.

Gameplay Prototyping After the ﬁrst sketch, the game designers start building a physical prototype of the game, which they playtest with the development team. This is most often a “paper or physical prototype” (see Figure 2.4) where cards, paper, dice, chips, or a board serve as ingredients for creating a ﬁrst playable game version.

This stage itself - like game development - should be iterative and aim at reﬁning

(a) A physical game prototype example from (b) A “paper computer” prototype developed [Fullerton04]. at the University of Applied Sciences Magdeburg-Stendal.

Figure 2.4: Physical gameplay prototypes created with not much more than pen and paper. the prototype, while it is played repeatedly. Later, the game designer starts writing the game treatment, where she formally explains game mechanics and gameplay. Subsequently, she should present this game to stakeholders and the development team, always keeping the unique selling points in focus.

The next prototype is a software prototype, where a computer program roughly shows the gameplay, usually using only placeholder or temporary graphics. Ideally,

4 The time around Christmas in December is where most video games are sold. 2.1 The Game Development Process 15 this software prototype is evaluated and playtested in iterative cycles, too. During this process, it should be possible to save notes and ideas on issues occurring unexpectedly.

Thus, an ideal software companion for prototyping would be a Wiki5, which designers and playtesters can edit together. Out of the Wiki notes, creating a detailed design document will advance much faster. Other software used for prototyping are multimedia editors and non-professional game suites6. The software prototype7 is usually used with the design document to pitch the game to a publisher.

Design document After having worked on these prototypes, the game has evolved into a mature stage, where the game designer has ﬂeshed out most features of the game. This is the time to collect all the ideas and thoughts into a detailed document that can then be used for building the full game during the production stage.

The design document outlines level-features, plot, gameplay characteristics, main characters and the story embedded in the game. When questions about the game occur later during the implementation, this reference should provide the answers to most of them. It is also important that the layout of the design document is attractive, which means that additionally to the Wiki, a good layout-tool and a reliable text processor should be used (e.g. Adobe InDesign, Microsoft Word, OpenOfﬁce).

Production Plan Usually, after building a software prototype and carving a design document, it is time to specify the planning for further production. As stated before, a publisher (or a producer) generally does this after seeing the game design prototype. Further production especially needs much money, and with that comes the need to keep the costs short.

Bigger development houses like Electronic Arts [ElectronicArts05], for example, plan the production internally. This includes milestones to check on the progress of the product and the constitution of the team. Therefore, the production team assigns and schedules tasks. An outline of required resources is laid out, and the prototype production starts subsequently.

Good tools for planning the production are project management tools, chat software,

5 Wiki is a collaborative software commonly used in the world wide web, which allows users to add content to a website for exchanging information. 6 Examples of this are Macromedia Flash, Macromedia Director, and Game Maker, a few of which will be discussed in section 3.3. 7 Often this is a prototype version enriched with polished graphics. 16 2 Basics of Game Development asset managers, and trackers. Some examples of these are Microsoft Project, Wiki Software, NXN Alienbrain, Perforce, Subversion, Miranda, Skype, PIM8 Software like Mozilla Thunderbird/Sunbird or Microsoft Outlook.

Before Proceeding: A Word About Asset Management Game developers refer to the media of the art and sound departments as asset files or assets [Llopis04]. In contrast to the code files, which contain plain text, they include binary data, which has a typically large byte-size. During the production of a game, the amount of assets increases exponentially. Managing these large amounts can become a serious problem, if the team does not use proper Software Configuration Management (SCM) tools.

Especially, during the following phases of game development, these tools are much needed. It is necessary to have a tool that organises the rapidly growing pile of game-related data and helps to manage different versions of code files, too. It is of major importance that development teams work with asset-management or SCM tools, which integrate into their work environment and keep track of the changes made to the files. These tools need to control multiple backups, updates, and the exchange of binary files through a network. Today, asset management has become an essential part of software development in general.

2.1.3 Prototyping

The prototyping phase starts the technical game production. The ﬁrst game spec-

Prototyping Cycles Phase

Artwork Production Tools A

● Models/Textures ● ● Level Creation s

Coordination s

● ● ● e

Animations Tasks and Milestones Effects t

● Maps ● Priorities ● Control Animation M an ag

Sound e Engineering Game Design m ●

Sound Effects e ● Engine Developers ● Gameplay n

● Game Mechanics ● Levels t ● Scripting ● Characters Quality Assurance ● System Conception ● Story ● Iterative Testing

Figure 2.5: The game iteratively evolves from the basic prototype to an early alpha stage. Thick arrows indicate a stronger collaboration between the departments. iﬁcations, made in the design document and seen in the ﬁrst software prototype,

8 Acronym for Personal Information Management. 2.1 The Game Development Process 17 need to be implemented and improved. According to the milestone plan, set up by production, the game engine9 is programmed in-house or the programming team needs to learn the middleware (see section 3.2 for further details on middleware).

Programmers begin building the tools, needed for level design and content creation. The art and sound department start to produce media. The decision, whether to use certain middleware (e.g. there is more available for AI and physics), is often a resource question (depending on time and money). Nevertheless, this choice is crucial for the quality of the ﬁnal game. Figure 2.5 outlines the prototyping stage.

Artwork Before prototyping, artists draw the concept art, which illustrates the look and feel of the game (see Figure 2.6). The art department transfers the sketches into the

(a) Concept art by Mr. Green of Massive (b) Concept art by Nicolas Bouvier (aka Sparth) Black for the game ICEWIND DALE (Black Isle for the game PRINCEOF PERSIA:WARRIOR WITHIN Studios). (Ubisoft)

Figure 2.6: Concept art character portraits for two different computer games. computer as either a three-dimensional textured model or a two-dimensional sprite graphic10. Sometimes, the texture artists take photos of animals or landscapes, similar to the ones used for the game. These photos serve as a basis for texturing

9 Figure 3.1 in section 3.1 will explain the different parts of an engine. 10 A sprite graphic is a two-dimensional image or animation that is integrated into a larger scenery. 18 2 Basics of Game Development the models later. Non-natural textures are often hand drawn within the computer.

The model department uses the images from the concept designs to create three- dimensional models. Animators have to imagine, how those models will behave and animate them, so they ﬁt into the setting. Later, the challenge is to integrate the models correctly into the game engine.

The art department and the concepts it produces are very important for helping game designers create the mood for the game world. While gameplay is mainly responsible for a great game experience, concept graphics are not less important for developing a coherent game experience for the player. A good design document and excellent concept art are the foundation of any successful game.

Production The publisher sometimes adds producers to the development team to assure that prototyping works and milestones are reached on time. Game production consists of iterative cycles, so the stakeholders (often the publishers) can constantly view how much the development has progressed. For managing these iterative cycles, SCM tools (like NXN Alienbrain, which is shown in Figure 2.7) provide a good way to save prototypes for each milestone. In addition, the development team uses internal messaging software as a communication channel. Tools for this task Figure 2.7: Alienbrain Manager Client is an application that tracks all changes made to the are chat and Voice-Over-IP clients ﬁles in a project and communicates those with (like Skype, ICQ, Yahoo Messenger, a central server for sharing them with internal MSN Messenger, AOL Instant Mes- and external team members. senger, Jabber, etc.).

Tools Tools are something that developers either source out (especially by acquiring middleware) or create internally in close connection with the production team. Some of the tools even make it into the release version of the game or are later shipped with an ADD-ON. Players use them for modding11 the original game.

11 Modding describes the manipulation or modiﬁcation of the original game to add new features and content. 2.1 The Game Development Process 19

Game Design Game designers not only take responsibility for the gameplay, they work a lot on the story as well. During prototyping they ﬂesh out ideas for levels. They add NPCs or other items to the game and give advice on what interface could be best for what purpose. Depending on the type of game, the team develops, the tasks of the game designer vary a bit here.

Quality Assurance Playtesting and bug-tracking are all parts of quality assurance, usually occurring towards the end of full game production just before the gold master. However, many people argue that the quality of the final game is much higher, if quality assurance becomes an essential part of game production during prototyping already. Errors in gameplay are much easier to fix early in a project. The longer bug-fixing is delayed, the more complicated it becomes.

It is not common practice everywhere yet, but the iterative testing during prototyping phases can also help to shorten the crunch time at the end of the project essentially. Thus, providing better quality of life for the developers. Usability testing provides a model to improve the game and broaden customer acceptance (see [Memisoglu04]).

The more formalised quality assurance becomes, the better it will integrate as an essential part of the game development pipeline. Iterative development demands quality assurance to be a part of regular milestone. Playtesting sessions should be conducted, among the development team as well as with external teams.

2.1.4 Full Production

Integrating all production tools and the game engine into the workﬂow of designers, artists, and programmers is an indicator of the blurred transition, where the development team reaches a game’s full production phase. Team size increases, and especially the engineering, art production, and level design departments are stacked up with personnel. Figure 2.8 highlights this by outlining those departments with a broad border.

Some companies even manage to start localisation at this stage. Quality assurance is an important part of this phase, especially, when a game reaches alpha state12. Some time at the end of beta testing, the developers declare the feature-freeze13.

12 The normal software production features unstable alpha and beta states before reaching a stable state. 13 This term means that no more features are being integrated into the game code. 20 2 Basics of Game Development

Most of the development resources are then part of quality assurance, and bug ﬁxing. Figure 2.8 shows the last part of the game development pipeline, which is reached when ﬁnishing the full production stage.

Full Production Cycles Phase

Artwork Production Localisation A ● ● ● Models/Textures Coordination/Scheduling Translation s s

● Animations ● Milestones e t

● ● Maps Priorities M

Sound an ●

Score Composition ag ●

Sound Effects e Engineering Game/Level Design m ● ●

Engine Refinement Gameplay e

● ● n Game Mechanics Levels Quality Assurance t ● Scripting ● Characters ● Iterative Testing ● System Refinement ● Story ● Bugtracking

Figure 2.8: The full production phase takes a game from alpha to gold master. Thick box outlines emphasise the departments mainly involved. Most work is probably done by the level designers and the quality assurance towards the end.

Quality assurance In large game projects, this has become much more than just playtesting and bug-ﬁxing. Some of the best practices in the games industry are automated regression tests, where integrated debug tests generate reports on the stability of code [IGDABusiness03]. Bug database tools most commonly used in the industry can be found in Table B.5 in Appendix B. There are different ways of classifying software defects, depending on the project stage, the tester experience and the severity of the bug. Each quality assurance team also has an own classiﬁcation of software defects. Some exemplary defect types tracked by a game company are:

5 Feature Wish This does not refer to a bug. It is a missing feature that is desirable at this point in the game. The report of something like this only makes sense in the last development stage, when the development team has reached feature freeze14. If the quality assurance department encounters an issue that is likely to bother the customer, a feature request is posted.

5 Trivial/Nice-to-Have Some minor problems or annoyances that happen during testing are put on record until they either turn out to become bigger problems or the development team has enough time left to ﬁx those issues.

14 A state, where no more features are added to the game. 2.1 The Game Development Process 21

5 Errors in the Text Often these are logical errors in the text leading to problems in solving a quest. Spelling and grammatical mistakes are other forms of text-errors that permanently occur during development.

5 Aesthetic Errors Often graphical errors with little or no effect on gameplay ﬁt this category. Graphical bugs can be very annoying to players, but can often be ﬁxed quickly by the developer. Figure 2.9 shows some popular graphical bugs.

(a) A graphical bug in the PC game SACRED de- (b) A bug in the graphics of the game VAMPIRE:THE veloped by Ascaron. MASQUERADE -BLOODLINES by Troika Games (Activi- sion).

Figure 2.9: Several graphical software defects from different retail versions of computer games.

5 Minor Error Logical inconsistencies in missions or character development are referred to as minor errors. This can also refer to animations not starting on a certain trigger or some essential graphics missing. Minor programming errors, e.g. if a script works incorrectly or the winning condition of a mission cannot be met, can become blockers as well.

5 Big Error Depending on the inﬂuence an error has on gameplay, it can become a bigger error. Some problems with the hitpoints being wrongfully applied to a character can lead to major gameplay changes that can uncover new bugs of higher or lesser importance.

5 Program Crash Severe code problems, like memory leaks, can cause the game to crash. 22 2 Basics of Game Development

5 Blocker These are the most severe software defects that block further development or lead to repeating crashes. Most of these issues can be ﬁxed during regression testing. If this kind of defect is discovered later, it can become harmful to the further development schedule and needs to be ﬁxed immediately.

While human testers most often are avid gamers that have a feeling for fun in games, they also need to be disciplined. They need to track all the bugs constantly, and describe clearly what caused them. They should discuss improvements about gameplay issues as well.

Popular freeware tools, used for bug-tracking, are Bugzilla and Mantis (shown in Figure 2.10), which also improve the communication between team members. Since

Figure 2.10: Mantis is a popular open-source bug-tracking tool used by the company impara GmbH for identifying software defects. those are open-source projects, many middleware projects are attached to them as well. They extend the functionality, in terms of immediate notiﬁcation applications 2.1 The Game Development Process 23 for Windows desktops, or simple communication libraries that work well with the respective Application Programming Interface (API).

Like all game development, quality assurance should be done iteratively at all milestone points during a game production. Most likely the developer will write a test plan and check-list to ensure all-important issues get ﬁxed properly. The best quality assurance is usually done in the console game development area. There is no possibility to PATCH the software later, and the game needs to apply to the high quality standard of the console manufacturer.

Game/Level Design In some projects, developing tools takes a long time until they reach a state, where level designers can actually use them to create maps belonging to the game project. Thus, especially in development teams that create their own engine, level design is often done at the end of production. After the programmers ﬁnish the fundamental software, the designers develop much content, especially the game maps. Level designers can then work with the game design department to create missions, levels, and maps.

Finishing Full Production During full production, a game goes through several completion stages (which are shown in Figure 2.11). The ﬁrst being the alpha version, which is the version that is

Full Production ⇓ Alpha Version Playtesting ⇓ Beta Version Playtesting ⇓ Gold Master Release ⇓ Maintenance Service (Patches)

Figure 2.11: The last stages of Production thoroughly playtested. This evolves into a beta version that is sometimes released to the public or and larger number of playtesters to uncover bugs in the gameplay, artiﬁcial intelligence, and network capabilities. Then the game reaches its release state: gold master. 24 2 Basics of Game Development

Unfortunately, many PC games are under severe release-pressure so that the developers sometimes not test intensely enough and games are released with strong defects. The developer has to keep the game alive by promptly posting patches on the internet, so that players can ﬁx most of the bugs in the game they bought.

This highlights a difference between regular software, which is usually maintained by updates through the internet and games, which are ﬁxed this way. In the next section, more differences between the traditional software industry and game development are discussed.

2.2 Traditional Software Development vs. Game Development

While most classical software development projects take place in clear hierarchical structure with speciﬁc requirements speciﬁcations, developing a game and an interaction that delivers fun and entertainment is much harder to grasp. Of course, the game mechanics are built on algorithms as well, but the way that objects in a game interact is more versatile than in regular shrink-wrap software. Table 2.1

Game Industry Traditional IT Industries

¨ Flat hierarchy structure ¨ Traditional hierarchy structure ¨ Interdisciplinary teams ¨ Advanced training ¨ Non-deferrable project schedule ¨ Stability is more important ¨ Harder planning ¨ User Interface matters less ¨ Informal skill improvement ¨ Long lasting support for products ¨ Contract work, similar to the movie industry ¨ Classic contracts ¨ Constantly educate yourself ¨ Coders and software engineers ¨ Latest technology is most important ¨ Graphics are less important ¨ Graphics are important ¨ University degrees matter ¨ Younger age of employees ¨ Former education is important ¨ Multimedia integration ¨ Stricter working hours

Table 2.1: The table compares game and traditional software development by highlighting remarkable features of each industry. The three most important features are printed in bold. shows the differences between software and game development. The three most important peculiarities of each industry are marked bold and will be discussed ﬁrst.

The ﬂatter hierarchy in most game development studios is often caused by the young age of most workers in this industry. This is good for innovation, and a 2.2 Traditional Software Development vs. Game Development 25

ﬂexible development team can adjust to requirement changes quickly. However,this might lead to problems with recognition of personal achievements, and some indi- viduals might feel that they do not get enough credit for the work they do.

Traditional hierarchy structures in classical software companies allow for a clearer career orientation, because a certain title clearly indicates the areas of responsibility a person has. Teams are more organised if competencies are clearly assigned and a hierarchical structure is present. This structure can be exploited, nevertheless, when insider deals are made. Still, the clear hierarchy structure is a sign for the maturity of the software company.

The interdisciplinary structure of development teams is not easy to manage, because most often many disciplines have their own distinguishing language that they can understand among each other. If some of these disciplines work together, they might encounter translation difﬁculties when trying to explain tasks to each other.

Skilled managers are needed for transporting the vision, for example, from the artist to the programmer and vice versa. These are often generalists that know the languages of all the different disciplines and work like a glue that holds together the different departments of specialists.

Most regular programmers at a software company have many possibilities for receiving advanced training. Although they are educated regularly about new software the company uses, they also have access to soft-skill seminars. Usually, programmers have the opportunity to get educated about software engineering, and go to workshops regularly to improve the way they write code. Generally, the company even pays for all costs of this.

For game development studios, a deal with a publisher is often not very ﬂexible. The project schedule is non-deferrable, giving a very narrow time-frame for the milestones and the ﬁnal release of the gold master. This is often due to market demands and seasonal sales peaks, with Christmas being the most prominent example for this.

It unfortunately leads many developers to working overtime and demanding an incredible workload of all employees towards the end of project. The period is referred to as crunch time, and this has a very heavy effect on the quality of life of most developers. In 2005, this has become a major issue being intensely discussed in the industry, with the IGDA ﬁghting for more rights of developers upfront. These challenges are typical for an industry on the verge of growing-up.

Traditional software is also aimed at a certain release date, but here the stability of the ﬁnal product is much more important. This is especially true for certain indus- 26 2 Basics of Game Development tries, where a leak in stability would have dreadful consequences (e.g. Aerospace, Medicine). Since the resale price of this kind of specialised product is also very high, the customer will be non-forgiving with fatal defects in the software.

The continuous improvement of graphics hardware and the addition of more sophisticated middleware (especially game engines) demands from developers to constantly adjust to new programs and improve the way they program. This makes planning a ﬁnal game much harder, because one has to predict the industry standard two or more years ahead (depending on the prognosed development time).

Most development studios have started thinking about the future, next-generation development, and the need for qualiﬁed personnel. These are young people that need experience urgently. Even though most game programming veterans are self-trained professionals, they need to improve their skills continually to stay up-to-date.

One needs to admit that in most traditional software the graphical appearance of applications matters less. In the games business, neat graphics still sell the game, although one should not forget about a unique idea and solid implementation of a well-working AI, which many customers expect these days. The integration of multimedia is essential for game developers, and they need to specialise on this aspect.

For most game developers, it is important to go to networking conventions such as IGDA meetings, games conventions and game developer conferences to educate themselves about the state of the industry. Academics usually do research on ﬁelds that are part of games as well and publicise their work and speak at those conferences.

The contracts for game developers are similar to those in the movie business (especially concerning upfront ﬁnancing of projects). Before people can see the game on the shelf, its development needs to be ﬁnanced by a publisher. Because this bears a high risk, it is also no wonder that external teams do outsourced work. This includes (most often) prerendered intro movies, as well as having the game assets made in a design studio. It also gives freelancers the possibility to work on a project (as needed) and then move on to their next contract-work.

A last word on the advantages of the traditional IT industry: The working hours are stricter and the academic degree of an applicant has a higher value than in the games industry, which is very skill-focused. These values also mark the advance of the traditional software industry.

By keeping a team within certain working-hours, all team-members can attend crucial meetings and faster communication is enforced. A young university graduate 2.3 Game Prototypes in Iterative Development 27 can bring much motivation to an entire team and will be more eager to challenge old ways of development.

Maintaining a good balance of people with different skill-set is what makes a company successful. The game industry will soon accept this fact as well.

2.3 Game Prototypes in Iterative Development

Iterative software development needs architectures, which build on basic sketches of their units. Prototypes are ﬁrst models of a game for testing a certain design idea or new development techniques.

In iterative development, every phase is accompanied by respective prototypes. The prototypes evolve incrementally. Additionally, game developers differentiate between different kinds of prototypes. There are usually software prototypes as well as physical prototypes, both are for testing the gameplay. [Rollings03b] more clearly outlines the following types as part of the development process.

• Gameplay Prototypes Most important prototypes for game developers. These will be discussed in the following. ¡ Physical Prototypes Models made on a non-software basis serve for playtesting gameplay with paper, cards, dice, and whatever can be used to model the ingredients of a game. Things are rough sketches concentrating on functionality rather than aesthetics [Barry05]. ¡ Software Prototypes Software prototypes are programmed game environments for testing ideas. They are kept separate from the regular game code, making them easy to remove if they stop working.

• User Interface Prototypes They are the second most important prototypes, because they are necessary for evaluating the interaction of the game with the player.

• Subsystem Prototypes These are use for testing the interaction of the subsystems and their software interfaces to other systems. They are of minor importance for a gameplay discussion.

• Algorithm Prototypes Usually, different algorithms are tested for certain situations. This is often done behind a software interface, so that the algorithm prototype does not affect the rest of the game code. 28 2 Basics of Game Development

The latter two will not be discussed here, because this thesis focusses on gameplay prototyping. A good source of information for the latter is [Rollings03, chap. 20]. Gameplay prototypes help to reﬁne, test, and structure game ideas, as well as software.

With them, developers deﬁne a rudimentary skeleton that can be referenced when entering game production. [Rollings03, pp.617–623] also call it a “preproject in- vestigation” and a “risk-reduction mechanism, allowing us to explore and evaluate simulated risks before we have to tackle them for real (when our money, and our development, is on the line) ”.

A game can be prototyped physically with almost anything that is capable of modelling the mechanics one wants to implement. This can be a simple set of toys, cards, dice, role-playing games or board games.

All game designers interviewed in section A.2 state the importance of using board games as an inspirational source. “Game design tools should speed the process of making a prototype that you can play”, game designer Bruce Shelley explains in subsection A.2.3, because playing prototypes helps to specify rules and features of a game.

One fact needs to be understood and [Rollings03, p. 618] clarify: Prototypes “are not, under any circumstances, to be used as a codebase for the game development itself”, because “they do not use the same development criteria as games”. While the latter need efﬁ- cient code and use most resources for speed, prototypes just display the idea of gameplay.

Thus, Rollings et. al. advise game de- Figure 2.12: Prototype of the game “Good velopers to use a different language Bugs, Bad Bugs”, produced in Squeak by or tool for programming the prototype students of the game design course at the than for the ﬁnal game [Rollings03]. Otto-von-Guericke University. Since most games are programmed in low-level languages like C or Assembly, a fresh approach would be to use a high- level language like SMALLTALK or even scripting languages like Lua, Python or Ruby. An example of using the Smalltalk programming environment Squeak for prototyping is shown in Figure 2.12. 2.4 Summary 29

All gameplay prototypes develop into more mature stages during game development. User interface prototypes also evolve constantly and are closest to gameplay prototypes, because the way a user interacts with a game is thoroughly responsible for the play experience she will feel [Pagulayan03, Nielsen05, Raskin00].

Interaction itself is the core of many games. Thus, interface prototypes evolve out of gameplay prototypes and the other way round, leaving room for creative and fresh ways of interacting with a game.

Summarising, the best solution for developing a game is to incrementally prototype for every development phase. Each phase needs prototypes, especially gameplay prototypes, because balancing gameplay is one the most important tasks in developing successful games. It is one of the essential selling points and the highest risk for publishers.

For both ﬁnancial and software-complexity issues, this should be done very early in and then continually during game development. One of the major advantages of a prototype is that it can be changed easily, and game programmers do not have to adapt the ﬁnal game, which is usually a complex structure. Keep in mind that there are different kinds of prototypes, but that the gameplay prototype the key player.

2.4 Summary

This chapter illustrated the stages of game development and outlined iterative development. The granularity for displaying the stages was rough, but we discussed all units in brief and the reader should know, there are more detailed descriptions of the development processes.

Also, Appendix B provides Figure B.2, which shows the complete game development pipeline. Most important for this thesis is the prototyping part, which was discussed in more detail in section 2.3. The different prototypes were sketched with a focus on gameplay.

This discussion leads to the next chapter, where we will talk about the tools common in game development, and the ones used for prototyping.

3 Game Development Tools

We shape our tools and then our tools shape us. We become what we behold.

(MARSHALL MCLUHAN)

The basic principles discussed in this chapter are the purpose of tools used in game development. A game engine is a collection of libraries that separates the game code from the hardware. The boundary between middleware and game engines is fuzzy. Thus, a game engine can utilise middleware and - depending on the scope of the project - also be seen as middleware for a game.

To fully discuss game engines it is necessary to include a discussion of both games middleware and associated tools. The transition from tools to middleware and on to complete game engines is not clearly deﬁned.

To clarify this, I will analyse these in terms of the level of programming involved. Different complexities of interface including scripting, modding, and programming are explained.

Consequently, game development tools are subdivided into different classes for clarifying respective areas of application. The ﬁnal section of this chapter shows future trends for game development.

In Appendix B, section B.5 shows which developer type uses what tools (according to CMP’s Game Career Guide [Sheerin04]). While many professional tools used for creating graphics, audio, and code have become standardised in their use over the years, an increasing amount of software is middleware.

3.1 More Than a Collection of Middleware: The Game Engine

Before one looks more closely at the parts of a game engine, game programming as a whole needs to be explained. Generally, three different areas of programming can be differentiated within game development [Llopis05]:

31 32 3 Game Development Tools

• General Game Programming Everything directly related to the game: Triggering animations, scripting the AI entities, displaying the score or health bar.

• Game Engine Programming Low-level programming with the main goal to build a layer of abstraction between hardware and game code. It provides core functionality that all games commonly need.

• Tools Programming Primarily developing tools for content creation. Those are often realised as plugins for the common tools used by designers and artists of the game. This can include developing custom middleware for a game.

A game is a large application, so this subdivision of programmers working on different levels of granularity is very important. This kind of granularity also applies to a game engine and blurs the border towards the real game code and other middleware.

A good engine can be partially build on middleware for graphics and sound, for example. Although, middleware for graphics is popular and has also many open- source projects attached to it, one needs to imagine an engine as software with an architecture, much like the structure of different prototypes discussed in section 2.3. Figure 3.1 outlines the elements of this software.

Core Game Engine e

Main Loop c Music & Sound n e

Audio g i

Engine l l e

Timer t n I

Output l a i

2d or 3d c i f

e Graphics i t r Engine Event r a r Handler A e w s d s r U c a i s H Input Controls User Interface y Ph n o dynamic i at l

Network Client Control game data u m i S e l r a a n o w t Software e e ti l

N Interface

di static dd d i game data A M

Figure 3.1: An overview of a game engine based on Masuch [Masuch05]. Simulation tasks like Physics or AI tend to be handled by middleware these days. 3.1 More Than a Collection of Middleware: The Game Engine 33

First, one can see there are two forms of interface with the user: The output she receives and the input she gives to the system. The user enters the input events with a hardware device that is listened to by a software controller system.

Controlling events come into the game engine via this hardware abstraction or via the network (for example, in a multiplayer game). The events are then sent to the game engine, which hands them over to the user interface. This also controls visual and auditory feedback from the engine to the player. These parts are smaller engines themselves: One of them being responsible for all types of audio processing and the other one being the graphics engine.

Usually the engine itself or some common libraries like DirectX take care of dealing with the hardware abstraction layer. The engine uses these libraries to access the underlying operating system efﬁciently for communicating with the user. A client controller unit handles all network events in the engine.

All units update and work with the main loop, where a timer and an event-handler control the game data, which is separated into static and dynamic types. The units should also have the possibility to integrate and communicate with other software or extra middleware through a façade layer.

More modules (like AI, collision detection or a physics engine) can be a part of the engine’s simulation system, or they are called externally. Here, the granularity comes into play again, as each subsystem is itself complex software and could be a collection of various middleware components.

The all-in-one approach that some game engines (especially commercial ones) follow is contrary to the partition into separate middleware components. This is because they are proprietary products, being used by a large development company that can afford spending workforce on extending these toolsets. An independent developer has the possibility to choose tools she thinks ﬁt best for the game type. The trade-off is that she will never have the leading AI, graphics or simulation engine.

One has to distinguish between separated game genres, which have distinct requirements for their speciﬁc engine. An example how different genres affect the graphics engine in a game engine is shown in Figure 3.2.

This not only affects the perspective from which one perceives the game world, but also the needs for micromanagement functionality, a physics system and artiﬁcial intelligence. Many of these factors have their origin in the ﬁrst gameplay prototype, and early prototyping in game design is making the choice for the tool-combination much easier. 34 3 Game Development Tools

Requirement-Specific Genre Specialisation of a Graphics Engine

Three-Dimensional (3D) Two-Dimensional (2D)

High-End 3D Graphics Regular 3D Graphics High-End 2D Graphics Low-End 2D Graphics

Figure 3.2: Different game genres have different requirements for graphics, which can be seen in this comparison of a high-end shooter on the left to a regular card game application on the right.

Granularity is the key to complex game creation. In the end, it is the success of the combination of independent units and their integration that is responsible for the success of the product as a whole. The design of a game development tool needs to take this observation into account.

3.2 General Deﬁnition of Middleware

Whether a game engine is a library that contains middleware or not, middleware itself is clearly a part of game programming these days. It has been around for a long time, and its description has always left a bit of room for interpretation of what can be described as middleware.

The term middleware describes a software layer that mediates between a set of various application layers. It is most often an abstraction layer between an application and the underlying operating system.

It was probably ﬁrst used in 1968 by computer analyst d’Agapeyeff in a conference about software engineering [Naur68]. Figure 3.3 illustrates his classic description of middleware and a modern view on middleware.

Modern middleware focusses on application integration and the use of standards like XML. Middleware game development focusses on building robust, integral, and expandable software that covers the most important areas of game functionality. Some essential areas of game development that utilise middleware are the following: 3.2 General Deﬁnition of Middleware 35

Game Application

Middleware

Other Applications (or Hardware)

(a) Middleware deﬁned by d’Agapeyeff (b) Middleware shown as an abstraction [Naur68] layer between other applications (or hardware) and the game application

Figure 3.3: Schematic views of middleware.

• Graphics Most popular game middleware are graphics engines, these range from low-level libraries like Direct3D to very elaborate object-oriented SDKs like OGRE. Many graphics engines can be used for free, but they are not professionally supported and sometimes less reliable than professional products. Graphics engines will always remain important components of a game engine.

• Physics Physics engines have become the second-most important components in games next to graphics. Where a decade ago the graphics system was what would sell the game, the graphics today are expected to be of photorealistic quality. The physics engines add another level of realism to the mix that is highly appreciated, especially among hardcore gamers.

• Artiﬁcial Intelligence A smart tactical AI is one of the key selling factors and rapidly gaining importance in game development. Especially the possibility to control AI with scripting behaviours is a feature that modern games need to offer.

• Networking Network functionality is often custom-programmed for a respective game. However, more advanced libraries that already offer a lot of functionality are becoming more popular.

• Audio Audio middleware is gaining importance, as features like surround sound are becoming the standard for video games. Popular audio middleware is the FMOD library and OpenAL - the audio equivalent of OpenGL, which are both open-source. 36 3 Game Development Tools

• Video For so-called “Cut-Scenes” that refer to pre-rendered video sequences played in a game after ﬁnishing a stage, the industry standard tools are Bink and Smacker, which allow for very smart high-quality video compression.

• Virtual Tree Generation SpeedTree is the classic story of a middleware being custom-developed for a special game requirement1 and then becoming an industry standard.

• Mobile Gaming Mobile gaming is still in its infancy, but already offers many challenges for developers. Good mobile gaming middleware will become more popular, as mobile game development grows in scope and complexity.

Middleware Graphics Audio Video Game ● OGR E ● F MOD ● Irrlicht ● Bink & S macker ● Miles (R AD Game Tools) ● (R AD Game Tools) Genesis 3D A ● S ensaura gameCODA ●

OpenGL s V ● ● OpenAL Direct3D s e e r t s

M i o a n n Artificial Intelligence

Networking Physics C Middleware a o g ● AI.implant ● ●

butterfly.net Havok n e ● ● ●

DirectIA S DK t Quazal ODE m ● ● r S imBionic Novodex o e ● Meqon l n ●

Ageia t Other

● S peedTree (Tree Generation Middleware) ● MAS S IV (MMOG Middleware) ● Mobile Gaming Middleware Another Application

(a) Different ﬂavours of middleware in game de- (b) Differentiation between middleware and as- velopment. set management applications.

Figure 3.4: Examples for middleware applications and the differentiation of middleware and production tools.

Subfigure 3.4(a) shows the most popular middleware applications for each area in game development. So, with all the specific areas of game development having their own middleware, a developer has to evaluate a tool for its usefulness for her specific game project. An interesting account of such an evaluation for using the middleware SpeedTree in the game SPELLFORCE 2 can be found in [Koch05].

It is also important to make a distinction between middleware applications, libraries, and production tools. The latter manage game ﬁles, and therefore have a close connection to the units of a game, but their functionality is not included in the game.

1 In this case, for generating a realistic nature environment, featuring the fast creation of many different trees. 3.2 General Deﬁnition of Middleware 37

They work on a more separate layer and organise the game code as well as the ﬁles that come from external applications. This process is outlined in Subﬁgure 3.4(b). Production tools will later be discussed in detail.

Overall, middleware is more and more used on game projects, because it has some obvious beneﬁts for developers.

• High-level abstraction Middleware allows developers to deﬁne the level of granularity they work on by ab- stracting low-level functionality.

• Interfaces allow for mixing custom middleware With common interfaces deﬁned between middleware applications and game engines, it becomes easier to integrate and combine custom tools for special game-speciﬁc requirements.

• Middleware speeds up game production With the growing number of middleware libraries, developers do not have to reinvent the wheel every time they start a project, and thus, development can be speed up. For next-generation game projects, a huge amount of complexity can be removed with middleware.

Nevertheless, not all tools are necessary for all areas. A pure multiplayer game has to worry less about artiﬁcial intelligence, so it is better to consider a good networking middleware solution and program the AI in-house. For every game, the requirements specify which middleware ﬁts best for the development tasks.

It is a question of resources and ambition, if a team learns to use one application over many game projects or starts over with programming own middleware and game engine libraries every time they want to create a new game2.

It has certainly been reasonable to program all the necessary tools and libraries that build the foundation for the game code in-house for the last decades. However, with growing project complexity, a good approach is to concentrate on making the game and using good, proven middleware as a foundation for this.

While most commercial game engines (or SDKs) like the Trinigy Vision SDK come with a set of tools for exchange or better integration of content into the game, the comprehensiveness of these sets differ.

2 A good example for this might be the following: Even though almost everybody is able to cook, or at least to ﬁx a meal, many people prefer eating in restaurants. This is because of the service and the low effort, compared with buying all the ingredients and ﬁxing the meal themselves. Much the same is true for middleware, which offers a certain service that takes tasks off the developers’ shoulders. 38 3 Game Development Tools

RenderWare Studio and Unreal Engine 3 offer a tools suite for sound, artiﬁcial intelligence, animation, networking, physics, and graphics.

Others prefer to underline their rendering engine, and include interfaces to industry standard applications covering the other areas. The following section will analyse game development suites and subdivide them into classes.

3.3 Game Development Suites

One commonly refers to game development suites as a complete package, including all tools necessary for producing a commercially successful game. Less complex tools are, however, more common in the non-professional game development sector.

Having talked about game engines and middleware in general, we will now look at

Game Development Suites

Professional Non-Professional

● Gamebryo ● Game Maker ● RenderWare Studio ● 3D Game Studio ● Unreal Engine 3 ● Reality Factory ● Trinigy Vision SDK ● Adventure Game Studio ● Visionaire ● RPG Maker XP

Multimedia Authoring Environments

● Macromedia Flash ● Macromedia Director

Figure 3.5: Professional and hobby game development suites, multimedia authoring environments. game tools, which include all of the aforementioned entities. In terms of granularity, these are the coarsest tools. Nevertheless, every tool collection can be broken down into its subparts, even though this feature is only required by professional developers. Non-professional users prefer easy-to-learn tools.

This makes simple toolsets common in the non-professional development area. Here, most people have little or no programming experience, but they want to ﬁnd a way to get started with creating games. For them, the process of visually creating a game with the use of simple scripts or assigning behaviours to objects is the preferred choice. 3.3 Game Development Suites 39

The previous chapter outlined that some of these suites (shown in Figure 3.5) make prototyping easy, because prototypes need to be altered quickly when new ideas are tested.

Consequently, the complex suites3 can be organised into three classes:

• Professional Development Suites This term refers to toolsets used in the industry to create commercial games. Most of these tools are the industry-standard for certain genre types and provide all kinds of libraries, plugins, and editing tools for developers, ranging from the programmer to the artist.

• Non-Professional Game Creation Tools These are game studio applications that make creating a game easy for less- experienced users. Often, they feature an easy-to-learn-and-master interface providing wizards and help for creating core game functionality.

• Multimedia Authoring Environments These tools are used by graphical designers for creating multimedia presentations, but are often complex enough to be utilised for creating games as well.

Figure B.1 gives an extra outline of asset management, middleware, and game development suites. The following list takes a representative tool from each class. Especially interesting are the ﬁrst two tools, Macromedia Flash 4 and Game Maker, because they are both used as prototyping tools in game projects, and they provide a good abstraction for non-professional, layman users.

3.3.1 Macromedia Flash

Macromedia Flash is very popular among web designers. It is broadly used for animations, sound, and video on the web, because of its very small vector ﬁle format. It combines the ease of use with an intuitive interface, a small output ﬁle format, and a scripting language that becomes more powerful with every new version of the program. The GUI of Flash and a game developed in Flash are shown in Figure 3.6.

The advantages of Flash are its easy-to-learn interface, the simplicity and yet extendibility of the scripting language “ActionScript”, and the possibility to render the content into a single executable ﬁle.

Its disadvantages include the lack of power to do graphically advanced games that need a lot of computing strength for complex graphics and AI. Flash games are

3 The word is here used to describe a game development toolset. 4 Often, Macromedia Director is equally used, but not discussed here in detail. 40 3 Game Development Tools

(a) The GUI of Macromedia Flash MX (b) The Game GIRLS INC.TEAMUP developed by Large Animal Games.

Figure 3.6: The Macromedia Flash MX interface and a screenshot of a casual game developed with it. always identiﬁable as Flash games, which is also due to the vector format used [Makar03].

Many mini games on the internet are created with the help of Flash, and the “cuteness” of the vector graphics add to their charm for casual gamers. An example of such a mini game is displayed in Subﬁgure 3.6(b).

More powerful, yet a little bit more complex than Macromedia Flash is the program Macromedia Director from the same company. It allows digital, multimedia, content authoring and has a much higher evolved scripting language. Some commercial games have been programmed completely in Macromedia Director, it has especially been used for casual games, where the focus is not on graphics but on gameplay.

3.3.2 Game Maker

Game Maker is an impressive educational game development tool (shown in Figure 3.7), which was written by Mark Overmars at Utrecht University in the Netherlands. Due to its ease of use and the fact that it is freeware, it has grown a huge, non-professional game development community.

Game Maker deﬁnes the game world by dividing it into one or more rooms that can contain objects. The objects are a representation for the entities in each game created with Game Maker. The rooms can have background graphics attached to them. Likewise objects can have a graphical sprite representation that changes when an event occurs. Sounds are also deﬁned separately and can be attached to behaviours in objects. 3.3 Game Development Suites 41

(a) Screenshot of Game Maker’s GUI. (b) A game developed in Game Maker.

Figure 3.7: The GUI of Game Maker and a game developed with it.

It also has its own scripting language called GML. It extends Game Maker with much functionality, especially for using advanced graphics features that should be hidden from less experienced users. Thus, GML provides a level of scalability for different users of Game Maker.

Yet more important are the interesting features of its interface. It lets one deﬁne behaviours quite easily and uses interesting syntax in terms of object-orientation. However, the functionality comes to its limits, when one wants to produce a complex game with advanced features, such as three-dimensional photorealistic real-time graphics or complex triggering mechanisms and real-time sound processing.

3.3.3 Vision SDK

The German company Trinigy offers industry proven middleware for developing games. A part of the game engine and a game currently in development with the Vision SDK are shown in Figure 3.8.

The game engine provides a set of tools called the Vision SDK. This toolset offers the granularity for professional game developers by providing tools for different developer types. One part is deﬁnitely the programming, which is done using the provided libraries and samples that the Vision SDK has to offer.

The artists on the other hand have many tools on their hands to edit a preview version of their models and shaders, directly in their favourite modelling tool5.

5 Using an in-game preview function that is offered for the industry standard tools Autodesk 3dsmax and Alias Maya. 42 3 Game Development Tools

(a) vEditXP is a scene creation tool that easily in- (b) DESPERADOS 2 is a game currently in devel- tegrates content created in other modelling pack- opment with Trinigy’s Vision SDK by Spellbound ages. Studios.

Figure 3.8: A tool from the Vision SDK and a screenshot of game that uses the game engine.

3.3.4 Important Aspects of Development Tools

Noel Llopis, a regular contributor of many programming articles in the Game Pro- gramming Gems series and the Game Developer Magazine, concisely sums up what programming languages are:

“You should always choose the right tool for the job, and a programming language is just that, a tool. Apart from a few physical limitations, you can almost get the job done with any language you want. However, if you choose the most appropriate language, the development will go much smoother and you will get done faster.” ([Llopis05b, p.183])

Thus, programming and scripting will be discussed in the following, as well as other ways to modify and create games.

Programming vs. Scripting Game development has proven to be rather complex in its scope. However, inexperienced developers always search for ways to get acquainted with the process of turning their idea into a game.

Programming languages tend to be static, harder to learn, and weakly typed. The latter means that they give the user much power by allowing her to declare an object type the way she thinks ﬁts best. This can cause compiler errors, but even worse, such wrong typing can remain hidden and cause a program to work incorrectly.

The dynamical approach of scripting languages6 is to allow more ﬂexibility by giving

6 And high-level programming languages. 3.3 Game Development Suites 43 a variety of programming layers. Most of them are strongly typed due to their architecture. The garbage collection takes care of wrong memory allocations, but might also cause performance to go down.

However, through their granularity, scripting languages are usable on many levels. The increase of hardware performance and the advantage of faster learning, when working on various layers of complexity, is a crucial advantage, which will cause scripting languages to be used mainly in the future. The better a scripting language is, the closer it can set its lowest layer to a low-level programming language.

Modding Games Most people have their ﬁrst encounter with game development in the form of making a modiﬁcation for their favourite game, and for this, not just modelling, texturing, and a sense of architecture are required.

To tell a story in this medium, interaction needs to be created, and that is most often done with the help of simple scripting languages like Lua, Tcl/Tk or Python in a modding tool, which are much easier to learn for novices compared to low-level programming languages.

This is a very popular way to start creating games for non-professional developers, because most games already ship with an editing tool, which allows altering its content. Nevertheless, this is only one way to generate new content and ideas for an existing game. Thus, it is not possible to generate a completely new game from scratch, because most of the innermost mechanics and the engine of a game cannot be altered.

Production Tools As stated before, the process of managing assets and keeping track of different version numbers is essential for an iterative workflow in game development. An asset management suite like NXN’s Alienbrain [NXN05] allows its users not only to check out new versions of files with a commentary, but also to work collaborative on the same files, and merge the changes later.

For eventual conflicts or to alert team members fast, there is an internal messaging function available in these systems. All in all, the control of files and the possibility to receive a most recent version of all files in one place (even if they were created around the globe) makes development more comfortable and for the project managers easier to monitor. 44 3 Game Development Tools

3.4 Deﬁning Classes for Game Development Tools

No classiﬁcation of game development toolsets is commonly known or has been published before, and because of the wide varieties among individual tools, this seems like a complicated effort. Nevertheless, this thesis will try to classify the different tools by qualities, to get a sketch of the peculiarities that separate professional from non-professional tools. It also helps to map the multimedia development suites to the pure game development tools.

First, the attributes with which this classiﬁcation is made for the different tools are discussed. Then, the attributes will be rated on their applicability within a toolset range.

Attributes of the Game Development Suites One can try to identify qualities of game development packages and use those to categorise the tools. Before the tools are classiﬁed in three groups depending on the people that use them most: professional, non-professional, or multimedia developers.

The following qualities present a cumulative overview over the most important features, without any claim for completeness. They were chosen with special regard to education, highlighting qualities that are common for software used in university courses.

• Effectiveness This term indicates the success in achieving a speciﬁed goal. It concerns only the ﬁnal outcome of a production, not involving any resources spent for accomplishing it. A development tool is effective, if it is capable of delivering professional results.

• Efficiency In contrast to effectiveness, efficiency describes producing results without redundant effort, minimizing wastage of resources. Efficient tools have low work overhead for users by defining clear interfaces to most necessary functions.

• Learning Curve The relation between work efficiency and user experience is described by the learning curve. The steeper a learning curve is, the more efficient a user will become in working with a tool, even after a short time-span. Gentle learning curves are not optimal, because they indicate that the program will also challenge experienced users. Ideally, a program should have a steeply falling learning curve, which means that it is fast to master. 3.4 Defining Classes for Game Development Tools 45

• Satisfactory Results The results produced by the development tools analysed here are computer games. Whether a computer game is satisfactory for the developer, is hard to grasp, depending largely on her ambitions and resources. Thus, evaluating this is very fuzzy and highly subjective.

• Scalability Educational tools need to hide complexity from inexperienced users, but should ideally allow more experienced users to modify core modules. Students tend to learn how to use a tool fast, which means that it is of major importance that a tool scales well for different demands of users.

• Creativity Creativity highlights the possibilities of a tool to aid in producing a wide variety of output. The less limits a tool puts on the developer, the more creative she can be. Good Prototypes demand for high-levels of creativity to play around with ideas and create innovative gameplay.

• Low-level Tuning This refers to scalability in a way. The less restricted and hidden the source code of a tool is and the better its documentation, the more possibilities there are for tuning low- level functionality. This provides means for optimising ﬁnal gameplay and is necessary for professional tools that aim at producing shrink-wrap software products.

• Quality of Graphics & Animation This links to satisfactory results of the ﬁnal game. The better the game graphics are and the more ﬂuent the animations work, the greater is the overall visual presentation. Humans process visual information best, so this is an important quality of games.

• Sound Capabilities Often neglected is the possibility for processing and altering the sound of a game. The more support a tool gives in creating, editing, mixing, and altering sounds, the more remarkable it is.

• Flexibility Flexible tools can be used for a many different tasks. They are generalised utilities, often accumulating special tools into a common environment.

• Extensibility The ability to extend to functionality of a tool becomes important, if requirements change. This links to ﬂexibility. Extensible tools always provide a high level of ﬂexi- bility. 46 3 Game Development Tools

Of course, this classiﬁcation only presents a subjective view on this topic. All of the classes are rated according to my own experience with the tools, additionally including the records and tests available in professional journals like Game De- veloper Magazine.

Table 3.1 presents the ratings for each of the aforementioned attributes. The ratings range from much agreement (⊕⊕) to no opinion or not enough experience ( ) to not ﬁnding this feature ( ) in the respective tool.

Using this knowledge will serve as a basis, when gathering requirements for an educational tool later, because even though these attributes classify game development suites, they also help in ﬁnding the best features of each tool.

QUALITIES CLASSES Professional Non-Professional Multimedia Environments Effectiveness ⊕⊕ ⊕ ⊕⊕ Efﬁciency ⊕⊕ ⊕ Learning Curve ⊕ ⊕ Satisfactory Re- ⊕⊕ ⊕ sults Scalability ⊕ Creativity ⊕ ⊕⊕ Low-level tuning ⊕⊕ Graphics & Anima- ⊕⊕ ⊕ tion Sound ⊕⊕ ⊕ ⊕ Flexibility ⊕⊕ ⊕ ⊕ Extensibility ⊕⊕

Table 3.1: Attributes of the different classes of game development suites.

3.5 Progress and Future Game Development Strategies

Game development at a professional level has reached a stage, where it is much too complex to adjust a recent title without a team of enthusiastic and skilled people [Shefﬁeld05]. Moreover, with the arrival of next generation consoles and multipro- cessor hardware, programming games becomes a huge venture, even for professional companies. Abstraction from hardware is an important trend that is widely followed in software development and will become more eminent in game development. 3.5 Progress and Future Game Development Strategies 47

While the abstraction from the original hardware makes code more portable among systems (since only the low-level interpreters need to be adjusted), it also costs performance. With games always being the most demanding applications on most computers, this is hardly appreciated by developers.

Nevertheless, when wanting to keep project complexities to a manageable size, one has to use this abstraction one time or the other. Although there will still be games that get the most out of hardware (and take either a long time or a big budget to develop), the tendency in programming is shifting towards better abstraction.

One of the major players here is Microsoft with its introduction of the C# programming language that follows the principles of Java, which already used a virtual machine and interpreted byte-code. The newer versions are also optimised for gaming SDKs like DirectX7 to speed up programming and keep complexity low.

As in one of the interviews in the subsection A.2.4, David A. Smith states that programming essentially is a translation task, and the easier the translation is, the faster the development will be. David A. Smith’s most recent project is the CROQUET tool, which also aims at a high abstraction of programming for three-dimensional and collaborative worlds. The systems runs in a virtual machine and is written completely in Squeak, a Smalltalk dialect.

Microsoft’s XNA (Xbox/DirectX New generation Architecture) is another interesting attempt to build a platform that combines different APIs for game development and creates a common framework for the Xbox console as well as the next-generation Windows. This technology has the potential to make the transportation of game from the PC to the console extremely easy. This will beneﬁt the Xbox, as most PC games created with XNA then could have the ability to run on the console as well.

Coming back to game development, the distinction between non-professional and professional game development will drift apart even more from now on. Creating small - so-called - puzzle and casual games has become more popular.

This means, the people, which have before tried to change professional games are searching for ways to easily put their idea into a game with the help of a tool that is not too complex, and yet, interesting and extensible enough to be used in bigger projects as well.

To make modding of big games more accessible for non-professional users, attempts are made to simplify game creation tools wherever possible. The Unreal Engine provides a good set of tools to do things in a visual way, which had to be done in code before.

7 DirectX is Microsoft’s graphics and game programming library. 48 3 Game Development Tools

(a) UnrealCascade, a visual particle system edi- (b) Unreal Kismet Visual Scripting Editor tor.

(e) UnrealEd Framework integrating the above tools

Figure 3.9: Unreal Engine 3 - Some of the editor components [Epic05]. 3.6 Summary 49

This is not only true for the visual scripting editor “Kismet”, but also for the animation tool “Matinee”. Almost all tools of this new engine put high focus on visual editing.

However, using the Unreal Engine will only bring out Unreal-Scenarios, fit for game requirements similar to those of the Unreal games, most likely first-person shooter games. This is what the engine was optimised for. Thus, it diminishes the flexibility of this tool towards creation of games from other genres.

The trend of the future clearly goes towards visual game creation (see Figure 3.9), just to make the tasks of programming more accessible for non-programmers that can later use the gained knowledge to work independently without the help of the wizards. This also aims at creative people, who have interesting ideas on program design, but have been kept away from the task, because of its complexity and the requirement of programming skills.

3.6 Summary

This chapter discussed the common development tools used for creating commercial games. First, the libraries that help in separating the game speciﬁc code from the hardware-abstraction code were introduced, leading to the deﬁnition of a game engine.

After looking a the general setup of a game engine, middleware applications and their main ﬁelds of use in games were highlighted, clearly stating the beneﬁts of middleware usage.

Game development toolsets were described as being the next level in granularity, using several middleware libraries and own game engines. Non-professional game tools and multimedia authoring environments were introduced with some prominent examples of each area. This lead to an explanation of attributes assigned to game development tools to help classifying them.

Finally, an outlook towards future game development strategies was given. The knowledge from chapter 2 and 3 builds the foundation to develop a concept for an educational prototyping tool in the next chapter.

4 Developing a Concept for an Educational Prototyping Tool

Whoever wants to understand much, must play much.

(GOTTFRIED BENN) In this chapter, the knowledge gained about the development process and the usability of certain tools and middleware in the previous chapter will be supplemented with an expedient analysis of the academic situation concerning teaching game development. Therefore, training available for aspiring game developers is classiﬁed and then described with some examples.

Even though the development community is often comparing our local situation here in Germany with the United States, the problem is globally extendible and not unique to a certain market or academic landscape. For developing an educational concept, the necessities of the games industry are addressed by analysing the four most prominent jobs in the development process.

Next up is a look at tools that are used within professional and academic game development, which ultimately leads to a concept for an educational tool that ﬁts in the game development pipeline at an early prototyping stage. Finally, further details of the architecture are discussed, giving the basis for the implementation discussed in the next chapter.

4.1 Game design vs. Game development

While still reﬁning a “critical language” for games [Costikyan02], developers use some terms that need to be deﬁned for someone not deeply familiar with game development. One of the most important distinctions has to be made between game design and game development. Game design is the “creative process of developing a game concept, its core elements and structure” [Masuch04b].

51 52 4 Developing a Concept for an Educational Prototyping Tool

[Rollings03b] additionally propose a “litmus test” for good game design by assuring the following aspects within a game: originality, coherency, interactivity, interest, and fun. Concentration on these aspects is an essential part of game design as well. Thus, game design builds a foundation for all further game development, which is described in [Masuch04b] as covering “game design, game programming and all other production related topics”.

A large portion of game development is the practical implementation - the programming part - and the creation of graphics, animation, music, and sound, while game design is a lot more concerned with the conceptual design and high-level composition of the game mechanisms and rules. Ideally, if the game design is very good, it makes development a more effective process [Rollings03b].

4.2 Adequate Education for Jobs in Game Development

Many people currently working in game development companies were never actually trained for their jobs. They have acquired their skills in other areas that are related to their professions in game development.

However, the professional situation is changing slowly as the industry matures. In the United States, there are now many schools and universities, offering education with a focus on computer game development.

They have faced similar challenges in setting up an adequate curriculum or game speciﬁc courses [Parberry05, Koelling96]. At “traditional” universities, this subject is difﬁcult to approach and the faculty is more biassed against it, while in private schools there is a lot of movement towards a professional education focused on games.

There are also schools with a focus on other areas that are using game development to teach their students interdisciplinary team-work and other skills [Yu02, Claypool05]. The emphasis usually lies on the aspects of game development that a department has specialised in, though other parts are also taught to give an insight into the game development process as a whole.

The Table 4.1 lists the different types of training institutions that provide training that can be used for developing games. Not all of them are solely focused on game production, but they all provide specialisation towards one area of game development.

First, one has to mention professional institutions that offer vocational training. The focus of education in these schools is tailored speciﬁcally for the needs of 4.2 Adequate Education for Jobs in Game Development 53

Type of School Teaching Emphasis Target Job Proﬁles Tools Used Professional Pri- Applications, Indus- ) Game Programmer Alias Maya vate Training try standard tools ) Game Artist/ Ani- Virtools School (e.g. Games and programming mator Nebula SDK Academy, DigiPen) languages ) Game/Level De- signer

University (e.g. Theory and concepts ) Game Designer Autodesk 3ds max Otto-von-Guericke behind games as ) Producer Squeak University, Uni- well as collaboration, ) Technical Director iEngine versity of North programming, and ) Project Manager Tweak Texas) project management CROQUET Shark 3d Java

Liberal Arts Fa- Classic art and de- ) Concept Artist Paint cility (e.g. Burg sign. Drawing, paint- ) 2d Artist Pencils Giebichenstein, ing, computer image ) 3d Artist Canvas New Jersey City manipulation ) Level designer (Adobe Photoshop) University)

Business School Project Management, ) Publishing Team Microsoft Ofﬁce (e.g. BITS) Leadership, ﬁnancial ) Producer Microsoft Project issues and game de- ) Management Entity-Relationship- sign ) Consulting Management

Writing School (e.g. Writing, narration, ) Storywriter Microsoft Ofﬁce Hochschule der story creation ) Dialogue Editor Final Draft Medien)

Table 4.1: Different types of game schools and their focusses the industry. The curricula are tight and result-driven, often with people from the industry being the teachers.

On the other hand, this special training is expensive (due to the high quality of the workspaces and the cost of professional personnel). Additionally, because the training is so speciﬁc, the certiﬁcate is only accepted in the target industry1.

A good example for a professional school with education solely focused on game development is the Games Academy in Berlin, Germany. Their curriculum includes courses in game programming, game art/animation and game design. The latter enforces a decision of the student after two semesters whether she wants to specialise in game art/animation or 3d programming.

1 In this case, the games industry 54 4 Developing a Concept for an Educational Prototyping Tool

The target job proﬁles are those of a game programmer, designer or artist in the German industry, with a strong focus on the tools taught at the academy. The course on game art and animation at the Games Academy can be seen in Subﬁg- ure 4.1(a).

A completely different approach to education in game development is what many universities offer. In contrast to the United States, there is no university degree “Bachelor (or Master) of Science in Game Development” at German universities. There are many institutes at universities already focussing on game development and offering a game-related focus as part of classic computer science for example. Therefore, the university courses are more centred towards the concepts and mech-

(a) A game art and animation course taught at (b) A game programming course taught at the the Games Academy Berlin. Otto-von-Guericke University Magdeburg.

Figure 4.1: Different education for future game developers at the Otto-von-Guericke University Magdeburg and the Games Academy Berlin. anisms behind games and the project-based management of their development. While other schools are certainly more practical, there is no equivalent of the theoretical analysis of games at universities.

An example of this is the Otto-von-Guericke-University of Magdeburg, where a special research group at the department of simulation and graphics teaches game development courses. These courses supplement the studies of computational visualists and computer scientists (Subﬁgure 4.1(b) shows a game programming course).

They offer a thorough specialisation in game development: A series of lectures ranging from an introductory course that teaches techniques of and reﬂection on games, to specialised courses that deepen students’ knowledge of real-time techniques and introduce them to game engine programming.

More information on the structure of these courses can be found in [Masuch04b]. 4.3 Teaching Focussed on Developer Tasks 55

The target job proﬁles are: Producer, game design lead or programming lead. These vocations are not the only possibilities for students, since the course also covers classic computer science, which opens doors to many other industries.

Another educational facility is the liberal arts college, which distinguishes itself from the aforementioned by concentrating on just one aspect of game development: Graphical Art. These colleges teach painting, drawing, graphics, and sometimes even communication and media design. Most of these schools not necessarily aim at the education of game artists, but this education allows the alumni to take any job that has to do with the creation of art2.

While they often make very good concept artists, their talent will also be appreciated as texture, interface or (depending on their knowledge) animation artists. An example of a German liberal arts college is the Burg Giebichenstein in Halle, which is centred around classical art, as well as research in virtual reality.

Other facilities, like business schools and writing schools, do not speciﬁcally educate game development, but offer courses that teach skills necessary for some development groups. Obviously, writing schools train storywriters, and business schools are geared towards the business side of game production.

Subsequently, business schools offer education concerned with game publishing. The focus is on leadership, project management, ﬁnancial planning and game production. An example of a German business school, focussing on game production, is the BITS in Iserlohn. Having discussed the higher education school types, let’s proceed to the real game projects and what types of developers have to handle what type of task.

4.3 Teaching Focussed on Developer Tasks

In chapter 2, the game development process was analysed and the different areas of development were shown. In [Bethke03], an overview of developer jobs is given with a rough division between design, programming, art, audio, management, quality assurance, and business, with the latter two not explicitly being part of the production, and often handled externally (e.g. by the publisher).

If we investigate the creation of a speciﬁc education for game developers, we have to consider the very different job proﬁles of the industry, each requiring a particular education. Four special developer types will be described in the following.

2 Seldom an artist focusses on sound creation and even though there are special schools for musical education, the education for sound engineers is more specialised in private schools allowing them to work in many industries. 56 4 Developing a Concept for an Educational Prototyping Tool

4.3.1 Game Designer

One of the most adored jobs is that of the game designer. But there are common misconceptions about what to find behind this terminology. As was pointed out before in section 4.1 the term is easily mixed up and hard to define. A possible definition could be: A visionary that knows the tools and has the skills to craft a game from an idea.

While game designers need to be highly creative, they also need to have a thorough understanding of mathematics, art, interactive storytelling, and the whole game production in general. Ideally, a lead game designer also adds team and project management skills to that.

Not all game designers specialise in the same things, some are more focussed on

(a) KATAMARI DAMACY has won the award (b) Keita Takahashi is the game for “Excellence in Game Design” at the 2005 designer of KATAMARI DAMACY. Game Developers Choice Awards.

Figure 4.2: The game with the best game design in 2005 was KATAMARI DAMACY, making his game designer Keita Takahashi popular over night. story creation, others prefer level/world building, while some only concentrate on the game mechanisms. The game design team, however, is at the heart of the game - without them, all other developers are not doing game development, but merely software or art creation.

The game designer has to do most work in the pre-production phase and during game balancing in full production. During all phases of production, she is critically involved when decision on gameplay issues are made. 4.3 Teaching Focussed on Developer Tasks 57

4.3.2 Producer

The producer is usually externally added to the development team by a publisher. She manages and coordinates the whole development process. Often, the producer acts as a gateway between the publisher and the developer.

She works very closely with the development leads, but is not part of the development team. While a project lead has to cope with crises within the team, the producer watches development from the outside, motivates the project lead and mediates between her and the publisher. Many areas of coordination, control and communication fall under the responsibility of a producer. She plans marketing, quality assurance, and localisation as well as budget-, time-, and resource-management, especially enforcing a good milestone policy. Her input is much needed in all phases of game development.

4.3.3 Game Programmers

If game designers are at the heart of a game project, then programmers are the blood that runs through it. With all the speciﬁcations and the advice from the game designers, the programmers ultimately turn a computer game into reality. Yet, the areas of programming are very diverse and cover almost all areas of classic computer science. The common programming areas were already described in section 3.1, but they can be reﬁned a bit more into these categories:

• Game Code Programmers ◦ Network Programmers ◦ Artiﬁcial Intelligence Programmers ◦ Graphics Programmers

• Game Engine Programmers ◦ Graphics Programmers (often low-level engine programmers)

• Tool Programmers

For example, a graphics programmer is concerned with putting vertex data through the rendering pipeline onto the screen. Thus, she comprises knowledge of algebra and geometry as well as image manipulation algorithms. She is a specialist for matrix operations and knows the qualities of normal computation. With the advent of the next generation of graphics cards, she also needs to have proﬁcient knowledge of shader programming.

Artiﬁcial intelligence programmers, on the other hand, need to put life into game objects, or develop elaborate collision concepts. They are skilled at developing 58 4 Developing a Concept for an Educational Prototyping Tool parsers for scripting languages used by level designers. The classic programmers are the tool programmers that create software applications, which allow to create and modify game levels. Depending on the development team size there might also be specialised programmers for audio, physics or networks. Programmers need to be able to abstract real systems into complex components.

4.3.4 Game Artists and Animators

In contrast to the programmers, are the artists that need to employ visual thinking and lots of creativity. Using the game designers’ concepts, they need to ﬁnd a visual representation for many ideas - giving the game world an individual look and feel.

While classic concept artists do a lot of the aforementioned traditional graphical artwork, 3d modellers take those concepts and craft a three dimensional computer model out of them. Some specialise in character modelling and texturing, thus contributing to the look of that model. Texture artists and other 2d artists need to have good painting and drawing skills and need to be able to create images with a professional software application.

Animators need to have a feeling for natural motion and to be able to recreate that by using keyframe or other forms of animation. Also, a popular trend at the moment is the use of motion capture. This allows to capture motions with special cameras and use the spatial data to animate computer models. Motion Capturing is a task that is often outsourced to external companies, because cleaning the data requires ﬁnesse in the use of special motion capturing software.

4.3.5 Conclusion for Education

Concluding, all those jobs in game development require a diverse range of skills from a variety of disciplines. A meaningful educational curriculum is a challenge to develop. While there have been attempts to formalise a curriculum ﬁtting university courses [IGDAEducation03], this research ﬁeld is still so young that it has troubles establishing itself as a formal academic discipline.

There are only a few research and teaching experiences to rely upon for reference [Yu02, McCallum04, Overmars04a, Masuch02]. It cannot be neglected, however, that especially for some rather theoretic areas of computer science, the entertainment value of games can invigorate subjects with a breadth of application possibilities. 4.3 Teaching Focussed on Developer Tasks 59

Accompanying this are largely highly motivated students, often producing better results and working more intensely on the subject [Claypool05]. With the games industry exponentially extending its market share every year, the need arises for a specialised education. Entertainment programs are today highly sophisticated systems relying on a complex architecture crafted by software experts (see Figure 3.1 for a detailed overview of the components of a game engine).

The past experiences mentioned above have shown a strong focus on two areas of application for teaching games:

• Teaching games for training professionals, who will work in the game industry The game industry matures and needs educated people to positively direct it into the future. Games are a global pervasive phenomenon that will become even bigger once the industry starts developing for niche markets, like games for elderly persons. The innovation and skill that young professionals from academia can bring into the industry will change its face forever.

• Using the motivational power of games as areas of application for traditional computer science subjects Classical computer science subjects have long yearned for interesting areas of application to increase their students’ interest and motivate them to research in these areas. Games provide the best motivation for learning computer sciences and often introduce children to computer technology and spark their interest to study this subject.

4.3.6 Advice from Professionals

Given that the game industry is continually changing, better educated personnel than academia produces these days is needed. Thus, more and better education needs to be developed and educated at universities and training schools. As aforementioned, the number of publications for teaching game development are only a few. Therefore, for developing further impressions on what would be necessary for teaching game development, some industry veterans were interviewed as part of this thesis. The transcripts of these interviews can be found in Appendix A.

As good advice, Mark Overmars points out in section A.1 that computer science can proﬁt from letting students design a game on their own. The focus should, of course, really be on the conceptual design and implementation, rather than the art creation. This way game design can serve as a means for students to learn object- oriented design and programming. The playful environment that games exhibit will enhance their interest in more abstract areas of computer science. 60 4 Developing a Concept for an Educational Prototyping Tool

David A. Smith also states in subsection A.2.4 that “code can often get in the

Figure 4.3: The Croquet project aims at developing a ﬂexible framework with that any user interface concept can easily be prototyped and deployed [SmithDA03]. way of a good idea” and he also works mainly on object-oriented programming for a collaborative, three-dimensional environment called Croquet [SmithDA03]. A screenshot of Croquet is shown in Figure 4.3. Here, he emphasises that programming “is a translation task”, which is made “far easier” by using objects. This resembles a software engineering approach that divides complex game systems into object components used by [Claypool05]. They created a course for computer science students that stresses the engineering perspective in game development. Like in [Masuch04b], there is a lot of emphasis on teamwork, coordination and management, which David A. Smith considers to be “the most important aspect of building computer games”.

Therefore, despite other speciﬁc approaches at academic facilities with particular training (be it in art or programming), all education of game development should have a focus on collaboration, object-orientation, and possibly game critique (the latter being pointed out by Jochen Hamma in subsection A.2.2). In the following section, we will look at game development tools employed by the different higher education schools. 4.4 Game Development Tools used to Facilitate Game Education 61

4.4 Game Development Tools used to Facilitate Game Education

Private academies have the advantage of being more ﬂexible in their curriculum, which can be altered quickly to ﬁt the changing needs of the industry. Universities are slower in changing established courses and shifting towards different tools than the ones established. For a list of professional tools refer to Table B.5 in section B.5. Some of these are also used in education.

Game designers often use board game prototypes to get started with a game. Bruce Shelley points out in subsection A.2.3 that “design by playing” is a key to good game design. Later, the students of the Games Academy, for example, count on a game creation environment called “Virtools” [DassaultSys05].

Liberal arts colleges rely not so much on software, but more on the practical application of their students’ skills using pencil, paint and canvas. If an art class teaches image processing software, then it is most often Adobes Photoshop or Illustrator3.

Business schools also do not focus completely on software, but expect their students to gain a sophisticated knowledge of all ofﬁce and project management software. Sometimes, they also utilise special ﬁnancial software, which is not quite as relevant to the games industry.

The major difﬁculty with professional game development software and programming languages is the initial skill adaptation training, because the link to the industry professionals is often not strong enough and the time needed for other theoretic subjects is lengthy. Still, there are a few students that spent more than a reasonable amount of time in learning the tools as well.

From the past experiences of [Masuch04b] and [Overmars04c], one can conclude that it is makes sense for introductory courses to emphasise the game development process as a whole rather than picking out a speciﬁc area. If the curriculum allows, then one can additionally add courses to game development education that focus on certain computer science aspects.

Software engineering is probably the closest discipline (and eventually spawns a new subdiscipline called “game engineering” [Claypool05]), but the focus on certain graphics aspects, such as real-time techniques, is also reasonable.

Since universities and private schools both aim at an education suitable for future game designers4, the tools to use for that are harder to deﬁne than e.g. programming or art. The knowledge of a game designer is more implicit, many facts of game 3 Both being the industry standard for game art as well, see [Sheerin04] 4 This, of course, means that they focus on educating game programmers or artists that have solid knowledge in game design and can later after years of experience try to get the job of a game designer. 62 4 Developing a Concept for an Educational Prototyping Tool development and the concept of gameplay needs to be understood rather than the mastery of a certain tool.

Game designers need good means to present a prototype of their idea. While this is possible with pen and paper, as well as on the computer, there is certainly a lack of good prototyping tools, Game Maker [Overmars04a] being the exception5. Comput- ers are preferred for prototyping in mature production when it comes to the design of the actual interaction (of the player and the game). This brings us to the concept of a game design prototyping tool for the use in education.

4.5 Towards an Educational Game Prototyping Tool

While there is absolutely no doubt that an university does not have the resources nor the capability to train fully educated game designers, this approach towards a game design prototyping tool is not aimed at teaching all that is necessary for game design. This would be impudent. It should rather provide computer literate students (that eventually become future game programmers) with an utility for capturing their game ideas quickly and presenting them to other people.

So, this thesis aims at supporting students interested in game development by adding a simple and easy-to-use tool to the development pipeline, which also allows students to deepen their knowledge on speciﬁc aspects of programming. Looking at Figure B.2, one can easily identify the prototyping cycle of a game designer during the conception phase of game development. It is recommended to produce a pen-and-paper prototype initially. Game designers have a “strong background in chess and various board games”, as Bob Bates states in subsection A.2.1.

Only after this first stage, the idea should be put into a computer, where with the help of a tool, a small two-dimensional prototype should be created. As Mark Overmars says in section A.1, “gameplay is completely two-dimensional”, even in most 3d first person shooters. So, by using this small utility, game designers can focus on creating gameplay, using simple 2d mock-up graphics for their level, figures and main character. Along with the ability to create an inspirational setting (a story and an interesting looking world), such a tool could help students to be more creative initially before starting to look at coding and algorithms for their game. In the following section, the basic requirements for such a tool will be discussed.

5 The Game Maker tool is used for much more than merely prototyping a game. It gives artists and non-professional developers possibilities to express themselves 4.5 Towards an Educational Game Prototyping Tool 63

4.5.1 Requirements Analysis for a Game Prototyping Tool

The preceding classiﬁcation of game development suites in section 3.4 can be used to identify requirements for a game creation utility6.Of course, not all requirements should be weighted with the same importance.

Since the application of the tool should be in education, the prerequisites are a bit different than those for non-professional or professional game development tools. One of the major goals is deﬁnitely that “using” the tool should be equivalent to “learning” about game development. So, factors like accessibility, scalability, and effectiveness have a bigger weight than efﬁciency or fast loading.

In addition to the classiﬁcation in section 3.4, a number of old and simple games that were so successful to spawn many clones over the years were analysed to get further insight into the core elements a basic game needs to feature. These “mini games” can be seen Figure 4.4. As follows, requirements for a game prototyping tool will be gathered based on these two prior investigations.

(a) A screenshot of PAC-MAN (b) TETRIS by Alexey Pajitnov (Ten- (c) PONG was one of the by Namco Limited (Midway) gen) is the classic puzzle game ﬁrst video games in his- on the ZXSpectrum (Screenshot of the Commodore 64 tory. version).

(d) 1942 by Capcom was a (e) The game BREAKOUT by Mid- (f) SPACE INVADERS by Taito vertically scrolling shooter. way (Midway) and its successor (Midway) was ported from ARKANOID by Taito (Imagine) were the Arcades to the Amiga huge arcade hits.

Figure 4.4: The different mini games that were analysed for ﬁnding necessary core game features.

6 One of the thesis goals is the creation of a game prototyping tool as stated in section 1.2 64 4 Developing a Concept for an Educational Prototyping Tool

® Core Game Elements For creating a structure for game creation, it is important to identify major elements of certain games. This was done by looking at “mini games” that are shown in Figure 4.4. In Appendix section B.4 the features of these games are outlined in Figure B.4. In particular, the games TETRIS,PAC-MAN, 1942, PONG,BREAK-OUT and SPACE INVADERS where analysed with special regards to the objects included in each game.

All games include three basic components (in different representations):

• Protagonist/Player Avatar Whether the player is represented as a block (TETRIS,PONG,BREAKOUT), an aeroplane (1942), a pizza (PAC-MAN), or a tank (SPACE INVADERS), there is always a graphical avatar giving visual feedback on the input actions. The most common form of controlling the player avatar is the keyboard or a joystick. • User Interface Most game objects have values attached to them, which can be altered during a game. The most important values are usually shown on the sur- face of the game screen, which is called the GUI of the game. Different forms of a game GUI are the shell interface before the start of a game, the in-game interface, which is present when playing the game, and lastly the transition screens like the “game over” or the loading screen. • Antagonists/Opponents In some games, the time is the only opponent (TETRIS), while in others the enemies are avatars controlled by the game AI or by other players.

This lead to the conclusion that all of these games consist of these objects and even different granularities of object classes are possible7. Thus, a collection of these different components should be available at the ﬁrst start of a prototyping tool to have a ready-to-use library of typical game components that can then be conﬁgured and individualised.

® Component structure The primary goal of this thesis is to build a component-based interface system that can be utilised for the education of game development. With the help of the system, it should be possible for non-professional users to understand the foundations of game creation. Thus, the system must be designed to be easily understandable. This means that a game can be “dragged and dropped”

7 For example, higher-level categories like classifying into in-game objects and interface objects. The in-game objects can be divided into player, graphical, and control objects (that either control hardware input or interface output). 4.5 Towards an Educational Game Prototyping Tool 65

together using own or preloaded graphics. An animation should be played on an event. An event should not need to be programmed in code, but simply be attached to a graphical object.

While the tool itself should be programmed using a component architecture, the game should be a “mix” of game components, each differing in functionality and scope. This also supports the understanding what a game is made up of. By individually deﬁning the components, students quickly get a hold of what components are important to create a functional game. It is also useful to facilitate the process for the teachers.

® Scalable Complexity A teaching tool should be less complex than the tools and development suites used in the games industry. As said before, this is due to the requirement to learn about important abilities rather than produce a perfect product. The motivation of having a game ready at the end is not so far above the ground but still enough for the students to take an interest in the subject matter. Less complexity in the ﬁnal product can also be an advantage if a course aims not so much about programming and algorithms, but rather at the understanding of game design.

By creating small games, students need to focus on the essence of gameplay and this helps them to intensely study game mechanics, which on the other side are most often just applied mathematical reason. Thus, an ideal educational game development tool should allow to put the focus on design aspects (by using a high-level interface), as well as to program and alter the code in the same environment.

Ideally, two views on the same core should be deﬁned:

• Professional View A professional should have the possibility to alter code and review the core mechanics of a game. • Non-Professional View Unnecessary complexity should be hidden from a non-professional, layman user, allowing her to tweak game functions through interfaces. Visual feedback on the user actions is also important.

Project length, similar to the complexity, is inherently much shorter for school or university courses than in a full-price development project. Thus, the creation of games should be possible in one semester or even in two months (which is the usual length for summer school projects). This time span is fea- sible for a study course that focusses not solely on games, but allows for a 66 4 Developing a Concept for an Educational Prototyping Tool

semester of intense training. If possible, all stages of game development should be passed to create a small game.

This utility aims at providing good means of prototyping for students and non- professional people interested in game design. Therefore, it is very necessary that the menus are easily accessible and most of the functions can be reached intuitively. Also the output of the program should focus solely on simple, interactive, 2d game prototypes, not including all functionality necessary to program a non-professional game.

Thus, it can also be featured in a game development course at an early design stage for gently introducing the students to the mechanics of a game. After having their prototypes ready, they can then start to work with code.

® Game Design and Object-Oriented Design Now, if the focus of an academic course is on game design8, then programming aspects should be simpliﬁed to a level, where a non-professional user can understand the essentials of object-oriented design. This, of course, implies that object-oriented design and game design resemble each other in certain aspects. Since both, game and software, should be made up of the components mentioned before, one should be able to learn about object-orientation through game creation. Game design can be used as a medium to raise a novices interest in programming.

When creating simple game prototypes, a tool should highlight that all games are complex systems made up of game objects. They exhibit a certain behaviour by specifying the attributes of these game objects. The behaviour connected with the user-interaction is the basic essence of any game, which should be observable and controllable in the tool. This can then be used to introduce further mechanisms of object-oriented design or even software engineering techniques to the students.

® Teamwork and Collaboration Another important requirement for a tool used in education is the collaboration aspect. Most regular development tools rely on third party vendors for the integration of communication and version control tools. It would be a great advantage if this functionality could be directly accessed from the tool, so that it can be used to brainstorm and sketch preliminary ideas as well in an integrated environment.

8 Game Design here is understood as the process of creating a game from initial concepts to a prototypical implementation 4.5 Towards an Educational Game Prototyping Tool 67

The collaborative nature of game development and the education of joint work is an obligation. Assigning tasks, meeting deadlines, exchanging ﬁles, communicating instantly and self-criticism are crucial skills not only needed in the games industry. It is also of great use if new users need support in using the tool and can get help this way.

It is of great use in bigger teams, if a fellow programmer can see who changed the code before or who has last used the system.

Many teamwork tasks can be facilitated by setting up a collaborative environment with version control systems, discussion boards and group chats. A tool, however, should either integrate nicely with those systems or allow the collaborative work on the assets used for the prototype.

® White Box Architecture A particular problem of many non-professional middleware applications is that they behave like a black box. While they often match many of the user’s con- ﬁguration needs, they unfortunately hide the low-level functionalities from the user so that the system can only be maintained by the original vendor.

This is certainly an important factor in the revenue-oriented professional industry, but it is bad for learning the structure of a system. The open source approach is better for education, because it allows opening and altering software within special limitations. For teaching algorithms, the system cannot be black box, but must be transparent for the students.

Students become more skilled in programming over time and want to understand the algorithms of a game rather than simply adding a collision detection by clicking. Middleware that allows students to change a system “on the ﬂy” and see the results immediately encourages the trial-and-error approach, which is popular for reﬁning complex systems. Ideally, the architecture of a tool should also allow writing extensions for it.

® Creativity Creativity was discussed in section 3.4 in detail. The better a tool can adapt to different forms of output, the more creative the user can be in creating a game. The less technical restrictions apply, the more variety the output will have.

While most creativity can certainly be put into paper prototypes, when it comes to prototyping with the computer, it is good to be able to concentrate on design aspects, rather than ﬁghting with code. An ideal rapid prototyping tool would support high-level programming and scripting languages, helping to understand game mechanisms. 68 4 Developing a Concept for an Educational Prototyping Tool

4.5.2 A Proposal for an Architecture of a Prototyping Tool

From the requirements analysed in the last section, basic traits of a software architecture for a prototyping tool are already obvious. Essentially, a tool needs to have a white box behaviour with its core architecture visible. Therefore, the game engine and its underlying system should be conﬁgurable down to its low-level architecture.

The problem with many proprietary tools is that they do not offer this level of customisation. Contrary to this are open source tools and engines widely available on the internet.

However, these tools often lack extensive documentation and most of the require thorough graphics and game programming skills that many students in university courses do not have. A good solution would be to use a high-level programming tool that includes multimedia capabilities9.

Besides the white box behaviour, customisable game objects should be the founda-

White Box

Core System

Game Engine

Programmer C Game Objects o l

View l a b o r a t i o

Non-Professional n View

Expandability Layer (Inheritance from Game Objects)

Figure 4.5: A high-level overview of the proposed architecture. tion of a prototyping tool. These game objects should closely relate to the analysed basic features of the mini games (see Figure B.4).

Ideally, prototyping should be done by professionals and non-professionals that work on the same code base. In reality, this is very difﬁcult, because the programmers usually have a more abstract view directly into the game code, while

9 Squeak would be an ideal choice for students, because it also enforces object-oriented programming. 4.6 Conclusion for the Implementation of a Prototyping Tool 69 most designers prefer to work in a visual environment. Thus, a prototyping tool needs to deﬁne multiple views on the same code base, so that both designer and programmers can work efﬁciently together.

This brings up another very important aspect: Collaboration. People that work together need to communicate and identify their shares of work to track the changes done among teams. An ideal collaborative environment needs the power to track and control users changes on the code base.

Last but not least, the architecture of an ideal prototyping tool should be ﬂexible enough to be extended and customised, which allows other programmers to add their own functionality to it. In an object-oriented system, this will not be major problems, because principles of inheritance apply and can be used to extend given classes with other functionalities, if a good interface is provided. An architectural sketch including all of the aforementioned is shown in Figure 4.5.

4.6 Conclusion for the Implementation of a Prototyping Tool

With the discussion of the preceding chapters about object-oriented design and the resemblance of this to game design, the choice of the development platform was made regarding the object-oriented languages available. Since “object orientation is the natural way of designing things” (Mark Overmars in section A.1), this leads to looking at educational programming environments used for teaching kids object- oriented programming [Guzdial02].

While other environments would have certainly been preferred by a game programmer, Squeak seems to be the less abstract and most high-level. This makes it ideal for high-level tasks like prototyping a game. Further details about this environment will be given in the next chapter.

From the preceding sections, we can mark the following essential features as the requirements for the prototyping tool, which will be implemented in the next chapter:

§ White Box For Game Engine and Objects The underlying architecture needs to be transparent, so that students can freely con- ﬁgure and extend the functionality. 70 4 Developing a Concept for an Educational Prototyping Tool

§ Scalable Complexity A good tool should be just as complex as the respective user needs it to be, therefore different views on the same code need to be provided.

§ Teamwork and Collaboration Many people work together in prototyping a game, so that a good tool can track and assign code to users.

§ Creativity Only few technical limitations should be set, so that creative freedom is given to the user.

§ Expandability Implied by the white box architecture, a prototyping tool should be easily extensible for altering it quickly to meet changing needs.

4.6.1 Summary

The look at the general education situation for developers with examples from the international academic landscape brought us towards an analysis of the different facilities and their respective target groups. Using the information about targeted job proﬁles for game developers, a closer look at the most important jobs was taken.

With the speciﬁc proﬁles in mind, academic courses, and the tools and mechanisms they teach were further investigated. This lead to the knowledge that game design is an essential skill for all development groups, especially for programmers and respectively computer scientists.

For the use within such an environment, a prototyping tool was sketched that can support the conceptual game design phase during game development (see Figure B.2). Lastly, the requirements for such a utility were gathered and serve as guidance for the prototypical implementation that is described in the next chapter. 5 Implementation of a Game Prototyping Tool

Technology is a word that describes something that doesn’t work yet.

(DOUGLAS ADAMS) In this chapter, we will take a closer look at game development with Smalltalk and Squeak; especially at the beneﬁts of those languages and development environments. It will introduce Squeak with a general outline of the history and the recent development, especially the improvements the impara GmbH1 is carrying out. Then, the focus is shifted on the iEngine2 and its games.

Next, we will discuss details about setting up the prototyping tool, called LeGaCy. The name of the tool is an acronym for “Lennart’s Game-Prototype Creation Util- ity”3. After a brief look at the architecture, the features are sketched out in detail. Subsequently, an example will highlight some of the characteristics of prototyping with Squeak. The focus is on understanding what prototypes are capable of, and why some features are not yet implemented. The conclusion then leads to the next chapter, where the the current work will be evaluated and discussed.

5.1 Game Development in Smalltalk

Many programming languages for developing games exist. Most developers prefer C, C++, or Assembly for reasons of speed, and especially mobile phones use Java for their code of choice. These languages are rather low-level languages that take intensive effort to learn and even more skill to use them efﬁciently.

Not all people in game development, especially not all game designers are familiar with programming at all. Thus, especially for level designers, high-level scripting

1 The impara GmbH is a German company involved in the development of Squeak. 2 The game engine developed at the impara GmbH is called the iEngine in the latter. 3 Thus, it combines the developer’s ﬁrst name with the intended purpose of use.

71 72 5 Implementation of a Game Prototyping Tool languages are the perfect choice. Even though they are less powerful, not necessarily object-oriented, and sometimes have to be extended by supplementary software (e.g. Dynamic Link Libraries (DLL) written in a low-level language). A possibility for people, who are not proﬁcient in programming, but want to learn, would be naturally a language used in the education of programming. This brings us to Squeak, an open-source Smalltalk system (which is explained in detail in subsection 5.2.1)

Squeak has been developed with the explicit goal in mind to teach children the basics of object-oriented programming. It includes an own scripting sys- tem4, and a whole set of multimedia tools that makes it attractive for playful exploration.

This playful learning and exploration of systems is what impara deﬁnes as one of the key visions of the company. The approach to combine entertain- Figure 5.1: Etoys is a high-level interface ment and education led to the develop- for scripting within Squeak. ment of a game engine for use within Squeak: the iEngine.

It is an experimental construction kit, which can serve as a meta tool for understanding and exploring objects, which are designed in code and as graphical representations. The game engine provides a white box architecture, where the hier- archies of the game objects and their behaviour can be explored and altered within the Squeak environment. This makes it ideal for use in the education of games. It will serve as a foundation for LeGaCy, because it provides a rich set of functionalities common in games.

Impara’s project Buccaneers, Inc. is so far the only larger game that builds on top of Squeak and the iEngine. However, it is not the only professional game title developed in Smalltalk. The Adventure Company has released a game called AURA:FATE OFTHE AGES in 2004, which was developed with Smalltalk MT5 and is shown in Figure 5.2.

4 Etoys is a scripting interface within Squeak (see Figure 5.1), which will not be discussed in detail here. For further information refer to [Guzdial01]. 5 The Smalltalk environment Smalltalk MT includes a hardware-optimised compiler for windows and abstraction layers of DirectX. It allows programmers to use Smalltalk with all the features known from Windows programming. The environment provides a graphical editor for Windows GUIs. Figure 5.2 shows Smalltalk MT as well as a screenshot of the game AURA. 5.2 The Development Environment 73

The game is an explorative adventure game from the ﬁrst person view, which resembles the popular adventure game MYST. The graphics are prerendered, there is not much animation happening and for a huge part of the game, the player has to solve click puzzles.

In conclusion, Smalltalk has not been vastly used in game development. Although many professional companies ﬂinch from using it due to the risk of losing speed6, for applications like prototyping and teaching game concepts, speed does not matter. This makes it attractive as a new and fresh testbed for game development in education. It is more important to get an insight into object-oriented design, which is certainly learned best by programming in Smalltalk.

5.2 The Development Environment

The beneﬁts of trying out Smalltalk as a programming language for educational game development are obvious. As said before, its open-source, virtual-machine, high-level architecture, and strict object-oriented design make it the primary choice.

However, it needs to be supported by a development environment that makes working with it comfortable. Enter Squeak, the open-source, multimedia, Smalltalk- development-environment that is supported by a very active, global community.

Its makers characterise Smalltalk, and consequently Squeak, as the truest language and environment to object-orientation available. With all this said about Squeak, we will look at the beneﬁts and details of this special programming environment.

5.2.1 Squeak

Squeak is a portable, open-source, object-oriented, multimedia development envi- ronment7 that stemmed from Smalltalk, which Adele Goldberg, Alan Kay, and their research group developed in the seventies at the Xerox Palo Alto Research Centre. Squeak is implemented in Smalltalk itself [Kay93].

It was in 1995 that Ingalls et. al. [Ingalls97] created Squeak at Apple Computers, with its ﬁrst release entering computing in 1996. Since then it has been further improved and expanded. It is used primarily in education to teach the principles of object-oriented programming and design to children. The alliance of a programming language with a graphical interface brings along a good number of tools for its own modiﬁcation.

6 A word-of-mouth recommendation for low-level languages has always negatively stigmatised high- level languages as being tremendously slow. However, the beneﬁts of understandable and structured code have to be weighted against the gain of speed. 7 It also uses a dialect of Smalltalk, so it is written in its own language. 74 5 Implementation of a Game Prototyping Tool

(a) Smalltalk MT is a Smalltalk environment and optimised compiler for the Microsoft Windows OS

(b) Aura is a “Myst”-like game developed by “The Adventure Company” in Smalltalk MT

Figure 5.2: Smalltalk MT and the Aura game that was created with it. 5.2 The Development Environment 75

More precisely, Squeak offers many beneﬁts “out of the box” that may be available for other programming languages as well, but not in a more complete set than in Squeak. Some of the reasons for using Squeak as an educational framework for game development are its following beneﬁts:

• High-Level Object-Orientation No other programming language consequently enforces object-oriented programming like Squeak. All expressions basically follow the same pattern of messageReceiver message, with all methods being triggered by messages.

• Multimedia Integration Squeak already supports lots media out of the box, providing interfaces for loading and altering media ﬁles.

• Community Support Squeak has a very active community, especially in Magdeburg, where impara (one of the key players in developing Squeak) and the research group computer games of the Otto-von-Guericke University focus on developments with Squeak. Thus, in a collaborative effort these people strive for spreading Squeak technology and are keen on helping developers.

• Open-Source White-Box Architecture Naturally, Squeak allow altering all its functionality, because of its transparent architecture, where all objects the system is made up of can be accessed and changed.

• Scalability The most important reason for choosing Squeak in education is its scalability. It naturally has built-in scripting interfaces (like Etoys seen in Figure 5.1) and provides different views on the code base. Also, the philosophy behind its new interface framework Tweak is to provide many abstraction layers, adjusting it to an even wider variety of user skills.

The whole user interface idea of Squeak and the use of windows were some of essential ideas behind Smalltalk8. The ideas were further extended by other companies and lead to the modern window interfaces that are common to most computer users today.

Also the idea of Squeak as being a “meta-medium” is becoming more popular on other systems. Squeak was one of the ﬁrst systems that brought along support for video, graphics, sound, and more, supporting all kinds of modern data formats.

8 Alan Kay, who invented the term object-oriented programming always wanted the computer to be more than it was for most people. His idea of the “Dynabook” was one of the forerunners of today’s computer notebooks. 76 5 Implementation of a Game Prototyping Tool

One of the central ideas behind Squeak are also giving different perspectives on the

(a) The old MVC interface in Squeak (b) Some graphical morphs in Squeak’s Morphic environment

Figure 5.3: The two GUI environments used in Squeak before the invention of Tweak. same data. This idea bases on a common design pattern called MVC9 [Gamma95]. The first graphic interface in Squeak was a simple MVC interface, which can be seen in Subfigure 5.3(a). It was soon replaced with a different framework called Morphic (shown in Subfigure 5.3(b)) that was easier to use. It is necessary to give a quick overview over those two GUI frameworks to better understand the benefits of the new framework Tweak.

® Model-View-Controller This is an architectural pattern, which separates a program into a model (representing the data), a presentation (of the data) and a controller (handling the logic and managing the data). Usually the view and the controller interact with the model, which means other controllers and views can use the same model as well. A controller can also control the output of several views.

This idea is popular especially for producing graphical user interfaces, because it keeps the system ﬂexible. It also makes extending the program more manageable, because code changes only have an effect on one location, e.g. in only the category, where the new interface is build on top the basic classes. So, once the core is established, all other changes only affect the local bits of code that utilise the model.

MVC was originally developed by Trygve Reenskaug, who also worked at the Palo Alto Research Centre with Alan Kay, for interfaces in Smalltalk in 1979. Inspired by this approach were the Swing framework in Sun’s Java and the Microsoft Foundation Classes. A screenshot of the MVC can be seen in Sub- ﬁgure 5.3(a).

9 This is short for Model-View-Controller. The model represents the data, the view visualises the data and the controller evaluates input from external devices. 5.2 The Development Environment 77

® Morphic Morphic is the recent GUI framework in Squeak and the successor of MVC. Thus, it was developed as part of the programming language Self, but soon became a part of Squeak [Maloney00]. The intention of its programmers was to simplify building user interfaces. It has one base class called Morph, which all other graphics classes in Morphic derive from. These Morphs can be ani- mated with a built-in stepping mechanism. An overview of the representations of Morphs within Squeak can be seen in Subﬁgure 5.3(b). A more detailed descriptions of these mechanism and Morphic itself can be found in [Maloney00] and [Guzdial01].

[Gadegast05, pp.18–19] discusses the current difﬁculties that new users of Morphic are facing. Removing current obstructions from Morphic to create a new and clean interface package was the original motivation to build a new framework, called Tweak. It will substitute the older frameworks used in Squeak in the future.

5.2.2 Tweak

Andreas Raab developed Tweak in 2001 and it is now being co-developed by his company impara to replace the older user interface frameworks in Squeak. The Tweak Core Architecture Release (TCAR)10 includes the following features:

• Tweak Compiler A separate compiler to support important aspects of Tweak, like the support for “ﬁelds”.

• Asynchronous Event Architecture If a script is started, it runs until it is ﬁnished. Running processes cannot be halted externally, but events can trigger scripts. This is a crucial feature, making Tweak more ﬂexible than its predecessors MVC and Morphic.

• Players and Costumes This is a concept much too complex to be explained here in detail. The graphical objects exist in dual representation by a Player11 and by a Costume12, which is a Player as well. A Player is an abstract object type that can direct Costumes, while Costumes notify Players of events. For internal details about these aspects, consult [Gadegast05, pp. 21–22].

10 All of the information is based on the release notes of the Tweak-1.2 release. 11 A player distantly resembles a model object in the MVC architecture 12 A Costume is the vague equivalent of a MVC view object 78 5 Implementation of a Game Prototyping Tool

• Fields Fields deﬁne variables that feature a certain event behaviour. Whenever the value of a variable is changed, an event is generated, to which can be listened by other objects.

• Widgets Several widgets are already available for use in programming a graphical interface for Tweak. These core libraries are not complete, but growing rapidly in functionality and providing a good basic toolset that one can work with.

• Authoring Environment The Tweak Project Builder is intended to become the authoring environment of Tweak, while at the moment it provides a collection of the tools available within Tweak.

The main features of Tweak are the asynchronous event architecture (probably being the key feature) and the concept of separating players and costumes, which both make it a very ﬂexible system. Changes of code have only a local effect (similar to the MVC pattern). Fields in Tweak can be regular or virtual types, the regular types just contain data values, while the virtual types are implemented as methods that allow setting and getting a value.

Tweak implements more and more Squeak tools and functionalities. Yet, some tools

Figure 5.4: The outline of the mixed Squeak-Tweak work environment that was used for programming LeGaCy. lack functionality at the moment. One of them is the system browser, which is 5.2 The Development Environment 79 easier to handle outside Tweak. It can be used to conﬁgure the classes of Tweak (as Squeak is open-source, with all code available at run-time, allowing adjusting almost anything inside it). A mix of Squeak and Tweak tools was also used for programming LeGaCy as is shown in Figure 5.4.

In conclusion, the philosophy of the new framework Tweak is very helpful for students that want to learn about object-orientation and ﬁnd out how encapsulated code works collaboratively. Many examples are already included with Tweak and its architecture is so sound that it will soon be mature enough to replace the older user interface frameworks of Squeak.

5.2.3 The iEngine

In addition to developing the Tweak framework, impara also has the objective to make Squeak a game programming environment. Development of the iEngine, which can be classiﬁed as a game engine13, was co-developed by Michael Rüger (who is the lead software architect at impara) almost a decade ago. It was put to new use as part of a collaborative project between the University of Magdeburg (the computer science department), the University of Applied Sci- ences Magdeburg-Stendal (the design and engineering departments) and the company impara. Figure 5.5: Setting up The large project was called “Virtual Physics” and was the project Pirates. aimed at the development of innovative user interfaces around a multiplayer game with a pirates theme [Masuch04]. Figure 5.5 shows the setup of the pirate environment for a public presentation. Following this project was a game called Steamer Battle, which was a technology showcase of the multiplayer and AI capabilities of the iEngine. As a proof-of-concept for the game engine, showing all that is possible in Squeak game programming, impara started developing the game Buccaneers, Inc., which can be seen in Fig- ure 5.6.

Developing a game in Smalltalk was a challenge for the professionals, but the process of developing a few prototypes before that helped in reﬁning common game functions and make additions to the iEngine. In the end, the ﬁnal game was running without much delay on a high-end computer14, proving that through many

13 The iEngine is a middleware library providing functionality of rendering, collision-detection, networking, basic artiﬁcial intelligence, and much more core game functionality. Therefore it is a game engine. 14 An additional browser plugin allows it to be started within a web-browser, where it runs with 80 5 Implementation of a Game Prototyping Tool

(a) Ships ﬁghting against each other. The dam- (b) Ports are service stations where ships can be age is shown in the ships. The hand is used to upgraded and repaired. navigate the ships.

Figure 5.6: Buccaneers, Inc. is a game demo developed by impara to show what is possible in terms of game development in Squeak with the iEngine. low-level optimisations a game can be made with Squeak.

Many of the employees later said that they particularly enjoyed the easy collaboration within Squeak through the inner code version control mechanisms that Squeak supplies (MONTICELLO being an example). So, besides providing all the benefits of the Squeak programming environment, the iEngine adds the following essential core functionalities commonly needed in most games: • AI While AI is programmed for each game individually, a common problem like path-finding needs to belong to an engine’s functionality. The A* algorithm is such a pathfinding algorithm that is part of the AI library within the iEngine. An AI emotion system was developed as part of a master’s thesis [Schuster04].

• Physics Basic physical functionality is available as part of the game engine, from which most is custom ﬁt for the game Buccaneers, Inc.

• Network Network support includes opening connections to other computers and providing wrappers to common network calls. Thus, the iEngine comes with basic libraries for common network functions, also supporting multiplayer settings.

• Collision Detection When two objects collide, an event is generated either to alter values belonging to game objects or trigger certain highscore counters.

almost 30 frames per second. 5.3 LeGaCy - A Tool for Rapid Game Prototyping 81

• Graphical Asset Animation Game objects are usually represented by graphics on a display. These objects can be three-dimensional models or two-dimensional sprite graphics. The engine supports loading and animating two-dimensional graphics from the most common image ﬁle formats.

• Rendering 1 The iEngine includes a 2 2 d graphics engine, which basically means that the inner calculations within the game world are done with three dimensions, while the rendered display is only in 2d.

Every Game class has GameScreen class, which has a method createRenderer, where the renderer can be chosen. The choice of the rendering output allows the engine to create different views on the game world.

This rendering mechanism, which earlier used the Morphic interface, was ported to Tweak in [Gadegast05]. Therefore, the iEngine proﬁts from Tweak already.

• Sound Just like graphics, sounds are imported as media assets into the game to triggered by an event.

5.3 LeGaCy - A Tool for Rapid Game Prototyping

In subsection 4.5.2, an architecture for an educational game prototyping tool was proposed, consequently highlighting the most important requirements for such a tool. Through discussing the abilities of Squeak in this chapter, it is obvious that many requirements for a special use in education are already fulﬁlled by it. However, remembering the conclusions of section 4.6 leads to pointing out the necessary features that are part of LeGaCy.

• Scalability The deﬁnition of different views on the same codebase allows programmers to utilise the LeGaCy library as well as non-professional users to work with its graphical user interface to create a game prototype. The graphical level-view of LeGaCy allows students to be more creative and easily make the transition from conceptual to programmable prototyping within Squeak. This concept will be discussed in detail in the next subsection. 82 5 Implementation of a Game Prototyping Tool

• Collaboration Working on the same code is made possible by utilising Squeak’s version control tool Monticello, which is integrated in LeGaCy. Also the programmer control of the system browser allows programmers working on the same Squeak image to track changes of others. The prototypes are saved in the XML ﬁle format, which can be exported to other applications with ease. The format can also be read and altered by a programmer outside of Squeak.

• Game Objects The different objects of the game world are divided into different categories, each representing their functionality. New objects can be added through the programming environment. For teaching game design and object-oriented design, this approach is especially important. The open nature of Squeak also allows students to research how the game objects are implemented and use these as templates for deﬁning their own game objects.

• Core Game Engine Functions All iEngine functions can be accessed and implemented as being part of the game object concept15. Therefore it helps new programmers to get to know basic iEngine functionality.

Subsequently, the approaches towards LeGaCy from a non-professional user perspective and from a programmer perspective will be elaborated, which will lead to an example showing detailed prototype-building from a non-professional perspective.

5.3.1 User Interfaces in LeGaCy

Non-professional users base their ﬁrst impressions of software upon whether they ﬁnd the user interface pleasant to use or not. So, thinking about essentially providing different interfaces for different users makes sense from a developer’s perspective. This is a principle that Game Maker also uses for hiding complexity16.

LeGaCy was designed to be used primarily by non-professional users, but with the possibility to let the user switch to more advanced options once she is confident enough with the environment. Figure 5.7 shows the two significantly different ways of working with LeGaCy. While Subfigure 5.7(b) shows the regular programming tools of Squeak (Class Browser and Monticello), non-professional users are presented an in-level view of the game world in Subfigure 5.7(a).

This latter view in LeGaCy represents a game-focussed view known from many game

15 This prevents programmers from constantly reinventing the wheel by speciﬁcally taking advantage of game engine methods provided by the iEngine. 16 Complex functions are only available through the tools scripting language GML. Simple functions are directly available from the GUI. 5.3 LeGaCy - A Tool for Rapid Game Prototyping 83

(a) Screenshot of the inGame Level Editing View (b) Screenshot of the programming view in of LeGaCy LeGaCy, allowing for access of the system browser and the versioning tool Monticello.

Figure 5.7: LeGaCy’s different views on the code base: A programmer view and a level- design view. editors used for generating mods (e.g. UnrealEd shown in Figure 3.9). Here, the user can browse graphical game objects and place them inside a level.

A preconﬁgured set of tiles represents the view on the level. A level itself is a grid of tiles stretching to set dimensions. The grid assigns game objects to the columns and rows. This way, the tool allows creating multiple instances. Every instance becomes a part of the grid.

More importantly, an in-game view supports the “suspension of disbelief” to which many players commit, when playing games [Rollings03]. Thus, it makes the transition from being a player to being a developer easier for non-professional users.

The programmer view of LeGaCy represents a look inside the code of the tool and its classes. Once users of LeGaCy start becoming more interested in changing the tool and its functionality, they can alter all classes of the tool in real-time. Missing functionality can be added or possible occurring defects can be repaired immediately.

This architecture is the main advantage of Squeak, and consequently of LeGaCy, smoothing the transition from scripting towards programming. While many objects can be explored in the in-game view within LeGaCy, the core functionality can be changed with the same ease as it would only be possible by regular scripting languages.

The crucial difference to programming environments with a compile-run cycle is that Squeak runs in a virtual machine already, and therefore no compilation is re- 84 5 Implementation of a Game Prototyping Tool quired. The effect of the changes that are made, can be seen instantly, which is a beneﬁt for non-professional users wanting to learn about programming by using a cause-and-effect cycle to get to know functions.

The transition from scripting and programming in the environment is smooth. Thus, it makes the tool attractive for users with a variety of different skills. Students of game development courses at an university are the typical example for such users. In conclusion, LeGaCy is optimised for this target group by taking into account that only scalability can provide satisfactory interfaces for different user-types.

5.3.2 The Features of LeGaCy

LeGaCy’s main objective is to provide easy-to-use game functions for non- professional users. Thus, next we will highlight some basic steps in using LeGaCy. Before a regular game project starts, the assets17 need to be loaded. This process is shown in Figure 5.8. Assets are distinguished into different types by the names of the files from the start. An identifier is used to assign asset files to objects. LeGaCy differentiates between the following game object types:

• Background Background objects are non-active, solid game objects serving only to put different graphics tiles into a game level. The identiﬁer of background assets is bg-.

• Prop Props are functional game items that either have inﬂuence to game characters or simply serve to populate the game world. A prop object can contain parameters, triggers and collision information. The identiﬁer of prop-assets is prop-.

• Player The avatar of the player represents her in the game world. It is usually the only character that is controlled in the game world. A player object can contain several parameters, collision information, triggers, and usually listens to a control interface. The identiﬁer of player assets is player-.

• Enemy Enemy characters are computer-controlled antagonists in a game. These characters commonly have the objective to hinder or eradicate the player. Enemy objects contain the same as player objects except they have no control interface towards the hardware but towards an AI. The identiﬁer of enemy assets is enem-.

By identifying game assets as belonging to one of these object types, they are stored in a list, where they can be accessed in the in-level view (the playground) of LeGaCy.

17 These are all media ﬁles that will be used in a game prototype. 5.3 LeGaCy - A Tool for Rapid Game Prototyping 85

(a) A menu in LeGaCy offers access to most functions.

(b) Selecting the Assets option to update the asset collection before the start. This step is necessary to make sure the newest assets are loaded into the iEngine.

(c) The program updates its internal assets library. The assets within a speciﬁed folder “ASSETS” are now ready to be used.

Figure 5.8: The mechanism of updating the assets within LeGaCy.

First, one needs to select the desired type of asset from a drop-down list. The left item list will then update the view to display the graphical objects belonging to this category. 86 5 Implementation of a Game Prototyping Tool

(a) The non-professional view is called the “Play- (b) This “playground” presents a default view of ground” and can be opened from the main a game level that can be used as a template for menu. new levels.

Figure 5.9: Accessing the game objects in LeGaCy. 5.3 LeGaCy - A Tool for Rapid Game Prototyping 87

Selecting one of these objects updates the brush18 to the graphical representation of the respective object. Now, the object can be painted onto a tile in the game world. The game object is placed at the position of the tile within the game world grid. Through the grid architecture of the game world, the exact place of the object within the grid can be stored into an XML ﬁle.

Figure 5.9 gives an overview of the process of selecting a game object category. Ideally, all objects of a category should have the same dimension, so that they ﬁt exactly on one place in the game world tiles. However, the iEngine also allows different dimensions of game objects to be painted inside the game world.

Besides the functionality provided by the playground in LeGaCy, it is also necessary to take a look at the library that is the essence of LeGaCy. A major part of the code is, of course, the interface, but the essential functions for games are implemented in the game objects that exist as classes inside LeGaCy.

The UML diagram in Figure 5.10 shows the interaction of the classes in LeGaCy. Note that the objects for the different LeGaCy game objects all inherit from a super object called GraphicalGameObject. This is provided by the engine as the template object for graphical objects in the game. Nevertheless, GraphicalGameObject also has a super object called GameObject, which provides even more basic functionality. A look into these objects will help to ﬁnd out about the core features that the iEngine provides.

The default collection of game objects in LeGaCy is merely a suggestion, because prototyping for other game genres might result in needing different game objects. The inheritance structure of the object-oriented code allows for implementing those additionally.

18 A yellow square represent the brush in the game world. 88 5 Implementation of a Game Prototyping Tool

Figure 5.10: UML view of the LeGaCy components. 5.4 A Game Prototyping Example 89

5.4 A Game Prototyping Example

In this section, we will demonstrate the single steps that a user goes through in developing a gameplay prototype. Therefore, a game idea is sketched out subsequently. Next, a demonstration shows the steps from the idea to the ﬁrst prototype within LeGaCy.

5.4.1 The Game Idea

Video games seldom appeal to women. While there is already some research being made in this direction [GranerRay04], and some games do have a certain fascina- tion to women (like THE SIMS), this problem is as old as video games themselves. Presuming that one comes into the situation of being a game designer, who is searching for ways to make games appeal to a female audience, the game idea developed here will be a tribute to one of the ﬁrst games that came to explore this market: PAC-MAN.

PAC-MAN is a game, where the main character has the form of a pizza and is chased by several enemies (all displayed as ghosts) while eating little white dots19 As a homage to one of the most original ideas in gameplay, the game prototype will be a little PAC-MAN game.

A pizza will serve as the main character of the game. But since graphics are more evolved today than they were in the times of PAC-MAN not just a yellow circle will sufﬁce. A pizza, a delivery boy, a maﬁa guy, and a chef (all shown in Figure 5.11)were created by a fellow designer to have some meaningful initial characters for a game. Figure 5.11: For the setting, props would be represented in the form of pizza The characters toppings and the background is a green texture representing for the game some kind of salad. With this initial setting in mind, a game de- prototype. signer can start LeGaCy and begin creating a game.

19 When most of the people knew little about gaming and companies were trying to develop new market strategies, game designer Toru Iwatani found himself facing the same problem [Lammers90]. His company Namco assigned him the task of developing a game that everybody would like to play. His researches included listening to conversations of women, especially in small diners. Then it came to him: Food would be a topic that both genders are discussing much. Since he liked pizza much, the idea for PAC-MAN was born. 90 5 Implementation of a Game Prototyping Tool

(a) First, the “Playground” (b) A background object is se- (c) Through placing these view is started within in lected and the brush changes solid objects into the level, a LeGaCy. to represent the selected ob- basic maze is created, which ject from the game item list. will later become a labyrinth for PAC-MAN.

(d) After placing numerous background tiles on (e) The properties are drawn into the game world the game map, the properties are selected in the the same way as the background objects. The game items list. brush places the props inside the level.

(f) Next, the antagonist type characters (called (g) Finally, the player avatar is placed inside the enemy objects) are selected from the game item game level. list and put inside the grid of the level.

Figure 5.12: Making a game prototype level in LeGaCy. 5.5 Summary 91

5.4.2 Demonstration

Figure 5.12 shows a step-by-step procedure of rapidly developing a game prototype with LeGaCy. After the two-dimensional game graphics are drawn and renamed following the convention explained in the last subsection, they are loaded into their appropriate categories in LeGaCy (shown in Figure 5.8). Then, one can easily click together a level with those objects.

Each game object comes with a default behaviour that can be adjusted by simply inspecting it. A progress done in Squeak by middle-clicking on an object. A ﬂap that triggers the game state between editing and playing lets one playtest if all settings work correctly. After the game has been set up, the level information can be saved in an XML ﬁle as stated before.

The ﬁle format was chosen because it is easily editable and a parser for these doc- uments exists inside Squeak already. In conclusion, the process from getting an idea to sketching it out on paper or with the help of LeGaCy takes almost the same amount of time. Thus, LeGaCy really is designed to allow non-professional users to prototype initial game ideas in a fast fashion.

5.5 Summary

In this chapter, the benefits of developing games in an educational environment with Smalltalk, especially with Squeak were highlighted. In particular, the advantages of the design principles behind the frameworks of Tweak and the iEngine were pointed out. Following this was an intense overview of the implemented features of LeGaCy, which fulfils the basic needs for rapidly prototyping a game within Squeak and with the help of the iEngine. Specifically the two different views on the same codebase were mentioned. Last, an example of a rapidly developed prototype with LeGaCy was given.

6 Summary and Conclusion

We’ve just ﬁnished that, but we can make it better!

(SHIGERU MIYAMOTO)

This chapter summarises the results of the research carried out in this thesis. It discusses and reviews the tools, approaches, and ideas behind this thesis. This includes a detailed review of using Squeak for game development, and some ideas and prospects of possible applications for LeGaCy in the future. The next section provides personal remarks of the author, before the last section concludes the work of this thesis.

6.1 Results of This Research

A thorough analysis of the game development process, which was elucidated in chapter 2 as a tier-based and iterative process, was the point of origin for all further argumentation in this thesis. There are many stages from the idea to the release, and on each stage, multiple, interdisciplinary layers collaborate and exchange ideas between one another.

During this process, prototypes can evolve parallel to game production, serving as a testbed for new ideas or techniques, which might be completely eradicated at the end of development phase. Also prototypes can serve as a core that is reﬁned and specialised further during all phases of development, ultimately leading to a ﬁn- ished game. Iteration cycles and milestones provide solid means for management to control the results of developers and constantly improves the quality of games in production.

While section 2.3 showed us that there are various prototypes that make up game architectures, the most important prototype for computer games remains the gameplay prototype, because it deals with the most essential part of games, the gameplay experience. It is important to keep in mind that good prototypes are not necessarily connected to lean software.

93 94 6 Summary and Conclusion

Optimisation is not the key element for prototyping and thus, the separation of a prototyping program and a game program is crucial. The computer is only one of the tools suitable for creating gameplay prototypes.

• Educational Game Development Needs Accessible and Scalable Tools Many tools discussed in chapter 3 were too complex to learn within a typical time-frame for academic courses (which usually run for a semester). Some tools are also too expensive or work completely in a black box. For the use in education, optimal tools are accessible, ideally open-source, and well- supported software with a low learning curve allowing teachers and students to employ them optimally for the development task they are up to.

The concept of supplying different views upon the same codebase allows students to adjust the way they interact with a development tool only by the skill they acquire. During the time of use, ideally they become proﬁcient enough to start programming by utilising the framework of the tool.

• Computer Science Education can Profit from Game Development As stated in chapter 4, game development teaches a wide variety of skills that are especially needed there, but also in many other areas. These include areas of traditional computer science as well as liberal arts. The benefit is not only the motivation that students have, when approaching computer science topics, but also the proximity to fields of application and the in-depth collaboration between different disciplines.

• Squeak is Ideal for Teaching Concepts of Object-Orientation as Part of Game Design Squeak is primarily a tool for explorative learning and thus, it does an extraordinary job at exposing students to the principles of object-orientation. This abstraction does come at a price of lower speed, but is ideal to understand deeper mechanisms that most object-oriented architectures expose. Thus, it is a good introductory tool for people searching for a starting place for programming as well as game development. Together with the Tweak and iEngine libraries, it is also useful for helping novices understand computer game architectures.

• Game Design and Object-Oriented Design Supplement Each Other Object-oriented design helps structuring any kind of architecture and gives it a formal shape [Alphonce02]. This has not been true of most game architectures of the past, where all importance was put towards being most efﬁcient with the code, even if that would mean loss of readability and reusability within a team. Now, as teams grow and games become more complex, game architectures need to be more formalised as well and therefore can employ many techniques natural to object-orientation. 6.2 Discussion 95

All of the above deliberations led to the development of a prototyping tool, which suits the special requirements of education. The most important of the latter is the ease-of-use combined with scalable complexity that allows users to operate on different levels of knowledge. Having a dynamic white box architecture, so that most conﬁgurations can be made during its run-time, was an essential factor for developing this tool in Squeak. Deﬁning different views to a game world was a key element that makes the tool suitable for students with varying skills.

6.2 Discussion

Game development is a relatively new ﬁeld of academic research allowing the exploration of new concepts for gameplay [Crawford03, SmithL02, McNaughton04] or graphical styles of games [Freudenberg04, Watt03]. Despite other areas of computer science, where techniques, tools, and educational focus have been well established over the years, game research remains a challenging academic ﬁeld [Kafai95, Squire03].

Especially, the transportation of techniques that make players want to master a game - which means learning its rules - into education is highly interesting. Creat- ing a gameplay experience, therefore, has much to do with placing rewards at right point of time or level of skill. This keeps a player interested in a game. Using this concept of motivation in education will be huge beneﬁt for teaching any subject.

Coming back to the thoughts in chapter 4, computer science proﬁts most from the motivational power of games: Video games are the main reason for many students to become interested in learning programming. Thus, a tool allowing playful as well as more serious education can help novices to understand more abstract concepts surrounding this subject.

One of the key concepts is object-orientation. Understanding this concept can help all kinds of designers, because it represents the most natural way to design things (as stated by Mark Overmars in section A.1). Game design and object-oriented design share the same core approach. More formal development steps of iterative design work efﬁciently in game production. Providing a clear overview of iterative development cycles can serve as a future reference for project managers.

Besides the theoretic concepts this thesis discussed, it also focussed on special software development with - at least for game developers - uncommon tools, testing new ways of developing games in an academic context. A speciﬁc review of how the work with these tools turned out is given in the following subsections. 96 6 Summary and Conclusion

6.2.1 Critical Review

While the initial expectations towards a game development tool were quite high, I came to realise that stressing the aspect of prototyping can take away much complexity of the tool. This way, it ﬁts better towards a speciﬁc need in education.

What I came to wonder about, was how many similarities existed between object- oriented design and game design. If games are merely systems of rules and these rules are their components, then they are complex objects. The further the granularity is refined, the more interesting these systems become. The thought that many systems can be refined in this way is definitely the reason, why object-oriented design has become so popular (not only in programming).

On a completely different note; one critical thought after the development of LeGaCy is that using one general tool for prototyping computer games might not be enough. Although the concept of having different views on data is certainly well-fit for introducing students to basic game programming, thus allowing them become more proficient at programming, different genres provide different challenges for game design. Not all of them can be covered by one tool. It is more likely genre-specific tools have to be developed to better suit particular needs.

This way, the granularity of prototyping tools needs to be less rough than in the approach that I pursued. However, this is the ﬁrst research in this area and thus leaves many possibilities for extending it towards more reﬁned tools or maybe integrating it better with other languages and packages than Squeak.

To my mind, Squeak will primarily remain a tool for learning and is still too slow to be used for the creation of high-end games1. Thus, it remains questionable, whether it is an ideal tool for game development. Nevertheless, its use in education is beneﬁcial, and will help to understand object-orientation much better than any other programming environment.

6.2.2 Advantages and Disadvantages of Game Development with Squeak

Developing games with a high-level language, especially with one that is completely unknown to most students is an approach that many of them have prejudices against. It has proven to be challenging to convince them at the beginning. Since education at an university focusses on concepts rather than training speciﬁc tools or languages, most of the students are convinced by the educational power behind Squeak at the end of a course.

1 Although many talented people are working on improving performance and three-dimensional issues with the Croquet project, this is still in its infancy. 6.3 Future Work Perspectives 97

On the one hand, educational facilities have the responsibility to orient their education on industry needs and to help future developers by teaching techniques and tools of the industry. Naturally, most students expect the work of a course on game development to deliver a good prototype that can extend their portfolio.

Industry professionals know that in the games industry, the only thing besides talent that separates the wheat from the chaff is a long track-record of completed games. Understanding the concepts behind game development is another crucial requirement.

On the other hand, academic institutions have the freedom to research in areas where development is not possible in the industry, so that they can expose themselves to ideas that are not proﬁtable there.

Traditional university education also aims at the mediation of conceptual thinking. The understanding of mechanisms is usually more important than proﬁciency and specialisation in a certain area. This again emphasises the use of a learning tool [Beck89].

However, my opinion on this is that students should have the chance to get close to both. While Squeak is good for novices, it should not remain the tool of choice if students want to explore advanced areas of game development. Especially, if some of the industry tools are available freely (like DirectX), I recommend using those as well for more advanced classes.

6.3 Future Work Perspectives

At this stage, the functionality of LeGaCy is clear-cut and plain, only allowing the construction of games that operate in a two-dimensional top-view environment. This is due to the time constraints that this thesis was written in. With the limits at hand, it was not possible to create a tool, offering full game functionality off the top of one’s head.

In the future, the application can be further extended, by simply adding new elements to the creation menus that will allow further speciﬁcation of the behaviours of objects. The customisation of the user interface can be extended to allow for a scripting language to be used a part of the environment.

It would also be more convenient to add user dialogues for the application to incorporate the different mechanisms for different player types much better. This way, one could part from the given naming scheme to load in object type images. 98 6 Summary and Conclusion

Areas of application Although LeGaCy is custom-built for use in teaching game development at a university-level course, it can certainly be used in other areas of education as well. A possible use could be the prototyping for other learning concepts that involve playful mechanisms.

The possibility of sketching out such an environment has often been raised, and many institutions deal with the creation of learning games that are often not much more than a prototype. These companies almost never have professional game designers at hand but pedagogically trained personnel that wants to bring across an idea in a playful way, which will accelerate learning. LeGaCy can be useful for those kind of users, too.

6.4 Personal Remarks

I personally found the use of Squeak as a programming language a fresh, instruc- tive, and interesting approach towards game development. The availability of many toolsets and all libraries of the programming environment is something that is unique, especially in open-source programs. However, all this comfort comes at the price of speed and hardware power that Tweak and especially the iEngine consume (more precisely, the calculations outside of the virtual machine).

Programming on such a high level makes up for some slowness discomfort. One could argue that this slowness can efﬁciently be pushed towards better performance by optimising the code and transferring performance-critical calculations into low-level code of the virtual machine. This, however, was not necessary for me, because the focus of a prototyping tool needs not to be on optimisation.

There was much help from the impara GmbH though, but I was in doubt whether the capabilities of the iEngine were useful for developing “real” games. This became less important, when I realised that a real game and a prototype have to differ essentially. The Buccaneers, Inc. game prototype was close to performing well, but still had many issues with sound loading and speed of the graphics display.

Having some prejudices about Squeak at ﬁrst, they were partly scattered when I started using it regularly. One of the reasons is the code control, which was made easy with the internal changeset system and a Monticello2 repository. I could easily revert to stable versions, and comment on the actual code, I was uploading.

The good examples of implemented tools within Squeak were helpful but not very

2 Monticello offers version control functionality. 6.5 Conclusion 99 useful, since a lot of the code had to base on the iEngine, which still - after more than a year - is horribly documented. I have to thank the programmers at impara, because without their help, it would have been impossible to reuse the code. The new user interface Tweak is better documented, and it features some good examples in the source code as well that help to get a grip of it. The concepts behind Tweak are incredible and will make it a powerful addition to Squeak.

6.5 Conclusion

Still, this work was supposed to be on game design, not on using Squeak and the concepts behind it. By using Squeak, there is no way of avoiding concentrating on object-orientation, which actually became quite useful in my research. It helps me see many similarities between the two, while learning the concepts of Squeak was difﬁcult for me at ﬁrst. I came to accept the language and the environment as useful for learning to program strictly object-oriented.

The results, however, were not much eye-candy, as one would expect them to be with a lower-level language (even though those could not have been achieved in the given time-frame, too). This trade-off bothered me at ﬁrst, but since this work concentrates on the educational possibilities of gameplay prototypes in Squeak, I came to accept it as a good learning tool.

The challenges of LeGaCy lie in its future. With more development time at hand, a skilled person might continue the work to craft it into something more reliable and maybe even faster. I would not doubt the possibility of this tool also being implemented in another language and with a different focus. The problem is certainly the genre and what genre a developer focusses on. There are so many different directions that game development can take that I doubt there can be one universal tool for prototyping but rather a more diverse range of tools, all in the sense of granularity and middleware, allowing different topics and speciﬁcations.

Glossary

API An Application Programming Interface is a set of deﬁnitions of the ways in which one piece of computer software communicates with another. It is a method of achieving abstraction, usually (but not necessarily) between lower-level and higher-level software.[Wikipedia]

ADD-ON Add-ons are optional computer game modules that generally enhance the original game or supplement it by adding maps and graphical material.

C# In this context, C# (pronounced C Sharp) is a programming language developed by Microsoft as part of the .NET platform, which is both reﬂective and object-oriented. Its syntax is directly based on Java and C++, while many of the ideas derive from the original Smalltalk.

CROQUET The Croquet project seeks to offer an open source, networked, 3d environment for collaborative work. While its primary target is in the educational area, it is conceived from the start as a series of shared worlds which can be created in other public and private domains where advanced collaborative software is needed. [Wikipedia]

DLL A Dynamic Link Library are special programming routines that ,once loaded into the memory of a computer, can be used by multiple applications at the same time.

DEVELOPER A computer game developer is the person or usually the company that develops a computer game. A developer studio is organised in many divisions, spanning all areas of game development, including game/level design, programming, graphics, music/sound, storytelling and quality assurance.

E3 The Electronic Entertainment Expo is the world’s largest annual trade show and the third largest gaming convention for the computer

101 102 Glossary

and video games industry. The expo is only open to game industry professionals and journalists who are over 18. It is usually held in May every year. [Wikipedia]

GCDC The Games Convention DEVELOPERs Conference is an annual gathering of international video game developers in Europe. The structure is less formal yet somewhat similar to the GDC.

GDC The Game Developers Conference is an annual gathering of video game developers. The conference is comprised of an expo and a variety of tutorials, lectures and round-tables by industry professionals on game-related topics covering programming, design, audio, production, business and legal, and art.

GML Game Maker Language is a programming language developed for use with a computer game creation application called Game Maker. It was created by Mark Overmars to help supplement the drag’n’drop system normally used within his program

GUI A Graphical User Interface is the kind of interface of a computer that is visually represented before the user’s eyes and serves as a primary interaction point for most computer applications.

GAME ENGINE A game engine is the core element of any computer game. The use of a game engine makes creating content for a video game much easier. A lot of the core technology of a game, including scripting, level design, networking, collision detection, artiﬁcial intelligence, sound and graphics rendering is done by the game engine. Most often it serves as a high level layer to the low level technology mentioned before. Figure B.3 shows a schematic overview of a game engine.

IDE An Integrated Development Environment comprises a lot of components needed for the development of software, including the text editor, compiler, linker, debugger or sometimes an interpreter. The text editor often offers many functions to format the code for better readability and automatisation of recurring tasks.

IEEE The Institute of Electrical and Electronics Engineers is an international non-proﬁt, professional organization for the advancement of technology related to electricity. It is the largest technical professional organization in the world (in number of members), with more than 360,000 members in 150 countries (as of 2004). [Wikipedia] Glossary 103

IGDA The International Game Developers Association is a non-proﬁt organization designed to promote, and strengthen the video game industry, and have computer games recognised as an art form. As part of promoting the industry, the IGDA presents the Game Develop- ers Choice Awards annually at the Game Developers Conference. [Wikipedia]

LEGACY LeGaCy stands for Lennart’s Game-Prototype Creation utility, which is the name the author of this thesis gave his software. It should be taken with a grain of salt as it also underlines the fact that the tool needed to leave out some desired features, which can be developed by others in the future.

MIDDLEWARE The term Middleware describes an independent communications layer between applications, which hides their complexity. When a software is broken up into separate components that can be used for other software as well, these components serve as middleware.

MONTICELLO Monticello is a distributed, concurrent, versioning system for Squeak code. Unlike other versioning systems, in which a package is associated with one repository, Monticello supports different versions on many repositories.

NDA A Non-Disclosure Agreement is a conﬁdential and binding legal agreement, which has to be signed by involved parties to prevent them from sharing technology or knowledge about technology. It is part of many game software licenses.

PATCH A patch is way to ﬁx software bugs after a game has been released. They are often made available on the internet and in pc magazines. Unfortunately, patches have become a common way to make (especially) pc games playable after the retail version sometimes crashes from the start. Some games even have to be re-released after most of the bugs are ﬁxed. Recent examples for this are SÖLDNER,THE FALL, and SACRED.

PITCH A pitch (especially in game development more correctly deﬁned as an elevator pitch) is the presentation of a game prototype usually done at a large sales fair (like the E3) often done in a very short time-span to get a publisher interested in producing the game, which means funding further development, marketing and distributing the product. Thus, it is an essential part of game development. 104 Glossary

PUBLISHER A publisher in game development refers to the company that usually does the marketing, distribution and sales for the developer.

SCM Software Conﬁguration Management is a set of activities designed to control change by identifying the work products that are likely to change. In other words, SCM is a methodology to control and manage a software development project. [Wikipedia]

SDK A Software Development Kit is a set of tools, APIs and documentation to assist with the development of software in a speciﬁc computer language or for a particular operating environment.

SMALLTALK Smalltalk is an object-oriented, dynamically typed, reﬂective, programming language created at Xerox Palo Alto Research Centre by Alan Kay, Dan Ingalls, Ted Kaehler, Adele Goldberg, and others during the 1970s, inﬂuenced by Sketchpad and Simula-97. The language was released as Smalltalk-80 and has been widely used since. Smalltalk is in continuing, active development. [Wikipedia]

SQUEAK Squeak is a portable, open-source, object-oriented multimedia development environment and programming language that derived from Smalltalk. It was originally developed in the 1970s by Dan Ingalls, Ted Kaehler, John Maloney, Scott Wallace and Alan Kay at Xerox Palo Alto Research Centre. The usage of Squeak is discussed in chapter 5.

UNIX Uniplexed Information and Computing System is a portable, multi- tasking and multi-user computer operating system originally developed by a group of AT&T Bell Labs employees including Ken Thomp- son, Dennis Ritchie and Douglas McIlroy. [Wikipedia]

XML The Extensible Markup Language is a general-purpose markup language for creating special-purpose markup languages recommended by the World Wide Web Consortium (W3C). It is a simpliﬁed subset of the Standard Generalised Markup Language (SGML), which can describe many different types of data. Its primary purpose is to simplify sharing data across different systems [Wikipedia]

XNA Microsoft’s XNA (Xbox/DirectX New generation Architecture) is the attempt to build a platform that combines different APIs for game development to create a common framework for the Xbox console as well as for the next-generation Windows operating system. References

[8BitMuseum05] 8Bit-Museum. The Dot Eaters/The Number Crunchers - Die Geschichte der Videospiele & Heimcomputer, 2005. http://www. 8bit-museum.de, last accessed July, 2005.

[Alphonce02] Carl Alphonce and Phil Ventura. Object orientation in cs1-cs2 by design. SIGCSE Bull., 34(3):70–74, 2002.

[Barry05] Isaac Barry. Introduction to Game Development, chapter 2.2 Game De- sign, pages 99 – 161. Charles River Media, 2005.

[Bates01] Bob Bates. Story: Writing Skills for Game Developers. In Game Design Proceedings of the Game Developers Conference 2001, San Jose, Califor- nia, USA, 2001. Game Developers Conference.

[Bates02] Bob Bates. Game Design: The Art and Business of Creating Games. Pre- mier Press, 2002.

[Beck89] Kent Beck and Ward Cunningham. A laboratory for teaching object oriented thinking. In OOPSLA ’89: Conference proceedings on Object-oriented programming systems, languages and applications, pages 1–6, New York, NY, USA, 1989. ACM Press.

[Bethke03] Eric Bethke. Game Development and Production. Wordware Publishing, 2003.

[Boettcher05] Ralf Armin Böttcher. Flow in Computerspielen. Master’s thesis, Otto- von-Guericke-University Magdeburg, Magdeburg, 2005. Diplomarbeit at the Institute for Simulation and Graphics.

[Claypool05] Kajal Claypool and Mark Claypool. Teaching Software Engineering Through Game Design. In Proceedings of the Innovation and Technology in Computer Science Education (ITiCSE) Conference, Lisbon, Portugal, June 2005.

[Costikyan02] Greg Costikyan. I Have No Words & I Must Design: Toward a Crit- ical Vocabulary for Games. In Frans Mäyrä, editor, Proceedings of Com- puter Games and Digital Cultures Conference, page 9–33, Tampere, Fin- land, 2002. Tampere University Press. http://www.digra.org/dl/db/ 05164.51146, last accessed September, 2005.

105 106 References

[Crawford03] Chris Crawford. Chris Crawford on Game Design. New Riders Pub- lishing, Indianapolis, Indiana, USA, ﬁrst edition, June 2003.

[Csikszentmihalyi91] Mihaly Csikszentmihalyi. Flow. Perennial, 1991.

[DassaultSys05] Dassault Systèmes. Virtools Website, 2005. http://www. virtools.com, last accessed October, 2005.

[DeBono04] Edward de Bono. How To Have a Beautiful Mind. Vermilion, 2004.

[DeBono85] Edward de Bono. Six Thinking Hats. Little, Brown, and Co., 1985.

[ElectronicArts05] Electronic Arts. EA Academy - How EA Makes Games, 2005. http://www.jobs.ea.com/how_ea_makes_games.html, last accessed July, 2005.

[Epic05] Epic Games. Unreal Engine Technology website, 2005. http://www. unrealtechnology.com/ last accessed July, 2005.

[Freudenberg04] Bert Freudenberg, Maic Masuch, and Thomas Strothotte. Real- Time Halftoning: Fast and Simple Stylized Shading. In Andrew Kirmse, editor, Game Programming Gems 4, pages 440–443. Charles River Media, 2004.

[Fullerton04] Tracy Fullerton, Christopher Swain, and Steven Hoffman. Game Design Workshop - Designing, prototyping and playtesting games. CMP Books, ﬁrst edition, March 2004.

[Gadegast05] Patty Gadegast. Objektorientierte Programmierung von Entertain- mentumgebungen in Squeak, 2005. Study report (Studienarbeit) at the Institute for Simulation and Graphics.

[Gamma95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. De- sign Patterns: Elements of Reusable Object-Oriented Software. Addison– Wesley, 1995.

[GranerRay04] Sheri Graner Ray. Gender Inclusive Game Design: Expanding the Market. Charles River Media, Massachusetts, USA, 2004.

[Guzdial01] Mark Guzdial. Squeak: Object-Oriented Design with Multimedia Appli- cations. Prentice Hall, ﬁrst edition, 2001.

[Guzdial02] Mark Guzdial and Kim Rose. Squeak: Open Personal Computing and Multimedia. Prentice Hall, ﬁrst edition, 2001.

[Hodgson03] David Hodgson. Half-Life 2: Prima’s Ofﬁcial Strategy Guide. Prima Games, 2004.

[IGDABusiness03] IGDA Business Committee. Quality Assurance/Testing Best Practices, April 2003. Best Practice Reports, last accessed July 2005. References 107

[IGDAEducation03] IGDA Education Committee. Curriculum framework, February 2003. IGDA Curriculum Framework - The Study of Games and Game Development, Version 2.3 beta, February 25, 2003, last accessed July 2005.

[IdSoftware05] id Software. Doom Product Website, 2005. http://www. idsoftware.com/games/doom/, last accessed July, 2005.

[Ingalls97] Dan Ingalls, Ted Kaehler, John Maloney, Scott Wallace, and Alan Kay. Back to the future: the story of squeak, a practical smalltalk written in itself. In OOPSLA ’97: Proceedings of the 12th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, pages 318–326, New York, NY, USA, 1997. ACM Press.

[Kafai95] Yasmin B. Kafai. Minds In Play: Computer Game Design as a Context for Children’s Learning. Lawrence Erlbaum Associates, Hillsdale, NJ, 1995.

[Kay93] Alan C. Kay. The early history of smalltalk. SIGPLAN Not., 28(3):69–95, 1993.

[Koch05] Nadin Koch. Baumgenerierung in Computerspielen, 2005. Study report (Studienarbeit) at the Institute for Simulation and Graphics.

[Koelling96] Michael Kölling and John Rosenberg. An object-oriented program development environment for the ﬁrst programming course. In SIGCSE ’96: Proceedings of the twenty-seventh SIGCSE technical symposium on Com- puter science education, pages 83–87, New York, NY, USA, 1996. ACM Press.

[Kushner03] David Kushner. Masters of Doom: How Two Guys Created an Empire and Transformed Pop Culture. Random House, 2003.

[Lammers90] Susan Lammers, editor. Programmers at Work: Interviews With 19 Programmers Who Shaped the Computer Industry. Microsoft Press,U.S., reissue edition, August 1990.

[Lischka02] Konrad Lischka. Spielplatz Computer - Kultur, Geschichte und Ästhetik des Computerspiels. Verlag Heinz Heise GmbH & Co KG, Hannover, Ger- many, 2002.

[Llopis04] Noel Llopis. Optimizing the content pipeline. Game Developer, 11(4):36– 44, April 2004. http://www.gamesfromwithin.com/articles/0408/ 000027.html, last accessed May, 2005.

[Llopis05] Noel Llopis. Introduction to Game Development, chapter 3.1 Teams and Processes, pages 163 – 183. Charles River Media, 2005.

[Llopis05b] Noel Llopis. Introduction to Game Development, chapter 3.2 C++, Java, and Scripting Languages, pages 183 – 202. Charles River Media, 2005. 108 References

[Makar03] Jobe Makar. Macromedia Flash MX Game Design Demystiﬁed. Peachpit Press, ﬁrst edition, 2003.

[Maloney00] John Maloney. An Introduction to Morphic: The Squeak User Interface Framework. Squeak: Open Personal Computing and Multimedia, pages 39– 68, 2000.

[Masuch02] Maic Masuch and Bert Freudenberg. Teaching 3D Computer Game Programming. In Ralf Dörner, Christian Geiger, Paul Grimm, and Michael Haller, editors, Workshop Proceedings Production Process of 3D Com- puter Graphics Applications - Structures, Roles, and Tools, Aachen, 2002. Shaker.

[Masuch04] Maic Masuch. Unkonventionelle Interfaces für Computerspiele. In Workshop Methoden und Werkzeuge zukünftiger Computerspiele der GI- Jahrestagung 2004, pages 165–169, Ulm, 2004. Gesellschaft für Infor- matik, P. Dadam and M. Reichert.

[Masuch04b] Maic Masuch and Lennart Nacke. Power and Peril of Teaching Game Programming. In Norman E. Gough and Quasim Mehdi, editors, Interna- tional Conference on Computer Games: Artiﬁcial Intelligence, Design and Education, pages 347–351, Reading, UK, November 2004. University of Wolverhampton UK.

[Masuch05] Maic Masuch and Michael Rüger. Challenges in Collaborative Game Design: Developing Learning Environments for Creating Games. In Third International Conference on Creating, Connecting and Collaborating through Computing, pages 67–74, Kyoto, Japan, January 2005. Yahiko Kambayashi and Katsumi Tanaka and Kim Rose.

[McCallum04] Simon McCallum, Jayson Mackie, and Lennart Nacke. Creating a Computer Game Design Course. In Proceedings of the New Zealand Game Developers Conference. NZGDC, 2004.

[McNaughton04] M. McNaughton, M. Cutumisu, D. Szafron, J. Schaeffer, J. Red- ford, and D. Parker. ScriptEase: Generative Design Patterns for Computer Role-Playing Games. In Proceedings of the 19th IEEE International Confer- ence on Automated Software Engineering (ASE’04), pages 88–99. Institute of Electrical and Electronics Engineers, 2004.

[Memisoglu04] Maral Memisoglu. Usability for Video Games (Die Anwendung von Usability-Methoden bei der Entwicklung von Videospielen). Game Face, 8:42–43, October/November 2004.

[Mencher03] Marc Mencher. Get in the Game! Careers in the Game Industry. New Riders Publishing, 2003.

[Mertens02] Mathias Mertens and Tobias Meißner. Wir waren Space Invaders - Geschichten vom Computerspielen. Eichborn, Frankfurt a. M., Germany, 2002. References 109

[NXN05] NXN. Ofﬁcial Alienbrain website, 2005. http://www.nxn-software. com/whde.php, last accessed July, 2005.

[Nacke04] Lennart Nacke. Co-Development, Delivery and Structural Analysis of a Computer Game Course, 2004. Study report (Studienarbeit) at the Insti- tute for Simulation and Graphics.

[Naur68] Peter Naur and Brian Randell. Software engineering: Report of a conference sponsored by the NATO Science Committee, 1968.

[Nielsen05] Jakob Nielsen. useit.com: Jakob Nielsen’s Website, 2005. http://www. useit.com/ last accessed July, 2005.

[Overmars04a] Mark H. Overmars. Teaching Computer Science through Game De- sign. In IEEE Computer, volume 37, pages 81–83. Institute of Electrical and Electronics Engineers, April 2004.

[Overmars04b] Mark H. Overmars. Learning object-oriented design by creating games. In IEEE, volume 23, pages 11–13. Institute of Electrical and Elec- tronics Engineers, 2004.

[Overmars04c] Mark Overmars. Game design in education. Technical Report UU- CS-2004-056, Institute of Information and Computing Sciences, Utrecht University, 2004.

[Pagulayan03] Randy J. Pagulayan, Kevin Keeker, Dennis Wixon, Ramon L. Romero, and Thomas Fuller. User-centered design in games. pages 883– 906, 2003.

[Parberry05] Ian Parberry, Timothy Roden, and Max B. Kazemzadeh. Experience with an industry-driven capstone course on game programming: extended abstract. In SIGCSE ’05: Proceedings of the 36th SIGCSE technical symposium on Computer science education, pages 91–95, New York, NY, USA, 2005. ACM Press.

[Pleva04] Greg Pleva. Game programming and the myth of child’s play. J. Comput. Small Coll., 20(2):125–136, 2004.

[Raskin00] Jef Raskin. The Humane Interface. New Directions for Designing Interac- tive Systems. Addison Wesley, 2000.

[Rollings03] Andrew Rollings and Ernest Adams. Andrew Rollings and Ernest Adams on Game Design. New Riders, Indianapolis, Indiana, USA, ﬁrst edition, May 2003.

[Rollings03b] Andrew Rollings and Dave Morris. Game Architecture and Design - A New Edition. New Riders, Indianapolis, Indiana, USA, 2003.

[Salen03] Katie Salen and Eric Zimmerman. Rules of Play: Game Design Funda- mentals. MIT Press, 2003. 110 References

[Schnetzler04] Nadja Schnetzler. Die Ideenmaschine. Wiley-VCH, 2004.

[Schuster04] Grit Schuster. Autonomes Verhalten für digitale Charaktere in in- teraktiven 3D-Welten. Master’s thesis, Otto-von-Guericke-Universität Magdeburg, Magdeburg, 2004. Diplomarbeit at the Institute for Simu- lation and Graphics.

[Sheerin04] Peter Sheerin. Must-know technologies. Game Career Guide, pages 63–64, Fall 2004.

[Shefﬁeld05] Brandon Shefﬁeld. Unreality: Epic’s Mark Rein on the Future of Game Middleware. Gamasutra, July 2005. http://www.gamasutra.com/ features/20050719/sheffield_01.shtml, last accessed July, 2005.

[Smed03] Jouni Smed and Harri Hakonen. Towards a Deﬁnition of a Computer Game. Technical Report TUCS-553, Turku Centre for Computer Science, Department of Information Technology, University of Turku, 2003.

[SmithDA03] David A. Smith, Alan Kay, Andreas Raab, and David P. Reed. Cro- quet - a collaboration system architecture. In First Conference on Cre- ating, Connecting and Collaborating Through Computing, 2003. C5 2003. Proceedings., pages 2–9. IEEE, 2003.

[SmithL02] Lesley Smith and Samuel Mann. Playing the Game: A Model for Game- ness in Interactive Game Based Learning. In Proceedings of the 15th An- nual NACCQ, Hamilton, New Zealand, July 2002. NACCQ.

[Squeak05] Squeak. An idea processor for children of all ages, 2005. http://www. squeak.org/, last accessed July, 2005.

[Squire03] Kurt Squire. Video games in education. International Journal of Intelli- gent Simulations and Gaming, 1(2), 2003.

[Watt03] Alan Watt and Fabio Policarpo. 3D Games: Animation and Advanced Real- Time Rendering: 2. Addison-Wesley, ﬁrst edition, 2003.

[Yu02] Connie Yu. Developing a Game Programming Course For Computer Sci- ence Majors In a Liberal Arts College. In Proceedings of the First Inter- national Conference on Information Technology & Applications, Bathurst, Australia, November 2002. ICITA. List of Figures

1.1 One of the ﬁrst video games in history: PONG...... 1 1.2 A screenshot of the games panel in Valve’s Steam...... 2 1.3 The students of a game design course at the Otto-von-Guericke Uni- versity of Magdeburg. They gather together for analysing video games, which will later help them producing a game in a team project. . . . . 4

2.1 An outline of iterative development as sketched by [Fullerton04]. . . . 11 2.2 The concept phase is the start of every game project ...... 11 2.3 The pre-production phase, where the game design document and the production plan merge to reach the actual prototype creation...... 13 2.4 Physical gameplay prototypes created with not much more than pen and paper...... 14 2.5 The game iteratively evolves from the basic prototype to an early alpha stage. Thick arrows indicate a stronger collaboration between the departments...... 16 2.6 Concept art character portraits for two different computer games. . . . 17 2.7 Alienbrain Manager Client is an application that tracks all changes made to the ﬁles in a project and communicates those with a central server for sharing them with internal and external team members. . . 18 2.8 The full production phase takes a game from alpha to gold master. Thick box outlines emphasise the departments mainly involved. Most work is probably done by the level designers and the quality assurance towards the end...... 20 2.9 Several graphical software defects from different retail versions of computer games...... 21 2.10Mantis is a popular open-source bug-tracking tool used by the company impara GmbH for identifying software defects...... 22 2.11The last stages of Production ...... 23 2.12Prototype of the game “Good Bugs, Bad Bugs”, produced in Squeak by students of the game design course at the Otto-von-Guericke University. 28

3.1 An overview of a game engine based on Masuch [Masuch05]. Simula- tion tasks like Physics or AI tend to be handled by middleware these days...... 32

111 112 List of Figures

3.2 Different game genres have different requirements for graphics, which can be seen in this comparison of a high-end shooter on the left to a regular card game application on the right...... 34 3.3 Schematic views of middleware...... 35 3.4 Examples for middleware applications and the differentiation of middleware and production tools...... 36 3.5 Professional and hobby game development suites, multimedia authoring environments...... 38 3.6 The Macromedia Flash MX interface and a screenshot of a casual game developed with it...... 40 3.7 The GUI of Game Maker and a game developed with it...... 41 3.8 A tool from the Vision SDK and a screenshot of game that uses the game engine...... 42 3.9 Unreal Engine 3 - Some of the editor components [Epic05]...... 48

4.1 Different education for future game developers at the Otto-von- Guericke University Magdeburg and the Games Academy Berlin. . . . 54 4.2 The game with the best game design in 2005 was KATAMARI DAMACY, making his game designer Keita Takahashi popular over night. . . . . 56 4.3 The Croquet project aims at developing a ﬂexible framework with that any user interface concept can easily be prototyped and deployed [SmithDA03]...... 60 4.4 The different mini games that were analysed for ﬁnding necessary core game features...... 63 4.5 A high-level overview of the proposed architecture...... 68

5.1 Etoys is a high-level interface for scripting within Squeak...... 72 5.2 Smalltalk MT and the Aura game that was created with it...... 74 5.3 The two GUI environments used in Squeak before the invention of Tweak. 76 5.4 The outline of the mixed Squeak-Tweak work environment that was used for programming LeGaCy...... 78 5.5 Setting up the project Pirates...... 79 5.6 Buccaneers, Inc. is a game demo developed by impara to show what is possible in terms of game development in Squeak with the iEngine. . . 80 5.7 LeGaCy’s different views on the code base: A programmer view and a level-design view...... 83 5.8 The mechanism of updating the assets within LeGaCy...... 85 5.9 Accessing the game objects in LeGaCy...... 86 5.10UML view of the LeGaCy components...... 88 5.11The characters for the game prototype...... 89 5.12Making a game prototype level in LeGaCy...... 90

B.1 Middleware, game development suites and asset management tools. . 133 B.2 The iterative game development process using the concepts suggested by [Mencher03, ElectronicArts05, Fullerton04, Bethke03] and [Masuch05] ...... 134 List of Figures 113

B.3 A conceptual overview of a game engine based on Masuch [Masuch05] 135 B.4 The ingredients of casual mini games that were analysed for creating the prototyping tool LeGaCy...... 136

Appendix A

Interviews

A.1 Interview with Mark Overmars

Mark Overmars is a Professor at the Department of Information and Computing Sciences at Utrecht University in the Netherlands. He teaches courses on game design and has created a hobby game development tool named “Game Maker” that has become very popular over the years. The interview is slightly abridged and was conducted personally during the GCDC 2005 in Leipzig.

My Question: In how far do you think that tools like the Game Maker can help students in ﬁnding out the essentials of game creation? What aspects are most important to a tool that teaches students game development?

Mark Overmars: Oops, that’s a difﬁcult one. (laughs). First, I think it is important to make a distinction between different aspects of gaming. You have the design, you have the technology development and you have the art creation. A big problem is, of course, that tools are meant to create complete games, which involves all of these aspects.

However, at the same moment, usually not the same people are good at these. That is a problem. I think it is difﬁcult - in general - to use a tool for teaching people something about game design without forcing them to know something about art, design and about the implementation.

My Question: So would you say that a tool like Game Maker focusses more on teaching students the game design part and how everything in

115 116 Appendix A Interviews

game development connects?

Mark Overmars: What I tried to do in Game Maker is to write a tool, in which the emphasis can lie on a design aspect. To achieve that I did two things: One is to build an easy interface to do the programming, drag-and-drop objects and still have all the choices. The second issue is that I never went into making 3d games. That has more to do with the art part. If you deal with 2d games then normally you can use standard sprites. There are many of them available. [...]

If you want to do a three-dimensional game, this is impossible. Even though there is standard stuff, you still have to design yourself. Modelling of the world gets much more complicated and so on. This means that you have to focus on solely artistic parts.

My Question: If students are going to learn about game design, is it necessary that they learn about 3d modelling? For me, it always looked like you left out 3d modelling in Game Maker intentionally, so students could focus on the basics of game design.

Mark Overmars: In the course I teach at Utrecht University that is what I do. Actually, in the original year I did not. Therefore, the course developed over the years. In the beginning, halfway through they had to do a small game using Game Maker in 2d and then, at the end, they were making a 3d game using VirTools, which I found okay. You have to have a development tool that makes it easy to do these things.

Now, the effect was that they were always unhappy with the results of the 3d game and it was also lousy what came out of the 3d game. Deﬁnitely, they completely forgot about game design once they were doing the 3d game. They were mainly modelling the worlds and making it interesting but then forgot about what to do.

My Question: So, modelling is more complex, right?

Mark Overmars: It is just more work. It is more complex, but you easily focus on the wrong things. Nevertheless, there is another question: Do A.1 Interview with Mark Overmars 117

you want to teach people to become game designers? Because you might assume that by asking and I much doubt that you want to teach people to become game designers.

Because I think the number of game designers that this world needs is extremely small and than I think you only become a game designer by much experience in many different areas. Therefore, what I do in the course: I concentrate on game design. However, I only teach that course because I feel it is important to our students, which are computer science students and who should become technology people to, at least, understand a part of the whole story.

I would not like to see a curriculum that focusses just on design. It is the same, which people say in the industry. They say you cannot train to become a game designer. You ﬁrst become one of the other people and then some of these people become game designers in the process.

My Question: We have many computational visualistics students, which are more into 3d graphics. They are the programmers that know a lot about graphics and then they want to make the transition to games. How can one softly push these people softly towards making games?

Mark Overmars: I think then it is very important to let them NOT concentrate on their art. (laughs)

My Question: Because...

Mark Overmars: Because then they start concentrating just on the art. They are computer science students and they should start concentrating on programming. If they put much time into doing great graphics and great motion planning, then they forget there is a game for which it is necessary to program. Game Maker was never written for that, of course. Game Maker was written for kids like high school kids that like games.

My Question: It was never written for educational use? 118 Appendix A Interviews

Mark Overmars: It was never written with - at least not university level - education in mind at all. I can explain the history, because it is a bit funny. I had my children growing up and I have always been interested in user interface design. By the way - Game Maker is user interface - that is the main part of Game Maker. It is not the game engine or anything.

I wrote some user interface packages in the old days for certain graphics machines. The ﬁrst software I wrote was a drawing program for people that cannot read. This makes you rethink your user interface because you cannot write things down. [...] Then I wrote a visual version of logo.

Again, with some sort of a drag-and-drop-interface that also later came into Game Maker. Then I realised that making a program that draws something was not exciting enough for kids any more. Therefore, my intent was a program that could animate and then that turned into Game Maker - very soon.

Before the ﬁrst version was released this was already about games. So it was really meant for kids from 10 and older. It was the idea to teach them how to do programming and then use creating games as the mechanism to understand ideas like object-oriented design. That is also why in Game Maker, there is much emphasis on the object-oriented design part.

It is very object-oriented, which in the end makes it a perfect tool to make the game design, I think. Nevertheless, that is maybe a bit more of a coincidence, rather than that I planned it. Now, education has been on my mind, but that is because I wanted to teach them something. The other main idea that I stuck to is simplicity. My goal is always keeping it simple.

My Question: But what about the ideas like the Game Maker Language (GML)? Did you implement these from the start?

Mark Overmars: There was a scripting language in the ﬁrst version. Yes. But it was limited in its possibilities. I did that because, as I said, the goal was to teach people how to program, so I hoped that at some stage they would want to write in a programming language. Again, the goal was more towards the programming than towards the game design originally. Now soon this changed and A.1 Interview with Mark Overmars 119

the focus was on game design.

My Question: Do you think those two ﬁt together and complement each other? One idea that I have been researching in my thesis is that object- oriented software engineering and game design somehow complement each other, because you have to think in components. If you subdivide a game into certain ingredients that interact with one another, you get an object-oriented model as well.

Mark Overmars: I am not sure. This is an interesting question. What I do think is that for a game designer it is natural to think in an object- oriented way. For most designers it is natural to think in an object-oriented way. Object-oriented design, even though in most programming-language courses that are taught to computer science students this is considered something complicated.

It is, however, the easiest way of thinking about things. Espe- cially if you can imagine these objects as being real objects and that, of course, is what you can do in a game. Although you have control over objects in a game, I am not sure whether this relation is there.

However, the object-oriented design in Game Maker makes it easy for people, which do not know much about programming, to create what they want to create because they think in that way, anyway. Still, I would not recommend the designers to do the programming or the programmers to do the design.

My Question: Is it better to teach a course on game design at a technical university to computer science students? What is the best starting point for people that want to take it to the next level in creating games?

Mark Overmars: The way we do it in Utrecht now is as follows: In the Utrecht area we have ﬁve different curricula that cope with game design. Within computer science we have a curriculum that is technology-oriented and in liberal arts there is a curriculum that talks a lot about cultural aspects, storylines, etc.

In the art school, there are two curricula. One focusses on design, also graphical design, and the other one is about art: The 120 Appendix A Interviews

kind of art with a capital “A”. These people make performances with game elements. And then there is another “Fachochschule”- type with an education in media technology, where people build things.

We are putting all of these together in something called UPGEAR now. It stands for “Utrecht Platform 4 Games Education and Research”1. (smiles). I made that word up, so I am really proud of that one. The ﬁrst mission is to ask high school kids: What are you interested in? You say you want to do something with games. What do you want exactly? What of these ﬁve areas, are you interested in? Therefore, they realise that these areas are different. There is no such thing like “I study games”. Then, based on that you decide which curriculum and place you go. I think, in each of these there should a little room for all the others, because people in the end have to communicate with one another. [...]

My Question: If you work in a game creation environment, the artists usually have to at least know how to export assets into game engine...

Mark Overmars: [...] Of course, it would be great to have people that are able to do everything. However, there are just too few of these people around. For me, the game design course in the computer science curriculum is the only design course. It is there to make the computer scientists feel humble, because they have a role in the whole process. They are not the thing that matters. In the end, it is the game design that matters.

If you go back to your ﬁrst question, “do tools like Game Maker help there?” Yes, I think, because they help you focus on a particular aspect, which makes it easier to learn about that. People that did do art education and have always been creating art tend to create much nicer games than the computer scientists do, because they think from a design perspective.

My Question: So your tool helps both worlds: it helps the computer scientists and the designers?

1 For more information visit http://www.upgear.nl A.1 Interview with Mark Overmars 121

Mark Overmars: Well, it helps the computer scientist to get an insight. Makes them not worry too much about programming. Sometimes by limiting them in what they can do. For the designer you give them a tool, so they can do some things they never could, if they had to program them or use a more complex tool like Flash or Director. I think, these help, but in the end it is not the tools, it is the education that matters and the teacher that teaches the topics.

And to be honest, if I look at what I see in the different curricula in the different countries at the moment, often the teachers do not understand much about game design when they are teaching these courses. Finding good people to teach is, I guess, the major problem in setting up these curricula. [...]

My Question: That brings you back to your statement: Keep it simple!

Mark Overmars: Well, yeah, it is this KISS principle which says “Keep it simple, stupid”. This is a standard principle in interface design. The programming language in Game Maker supports that much. Ev- erything that I consider being too complex for the average user, I only put in as functions in the programming language and not in the user interface. Because of that, I added 3d graphics to the latest version, but it is only in the programming language. Therefore, anybody else will not even see it and it does not become harder to use the tool. [...]

I had these workshop kids, probably between twelve and ﬁfteen and in this workshop; we let them make a little maze game with Game Maker. After they all had made this maze game, I said, “you probably do not realise it, but games like DOOM are just maze games. They only put a fancy interface and ﬁrst person view around it.” What I showed them was a DOOM-like game that I made in Game Maker. I also showed them the level design, which was just a maze. The same game, they had made before. Only these objects, rather than being 2d, are drawn in three dimensions. The rest of the gameplay is completely two- dimensional, which even the makers of Doom realised. [...] 3d has often not that much to do with gameplay, although it can enhance the immersion effect. 122 Appendix A Interviews

A.2 Five Questions for Four Game Industry Veterans

In the following, you will ﬁnd a list of four interviews with veterans from the game industry. I especially wanted to get the game designers’ views on game development and contrast it with that of a programmer. Therefore, all of them had to answer the same questions and express their feelings and thoughts towards game development, education and object-oriented design.

I found these interviews more informative than most of the papers I have read about game education. The e-mail interviews happened shortly after a meeting with them on the GCDC 2005 in Leipzig, except for the interview with David A. Smith. I interviewed him by e-mail with the help of the folks at the impara GmbH.

A.2.1 Interview with Bob Bates

Bob Bates currently is the chairperson of the IGDA. Since he started game design at Infocom (1986), he contributed to making more than 25 AAA titles (for example Unreal 2). He speaks at industry conferences [Bates01] and writes books on game development [Bates02].

My Question: Do you think the use of a game creation suite (like a development kit - as for example 3d Game Studio or Renderware Studio) can help students understand game development in a university-level course?

Bob Bates: Deﬁnitely yes. The best way for someone to learn about game design and game development is to DO it. Whether you use 3D Game Studio, Renderware or an available engine that ships with a game to do mods (Unreal, for example), the actual experience of getting in there and *making* something (and then making it work ), is invaluable.

My Question: If a course aims at teaching computer science students the basics of game design (which, of course, they cannot learn during a semester) what areas of game design should it focus on?

Bob Bates: If it’s pure game design (as opposed to programming, for example), I would focus on anything that teaches the student what I call “player A.2 Five Questions for Four Game Industry Veterans 123

empathy.” Which is to say that the student should train him/herself in the art of putting themselves “in the player’s shoes.” This, I believe, is the single most important attribute a game designer must have to be successful.

No matter what genre you’re working in, if you cannot mentally put yourself in the player’s place – think what he must be thinking, anticipate what he will want to try, steer him in the right direction, etc – then you will not be a good game designer. Personally, I have found designing small adventure games and puzzles to be good training for this, but I’m sure the same effect could be achieved by doing small versions of games in different genres.

My Question: One idea that I have been researching in my thesis is that object- oriented software engineering and game design somehow complement each other, because you have to think in units. If you subdivide a game into certain ingredients that interact with one another, you get an object-oriented model as well. A game is not more than many connected objects on an abstract level. Do you think that game design and object-oriented programming can learn from each other?

Bob Bates: I don’t know enough about object-oriented programming to really respond to this. (I stopped programming my own games right at the time that object-oriented programming came into vogue).

My impression, however, is that game design and development is “messier” than you are anticipating. In my experience, a game is like a big web, and when you touch it in one place, it vibrates in another. (This should not be true of the game engine, btw, which indeed should be modularized). But I can’t tell you the number of times that someone has suggested a “small change that shouldn’t affect anything” only to ﬁnd that there are hidden dependencies that were built in that makes the “small change” into a big one. One can certainly say that in theory this should not be so. But in practice, I have generally found it to be true in most game types, and especially in adventure and action-adventure games.

My Question: What can and cannot be learned from using game design tools? Should computer science students learn to think outside the box, and create pen-and-paper-based games as well? What contents would be most necessary for a semester course? 124 Appendix A Interviews

Bob Bates: The more different ways you come at game design, the better. I have a strong background in chess and various board games. Card games (both traditional, like Poker, and new like Magic the Gather- ing [OK, *relatively* new ]), and every other kind of game imagin- able can all be drawn upon when making computer games. I would also add that a broad, liberal arts education is also a very good idea.

The wider the student casts his net, the better off he will be. Will Wright draws inspiration from reading about architecture and robotic design, others read science ﬁction novels, take nature walks, or go scuba diving. Whenever game designers gather, I am always astounded at their sheer breadth of interests, the range of things that inspire them, and how *all* of them are curious individ- uals and lifelong learners.

My Question: Name three peculiarities that - to your mind - college cannot teach you about game development! Explain brieﬂy why!

Bob Bates: 1. Corporate politics and how and why games get built or can- celled. The market realities in our business are brutal, and the economic models are changing all the time. The only way to learn about this is to get slapped in the face with it.

2. Corollary to the ﬁrst: Game development is not a stable job. Companies come and go, projects rise and fall. The burnout rate is high. Anyone looking for security should look some- where else. It’s hard for a college student to understand the choices that developers are often forced to make: “Do I take the uninteresting job with the company that looks stable, or do I take the interesting job with the startup?” Often, the “stable” company may be on the verge of folding, but then again the startup will run out of money quickly. It’s a very tough life, and you have to get used to living on a roller coaster.

To put it another way, I have worked on around 30 games *that have been published* (in addition to others) and I have *never* had a project go from beginning to end without at least one major crisis during which we thought the whole thing, or possibly the whole company, would go up in smoke. I don’t think you can teach how to react to life-wrenching trauma like this – you can only experience it and ﬁgure out how to deal with the particulars of each case, over and over again. A.2 Five Questions for Four Game Industry Veterans 125

3. Collaboration. You can study theory until the cows come home, but the fact is that games are made by groups of people who constantly have to make compromises with each other. To the extent that schools put groups of people together to work on projects, the student will be exposed to this, however, it is never something that can be learned from a book. The give and take of getting something built is, again, something that must be lived through to be understood.

A.2.2 Interview with Jochen Hamma

Jochen Hamma was the co-founder and managing director of “attic Entertainment Software GmbH” (1989), where he lead projects and quality assurance for more than 15 AAA titles. Today, he is a successful freelance producer, game and interface designer of both, mobile and PC titles.

Jochen Hamma: Deﬁnitely. I do recommend using Virtools for students new to the subject. Teams with good coding and art skills might be willing and able to use Renderware, Vision or Nebula instead. Local middleware solutions are preferred by students, as they can get hints and feedback from the creators of such packages more easily.

My Question: If a course aims at teaching computer science students the basics of game design (which, of course, they cannot learn during a semester) what areas of game design should it focus on?

Jochen Hamma: Brieﬂy introducing game critique - that to say helping them understanding and analysing other (and their own) games (why do they work, why don’t they work). Based on these skills a game design course should be introducing the most interesting game design skills and techniques during the game design process (high concept, game design document writing, designing features...). 126 Appendix A Interviews

Probably one of the most important things to learn is bringing critique skills and design skills together in very short time spans - by discussing the ideas with team members and other project teams (at least once a week), building on the results of the discussions and constantly iterating to better designs like that.

An issue mostly forgotten in game design courses is interaction design. As you access board games directly and you mostly have to use keyboard or mouse devices to access games - interface design is critical. Good game design hidden behind bad interfaces will never be able shine. Bad game design implemented in some easy to use and fun interface can at least offer a couple of minutes with some fun value for the player.

My Question: One idea that I have been researching in my thesis is that object- oriented software engineering and game design somehow complement each other, because you have to think in units. If you subdivide a game into certain ingredients that interact with one another, you get an object-oriented model as well. A game is not more than many connected objects on an abstract level. Do you think that game design and object-oriented programming can learn from each other?

Jochen Hamma: Probably yes. However, the components you would get, if you create an image of the units of a game to be built by programmers and game designers on one single paper, will be more matrix-oriented. The main areas of good game design according to the “flow” concept (goals/feedback/rewards, appropriate difficulty level, discovery, social needs/bragging rights, flow protection, control/power) will have to be reflected in every single feature programmed [Csikszentmihalyi91]2. On the other hand, if you want to create goals/feedback/rewards, you need every single component of the code programmed (visuals, sound, AI, ...). Both - game design and implementation - may use an object oriented design, but their components will be completely different.

My Question: What can and cannot be learned from using game design tools? Should computer science students learn to think outside the box, and create pen-and-paper-based games as well? What contents would be most necessary for a semester course?

2 A research on the ﬂow concept was also done by [Boettcher05] A.2 Five Questions for Four Game Industry Veterans 127

Jochen Hamma: When it comes to game rules, then board games are very interesting as a good source. However, the most interesting part of gameplay does not result from rules (my opinion) it more emerges from Salen/Zimmermans - PLAY - component of games, what others (maybe Crawford) would probably name “interactivity”. Designing a board game as a prerequisite to designing computer games is not bad. That approach is widely used at universities and schools already (Uni Stuttgart, ETH Zürich, Games Academy Berlin).

My Question: Name three peculiarities that - to your mind - college cannot teach you about game development! Explain brieﬂy why!

Jochen Hamma: 1. You can learn a lot about project management, programming, interface and game design as well as graphics at Universities. However, students don’t get paid for their work. Expectation level for university projects is mainly driven by intrinsic student motivation. Expectation level in the industry is driven by extrinsic factors like publisher’s or lead stuff expectations and competitive standards. That makes the biggest difference.

Extrinsic expectations will have to be met - intrinsic expectations can be adjusted and modiﬁed on the ﬂy - it just depends how well the project is on its way. Therefore, students should have a chance to work with real projects in the industry for at least 6 months - even better for one year.

2. Professional Game Development teams do have clear hierarchical structures. If the lead designer decides which way to go, other designers will have to follow his guidance. In most of the student teams I know, a structure with clearly deﬁned responsibilities is completely missing. Building structures which work is something which can hardly be taught at Universities.

3. Rating the skill level. It is important to rate one’s skill level compared to people from the industry. Without a clear rating of one’s skill level, an understanding of the worldwide competitive level and with knowledge of the skill level of 128 Appendix A Interviews

some of the best people in the industry it is hard to understand what has to be learned (skills and knowledge) to make it to the desired position in the games industry. Students with contact to some of the best people have better chance to rate their skill level.

A.2.3 Interview with Bruce Shelley

Bruce Shelley is developing “Age of Empires 3” with Ensemble Studios, which he has been working for since 1995 as a game designer for the “Age” series. His past career includes working for Microprose in 1987 and helping Sid Meier with the game design for “Civilization”.

Bruce Shelley: I think so. The technology is not key. Understanding what makes games entertaining is critical. Technology is just the canvas we paint on, so to speak. The real rocket science is creating entertainment. When I made board games we put together prototypes long before we had written rules. It was essential that we get playing and that is still true today. Prototype early and design by playing. Technology that gets you to playing is good.

My Question: If a course aims at teaching computer science students the basics of game design (which, of course, they cannot learn during a semester) what areas of game design should it focus on?

Bruce Shelley: I would focus on creating interesting decisions for the player to make. The best games pose interesting decisions. I would compare games that are successful with those that are not and try to ﬁgure out why that is. Being able to analyze good and bad gameplay is essential. Bad gameplay usually means the decisions the player is making are not interesting.

divide a game into certain ingredients that interact with one another, you get an object-oriented model as well. A game is not more than many connected objects on an abstract level. Do you think that game design and object-oriented programming can learn from each other?

Bruce Shelley: Sorry but I don’t really understand this question. I am not a programmer and don’t understand what object oriented software engineering is.

Bruce Shelley: Game designers should play all types of game, especially board games. They aren’t that different. What makes them work applies to video games as well. Game design tools should speed the process of making a prototype that you can play. Then you continually play, make adjustments, redesign, play, readjust, etc. This is design by playing. Games are not engineering problems. Rely on your instinct as a gamer to tell you when it is fun to play and when it is not. We had a playable prototype for Age 3 within 6-8 months and have played it nearly every day since.

My Question: Name three peculiarities that - to your mind - college cannot teach you about game development! Explain brieﬂy why!

Bruce Shelley: As I say above, you either have the instincts of a game player or you don’t. If you do, you should be able to tell by playing when a game is working or not. To be good at this you need to be able to offer solutions when things are not working right. I don’t think those instincts can be taught. They come from playing lots of games, having an analytical mind, and being open minded.

Designers have to have vision and I don’t know if that can be taught. You look at a game and see how it could be different. But it also has to have wide appeal to be successful, so you have to be broad minded and think about what will be fun for lots of people, not just you. I don’t know that anything else can’t be taught. 130 Appendix A Interviews

A.2.4 Interview with David A. Smith

David A. Smith is currently one of the lead architects of the Croquet Project, where he focusses on creating 3d object based architectures. His past career includes working on a virtual camera system. James Cameron used it for his movie “The Abyss”. David A. Smith also created “The Colony”, the ﬁrst 3d interactive game on a Macintosh computer in 1987. Also, he co-founded Red Storm Entertainment with Tom Clancy and Timeline Computer Entertainment with Michael Crichton.

David A. Smith: Possibly. Game design is very much multidisciplinary today. That is, unlike when I wrote my ﬁrst game where I did everything, today you need entire teams of people to develop. More often than not, the actual game designer is not even a programmer. The areas of expertise required today are numerous. Here are a few of the main ones:

• Game designer. Basically a story-teller. A person that figures out what worlds to build, and what happens in those worlds. • Graphics programmer - at one time the most important, rapidly becoming the least important member of the team. It is important to have flashy effects, but that is not important if the game design and story are bad. • AI programmer - very important if the game wants to achieve some level of realism with the game characters. • Game architecture designer - game engines are far more complex, especially given demands for multi-user. This requires a well designed game OS that is open and flexible enough for the developers to easily extend. • World designers - this is a production lead designer. Differ- ent from the artists, though they probably report to the world designer. Focus on standard look to the world and making the game designers ideas come to life. A.2 Five Questions for Four Game Industry Veterans 131

• World artists, animators - these are the guys that make the world designers ideas real.

What this means is that game development frameworks only present part of the solution, and perhaps the least important part. They create a world where the rendering will happen, but the important part of the process is in the actual game design and the artwork.

My Question: If a course aims at teaching computer science students the basics of game design (which, of course, they cannot learn during a semester) what areas of game design should it focus on?

David A. Smith: This is a lot like asking “If I want to learn to make movies, what aspects of movie making should I focus on?” You can do a survey course, where you talk about being a director, actor, cinematog- rapher, (even criticism) etc, but the only real way to learn to make movies is to make movies. If you focus on just one area it is like the blind men and the elephant attempting to ﬁgure out what elephants are by touching one part of their bodies. In a real sense, the most important aspects of building computer games is working as a team with a diverse group of talented people.

David A. Smith: Depends on the game of course. The kinds of games I like to do - recreations of possible worlds, pretty much require an object oriented approach - the later bound the language, the better. Programming is essentially a translation task, especially simulation, where we take some concrete idea and attempt to describe it in a way that a computer can understand. Objects make this translation task far easier. 132 Appendix A Interviews

David A. Smith: This touches on the core idea of game design - games must be fun. The tools we use to express these games have NO effect on how good a game is. Only the designers abilities to understand what people like doing, what will surprise and excite them, what will keep them coming back for more matters in game design. A game with poor graphics and great gaming will ALWAYS beat a game with great graphics and poor game design. Focus on this aspect - real game design - no matter what the medium. Code can often just get in the way of a good idea.

My Question: Name three peculiarities that - to your mind - college cannot teach you about game development! Explain brieﬂy why!

David A. Smith: 1. Telling a story. 2. Understanding what might be fun. 3. Seeing the world through other people’s eyes. Appendix B

Figures and Tables

B.1 Middleware and Tools

Middleware Graphics G a H Audio m o e

● b

OGRE ● ● ● ●

b ● ● De FMOD Irrlicht y

● R R 3 G Miles (RAD Game Tools) ● v

Genesis 3D D PG e e a ● a m Sensaura gameCODA ● l OpenGL G o l

i e M p ● t ● a

OpenAL y Direct3D m m a M

F k e a e a e

k n ct r S e

t t X o r

Physics u S P r d y u

Video i Artificial Intelligence o i

● t

Havok e

● s ● Bink & Smacker ODE ● AI.implant ● (RAD Game Tools) Novodex ● DirectIA SDK ● Meqon ● SimBionic P r

Networking Other o ● ● ● ● f e s ● ● s

butterfly.net SpeedTree (Tree Generation Middleware) T U R Gam i r e n ● ● o i n

Quazal MASSIV (MMOG Middleware) n r n e d ● i a g e Mobile Gaming Middleware a e l y b l r

W ry E V n i a o s g r i i o e n n

e S

S t 3 u D d K i Asset Management Multimedia Authoring Environments o

● Alienbrain Studio ● Macromedia Flash ● Perforce ● Macromedia Director

Figure B.1: Middleware, game development suites and asset management tools.

133 134 Appendix B Figures and Tables

B.2 The Game Development Pipeline

Concept Phase Money Acquisition Gathering Ideas Theme Funding

Pre-Production Phase

Gameplay Prototyping Publisher Physical Prototype A Q

n Financial Plan

i Presentation t s e t ay l

P Software Prototype Production Planning

Design Document ● Task Breakdown ● Story ● Priorities ● Gameplay/Mechanics ● Milestones ● Characters ● Scheduling ● Levels ● Resource Management

Prototyping Cycles Phase

Artwork Production Tools A

● Models/Textures ● ● Level Creation s

Coordination s

● ● ● e

Animations Tasks and Milestones Effects t

● Maps ● Priorities ● Control Animation M an ag

Sound e Engineering Game Design m ●

Sound Effects e ● Engine Developers ● Gameplay n

● Game Mechanics ● Levels t ● Scripting ● Characters Quality Assurance ● System Conception ● Story ● Iterative Testing

Full Production Cycles Phase

Artwork Production Localisation A ● ● ● Models/Textures Coordination/Scheduling Translation s s

● Animations ● Milestones e t

● ● Maps Priorities M

Sound an ●

Score Composition ag ●

Sound Effects e Engineering Game/Level Design m ● ●

Engine Refinement Gameplay e

● ● n Game Mechanics Levels Quality Assurance t ● Scripting ● Characters ● Iterative Testing ● System Refinement ● Story ● Bugtracking

Figure B.2: The iterative game development process using the concepts suggested by [Mencher03, ElectronicArts05, Fullerton04, Bethke03] and [Masuch05] B.3 Game Engine Overview 135

B.3 Game Engine Overview

Core Game Engine e

Main Loop c Music & Sound n e

Audio g i

Engine l l e

Timer t n I

Output l a i

2d or 3d c i f

e Graphics i t r Engine Event r a r Handler A e w s d s r U c a i s H Input Controls User Interface y Ph n o dynamic i at l

Network Client Control game data u m i S e l r a a n o w t Software e e ti l

N Interface

di static dd d i game data A M

Figure B.3: A conceptual overview of a game engine based on Masuch [Masuch05] 136 Appendix B Figures and Tables

B.4 Mini Games

Figure B.4: The ingredients of casual mini games that were analysed for creating the prototyping tool LeGaCy. B.5 Common Development Tools 137

B.5 Common Development Tools

Area of Game Development Standard Tools Audio Steinberg Nuendo Sony Soundforge The Miles Sound System (RAD Game Tools)

Game Engine RenderWare Platform Gamebryo (from NDL) Unreal Engine Valve Source Engine Doom/Quake Engines Trinigy Vision Game Engine GarageGames Torque Game Engine OGRE

Avid Alienbrain Studio Software/Asset Management Perforce Subversion

3D Animation Autodesk 3ds max Alias Maya Avid SOFTIMAGE|XSI NewTek Lightwave 3d

Artwork Adobe Photoshop Adobe Illustrator

Programming Visual Studio 2005 MetroWerks CodeWarrior Eclipse

Project Management ProWorkflow (from ProActive Software) Microsoft Office Project Groove Virtual Office PhpCollab Open Workbench

Prototyping and Multimedia Authoring Macromedia Flash Professional Macromedia Director MX Dassault Systèmes’ Virtools Dev

Quality Assurance Flyspray phpBugTracker Mantis BT Bugzilla TechExcel DevTrack TechExcel DevTest Mercury TestDirector Seapine TestTrack Pro JIRA (from Atlassian Software)

Table B.1: An shortened list of some of the more important tools used in the game development process.

Index

Symbols API, 23 3ds max, 137 C#, 47 Croquet, 47, 53 Numbers developer, ii, 2, 102 1942, 64 DLL, 72 A E3, 103 game engine, 6 AI, 26, 33 GCDC, v Alienbrain, 43, 137 GDC, 14, 102 Architecture GML, 41 of LeGaCy, 68 GUI, 39 Artwork, 17 IGDA, ii Asset Management, 16 LeGaCy, 7 Aura, 72 middleware, 6 Aura: Fate of the Ages, 72 Monticello, 80 B NPC, 19 Break-Out, 64 patch, 23 Breakout, 64 Pitch, 10 publisher, 2 D SCM, 16 Design document, 15 Smalltalk, 28 Doom, 2, 121 Squeak, iii XML, 34 F XNA, 47 Funding, 12 GML, 102 G H Game Design, 18 Half-Life 2, 2 game engine, 137 Game Maker, 40, 115–121 I GML, 118 Idea, 12, 13, 15, 26, 42, 47, 49 Gamebryo, 137 Interview Glossary Terms with Bob Bates, 122 add-on, 18 with Bruce Shelley, 128

139 140 Index

with David A. Smith, 130 UPGEAR, 120 with Jochen Hamma, 125 with Mark Overmars, 115 V Vision SDK, 137 L Level Design, 23 M Macromedia Flash MX, 39 Miles, 137 Myst, 73 P Pac-Man, 64, 89 PONG, 1 Pong, 1, 64 Production, 15, 18 Prototype, 14 Prototypes Deﬁnition, 27 Q QA (Quality Assurance), 20 Quality Assurance, 19 R RenderWare, 38, 137 S Söldner, 103 Sacred, 103 SCM, 137 Scripting Lua, 28 Python, 28 Ruby, 28 Space Invaders, 64 SpeedTree, v, 36 Spellforce 2, 36 T Tennis for Two, 1 Tetris, 64 The Fall, 103 The Sims, 89 Tools, 18 Trinigy Vision SDK, 37, 41 U Unreal Engine, 38, 48, 49, 137 Declaration

I declare, that the present work has been created independently by myself. No other than the references and aids listed herein have been used.

Magdeburg, November 04, 2005

No part of this thesis may be reproduced in any way, stored in a retrieval system of any type, or transmitted by any means or media - electronic, mechanical, or other - including, but not limited to, ﬁlesharing, photocopy, recording, or scanning, without explicit prior written permission from the author. The author shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this thesis or visiting the internet links contained in it.

i Lennart Nacke B Mittelstr. 51 39114 Magdeburg Germany

T (+49) 391 531 66 91 k [email protected] http://thesis.pxfx.de

Final Version