Facilitating the Education of Game Development

Transcription

1 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

2

3 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 LENNAR T NACKE Matrikel-Nr Date of Submission: November 04, 2005 Examiner: Prof. Dr.-Ing. MAIC MASUCH Dr.-Ing. KNUT HAR TMANN Supervisor: Prof. Dr.-Ing. MAIC MASUCH Processing Period: May 23 November 04, 2005 Diplomstudiengang Computervisualistik Otto-von-Guericke Universität Magdeburg Fakultät für Informatik Universitätsplatz 2, D Magdeburg

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

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

6

7 Revolutions come from standing on the shoulders of giants and facing in a better direction. ALAN KAY Acknowledgements First, a huge thank you to the many fantastic friends that gave their time, moral support, ideas, expertise, and cheers during the writing of this thesis. Without you, I could not have 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 L A TEX 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

8

9 Contents 1 Introduction Motivation Research Objectives Structure of This Thesis Basics of Game Development The Game Development Process Concept Pre-Production Prototyping Full Production Traditional Software Development vs. Game Development Game Prototypes in Iterative Development Summary Game Development Tools More Than a Collection of Middleware: The Game Engine General Definition of Middleware Game Development Suites Macromedia Flash Game Maker Vision SDK Important Aspects of Development Tools Defining Classes for Game Development Tools Progress and Future Game Development Strategies Summary Developing a Concept for an Educational Prototyping Tool Game design vs. Game development Adequate Education for Jobs in Game Development Teaching Focussed on Developer Tasks Game Designer Producer Game Programmers Game Artists and Animators Conclusion for Education Advice from Professionals Game Development Tools used to Facilitate Game Education Towards an Educational Game Prototyping Tool vii

10 viii Contents Requirements Analysis for a Game Prototyping Tool A Proposal for an Architecture of a Prototyping Tool Conclusion for the Implementation of a Prototyping Tool Summary Implementation of a Game Prototyping Tool Game Development in Smalltalk The Development Environment Squeak Tweak The iengine LeGaCy - A Tool for Rapid Game Prototyping User Interfaces in LeGaCy The Features of LeGaCy A Game Prototyping Example The Game Idea Demonstration Summary Summary and Conclusion Results of This Research Discussion Critical Review Advantages and Disadvantages of Game Development with Squeak Future Work Perspectives Personal Remarks Conclusion Glossary 101 References 105 A Interviews 115 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 B Figures and Tables 133 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 Index 139

11 1 Introduction The only legitimate use of a computer is to play games. (EUGENE JARVIS) Although people have played games since the beginning of humankind, it was not until in 1958, when the physicist William A. Higinbotham developed TENNIS FOR TWO 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 PONG-phenomenon spawned the global video game mass-market in 1972 [Mertens02, Lischka02]. Figure 1.1 shows a screenshot of PONG. Today, an increasing number of the living 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

12 2 1 Introduction 1.1 Motivation Developing a professional computer game has become an incredibly complex task over the years. In the 1980s, a single person was able to create a computer game by herself - usually a programmer - that designed, programmed and delivered the game all on her own. The art was usually homespun, because of the graphic capacities of the hardware and the target group consisted of technology interested people only. However, things changed fast. Over the past decades, the complexity and quality of game graphics became the biggest selling point in this competitive market. Therefore, the programmers had to team up with artists and management people. After the great success of id Software s DOOM [IdSoftware05], game DEVELOPERs and PUBLISHERs discovered the Internet as a distribution and marketing medium [Kushner03]. Even today the distribution and safety protection of computer games via the Internet are reaching new heights with the release of HALF-LIFE 2 and its accompanying software Steam by Valve 1 [Hodgson03]. The software is shown in Figure 1.2. This novel approach has the potential to change game publishing forever. The classic role of publishers as the powerful controlling instance over marketing and distribution might become obsolete in the future, and Figure 1.2: A screenshot of the games panel in Valve s Steam. 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.

13 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. 1.2 Research Objectives This thesis aims at showing how games and education supplement and connect to each other. Computer games do not only serve as attractive motivational sources that challenge students to spent more time on thinking about algorithms and mathematics, but they are visually comprehensive for non-professional people, too.

14 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 tools 2. 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.

15 1.2 Research Objectives 5 Nevertheless, the primary goal is the academic education of game development rather than producing a professional product 3. A nice secondary side-effect is the mediation of diverse knowledge from other areas of computer science. There can be other teaching goals as well, but the emphasis needs to be on understanding game development as a complex process. Therefore, the ideal way of approaching game development is to focus on one part of it and try to teach decent knowledge of the other parts. In a computer-science environment, the focus naturally is technical-related. An important area of programming is object-orientation, a principle that becomes more popular among computer scientists. Object-oriented design is an intuitive method for learning programming, so the aim of this thesis is to develop software that allows for understanding object-orientation, as well as game design. My hypothesis is that object orientation is a natural approach to game design. It does not help to grasp the subject, but it introduces structured and abstract thinking to computer scientists. Here, the focus of a tool has to be on creating small comprehensive game prototypes that show functionalities of the gameplay rather than polished graphics or 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-doing 4 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.

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

17 1.3 Structure of This Thesis 7 Next, an outline of implemented classes of the prototyping tool LEGACY 5 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.

18

19 2 Basics of Game Development You have to learn the rules of the game. And then you have to play better than anyone else. (ALBER T EINSTEIN) This chapter gives the basic foundation for further analysis in this thesis. First, the iterative cycles of game development show how the industry works and how the development groups interact. Section 2.1 outlines game development in stages of conception, pre-production, prototyping, and full production. This approach should be taken with the usual reserve. Other views of game development do exist, and they can be true as well. To understand how to teach game development in academia, we need to structure and classify its parts to fully grasp the process as a whole. A development pipeline is sketched in the 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

20 10 2 Basics of Game Development Concept The game idea is the initial spark that comes to mind and then matures into a more complex combination of ideas. It defines the core theme of a game that is fleshed out in the concept. Ideally, the first game ideas are independently developed. However, the truth is that often potential funding mainly influences and depends on the theme of a game. Forming an Idea Designing the Idea to get Funding Pre-Production Small and less professional game development studios sometimes start directly from here: Programming the prototype, as the idea and gameplay develops in their head. However, this stage should really involve careful gameplay testing and exact planning. Gameplay Prototyping Pitching 1 the Prototype Planning the Production Writing a Design Document Prototyping Several prototypes are produced in a collaborative effort. The designers produce a framework, around which the game will be built. The prototypes are refined until they reach a mature stage (e.g. a stable organisation of features) where full production starts. Artwork and Sound Creation Engineering Developers Production and Management Game Design Tool Programming Quality Assurance Full Production This is the final development stage, before the game is finished and the gold master 2 is handed over to marketing and distribution. The focus is on reaching several milestones and avoiding critical bugs. Art Focus Production Focus Programming Focus Level Design Focus 1 see glossary: PITCH 2 A term for the completed game that will ship to stores.

21 2.1 The Game Development Process 11 The process of game development is usually carried out in an iterative manner during all of its phases [Mencher03, ElectronicArts05]. There is no common agreement or universally valid 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 Theme Money Acquisition Funding Pre-Production Phase Figure 2.2: The concept phase is the start of every game project

22 12 2 Basics of Game Development 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 wishes 3.

23 2.1 The Game Development Process 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 Pre-Production Phase Game Design Prototyping Playtesting / QA Physical Prototype Presentation Software Prototype Publisher Financial Plan 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.

24 14 2 Basics of Game Development The publishers focus on market demands and sales deadlines is also responsible for a decrease of innovative games and much pressure, which is put on developers for meeting the Christmas deadline 4. 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 Gameplay Prototyping 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.

25 2.1 The Game Development Process 15 this software prototype is evaluated and playtested in iterative cycles, too. During this process, it should be possible to save notes and ideas on issues occurring unexpectedly. Thus, an ideal software companion for prototyping would be a Wiki 5, 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 suites 6. The software prototype 7 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 Often this is a prototype version enriched with polished graphics.

26 16 2 Basics of Game Development asset managers, and trackers. Some examples of these are Microsoft Project, Wiki Software, NXN Alienbrain, Perforce, Subversion, Miranda, Skype, PIM 8 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 Prototyping The prototyping phase starts the technical game production. The first game spec- Prototyping Cycles Phase Artwork Models/Textures Animations Maps Engineering Engine Developers Game Mechanics Scripting System Conception Production Coordination Tasks and Milestones Priorities Game Design Gameplay Levels Characters Story Tools Level Creation Effects Control Animation Sound Sound Effects Quality Assurance Iterative Testing Asset Management 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.

27 2.1 The Game Development Process 17 need to be implemented and improved. According to the milestone plan, set up by production, the game engine 9 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 ICEWIND DALE (Black Isle Studios). (b) Concept art by Nicolas Bouvier (aka Sparth) for the game PRINCE OF PERSIA: WARRIOR WITHIN (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 graphic 10. 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.

28 18 2 Basics of Game Development the models later. Non-natural textures are often hand drawn within the computer. The model department uses the images from the concept designs to create 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 it- erative cycles, so the stakeholders (often the publishers) can constantly view how much the development has progressed. For managing these iterative cycles, SCM tools (like NXN Alienbrain, which is shown in Figure 2.7) provide a good way to save prototypes for each milestone. In addition, the development team uses internal messaging software as a communication channel. Tools for this task are chat and Voice-Over-IP clients (like Skype, ICQ, Yahoo Messenger, MSN Messenger, AOL Instant Messenger, Jabber, etc.). Tools Figure 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. 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 modding 11 the original game. 11 Modding describes the manipulation or modification of the original game to add new features and content.

29 2.1 The Game Development Process 19 Game Design Game designers not only take responsibility for the gameplay, they work a lot on the story as well. During prototyping they 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 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 state 12. Some time at the end of beta testing, the developers declare the feature-freeze 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.

30 20 2 Basics of Game Development 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 Artwork Models/Textures Animations Maps Engineering Engine Refinement Game Mechanics Scripting System Refinement Production Coordination/Scheduling Milestones Priorities Game/Level Design Gameplay Levels Characters Story Localisation Translation Sound Score Composition Sound Effects Quality Assurance Iterative Testing Bugtracking Asset Management 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: 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 freeze 14. If the quality assurance department encounters an issue that is likely to bother the customer, a feature request is posted. 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.

31 2.1 The Game Development Process 21 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. 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 SACRED developed by Ascaron. (b) A bug in the graphics of the game VAMPIRE: THE MASQUERADE - BLOODLINES by Troika Games (Activision). Figure 2.9: Several graphical software defects from different retail versions of computer games. 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. 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. Program Crash Severe code problems, like memory leaks, can cause the game to crash.

32 22 2 Basics of Game Development 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

33 2.1 The Game Development Process 23 for Windows desktops, or simple communication libraries that work well with the respective Application Programming Interface (API). Like all game development, quality assurance should be done iteratively at all milestone points during a game production. Most likely the developer will write a test plan and check-list to ensure all-important issues get 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.

34 24 2 Basics of Game Development Unfortunately, many PC games are under severe release-pressure so that the developers sometimes not test intensely enough and games are released with strong defects. The developer has to keep the game alive by promptly posting patches on the internet, so that players can 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

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

36 26 2 Basics of Game Development tries, where a leak in stability would have dreadful consequences (e.g. Aerospace, Medicine). Since the resale price of this kind of specialised product is also very high, the customer will be non-forgiving with fatal defects in the software. The continuous improvement of graphics hardware and the addition of more sophisticated middleware (especially game engines) demands from developers to constantly adjust to new programs and improve the way they program. This makes planning a 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

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

38 28 2 Basics of Game Development The latter two will not be discussed here, because this thesis focusses on gameplay prototyping. A good source of information for the latter is [Rollings03, chap. 20]. Gameplay prototypes help to 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 ] 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 developers to use a different language or tool for programming the prototype than for the final game [Rollings03]. Since most games are programmed in Figure 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. low-level languages like C or Assembly, a fresh approach would be to use a highlevel language like SMALLTALK or even scripting languages like Lua, Python or Ruby. An example of using the Smalltalk programming environment Squeak for prototyping is shown in Figure 2.12.

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

40

41 3 Game Development Tools We shape our tools and then our tools shape us. We become what we behold. (MARSHALL MCLUHAN) The basic principles discussed in this chapter are the purpose of tools used in game development. A game engine is a collection of libraries that separates the game code from the hardware. The boundary between middleware and game engines is fuzzy. Thus, a game engine can utilise middleware and - depending on the scope of the project - also be seen as middleware for a game. To fully discuss game engines it is necessary to include a discussion of both games middleware and associated tools. The transition from tools to middleware and on to complete game engines is not clearly 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. 3.1 More Than a Collection of Middleware: The Game Engine Before one looks more closely at the parts of a game engine, game programming as a whole needs to be explained. Generally, three different areas of programming can be differentiated within game development [Llopis05]: 31

42 32 3 Game Development Tools General Game Programming Everything directly related to the game: Triggering animations, scripting the AI entities, displaying the score or health bar. Game Engine Programming Low-level programming with the main goal to build a layer of abstraction between hardware and game code. It provides core functionality that all games commonly need. Tools Programming Primarily developing tools for content creation. Those are often realised as plugins for the common tools used by designers and artists of the game. This can include developing custom middleware for a game. A game is a large application, so this subdivision of programmers working on different levels of granularity is very important. This kind of granularity also applies to a game engine and blurs the border towards the real game code and other middleware. A good engine can be partially build on middleware for graphics and sound, for example. Although, middleware for graphics is popular and has also many 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. Core Game Engine User Output Input Hardware Audio Graphics Controls Music & Sound Engine 2d or 3d Engine User Interface Main Loop Timer Event Handler Artificial Intelligence Physics Network Client Control dynamic game data Simulation Net Additional Middleware Software Interface 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.

43 3.1 More Than a Collection of Middleware: The Game Engine 33 First, one can see there are two forms of interface with the user: The output she receives and the input she gives to the system. The user enters the input events with a hardware device that is listened to by a software controller system. Controlling events come into the game engine via this hardware abstraction or via the network (for example, in a multiplayer game). The events are then sent to the game engine, which hands them over to the user interface. This also controls visual and auditory feedback from the engine to the player. These parts are smaller engines themselves: One of them being responsible for all types of audio processing and the other one being the graphics engine. Usually the engine itself or some common libraries like DirectX take care of dealing with the hardware abstraction layer. The engine uses these libraries to access the underlying operating system 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.

44 34 3 Game Development Tools 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:

45 3.2 General Definition of Middleware 35 Game Application Middleware Other Applications (or Hardware) (a) Middleware defined by d Agapeyeff [Naur68] (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.

46 36 3 Game Development Tools 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 requirement 1 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 Audio F MOD Miles (RAD Game Tools) S ensaura gamecoda OpenAL Artificial Intelligence AI.implant DirectIA S DK S imbionic Graphics OGR E Irrlicht Genesis 3D OpenGL Direct3D Networking butterfly.net Quazal Video Bink & S macker (RAD Game Tools) Physics Havok ODE Novodex Meqon Ageia Game Middleware Version Control Asset Management Other S peedtree (Tree Generation Middleware) MAS SIV (MMOG Middleware) Mobile Gaming Middleware Another Application (a) Different flavours of middleware in game development. (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 SPELLFORCE 2 can be found in [Koch05]. It is also important to make a distinction between middleware applications, libraries, and production tools. The latter manage game 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.

47 3.2 General Definition of Middleware 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 game 2. 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.

48 38 3 Game Development Tools 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 Non-Professional Gamebryo RenderWare Studio Unreal Engine 3 Trinigy Vision SDK 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.

49 3.3 Game Development Suites 39 The previous chapter outlined that some of these suites (shown in Figure 3.5) make prototyping easy, because prototypes need to be altered quickly when new ideas are tested. Consequently, the complex suites 3 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 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.

50 40 3 Game Development Tools (a) The GUI of Macromedia Flash MX (b) The Game GIRLS INC. TEAMUP developed by Large Animal Games. Figure 3.6: The Macromedia Flash MX interface and a screenshot of a casual game developed with it. always 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 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.

51 3.3 Game Development Suites 41 (a) Screenshot of Game Maker s GUI. (b) A game developed in Game Maker. Figure 3.7: The GUI of Game Maker and a game developed with it. It also has its own scripting language called GML. It extends Game Maker with much functionality, especially for using advanced graphics features that should be hidden from less experienced users. Thus, GML provides a level of scalability for different users of Game Maker. Yet more important are the interesting features of its interface. It lets one 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 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 tool 5. 5 Using an in-game preview function that is offered for the industry standard tools Autodesk 3dsmax and Alias Maya.

52 42 3 Game Development Tools (a) veditxp is a scene creation tool that easily integrates content created in other modelling packages. (b) DESPERADOS 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 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 languages 6 is to allow more flexibility by giving 6 And high-level programming languages.

53 3.3 Game Development Suites 43 a variety of programming layers. Most of them are strongly typed due to their architecture. The garbage collection takes care of wrong memory allocations, but might also cause performance to go down. However, through their granularity, scripting languages are usable on many levels. The increase of hardware performance and the advantage of faster learning, when working on various layers of complexity, is a crucial advantage, which will cause scripting languages to be used mainly in the future. The better a scripting language is, the closer it can set its lowest layer to a low-level programming language. Modding Games Most people have their 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.

54 44 3 Game Development Tools 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.

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

56 46 3 Game Development Tools 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. QUALITIES CLASSES Professional Non-Professional Multimedia Environments Effectiveness Efficiency Learning Curve Re- Satisfactory sults Scalability Creativity Low-level tuning Graphics & Animation Sound Flexibility Extensibility Table 3.1: Attributes of the different classes of game development suites. 3.5 Progress and Future Game Development Strategies Game development at a professional level has reached a stage, where it is much too complex to adjust a recent title without a team of enthusiastic and skilled people [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.

57 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 DirectX 7 to speed up programming and keep complexity low. As in one of the interviews in the subsection A.2.4, David A. Smith states that programming essentially is a translation task, and the easier the translation is, the faster the development will be. David A. Smith s most recent project is the CROQUET tool, which also aims at a high abstraction of programming for three-dimensional and collaborative worlds. The systems runs in a virtual machine and is written completely in Squeak, a Smalltalk dialect. Microsoft s XNA (Xbox/DirectX New generation Architecture) is another interesting attempt to build a platform that combines different APIs for game development and creates a common framework for the Xbox console as well as the next-generation Windows. This technology has the potential to make the transportation of game from the PC to the console extremely easy. This will 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.

58 48 3 Game Development Tools (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].

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

60

61 4 Developing a Concept for an Educational Prototyping Tool Whoever wants to understand much, must play much. (GOTTFRIED BENN) In this chapter, the knowledge gained about the development process and the usability of certain tools and middleware in the previous chapter will be supplemented with an expedient analysis of the academic situation concerning teaching game development. Therefore, training available for aspiring game developers is 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

62 52 4 Developing a Concept for an Educational Prototyping Tool [Rollings03b] additionally propose a litmus test for good game design by assuring the following aspects within a game: originality, coherency, interactivity, interest, and fun. Concentration on these aspects is an essential part of game design as well. Thus, game design builds a foundation for all further game development, which is described in [Masuch04b] as covering game design, game programming and all other production related topics. A large portion of game development is the practical implementation - the programming part - and the creation of graphics, animation, music, and sound, while game design is a lot more concerned with the conceptual design and high-level composition of the game mechanisms and rules. Ideally, if the game design is very good, it makes development a more effective process [Rollings03b]. 4.2 Adequate Education for Jobs in Game Development Many people currently working in game development companies were never actually trained for their jobs. They have acquired their skills in other areas that are related to their professions in game development. However, the professional situation is changing slowly as the industry matures. In the United States, there are now many schools and universities, offering education with a focus on computer game development. They have faced similar challenges in setting up an adequate curriculum or game 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

63 4.2 Adequate Education for Jobs in Game Development 53 Type of School Teaching Emphasis Target Job Profiles Tools Used Professional Private Training School (e.g. Games Academy, DigiPen) Applications, Industry standard tools and programming languages Game Programmer Game Artist/ Animator Game/Level Designer Alias Maya Virtools Nebula SDK University (e.g. Otto-von-Guericke University, University of North Texas) Theory and concepts behind games as well as collaboration, programming, and project management Game Designer Producer Technical Director Project Manager Autodesk 3ds max Squeak iengine Tweak CROQUET Shark 3d Java Liberal Arts Facility (e.g. Burg Giebichenstein, New Jersey City University) Classic art and design. Drawing, painting, computer image manipulation Concept Artist 2d Artist 3d Artist Level designer Paint Pencils Canvas (Adobe Photoshop) Business (e.g. BITS) School Project Management, Leadership, financial issues and game design Publishing Team Producer Management Consulting Microsoft Office Microsoft Project Entity-Relationship- Management Writing School (e.g. Hochschule der Medien) Writing, narration, story creation Storywriter Dialogue Editor 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 industry 1. 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

64 54 4 Developing a Concept for an Educational Prototyping Tool 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].

65 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 art 2. 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. 4.3 Teaching Focussed on Developer Tasks In chapter 2, the game development process was analysed and the different areas of development were shown. In [Bethke03], an overview of developer jobs is given with a rough division between design, programming, art, audio, management, quality assurance, and business, with the latter two not explicitly being part of the production, and often handled externally (e.g. by the publisher). If we investigate the creation of a 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.

66 56 4 Developing a Concept for an Educational Prototyping Tool Game Designer One of the most adored jobs is that of the game designer. But there are common misconceptions about what to find behind this terminology. As was pointed out before in section 4.1 the term is easily mixed up and hard to define. A possible definition could be: A visionary that knows the tools and has the skills to craft a game from an idea. While game designers need to be highly creative, they also need to have a thorough understanding of mathematics, art, interactive storytelling, and the whole game production in general. Ideally, a lead game designer also adds team and project management skills to that. Not all game designers specialise in the same things, some are more focussed on (a) KATAMARI DAMACY has won the award for Excellence in Game Design at the 2005 Game Developers Choice Awards. (b) Keita Takahashi is the game designer of KATAMARI DAMACY. Figure 4.2: The game with the best game design in 2005 was KATAMARI DAMACY, making his game designer Keita Takahashi popular over night. story creation, others prefer level/world building, while some only concentrate on the game mechanisms. The game design team, however, is at the heart of the game - without them, all other developers are not doing game development, but merely software or art creation. The game designer has to do most work in the pre-production phase and during game balancing in full production. During all phases of production, she is critically involved when decision on gameplay issues are made.

67 4.3 Teaching Focussed on Developer Tasks 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 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

68 58 4 Developing a Concept for an Educational Prototyping Tool parsers for scripting languages used by level designers. The classic programmers are the tool programmers that create software applications, which allow to create and modify game levels. Depending on the development team size there might also be specialised programmers for audio, physics or networks. Programmers need to be able to abstract real systems into complex components 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 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.

69 4.3 Teaching Focussed on Developer Tasks 59 Accompanying this are largely highly motivated students, often producing better results and working more intensely on the subject [Claypool05]. With the games industry exponentially extending its market share every year, the need arises for a specialised education. Entertainment programs are today highly sophisticated systems relying on a complex architecture crafted by software experts (see Figure 3.1 for a detailed overview of the components of a game engine). The past experiences mentioned above have shown a strong focus on two areas of application for teaching games: Teaching games for training professionals, who will work in the game industry The game industry matures and needs educated people to positively direct it into the future. Games are a global pervasive phenomenon that will become even bigger once the industry starts developing for niche markets, like games for elderly persons. The innovation and skill that young professionals from academia can bring into the industry will change its face forever. Using the motivational power of games as areas of application for traditional computer science subjects Classical computer science subjects have long yearned for interesting areas of application to increase their students interest and motivate them to research in these areas. Games provide the best motivation for learning computer sciences and often introduce children to computer technology and spark their interest to study this subject 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.

70 60 4 Developing a Concept for an Educational Prototyping Tool David A. Smith also states in subsection A.2.4 that code can often get in the Figure 4.3: The Croquet project aims at developing a 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.

71 4.4 Game Development Tools used to Facilitate Game Education Game Development Tools used to Facilitate Game Education 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 Illustrator 3. 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 designers 4, 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.

72 62 4 Developing a Concept for an Educational Prototyping Tool development and the concept of gameplay needs to be understood rather than the mastery of a certain tool. Game designers need good means to present a prototype of their idea. While this is possible with pen and paper, as well as on the computer, there is certainly a lack of good prototyping tools, Game Maker [Overmars04a] being the exception 5. 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

73 4.5 Towards an Educational Game Prototyping Tool 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 utility 6.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 PAC-MAN by Namco Limited (Midway) on the ZXSpectrum (b) TETRIS by Alexey Pajitnov (Tengen) is the classic puzzle game (Screenshot of the Commodore 64 version). (c) PONG was one of the first video games in history. (d) 1942 by Capcom was a vertically scrolling shooter. (e) The game BREAKOUT by Midway (Midway) and its successor ARKANOID by Taito (Imagine) were huge arcade hits. (f) SPACE INVADERS 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

74 64 4 Developing a Concept for an Educational Prototyping Tool Core Game Elements For creating a structure for game creation, it is important to identify major elements of certain games. This was done by looking at mini games that are shown in Figure 4.4. In Appendix section B.4 the features of these games are outlined in Figure B.4. In particular, the games TETRIS, PAC-MAN, 1942, PONG, BREAK-OUT and SPACE INVADERS where analysed with special regards to the objects included in each game. All games include three basic components (in different representations): Protagonist/Player Avatar Whether the player is represented as a block (TETRIS, PONG, BREAKOUT), an aeroplane (1942), a pizza (PAC-MAN), or a tank (SPACE INVADERS), there is always a graphical avatar giving visual feedback on the input actions. The most common form of controlling the player avatar is the keyboard or a joystick. User Interface Most game objects have values attached to them, which can be altered during a game. The most important values are usually shown on the 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 (TETRIS), while in others the enemies are avatars controlled by the game AI or by other players. This lead to the conclusion that all of these games consist of these objects and even different granularities of object classes are possible 7. 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).

75 4.5 Towards an Educational Game Prototyping Tool 65 together using own or preloaded graphics. An animation should be played on an event. An event should not need to be programmed in code, but simply be attached to a graphical object. While the tool itself should be programmed using a component architecture, the game should be a mix of game components, each differing in functionality and scope. This also supports the understanding what a game is made up of. By individually 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

76 66 4 Developing a Concept for an Educational Prototyping Tool semester of intense training. If possible, all stages of game development should be passed to create a small game. This utility aims at providing good means of prototyping for students and 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 design 8, 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

77 4.5 Towards an Educational Game Prototyping Tool 67 The collaborative nature of game development and the education of joint work is an obligation. Assigning tasks, meeting deadlines, exchanging 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.

78 68 4 Developing a Concept for an Educational Prototyping Tool 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 capabilities 9. Besides the white box behaviour, customisable game objects should be the founda- White Box Core System Game Engine Programmer View Non-Professional View Game Objects Collaboration 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.

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

80 70 4 Developing a Concept for an Educational Prototyping Tool Scalable Complexity A good tool should be just as complex as the respective user needs it to be, therefore different views on the same code need to be provided. Teamwork and Collaboration Many people work together in prototyping a game, so that a good tool can track and assign code to users. Creativity Only few technical limitations should be set, so that creative freedom is given to the user. Expandability Implied by the white box architecture, a prototyping tool should be easily extensible for altering it quickly to meet changing needs 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.

81 5 Implementation of a Game Prototyping Tool Technology is a word that describes something that doesn t work yet. (DOUGLAS ADAMS) In this chapter, we will take a closer look at game development with Smalltalk and Squeak; especially at the 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 GmbH 1 is carrying out. Then, the focus is shifted on the iengine 2 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

82 72 5 Implementation of a Game Prototyping Tool languages are the perfect choice. Even though they are less powerful, not necessarily object-oriented, and sometimes have to be extended by supplementary software (e.g. Dynamic Link Libraries (DLL) written in a low-level language). A possibility for people, who are not 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 system 4, 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 AURA: FATE OF THE AGES in 2004, which was developed with Smalltalk MT 5 and is shown in Figure Etoys is a scripting interface within Squeak (see Figure 5.1), which will not be discussed in detail here. For further information refer to [Guzdial01]. 5 The Smalltalk environment Smalltalk MT includes a hardware-optimised compiler for windows and abstraction layers of DirectX. It allows programmers to use Smalltalk with all the features known from Windows programming. The environment provides a graphical editor for Windows GUIs. Figure 5.2 shows Smalltalk MT as well as a screenshot of the game AURA.

83 5.2 The Development Environment 73 The game is an explorative adventure game from the first person view, which resembles the popular adventure game MYST. The graphics are prerendered, there is not much animation happening and for a huge part of the game, the player has to solve click puzzles. In conclusion, Smalltalk has not been vastly used in game development. Although many professional companies flinch from using it due to the risk of losing speed 6, for applications like prototyping and teaching game concepts, speed does not matter. This makes it attractive as a new and fresh testbed for game development in education. It is more important to get an insight into object-oriented design, which is certainly learned best by programming in Smalltalk. 5.2 The Development Environment The 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 Squeak Squeak is a portable, open-source, object-oriented, multimedia development environment 7 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 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.

84 74 5 Implementation of a Game Prototyping Tool (a) Smalltalk MT is a Smalltalk environment and optimised compiler for the Microsoft Windows OS (b) Aura is a Myst -like game developed by The Adventure Company in Smalltalk MT Figure 5.2: Smalltalk MT and the Aura game that was created with it.

85 5.2 The Development Environment 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 Smalltalk 8. 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.

86 76 5 Implementation of a Game Prototyping Tool One of the central ideas behind Squeak are also giving different perspectives on the (a) The old MVC interface in Squeak (b) Some graphical morphs in Squeak s Morphic environment Figure 5.3: The two GUI environments used in Squeak before the invention of Tweak. same data. This idea bases on a common design pattern called MVC 9 [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 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.

87 5.2 The Development Environment 77 Morphic Morphic is the recent GUI framework in Squeak and the successor of MVC. Thus, it was developed as part of the programming language Self, but soon became a part of Squeak [Maloney00]. The intention of its programmers was to simplify building user interfaces. It has one base class called Morph, which all other graphics classes in Morphic derive from. These Morphs can be 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 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 Player 11 and by a Costume 12, 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 ]. 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

88 78 5 Implementation of a Game Prototyping Tool 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

89 5.2 The Development Environment 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 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 engine 13, 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. The large project was called Virtual Physics and was aimed at the development of innovative user interfaces Figure 5.5: Setting up the project Pirates. 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 computer 14, 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

90 80 5 Implementation of a Game Prototyping Tool (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 (MONTICELLO being an example). So, besides providing all the benefits of the Squeak programming environment, the iengine adds the following essential core functionalities commonly needed in most games: AI While AI is programmed for each game individually, a common problem like path-finding needs to belong to an engine s functionality. The A* algorithm is such a pathfinding algorithm that is part of the AI library within the iengine. An AI emotion system was developed as part of a master s thesis [Schuster04]. Physics Basic physical functionality is available as part of the game engine, from which most is custom 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.

91 5.3 LeGaCy - A Tool for Rapid Game Prototyping 81 Graphical Asset Animation Game objects are usually represented by graphics on a display. These objects can be three-dimensional models or two-dimensional sprite graphics. The engine supports loading and animating two-dimensional graphics from the most common image file formats. Rendering The iengine includes a 2 1 d graphics engine, which basically means that the 2 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. 5.3 LeGaCy - A Tool for Rapid Game Prototyping In subsection 4.5.2, an architecture for an educational game prototyping tool was proposed, consequently highlighting the most important requirements for such a tool. Through discussing the abilities of Squeak in this chapter, it is obvious that many requirements for a special use in education are already 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.

92 82 5 Implementation of a Game Prototyping Tool Collaboration Working on the same code is made possible by utilising Squeak s version control tool Monticello, which is integrated in LeGaCy. Also the programmer control of the system browser allows programmers working on the same Squeak image to track changes of others. The prototypes are saved in the XML 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 concept 15. 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 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 complexity 16. 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.

93 5.3 LeGaCy - A Tool for Rapid Game Prototyping 83 (a) Screenshot of the ingame Level Editing View of LeGaCy (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-

94 84 5 Implementation of a Game Prototyping Tool 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 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 assets 17 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.

95 5.3 LeGaCy - A Tool for Rapid Game Prototyping 85 (a) A menu in LeGaCy offers access to most functions. (b) Selecting the Assets option to update the asset collection before the start. This step is necessary to make sure the newest assets are loaded into the iengine. (c) The program updates its internal assets library. The assets within a 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.

96 86 5 Implementation of a Game Prototyping Tool (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.

97 5.3 LeGaCy - A Tool for Rapid Game Prototyping 87 Selecting one of these objects updates the brush 18 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.

98 88 5 Implementation of a Game Prototyping Tool Figure 5.10: UML view of the LeGaCy components.

99 5.4 A Game Prototyping Example 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 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 THE SIMS), this problem is as old as video games themselves. Presuming that one comes into the situation of being a game designer, who is searching for ways to make games appeal to a female audience, the game idea developed here will be a tribute to one of the first games that came to explore this market: PAC-MAN. PAC-MAN is a game, where the main character has the form of a pizza and is chased by several enemies (all displayed as ghosts) while eating little white dots 19 As a homage to one of the most original ideas in gameplay, the game prototype will be a little PAC-MAN game. A pizza will serve as the main character of the game. But since graphics are more evolved today than they were in the times of PAC-MAN not just a yellow circle will 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 PAC-MAN was born.

100 90 5 Implementation of a Game Prototyping Tool (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 PAC-MAN. (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.