d 3D Racing Car Game Project Lloyd Bachelor’s Thesis SVEN ABELSSON RUNING SVEN ANDERSSON MATHIAS HÄLLMAN FREDRIK TOFT NICOLE ANDERSSON RICKARD NILSSON Department of Computer Science and Engineering CHALMERS UNIVERSITY OF TECHNOLOGY Gothenburg, Sweden, 2009 3D Racing Car Game 2009-05-19 3D Racing Car Game Project Lloyd Sven Abelsson Runing Sven Andersson Mathias Hällman Fredrik Toft Nicole Andersson Rickard Nilsson © Sven Abelsson Runing, Sven Andersson, Mathias Hällman, Fredrik Toft, Nicole Andersson, Rickard Nilsson, May 2009. Department of Computer Science and Engineering CHALMERS UNIVERSITY OF TECHNOLOGY SE-412 96 Gothenburg Sweden 2 (51) 3D Racing Car Game 2009-05-19 Abstract This bachelor thesis describes a case study, where we focusing on developing a 3D racing car game, using a process based upon agile development; an evolutionary development method. The thesis will cover implementation of real-time graphics, physics engine, network support, as well as sound effects and background music. In the end, our case study will show that this development process was an appropriate choice for our game development project. Sammanfattning Denna slutrapport beskriver en fallstudie gjord på utvecklingen av ett 3D-bilspel. Utvecklingen använder sig av en process baserad på agile development, som är en metod inom evolutionary development. Slutrapporten kommer att täcka implementering av realtidsrenderad grafik, fysikmotor, nätverksstöd, liksom ljudeffekter och bakgrundsmusik. I slutändan kommer fallstudien att visa att utvecklingsprocessen var ett lämpligt val för vårt spelutvecklingsprojekt. 3 (51) 3D Racing Car Game 2009-05-19 4 (51) 3D Racing Car Game 2009-05-19 Table of Content 1. INTRODUCTION ....................................................................................................................... 7 2. GAME DESIGN ........................................................................................................................... 8 2.1. Game Design and Concepts ................................................................................................ 8 2.1.1. Initial Concept .............................................................................................................. 8 2.1.2. Second Iteration ............................................................................................................ 8 2.1.3. Final Concept ................................................................................................................ 8 2.2. Development Process .......................................................................................................... 9 What Is a Software Process Model? .................................................................................. 9 The Waterfall Model ........................................................................................................ 10 Component-based Software Engineering ........................................................................ 11 Evolutionary Development .............................................................................................. 11 2.2.1. Our Development Process ......................................................................................... 11 Agile Methods................................................................................................................... 12 Milestones ......................................................................................................................... 13 2.3. Game Engine ...................................................................................................................... 13 2.3.1. Game Framework ....................................................................................................... 13 Microsoft XNA ................................................................................................................. 13 CodePlex ........................................................................................................................... 14 2.3.2. Physics Engine............................................................................................................ 14 Background ....................................................................................................................... 14 JigLibX .............................................................................................................................. 15 Limitations ........................................................................................................................ 15 2.3.4. Game Assets ............................................................................................................... 17 2.3.4.1. Creation................................................................................................................ 17 2.3.4.2. Result and Discussion ......................................................................................... 18 2.3.4.3. Loading ................................................................................................................ 18 2.3.5. GUI, Menu and HUD ................................................................................................. 19 Background ....................................................................................................................... 19 Results ............................................................................................................................... 20 Discussion ......................................................................................................................... 21 3. GRAPHICS ................................................................................................................................ 22 3.1. Lights and Rendering ........................................................................................................ 22 3.1.1. Ambient Pass .............................................................................................................. 23 3.1.2. Light Pass .................................................................................................................... 24 3.2. Shadows ............................................................................................................................. 25 5 (51) 3D Racing Car Game 2009-05-19 3.2.1 Shadow Mapping ......................................................................................................... 25 3.2.2. Variance Shadow Mapping........................................................................................ 26 3.3. Bump Mapping .................................................................................................................. 27 3.3.1. Techniques .................................................................................................................. 27 3.3.2. Normal Mapping ........................................................................................................ 27 3.3.3. Parallax Mapping ....................................................................................................... 27 3.3.4. Result and Discussion ................................................................................................ 27 3.4. Post-processing Effects ..................................................................................................... 28 3.4.1. Motion Blur ................................................................................................................ 28 3.4.2. Screen-Space Ambient Occlusion ............................................................................. 29 3.4.3. Bloom .......................................................................................................................... 31 3.5. Particle Systems ................................................................................................................. 32 3.5.1. Sparks .......................................................................................................................... 33 3.5.2. Sprinkles and Glow .................................................................................................... 34 3.5.3. Smoke.......................................................................................................................... 34 3.6. Result .................................................................................................................................. 35 3.7. Discussion .......................................................................................................................... 36 4. NETWORK ............................................................................................................................... 37 4.1. Background ........................................................................................................................ 37 4.2. Results ................................................................................................................................ 38 4.3. Discussion .......................................................................................................................... 42 5. SOUND ...................................................................................................................................... 42 5.1. Sound Effects ..................................................................................................................... 42 5.2. Background Music ............................................................................................................. 43 6. RESULTS .................................................................................................................................. 43 6.1. Requirements ..................................................................................................................... 43 6.2. Features .............................................................................................................................. 43 6.3. Time Estimations ............................................................................................................... 44 6.4. The Development Process ................................................................................................. 44 7. DISCUSSION ............................................................................................................................ 45 8. ABBREVIATIONS ................................................................................................................... 46 APPENDIX A ................................................................................................................................ 47 APPENDIX B ................................................................................................................................ 48 REFERENCES ............................................................................................................................... 49 6 (51) 3D Racing Car Game 2009-05-19 1. Introduction real-time rendered soft shadows, motion blur, and ambient occlusion. Developing software applications is a time-consuming process, and with Working with these requirements, we time-consuming processes come high decided to use Microsoft XNA as our costs. During the last years, several platform to develop our 3D game with. software development methodologies, This decision was made with regard to often known as agile software that the platform had many in-built development, have become widely used tools and provided a good framework by software developers to address this for us to get started with the issue. Many different development development as fast as possible. The methodologies can be more or less fact that Microsoft XNA also used C# good, depending of the task and as development language was also in application type. consideration, since we wanted to learn this newly developed C-based object- One of the software development oriented language. methodologies is the evolutionary software method, which, as the name The requirement for the game to hints, takes on an evolutionary contain 3D graphics introduced an approach to the problem, and allows interesting challenge for the project the project to evolve through different group, since all had none or little stages of the project. Our case study experience in 3D modelling. Spending will show how well this evolutionary time learning how to model proper 3D approach worked on our project where models for our game was therefore we choose to develop a 3D graphic necessary. During the research to find computer game. Some requirements out what 3D modelling program to use, for the computer game were given from we found that we could use different the beginning, such as: studios to create models that we could later import to our game project. The 3D graphics – The game must complete game contains models made contain 3D models, and render these in in both Blender and 3D Studio MAX. the game. 3D environments were never a requirement, and platform games With these choices made, we soon had with 2D environment could still open our development environment set to up for 3D objects. use Microsoft Visual Studio 2008 with Microsoft XNA Game Studio 3.0 Impressive result – The game result supporting the framework, and must impress whoever plays the game. Blender and 3D Studio MAX for It should last long, and make the modelling the graphical components. players come back and play it over and For some of the sound effects we also over again. made use of Adobe Audition 2.0. Graphical effects – To achieve an impressive result, we would need to add modern graphical effects, such as 7 (51) 3D Racing Car Game 2009-05-19 2. Game Design levelling, something that many players appreciate. It was also decided that the 2.1. Game Design and Concepts racing track should be a garage or a In this project, we were left free to store-house, filled with containers, decide what type of game we wanted to boxes, and miscellaneous objects develop. The suggestion was that a suitable for that environment. Since racing game would be suitable, since driving a real car around a garage is such a game usually do not depend on virtually impossible, it was decided advanced assets, e.g. animated models. that we should make remote controlled After some brainstorming, it was cars instead. decided that a racing game should be 2.1.3. Final Concept developed. However, there were two We kept most of the ideas from the different racing game ideas, which will second iteration with one exception for be described below. the death rally concept. It appeared In compliance with our development that our first instinct, to give this idea a process, the game concept evolved, as low priority, was right and in this last more and more features were added. iteration, the idea was dropped. To further explain how the game However, a racing game where players concept evolved, the development has only may collect coins and nothing been divided into three parts. more, sounded a bit boring. Influenced by games like Super Mario Kart, it was 2.1.1. Initial Concept decided that power-ups should be Our first concept had a game play added. There are a number of different similar to Remedy’s game in 1996, power-ups, and they could be divided called Death Rally1, where each player into two groups; those that affect the had a car equipped with a weapon, and car that hit the power-up, and those the goal was to hunt down the that affect the opponents’ cars. A more opponent’s cars. The other idea was to profound description of the different create a simple race track where power-ups follows. players could collect coins in order to win. Since the first idea involved much In addition to the other improvements, greater work than the latter one, it was one change was made to the points decided that the first idea were to be system. It should be possible to collect given a low priority, whereas the three types of coins, worth 50, 100 and second were to be given a high priority. 200 points. 2.1.2. Second Iteration We decided that a joint solution would be best, where players are able to collect coins and then use the money to make upgrades. Example of upgrades was better weapons, faster engine, and heavier car body. These upgrades would be similar to the concept of 8 (51) 3D Racing Car Game 2009-05-19 Power- Affects Description robustness, availability, maintain- up opponents’ ability, dependability and usability. To cars meet such varying demands, it is Nitro The player’s important to base the work on a well car moves prepared strategy. In software engi- faster. neering, the term for such a strategy is commonly known as software process, Punch A punch from a which is built on one or several random direction hits software process models. the opponents’ What Is a Software Process Model? cars. A software process model is a Double The player’s theoretical philosophy that describes points points are the best way of developing software. doubled. Based on one or several models, a software process is formed providing Slow Slows down guidance on how to operate. A software the opponents. process model may also be described as an abstract representation of a soft- Reverse The ware process. The concept of the opponents’ process model is similar to an abstract steering controls are java class, which can not be instan- reversed. tiated, but it can be implemented by another class, thus providing basic Low Causes the car guidelines for that other class. Friction to lose friction to the ground. A model may for example demand customer involvement, but it does not state exactly how. A process imple- menting that model should involve the customer in the process’ activities, but is free to choose how2. There is not only one type of process model, but two. The first one is the most common, and described above. The second type of process model is called a process paradigm, which is a model even more general than an Figure 1: Punch object. ordinary process model. Such a model 2.2. Development Process does not hold any details on how the In a software development project, the activities that lead to the completion of resulting product is required to fulfil a project should be performed, but many different qualities. Examples of what it does hold is basic guidelines of such quality requirements are: how to develop software, and assump- 9 (51) 3D Racing Car Game 2009-05-19 tions about what sort of project could Requirements definition benefit from implementing a particular model. With this in regard, one can System and software design conclude that a process paradigm Implementation provides a framework that may be and unit testing adapted to form a process which suits a Integration and system testing particular project. Operation and maintenance There are three major process para- digms that are commonly used today in Figure 2: The waterfall model2. software engineering practice; the 1. Requirements definition All waterfall model, component-based requirements on the system are software engineering and evolutionary found by talking to system users. development2. Example of requirements can be services, constraints and goals, The Waterfall Model such as “We want a webpage that The waterfall model is recommended colour-blind people can enjoy”. for large and complex systems that 2. System and software design In have a long life-time2. Some systems this activity, the overall which carry these attributes are also architecture of the system is critical systems. This means that if a established. fault would occur, it may result in: 3. Implementation and unit testing The software is implemented in Threat to human life (death or units which also are tested. injury) 4. Integration and system testing The units are merged together Economic loss into a complete system. Further testing is required. Environmental damage2 5. Operation and maintenance The system is delivered to the It is believed that the waterfall model customer and put into operation. would be an appropriate choice when “Bugs” are almost always found, developing a critical system, since the and therefore the system model emphasises on thoroughness3. required bug-fixing and maintenance. The basic concept is to take all the activities and treat them separately. In each of the activities described One activity is always followed by above, one or several documents are another, in the same way water travels produced. The idea is not to start on a down some falls. This description new activity until the documents becomes even more obvious when belonging to the previous activity is looking at a visualization of the model signed off, but in practice, this is not (Figure 2). how it is done. Instead most of the activities overlap and all the documents feed information to the different activities. Although these documents provide a good overlook, 10 (51)