Facilitating the Education of Game Development

Transcription

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 Grafik
Arbeitsgruppe Grafische und Interaktive Methoden für Computerspiele
Diplomarbeit
Facilitating the Education of Game Development
L ENNAR T N ACKE
Matrikel-Nr. 159745
Date of Submission:
Examiner:
November 04, 2005
Prof. Dr.-Ing. M AIC M ASUCH
Dr.-Ing. K NUT H AR TMANN
Supervisor:
Processing Period:
Prof. Dr.-Ing. M AIC M ASUCH
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 indefinite 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.
c 2005 by Lennart Nacke. All rights reserved.
Abstract
This thesis focusses on game development and educational benefits 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 specific 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 S QUEAK into play. After showing the educational benefits of Squeak, one can find 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.
A LAN K AY
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 finished 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 proofread my alpha versions of this thesis and helped me improving it. They also consistently 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 defining software defects in the quality assurance workflow.
Finally, of course, thanks to my family especially my parents, Wolfgang and Anne
Nacke, for their incredible moral support, love and encouragement - and my girlfriend Ellen Zacher, who supported me during the writing of this thesis in every
possible way. Thank you.
Lennart Nacke, November 2005
v
Contents
1 Introduction
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Research Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Structure of This Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Basics of Game Development
2.1 The Game Development Process . . . . . . .
2.1.1 Concept . . . . . . . . . . . . . . . . .
2.1.2 Pre-Production . . . . . . . . . . . . .
2.1.3 Prototyping . . . . . . . . . . . . . . .
2.1.4 Full Production . . . . . . . . . . . . .
2.2 Traditional Software Development vs. Game
2.3 Game Prototypes in Iterative Development .
2.4 Summary . . . . . . . . . . . . . . . . . . . .
1
2
3
6
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
Development
. . . . . . . .
. . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
12
13
16
19
24
27
29
3 Game Development Tools
3.1 More Than a Collection of Middleware: The Game Engine
3.2 General Definition of Middleware . . . . . . . . . . . . . .
3.3 Game Development Suites . . . . . . . . . . . . . . . . . .
3.3.1 Macromedia Flash . . . . . . . . . . . . . . . . . . .
3.3.2 Game Maker . . . . . . . . . . . . . . . . . . . . . .
3.3.3 Vision SDK . . . . . . . . . . . . . . . . . . . . . . .
3.3.4 Important Aspects of Development Tools . . . . . .
3.4 Defining Classes for Game Development Tools . . . . . .
3.5 Progress and Future Game Development Strategies . . .
3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
31
34
38
39
40
41
42
44
46
49
.
.
.
.
.
.
.
.
.
.
.
51
51
52
55
56
57
57
58
58
59
61
62
4 Developing a Concept for an Educational Prototyping Tool
4.1 Game design vs. Game development . . . . . . . . . . . . . .
4.2 Adequate Education for Jobs in Game Development . . . . .
4.3 Teaching Focussed on Developer Tasks . . . . . . . . . . . .
4.3.1 Game Designer . . . . . . . . . . . . . . . . . . . . . . .
4.3.2 Producer . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.3 Game Programmers . . . . . . . . . . . . . . . . . . . .
4.3.4 Game Artists and Animators . . . . . . . . . . . . . . .
4.3.5 Conclusion for Education . . . . . . . . . . . . . . . . .
4.3.6 Advice from Professionals . . . . . . . . . . . . . . . . .
4.4 Game Development Tools used to Facilitate Game Education
4.5 Towards an Educational Game Prototyping Tool . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vii
viii
Contents
4.5.1 Requirements Analysis for a Game Prototyping Tool
4.5.2 A Proposal for an Architecture of a Prototyping Tool
4.6 Conclusion for the Implementation of a Prototyping Tool .
4.6.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . .
5 Implementation of a Game Prototyping Tool
5.1 Game Development in Smalltalk . . . . . . . .
5.2 The Development Environment . . . . . . . .
5.2.1 Squeak . . . . . . . . . . . . . . . . . . .
5.2.2 Tweak . . . . . . . . . . . . . . . . . . .
5.2.3 The iEngine . . . . . . . . . . . . . . . .
5.3 LeGaCy - A Tool for Rapid Game Prototyping
5.3.1 User Interfaces in LeGaCy . . . . . . .
5.3.2 The Features of LeGaCy . . . . . . . . .
5.4 A Game Prototyping Example . . . . . . . . .
5.4.1 The Game Idea . . . . . . . . . . . . . .
5.4.2 Demonstration . . . . . . . . . . . . . .
5.5 Summary . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Summary and Conclusion
6.1 Results of This Research . . . . . . . . . . . . . . .
6.2 Discussion . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Critical Review . . . . . . . . . . . . . . . . .
6.2.2 Advantages and Disadvantages of Game
Squeak . . . . . . . . . . . . . . . . . . . . . .
6.3 Future Work Perspectives . . . . . . . . . . . . . . .
6.4 Personal Remarks . . . . . . . . . . . . . . . . . . .
6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
63
68
69
70
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
71
71
73
73
77
79
81
82
84
89
89
91
91
. . . . . . . .
. . . . . . . .
. . . . . . . .
Development
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . .
. . . .
. . . .
with
. . . .
. . . .
. . . .
. . . .
93
93
95
96
96
97
98
99
Glossary
101
References
105
A Interviews
A.1 Interview with Mark Overmars . . . . . . . . . . .
A.2 Five Questions for Four Game Industry Veterans
A.2.1 Interview with Bob Bates . . . . . . . . . .
A.2.2 Interview with Jochen Hamma . . . . . . .
A.2.3 Interview with Bruce Shelley . . . . . . . .
A.2.4 Interview with David A. Smith . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
115
115
122
122
125
128
130
B Figures and Tables
B.1 Middleware and Tools . . . . . .
B.2 The Game Development Pipeline
B.3 Game Engine Overview . . . . .
B.4 Mini Games . . . . . . . . . . . .
B.5 Common Development Tools . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
133
133
134
135
136
137
Index
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
139
1 Introduction
The only legitimate use of a computer is
to play games.
(E UGENE J ARVIS )
Although people have played games since the beginning of humankind, it was not
until in 1958, when the physicist William A. Higinbotham developed T ENNIS FOR
T WO that games would find their way into computers [8BitMuseum05]. It took more
than ten further years for games to conquer the amusement arcades around the
world, when the P ONG-phenomenon spawned the global video game mass-market
in 1972 [Mertens02, Lischka02]. Figure 1.1 shows a screenshot of P ONG.
Today, an increasing number of the living population 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 fascinate scientists, but the educational contexts
of some games are also useful. This especially
applies for computer science, because game
development incorporates almost every aspect
of it.
Figure 1.1: One of the first video
games in history: PONG.
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 D OOM
[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 Internet are reaching new heights with the release of
H ALF -L IFE 2 and its accompanying software “Steam” by
Valve1 [Hodgson03]. The software is shown in Figure 1.2.
Figure 1.2: A screenThis novel approach has the potential to change game
shot 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-conflict
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-specification than a casual game developed by
non-professional programmers.
After prior reflections 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.
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 Magdeburg). 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.
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
final games. Creating such game prototypes can also serve as a quality analysis for
tools, since the games are typical “first” 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 benefits 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
classified. 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 classification
made to differentiate between them. The final 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 definition clarifies 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 fill, a description of the most important jobs in game development follows. The
subsequent paragraphs depict some experiences of teaching towards these profiles.
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. Finally, 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 benefits of its different
interface-toolkits.
1.3 Structure of This Thesis
7
Next, an outline of implemented classes of the prototyping tool L E G A C Y5 is given. It
discusses thoughts on the interface, introduces details of the program library, and
shows how to extend or reuse them. Before finishing, 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 first name, for details see glossary.
You have to learn the rules of the game.
And then you have to play better than
anyone else.
(A LBER T E INSTEIN )
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 first 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
G 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.
F Forming an Idea
F Designing the Idea to get Funding
G 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.
F
F
F
F
Gameplay Prototyping
Pitching1 the Prototype
Planning the Production
Writing a Design Document
G Prototyping
Several prototypes are produced in a collaborative effort. The designers produce a framework, around which the game will be built. The prototypes are refined until they reach a
mature stage (e.g. a stable organisation of features) where full production starts.
F
F
F
F
F
F
Artwork and Sound Creation
Engineering Developers
Production and Management
Game Design
Tool Programming
Quality Assurance
G Full Production
This is the final development stage, before the game is finished and the gold master2 is
handed over to marketing and distribution. The focus is on reaching several milestones
and avoiding critical bugs.
F
F
F
F
Art Focus
Production Focus
Programming Focus
Level Design Focus
1 see glossary: P ITCH
2 A term for the completed game that will ship to stores.
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 definition 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 Figure 2.1) mix very well with the abstract outline given in [Masuch05] and the more informal
workflow sketched by [ElectronicArts05].
Figure B.2 in the Appendix B shows a workflow
diagram of the incremental development phases
that are subsequently discussed in more detail.
The pipeline has a strong focus on these layers of production that each contain iterative revisions of the ideas and prototypes generated
within them. The stages are described, however,
without any claim for completeness.
Figure 2.1: An outline of iterative development as sketched by
[Fullerton04].
Although the specific 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 refinement of the
game), collaborative, interdisciplinary teamwork and economy-focused production
constraints will be highlighted as essential parts of the following phases.
Concept Phase
Gathering Ideas
Money Acquisition
Theme
Funding
Pre-Production Phase
Figure 2.2: The concept phase is the start of every game project
12
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 first 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 first game design is fuzzy, as some
development studios prefer to first 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 .
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 first 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
Playtesting / QA
Game Design Prototyping
Publisher
Physical Prototype
Financial Plan
Presentation
Software Prototype
Production Planning
Design Document
●
Story
●
Gameplay/Mechanics
●
Characters
●
Levels
●
●
●
●
●
Task Breakdown
Priorities
Milestones
Scheduling
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 finish. 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 find 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
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 Association (IGDA) hosted “Quality of Life”-panels at the Game Developers Conference
(GDC) in 2005.
After the first 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 first playable game version.
This stage itself - like game development - should be iterative and aim at refining
(a) A physical game prototype example from
[Fullerton04].
(b) A “paper computer” prototype developed
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.
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 fleshed 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, OpenOffice).
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
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 first game spec-
Prototyping Cycles Phase
Production
●
Coordination
●
Tasks and Milestones
●
Priorities
Tools
●
Level Creation
●
Effects
●
Control Animation
Engineering
●
Engine Developers
●
Game Mechanics
●
Scripting
●
System Conception
Game Design
●
Gameplay
●
Levels
●
Characters
●
Story
Sound
●
Sound Effects
Asset Management
Artwork
●
Models/Textures
●
Animations
●
Maps
Quality Assurance
●
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.
ifications, made in the design document and seen in the first software prototype,
8 Acronym for Personal Information Management.
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 final 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
Black for the game I CEWIND D ALE (Black Isle
Studios).
(b) Concept art by Nicolas Bouvier (aka Sparth)
for the game P RINCE OF P ERSIA : WARRIOR W ITHIN
(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
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 threedimensional models. Animators have to imagine, how those models will behave and
animate them, so they fit 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 communicaFigure 2.7: Alienbrain Manager Client is an
tion channel. Tools for this task
application that tracks all changes made to the
are chat and Voice-Over-IP clients
files in a project and communicates those with
(like Skype, ICQ, Yahoo Messenger,
a central server for sharing them with internal
MSN Messenger, AOL Instant Mesand 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 modification of the original game to add new features and
content.
19
Game Design
Game designers not only take responsibility for the gameplay, they work a lot on
the story as well. During prototyping they flesh 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 workflow 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
Most of the development resources are then part of quality assurance, and bug
fixing. Figure 2.8 shows the last part of the game development pipeline, which is
reached when finishing the full production stage.
Full Production Cycles Phase
Production
●
Coordination/Scheduling
●
Milestones
●
Priorities
Engineering
●
Engine Refinement
●
Game Mechanics
●
Scripting
●
System Refinement
Game/Level Design
●
Gameplay
●
Levels
●
Characters
●
Story
Localisation
●
Translation
Sound
●
Score Composition
●
Sound Effects
Quality Assurance
●
Iterative Testing
●
Bugtracking
Asset Management
Artwork
●
Models/Textures
●
Animations
●
Maps
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-fixing. 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 classification of software
defects. Some exemplary defect types tracked by a game company are:
Z 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.
Z 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 fix those issues.
14 A state, where no more features are added to the game.
21
Z 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.
Z Aesthetic Errors
Often graphical errors with little or no effect on gameplay fit this category. Graphical
bugs can be very annoying to players, but can often be fixed quickly by the developer.
Figure 2.9 shows some popular graphical bugs.
(a) A graphical bug in the PC game S ACRED de- (b) A bug in the graphics of the game VAMPIRE : T HE
veloped by Ascaron.
M ASQUERADE - B LOODLINES by Troika Games (Activision).
Figure 2.9: Several graphical software defects from different retail versions of computer
games.
Z 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.
Z Big Error
Depending on the influence 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.
Z Program Crash
Severe code problems, like memory leaks, can cause the game to crash.
22
Z Blocker
These are the most severe software defects that block further development or lead to
repeating crashes. Most of these issues can be fixed during regression testing. If this
kind of defect is discovered later, it can become harmful to the further development
schedule and needs to be fixed 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 notification applications
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 fixed 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 finish 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 first 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,
artificial intelligence, and network capabilities. Then the game reaches its release
state: gold master.
24
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 fix 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 fixed 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 specific requirements specifications, 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
Ý
Ý
Ý
Ý
Ý
Ý
Ý
Ý
Ý
Ý
Ý
Flat hierarchy structure
Interdisciplinary teams
Non-deferrable project schedule
Harder planning
Informal skill improvement
Contract work, similar to the movie industry
Constantly educate yourself
Latest technology is most important
Graphics are important
Younger age of employees
Multimedia integration
Traditional IT Industries
Ý
Ý
Ý
Ý
Ý
Ý
Ý
Ý
Ý
Ý
Ý
Traditional hierarchy structure
Advanced training
Stability is more important
User Interface matters less
Long lasting support for products
Classic contracts
Coders and software engineers
Graphics are less important
University degrees matter
Former education is important
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
first.
The flatter 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
flexible development team can adjust to requirement changes quickly. However,this
might lead to problems with recognition of personal achievements, and some individuals 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 difficulties 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 flexible.
The project schedule is non-deferrable, giving a very narrow time-frame for the
milestones and the final 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 fighting 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 final product is much more important. This is especially true for certain indus-
26
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 final 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 qualified 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
fields 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 financing of projects). Before people can see the
game on the shelf, its development needs to be financed 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 first 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
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 refine, test, and structure game ideas, as well as
software.
With them, developers define a rudimentary skeleton that can be referenced when
entering game production. [Rollings03, pp.617–623] also call it a “preproject investigation” 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 efficient code and use most resources for
speed, prototypes just display the idea
of gameplay.
Thus, Rollings et. al. advise game deFigure 2.12: Prototype of the game “Good
velopers to use a different language
Bugs, Bad Bugs”, produced in Squeak by
students of the game design course at the
or tool for programming the prototype
Otto-von-Guericke University.
than for the final game [Rollings03].
Since most games are programmed in
low-level languages like C or Assembly, a fresh approach would be to use a highlevel language like S MALLTALK 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 financial 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 final 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.
We shape our tools and then our tools
shape us. We become what we behold.
(M ARSHALL M C L UHAN )
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 defined.
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 final 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.
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
• 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 opensource 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.
Music & Sound
Engine
Main Loop
Timer
2d or 3d
Engine
Controls
User Interface
Network
Client Control
Software
Interface
Event
Handler
Physics
Graphics
Additional
Middleware
Net
Input
Hardware
User
Output
dynamic
game data
Simulation
Audio
Artificial Intelligence
Core Game Engine
static
game data
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.
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 efficiently 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 fit 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 specific 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 artificial
intelligence. Many of these factors have their origin in the first gameplay prototype,
and early prototyping in game design is making the choice for the tool-combination
much easier.
34
Requirement-Specific Genre Specialisation
of a Graphics Engine
T hree-Dimens ional (3D)
High-E nd 3D Graphic s
R egular 3D Graphic s
T wo-Dimens ional (2D)
High-E nd 2D Graphic s
L ow-E nd 2D Graphic s
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 Definition 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 first 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:
35
Game Application
Middleware
Other Applications
(or Hardware)
(a) Middleware
[Naur68]
defined
by
d’Agapeyeff
(b) Middleware shown as an abstraction
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.
• Artificial 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
• Video
For so-called “Cut-Scenes” that refer to pre-rendered video sequences played in a
game after finishing 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
Graphic s
Audio
●
●
●
Artific ial Intelligenc e
●
●
●
AI.implant
DirectIA S DK
S imB ionic
●
●
●
OGR E
Irrlicht
Genes is 3D
OpenGL
Direct3D
Networking
●
●
butterfly.net
Quazal
Game
Video
●
B ink & S macker
(R AD Game T ools )
P hys ic s
●
●
●
●
●
Havok
ODE
Novodex
Meqon
Ageia
Middleware
Vers ion Control
●
●
As s et Management
●
F MOD
Miles (R AD Game T ools )
S ens aura gameCODA
OpenAL
Other
●
●
●
S peedT ree (T ree Generation Middleware)
MAS S IV (MMOG Middleware)
Mobile Gaming Middleware
(a) Different flavours of middleware in game development.
Another Application
(b) Differentiation between middleware and asset 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 S PELLFORCE 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 files, 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.
37
They work on a more separate layer and organise the game code as well as the files
that come from external applications. This process is outlined in Subfigure 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 benefits for developers.
• High-level abstraction
Middleware allows developers to define the level of granularity they work on by abstracting low-level functionality.
• Interfaces allow for mixing custom middleware
With common interfaces defined between middleware applications and game engines,
it becomes easier to integrate and combine custom tools for special game-specific
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 artificial 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 fits 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 fix 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 fixing the meal themselves. Much
the same is true for middleware, which offers a certain service that takes tasks off the developers’
shoulders.
38
RenderWare Studio and Unreal Engine 3 offer a tools suite for sound, artificial
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
●
●
●
●
Gamebryo
RenderWare Studio
Unreal Engine 3
Trinigy Vision SDK
Non-Professional
●
●
●
●
●
●
Game Maker
3D Game Studio
Reality Factory
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 find
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.
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 lessexperienced 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 first 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 file format.
It combines the ease of use with an intuitive interface, a small output file 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 file.
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
(a) The GUI of Macromedia Flash MX
(b) The Game G IRLS I NC . T EAM UP developed by
Large Animal Games.
Figure 3.6: The Macromedia Flash MX interface and a screenshot of a casual game
developed with it.
always identifiable 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 Subfigure 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 defines 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 defined separately and can be attached to
behaviours in objects.
(a) Screenshot of Game Maker’s GUI.
41
(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 define
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 definitely 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
(a) vEditXP is a scene creation tool that easily integrates content created in other modelling packages.
(b) D ESPERADOS 2 is a game currently in development with Trinigy’s Vision SDK by Spellbound
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 Programming 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 fits 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 flexibility by giving
6 And high-level programming languages.
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 first encounter with game development in the form of making
a modification 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.4 Defining Classes for Game Development Tools
No classification 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 classification 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 classified 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 specified goal. It concerns only the
final 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 lowlevel functionality. This provides means for optimising final 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 final game. The better the game graphics are
and the more fluent 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 flexibility. Extensible tools always provide a high level of flexibility.
46
Of course, this classification 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 Developer 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
finding 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 finding the best features of each tool.
Q UALITIES
C LASSES
Professional
Non-Professional
Multimedia Environments
Effectiveness
⊕⊕
⊕
⊕⊕
Efficiency
⊕⊕
⊕
Learning Curve
⊕
⊕
⊕⊕
⊕
Scalability
⊕
Creativity
⊕
⊕⊕
Low-level tuning
⊕⊕
Graphics & Animation
⊕⊕
⊕
Sound
⊕⊕
⊕
⊕
Flexibility
⊕⊕
⊕
⊕
Extensibility
⊕⊕
Satisfactory
sults
Re-
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
[Sheffield05]. Moreover, with the arrival of next generation consoles and multiprocessor 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 C ROQUET
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 benefit 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
(a) UnrealCascade, a visual particle system editor.
(b) Unreal Kismet Visual Scripting Editor
(c) Unreal AnimTree Editor edits a tree of animation nodes.
(d) Unreal Matinee Animation System
(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 specific code from
the hardware-abstraction code were introduced, leading to the definition of a game
engine.
After looking a the general setup of a game engine, middleware applications and
their main fields of use in games were highlighted, clearly stating the benefits 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.
(G OTTFRIED B ENN )
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 classified
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 fits
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 refining a “critical language” for games [Costikyan02], developers use
some terms that need to be defined 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
[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
specific courses [Parberry05, Koelling96]. At “traditional” universities, this subject
is difficult 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 specifically for the needs of
4.2 Adequate Education for Jobs in Game Development
Type of School
Teaching Emphasis
Professional
Private
Training
School (e.g. Games
Academy, DigiPen)
Applications, Industry standard tools
and
programming
languages
University
(e.g.
Otto-von-Guericke
University,
University of North
Texas)
Theory and concepts
behind games as
well as collaboration,
programming,
and
project management
Liberal Arts Facility (e.g. Burg
Giebichenstein,
New Jersey City
University)
Classic art and design. Drawing, painting, computer image
manipulation
Business
(e.g. BITS)
School
Project Management,
Leadership, financial
issues and game design
Writing School (e.g.
Hochschule
der
Medien)
Writing,
narration,
story creation
53
Target Job Profiles
Tools Used
N Game Programmer
N Game Artist/ Animator
N Game/Level
Designer
. Alias Maya
. Virtools
. Nebula SDK
N
N
N
N
Game Designer
Producer
Technical Director
Project Manager
. Autodesk 3ds max
. Squeak
/ iEngine
/ Tweak
/ C ROQUET
. Shark 3d
. Java
N
N
N
N
Concept Artist
2d Artist
3d Artist
Level designer
.
.
.
.
N
N
N
N
Publishing Team
Producer
Management
Consulting
. Microsoft Office
. Microsoft Project
. Entity-RelationshipManagement
N Storywriter
N Dialogue Editor
Paint
Pencils
Canvas
(Adobe Photoshop)
. Microsoft Office
. Final Draft
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 specific, the certificate 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
The target job profiles 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 Subfigure 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
the Games Academy Berlin.
(b) A game programming course taught at the
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 (Subfigure 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 reflection
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 profiles 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 specifically 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, financial 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.
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 specific education for game developers, we have to
consider the very different job profiles 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.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) K ATAMARI D AMACY has won the award
for “Excellence in Game Design” at the 2005
Game Developers Choice Awards.
(b) Keita Takahashi is the game
designer of K ATAMARI D AMACY.
Figure 4.2: The game with the best game design in 2005 was K ATAMARI D AMACY, 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.
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 specifications 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 refined a bit more into these categories:
• Game Code Programmers
◦ Network Programmers
◦ Artificial 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 proficient knowledge
of shader programming.
Artificial intelligence programmers, on the other hand, need to put life into game
objects, or develop elaborate collision concepts. They are skilled at developing
58
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 find 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 finesse 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 fitting university
courses [IGDAEducation03], this research field 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.
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 profit 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 objectoriented design and programming. The playful environment that games exhibit will
enhance their interest in more abstract areas of computer science.
60
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 flexible 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 specific 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.
61
Private academies have the advantage of being more flexible in their curriculum,
which can be altered quickly to fit 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 office and project management software. Sometimes, they also utilise special financial software, which is not quite as
relevant to the games industry.
The major difficulty 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 specific 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 define 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
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 . Computers 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 specific 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
63
4.5.1 Requirements Analysis for a Game Prototyping Tool
The preceding classification 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 definitely that “using” the tool should be equivalent to
“learning” about game development. So, factors like accessibility, scalability, and
effectiveness have a bigger weight than efficiency or fast loading.
In addition to the classification 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 P AC -M AN
by Namco Limited (Midway)
on the ZXSpectrum
(d) 1942 by Capcom was a
vertically scrolling shooter.
(b) T ETRIS by Alexey Pajitnov (Tengen) is the classic puzzle game
(Screenshot of the Commodore 64
version).
(e) The game B REAKOUT by Midway (Midway) and its successor
A RKANOID by Taito (Imagine) were
huge arcade hits.
(c) P ONG was one of the
first video games in history.
(f) S PACE I NVADERS by Taito
(Midway) was ported from
the Arcades to the Amiga
Figure 4.4: The different mini games that were analysed for finding 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
ä 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 T ETRIS, P AC -M AN, 1942,
P ONG, B REAK -O UT and S PACE I NVADERS 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 (T ETRIS, P ONG, B REAKOUT),
an aeroplane (1942), a pizza (P AC -M AN), or a tank (S PACE I NVADERS),
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 surface 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 (T ETRIS), 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 first start of a prototyping tool to have a ready-to-use library of typical game components that can
then be configured 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).
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 defining 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 final 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 defined:
• 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 feasible for a study course that focusses not solely on games, but allows for a
66
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 nonprofessional 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 simplified 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
67
The collaborative nature of game development and the education of joint work
is an obligation. Assigning tasks, meeting deadlines, exchanging files, 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 configuration 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
fly” and see the results immediately encourages the trial-and-error approach,
which is popular for refining 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 fighting with code. An ideal rapid prototyping tool would
support high-level programming and scripting languages, helping to understand game mechanisms.
68
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 configurable 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 foundaWhite Box
Core System
Game Engine
Game Objects
Non-Professional
View
Collaboration
Programmer
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 difficult, 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 define multiple views on the same code base, so that both designer and
programmers can work efficiently 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 flexible
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 objectoriented 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 configure and extend the functionality.
70
Ü 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 profiles for game developers, a closer look at the most important jobs was taken.
With the specific profiles 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.
(D OUGLAS A DAMS )
In this chapter, we will take a closer look at game development with Smalltalk
and Squeak; especially at the benefits 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 Utility”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 efficiently.
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 first name with the intended purpose of use.
71
72
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 proficient 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 system4 , and a whole set of multimedia
tools that makes it attractive for playful exploration.
This playful learning and exploration
of systems is what impara defines as
one of the key visions of the company.
The approach to combine entertainment and education led to the development of a game engine for use within
Squeak: the iEngine.
Figure 5.1: Etoys is a high-level interface
for scripting within Squeak.
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 hierarchies 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 A URA : F ATE
OF THE A GES 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 A URA.
5.2 The Development Environment
73
The game is an explorative adventure game from the first person view, which resembles the popular adventure game M YST. 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 flinch 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.
The benefits 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, Smalltalkdevelopment-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 benefits and details of this special programming environment.
5.2.1 Squeak
Squeak is a portable, open-source, object-oriented, multimedia development environment7 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 first 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
modification.
6 A word-of-mouth recommendation for low-level languages has always negatively stigmatised highlevel languages as being tremendously slow. However, the benefits 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
(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.
75
More precisely, Squeak offers many benefits “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 benefits:
• 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 files.
• 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 first 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
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 flexible. 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 Subfigure 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.
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 animated with a built-in stepping mechanism. An overview of the representations
of Morphs within Squeak can be seen in Subfigure 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 difficulties 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
“fields”.
• Asynchronous Event Architecture
If a script is started, it runs until it is finished. Running processes cannot be halted
externally, but events can trigger scripts. This is a crucial feature, making Tweak more
flexible 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
• Fields
Fields define 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 flexible 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
79
easier to handle outside Tweak. It can be used to configure 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 find 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 classified 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 Sciences 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 Figure 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 refining common
game functions and make additions to the iEngine. In the end, the final 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 artificial 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
(a) Ships fighting against each other. The damage is shown in the ships. The hand is used to
navigate the ships.
(b) Ports are service stations where ships can be
upgraded and repaired.
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 (M ONTICELLO 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 fit 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.
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 file formats.
• Rendering
The iEngine includes a 2 12 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 profits from Tweak
already.
• Sound
Just like graphics, sounds are imported as media assets into the game to
triggered by an event.
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 fulfilled by it. However,
remembering the conclusions of section 4.6 leads to pointing out the necessary
features that are part of LeGaCy.
• Scalability
The definition 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
• 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 file
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 defining 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 first impressions of software upon whether they
find 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 specifically 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.
(a) Screenshot of the inGame Level Editing View
of LeGaCy
83
(b) Screenshot of the programming view in
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 leveldesign 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 preconfigured 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
quired. The effect of the changes that are made, can be seen instantly, which is a
benefit 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 nonprofessional 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 identifier of background assets is bg-.
• Prop
Props are functional game items that either have influence to game characters or simply serve to populate the game world. A prop object can contain parameters, triggers
and collision information. The identifier 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 identifier 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 identifier 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 files that will be used in a game prototype.
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 specified
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
(a) The non-professional view is called the “Playground” and can be opened from the main
menu.
(b) This “playground” presents a default view of
a game level that can be used as a template for
new levels.
(c) In a drop-down list on the left, the different object types can be accessed and painted inside
the level.
Figure 5.9: Accessing the game objects in LeGaCy.
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 file.
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 fit
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 find 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
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 first 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 fascination to women (like T HE S IMS), 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 first games that came to explore this
market: P AC -M AN.
P AC -M AN 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 P AC -M AN 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
P AC -M AN not just a yellow circle will suffice. A pizza, a delivery
boy, a mafia 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.
For the setting, props would be represented in the form of pizza
toppings and the background is a green texture representing
some kind of salad. With this initial setting in mind, a game designer can start LeGaCy and begin creating a game.
Figure
5.11:
The characters
for the game
prototype.
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 P AC -M AN was born.
90
(a) First, the “Playground”
view is started within in
LeGaCy.
(b) A background object is selected and the brush changes
to represent the selected object from the game item list.
(c) Through placing these
solid objects into the level, a
basic maze is created, which
will later become a labyrinth
for P AC -M AN.
(d) After placing numerous background tiles on
the game map, the properties are selected in the
game items list.
(e) The properties are drawn into the game world
the same way as the background objects. The
brush places the props inside the level.
(f) Next, the antagonist type characters (called
enemy objects) are selected from the game item
list and put inside the grid of the level.
(g) Finally, the player avatar is placed inside the
game 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 flap 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 file as stated before.
The file format was chosen because it is easily editable and a parser for these documents 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.
We’ve just finished that, but we can
make it better!
(S HIGERU M IYAMOTO )
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 refined and
specialised further during all phases of development, ultimately leading to a finished 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
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 wellsupported 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 proficient 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 efficient 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 configurations can be made during its run-time, was an essential factor for
developing this tool in Squeak. Defining 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 field 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 field
[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. Creating 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 benefit for teaching any subject.
Coming back to the thoughts in chapter 4, computer science profits 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 efficiently 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 specific review of how the
work with these tools turned out is given in the following subsections.
96
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 fits better towards a specific need in education.
What I came to wonder about, was how many similarities existed between objectoriented 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 first research in this area and thus
leaves many possibilities for extending it towards more refined 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 beneficial, 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 specific 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 profitable there.
Traditional university education also aims at the mediation of conceptual thinking.
The understanding of mechanisms is usually more important than proficiency 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 specification 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
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, instructive, 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 efficiently 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 first, 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 difficult for me at first. 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 first, 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 specifications.
Glossary
API
An Application Programming Interface is a set of definitions 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]
A DD - 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
reflective and object-oriented. Its syntax is directly based on Java
and C++, while many of the ideas derive from the original Smalltalk.
C ROQUET
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.
D EVELOPER
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.
G AME E NGINE 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, artificial 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-profit, 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-profit 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 Developers 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.
M IDDLEWARE 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.
M ONTICELLO
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 confidential 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.
P ATCH
A patch is way to fix 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 fixed. Recent examples for this are S ÖLDNER, T HE F ALL,
and S ACRED.
P ITCH
A pitch (especially in game development more correctly defined 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
P UBLISHER
A publisher in game development refers to the company that usually
does the marketing, distribution and sales for the developer.
SCM
Software Configuration 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 specific computer
language or for a particular operating environment.
S MALLTALK
Smalltalk is an object-oriented, dynamically typed, reflective, programming language created at Xerox Palo Alto Research Centre by
Alan Kay, Dan Ingalls, Ted Kaehler, Adele Goldberg, and others during the 1970s, influenced 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]
S QUEAK
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, multitasking and multi-user computer operating system originally developed by a group of AT&T Bell Labs employees including Ken Thompson, 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 simplified 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 Design, 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, California, USA, 2001. Game Developers Conference.
[Bates02] Bob Bates. Game Design: The Art and Business of Creating Games. Premier 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, Ottovon-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 Critical Vocabulary for Games. In Frans Mäyrä, editor, Proceedings of Computer Games and Digital Cultures Conference, page 9–33, Tampere, Finland, 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 Publishing, Indianapolis, Indiana, USA, first edition, June 2003.
[Csikszentmihalyi91] Mihaly Csikszentmihalyi. Flow. Perennial, 1991.
[DassaultSys05] Dassault Systèmes.
Virtools Website, 2005.
virtools.com, last accessed October, 2005.
http://www.
[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. RealTime 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, first edition, March 2004.
[Gadegast05] Patty Gadegast. Objektorientierte Programmierung von Entertainmentumgebungen in Squeak, 2005. Study report (Studienarbeit) at the
Institute for Simulation and Graphics.
[Gamma95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design 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 Applications. Prentice Hall, first edition, 2001.
[Guzdial02] Mark Guzdial and Kim Rose. Squeak: Open Personal Computing and
Multimedia. Prentice Hall, first edition, 2001.
[Hodgson03] David Hodgson. Half-Life 2: Prima’s Official 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 first programming course. In SIGCSE ’96:
Proceedings of the twenty-seventh SIGCSE technical symposium on Computer 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, Germany, 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 Demystified. Peachpit
Press, first 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 Computer 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 GIJahrestagung 2004, pages 165–169, Ulm, 2004. Gesellschaft für Informatik, 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, International Conference on Computer Games: Artificial 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. Redford, and D. Parker. ScriptEase: Generative Design Patterns for Computer
Role-Playing Games. In Proceedings of the 19th IEEE International Conference 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. Official 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 Institute 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 Design. 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 Electronics Engineers, 2004.
[Overmars04c] Mark Overmars. Game design in education. Technical Report UUCS-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 Interactive Systems. Addison Wesley, 2000.
[Rollings03] Andrew Rollings and Ernest Adams. Andrew Rollings and Ernest
Adams on Game Design. New Riders, Indianapolis, Indiana, USA, first
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 Fundamentals. MIT Press, 2003.
110
References
[Schnetzler04] Nadja Schnetzler. Die Ideenmaschine. Wiley-VCH, 2004.
[Schuster04] Grit Schuster. Autonomes Verhalten für digitale Charaktere in interaktiven 3D-Welten. Master’s thesis, Otto-von-Guericke-Universität
Magdeburg, Magdeburg, 2004. Diplomarbeit at the Institute for Simulation and Graphics.
[Sheerin04] Peter Sheerin. Must-know technologies. Game Career Guide, pages
63–64, Fall 2004.
[Sheffield05] Brandon Sheffield. 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 Definition 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. Croquet - a collaboration system architecture. In First Conference on Creating, 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 Gameness in Interactive Game Based Learning. In Proceedings of the 15th Annual 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 Intelligent Simulations and Gaming, 1(2), 2003.
[Watt03] Alan Watt and Fabio Policarpo. 3D Games: Animation and Advanced RealTime Rendering: 2. Addison-Wesley, first edition, 2003.
[Yu02]
Connie Yu. Developing a Game Programming Course For Computer Science Majors In a Liberal Arts College. In Proceedings of the First International Conference on Information Technology & Applications, Bathurst,
Australia, November 2002. ICITA.
List of Figures
1.1 One of the first video games in history: PONG. . . . . . . . . . . . . . .
1.2 A screenshot of the games panel in Valve’s Steam. . . . . . . . . . . . .
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. . . . .
1
2
4
2.1 An outline of iterative development as sketched by [Fullerton04]. . . .
2.2 The concept phase is the start of every game project . . . . . . . . . . .
2.3 The pre-production phase, where the game design document and the
production plan merge to reach the actual prototype creation. . . . . .
2.4 Physical gameplay prototypes created with not much more than pen
and paper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 The game iteratively evolves from the basic prototype to an early alpha stage. Thick arrows indicate a stronger collaboration between the
departments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6 Concept art character portraits for two different computer games. . . .
2.7 Alienbrain Manager Client is an application that tracks all changes
made to the files in a project and communicates those with a central
server for sharing them with internal and external team members. . .
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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.9 Several graphical software defects from different retail versions of computer games. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.10 Mantis is a popular open-source bug-tracking tool used by the company impara GmbH for identifying software defects. . . . . . . . . . . .
2.11 The last stages of Production . . . . . . . . . . . . . . . . . . . . . . . . .
2.12 Prototype of the game “Good Bugs, Bad Bugs”, produced in Squeak by
students of the game design course at the Otto-von-Guericke University.
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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
11
13
14
16
17
18
20
21
22
23
28
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. . . . . . . . . . . . . . . . .
3.3 Schematic views of middleware. . . . . . . . . . . . . . . . . . . . . . . .
3.4 Examples for middleware applications and the differentiation of middleware and production tools. . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Professional and hobby game development suites, multimedia authoring environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6 The Macromedia Flash MX interface and a screenshot of a casual game
developed with it. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7 The GUI of Game Maker and a game developed with it. . . . . . . . . .
3.8 A tool from the Vision SDK and a screenshot of game that uses the
game engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9 Unreal Engine 3 - Some of the editor components [Epic05]. . . . . . . .
4.1 Different education for future game developers at the Otto-vonGuericke University Magdeburg and the Games Academy Berlin. . . .
4.2 The game with the best game design in 2005 was K ATAMARI D AMACY,
making his game designer Keita Takahashi popular over night. . . . .
4.3 The Croquet project aims at developing a flexible framework with that
any user interface concept can easily be prototyped and deployed
[SmithDA03]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 The different mini games that were analysed for finding necessary core
game features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5 A high-level overview of the proposed architecture. . . . . . . . . . . . .
5.1
5.2
5.3
5.4
Etoys is a high-level interface for scripting within Squeak. . . . . . . .
Smalltalk MT and the Aura game that was created with it. . . . . . . .
The two GUI environments used in Squeak before the invention of Tweak.
The outline of the mixed Squeak-Tweak work environment that was
used for programming LeGaCy. . . . . . . . . . . . . . . . . . . . . . . .
5.5 Setting up the project Pirates. . . . . . . . . . . . . . . . . . . . . . . . .
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. . .
5.7 LeGaCy’s different views on the code base: A programmer view and a
level-design view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.8 The mechanism of updating the assets within LeGaCy. . . . . . . . . .
5.9 Accessing the game objects in LeGaCy. . . . . . . . . . . . . . . . . . . .
5.10 UML view of the LeGaCy components. . . . . . . . . . . . . . . . . . . .
5.11 The characters for the game prototype. . . . . . . . . . . . . . . . . . . .
5.12 Making a game prototype level in LeGaCy. . . . . . . . . . . . . . . . . .
34
35
36
38
40
41
42
48
54
56
60
63
68
72
74
76
78
79
80
83
85
86
88
89
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 finding 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 difficult 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 difficult - 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. Definitely, 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
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 first 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
their art. (laughs)
My Question:
NOT
concentrate on
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
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 first 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 first 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 first 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
119
the focus was on game design.
My Question:
Do you think those two fit together and complement each other?
One idea that I have been researching in my thesis is that objectoriented 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 objectoriented 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. Especially 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 five 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
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 first 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 five 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 first 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
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. Everything 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 fifteen
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 D OOM
are just maze games. They only put a fancy interface and first
person view around it.” What I showed them was a D OOM-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 twodimensional, 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
In the following, you will find 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:
Definitely 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 <g>), 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
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 objectoriented 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 find 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
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 Gathering [OK, *relatively* new <g>]), and every other kind of game imaginable 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 fiction 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 individuals and lifelong learners.
My Question: Name three peculiarities that - to your mind - college cannot teach
you about game development! Explain briefly why!
Bob Bates:
1. Corporate politics and how and why games get built or cancelled. 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 first: 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 somewhere 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 figure out how to deal
with the particulars of each case, over and over again.
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.
My Question:
Do you think the use of a game creation suite (like a development
help students understand game development in a universitylevel course?
Jochen Hamma: Definitely. 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: Briefly 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
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 objectoriented 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 flow concept was also done by [Boettcher05]
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:
Jochen Hamma:
Name three peculiarities that - to your mind - college cannot
teach you about game development! Explain briefly why!
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 modified on the fly - 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
defined 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
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”.
My Question:
course?
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 figure
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.
My Question:
One idea that I have been researching in my thesis is that objectoriented software engineering and game design somehow complement each other, because you have to think in units. If you sub-
129
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.
My Question:
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 briefly 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
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 first 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.
My Question:
course?
David A. Smith: Possibly. Game design is very much multidisciplinary today. That
is, unlike when I wrote my first 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. Different 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.
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, cinematographer, (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 figure 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.
My Question:
One idea that I have been researching in my thesis is that objectoriented 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?
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
My Question:
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 N O 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 A LWAYS 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:
David A. Smith:
Name three peculiarities that - to your mind - college cannot
teach you about game development! Explain briefly why!
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
Physics
Video
●
●
Bink & Smacker
(RAD Game Tools)
●
●
●
●
●
●
AI.implant
DirectIA SDK
SimBionic
Other
●
●
Asset Management
●
●
Alienbrain Studio
Perforce
SpeedTree (Tree Generation Middleware)
MASSIV (MMOG Middleware)
Mobile Gaming Middleware
Multimedia Authoring Environments
●
●
●
●
●
butterfly.net
Quazal
Gamebryo
RenderWare Studio
Unreal Engine 3
Trinigy Vision SDK
●
●
●
●
Professional
Networking
Havok
ODE
Novodex
Meqon
●
●
●
●
Game Maker
3D Game Studio
Reality Factory
RPG Maker XP
●
●
●
●
OGRE
Irrlicht
Genesis 3D
OpenGL
Direct3D
●
●
●
Hobby
●
FMOD
Miles (RAD Game Tools)
Sensaura gameCODA
OpenAL
●
Game Development Suites
Graphics
Audio
Macromedia Flash
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
Playtesting / QA
Publisher
Physical Prototype
Financial Plan
Presentation
Software Prototype
Production Planning
Design Document
●
Story
●
Gameplay/Mechanics
●
Characters
●
Levels
●
●
●
●
●
Task Breakdown
Priorities
Milestones
Scheduling
Resource Management
Prototyping Cycles Phase
Production
●
Coordination
●
Tasks and Milestones
●
Priorities
Tools
●
Level Creation
●
Effects
●
Control Animation
Engineering
●
Engine Developers
●
Game Mechanics
●
Scripting
●
System Conception
Game Design
●
Gameplay
●
Levels
●
Characters
●
Story
Sound
●
Sound Effects
Asset Management
Artwork
●
Models/Textures
●
Animations
●
Maps
Quality Assurance
●
Iterative Testing
Full Production Cycles Phase
Production
●
Coordination/Scheduling
●
Milestones
●
Priorities
Engineering
●
Engine Refinement
●
Game Mechanics
●
Scripting
●
System Refinement
Game/Level Design
●
Gameplay
●
Levels
●
Characters
●
Story
Localisation
●
Translation
Sound
●
Score Composition
●
Sound Effects
Quality Assurance
●
Iterative Testing
●
Bugtracking
Asset Management
Artwork
●
Models/Textures
●
Animations
●
Maps
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
Music & Sound
Engine
Main Loop
Timer
2d or 3d
Engine
Controls
User Interface
Network
Client Control
Software
Interface
Event
Handler
Physics
Graphics
Additional
Middleware
Net
Input
Hardware
User
Output
dynamic
game data
Simulation
Audio
Core Game Engine
static
game data
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
Audio
Game Engine
Software/Asset Management
3D Animation
Artwork
Programming
Project Management
Prototyping and Multimedia Authoring
Quality Assurance
Standard Tools
. Steinberg Nuendo
. Sony Soundforge
. The Miles Sound System (RAD Game Tools)
.
.
.
.
.
.
.
.
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
. Perforce
. Subversion
.
.
.
.
Autodesk 3ds max
Alias Maya
Avid SOFTIMAGE|XSI
NewTek Lightwave 3d
. Adobe Photoshop
. Adobe Illustrator
. Visual Studio 2005
. MetroWerks CodeWarrior
. Eclipse
.
.
.
.
.
ProWorkflow (from ProActive Software)
Microsoft Office Project
Groove Virtual Office
PhpCollab
Open Workbench
. Macromedia Flash Professional
. Macromedia Director MX
. Dassault Systèmes’ Virtools Dev
.
.
.
.
.
.
.
.
.
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
Funding, 12
API, 23
C#, 47
Croquet, 47, 53
developer, ii, 2, 102
DLL, 72
E3, 103
game engine, 6
GCDC, v
GDC, 14, 102
GML, 41
GUI, 39
IGDA, ii
LeGaCy, 7
middleware, 6
Monticello, 80
NPC, 19
patch, 23
Pitch, 10
publisher, 2
SCM, 16
Smalltalk, 28
Squeak, iii
XML, 34
XNA, 47
GML, 102
G
H
Game Design, 18
game engine, 137
Game Maker, 40, 115–121
GML, 118
Gamebryo, 137
Glossary Terms
add-on, 18
Half-Life 2, 2
3ds max, 137
Numbers
1942, 64
A
AI, 26, 33
Alienbrain, 43, 137
Architecture
of LeGaCy, 68
Artwork, 17
Asset Management, 16
Aura, 72
Aura: Fate of the Ages, 72
B
Break-Out, 64
Breakout, 64
D
Design document, 15
Doom, 2, 121
F
I
Idea, 12, 13, 15, 26, 42, 47, 49
Interview
with Bob Bates, 122
with Bruce Shelley, 128
139
140
with David A. Smith, 130
with Jochen Hamma, 125
with Mark Overmars, 115
Index
UPGEAR, 120
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
Definition, 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
Lennart Nacke
Copyright 2005 by Lennart Nacke. All rights reserved.
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, filesharing, 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 thesis@pxfx.de
http://thesis.pxfx.de
Final Version

Facilitating the Education of Game Development

Transcription

Similar documents

24 hours - Alex Schwartz

PIC12F683 Exercise Book 1 Storage box 2 Exercise booklet 3 CD

© www.jbonzer.com Graphics DJ Inkers

FD620D

Dual Port, Four Barrel, Aluminium lnlet Manifold. Crane Cam and

MOTORUP XTREME 800 Engine Treatment PDF

Rapid Prototyping

World Wide Web 1 Basics - the Greenville Public Library

the Honda BF5 sales sheet