Welcome to the world of XNA. As a game programmer you probably know about DirectX and maybe even the basics of the XNA Framework... more

Welcome to the world of XNA. As a game programmer you probably know about DirectX and maybe even the basics of the XNA Framework. This chapter explains how to install XNA Game Studio Express and how to use it in a productive way. It also contains quite a lot of tips that might even be useful for anyone who already knows the basics.

In the next few chapters you start developing some cool smaller games. Part I contains the basic foundation and information about the helper classes you will use later in this book to develop a full-blown graphics engine for more advanced game projects. To keep things simple you start with 2D programming in Part I and then advance to 3D in Part II.

Let’s get started.

... less

This chapter provides information on designing and creating a simple Pong game. Pong was the first video game ever and even... more

This chapter provides information on designing and creating a simple Pong game. Pong was the first video game ever and even before the first Pong versions in the sixties there was a version that could be played on an oscilloscope (Tennis for Two, 1958, by William A. Higinbotham). This shows how easy it is to implement a very basic version of Pong. A TV engineer named Ralph Baer claims that he had the idea of implementing Pong even before that in 1951, but not until 1966 was he able to produce the first prototypes. Atari licensed Pong in the eighties and even fought a court case with another company claiming it was the first to invent Pong. If you think about it today the fight sounds really crazy for such a simple game. You can read the whole Pong story at www.pong-story.com.

Implementing a very simple Pong clone doesn’t take much time, but you will also learn about the sprite classes of XNA in this chapter. You start by writing the concept of your game and go through the full design phase of game projects. In future projects, you already know the process of writing a concept first, then create the first unit tests with help of the concept and finally go to the implementation process through each of the unit tests. Then you learn about an effective way to organize and use textures for your games. Additionally you will fine-tune the game, make it more fun, add two-player support, and even test it on the Xbox 360 console.

Although this chapter focuses on the Pong game, it is not the only thing you are going to learn. The Pong game is used to learn more about the Agile Methodology I mention later in this chapter. You will learn why it is important to write unit tests first and design the game up front in a very quick process and then improve it as you go along. In the next chapters, you use unit tests for additional classes, too. For this game, you just have one simple class and a couple of unit tests added at the end of it to test out the graphics and the collision testing, and to position everything correctly.

The types of unit tests used in this chapter are referred to as static unit tests as opposed to the dynamic unit tests you learn about in the next chapter. The difference is that you have to start static unit tests by hand and check the results yourself by watching the result on the screen. Dynamic unit tests, on the other hand, are executed automatically with the help of a Unit Testing Framework such as NUnit. For more details about the Unit Testing Framework, read Chapter 3.

... less

In the Helper namespace I usually put a lot of helpful little tools and classes, which become quite useful over time. For... more

In the Helper namespace I usually put a lot of helpful little tools and classes, which become quite useful over time. For a single project, it might not be the most important or valuable code, but because it is used again and again, no matter whether other parts of the engine change, helper classes will be the most consistent part of your engines and projects. Most of the helper classes don’t have much to do with game programming, and they are useful in other projects or even in websites.

You just saw in the previous chapter that you can write a whole game without any helper classes and without even using any extra files or classes at all. But as the projects become bigger and bigger, you will see that there are a lot of repeating patterns and similar problems occur, which were already solved in the past. Usually most of the reused functionality in XNA is graphic components. In the next chapter and especially in the second part of this book, you learn more about game components and the graphics engine. For now, this chapter keeps the focus on the very basic functionality to log messages, access the game content, and do unit testing effectively, as well as how to generate random numbers, and many other smaller issues.

To make this chapter a little bit more exciting, you also create another little game just for the fun of it. Not all of the helper classes will be used, but building a game engine is not an easy task. For that reason, this and the next chapter start with the helper classes and the game components to make developing your graphic engine in Part II of this book a little easier. Please note that I did not write the helper classes in the way they are presented in this chapter; they evolved over the course of the past couple of years. Just add functionality or your own helper classes whenever you need them. If you solve a problem once and think it might not be useful again, just leave it where it is. But if you find yourself copying that solution over to a new project or maybe just to another class several times, you should seriously consider extracting the logic and putting it into a special class.

Additionally, you learn a little bit more about the content pipeline you already used in the previous chapters to support the Xbox 360. It is possible to directly load textures or shaders without using the content pipeline, but all these methods work only on the Windows platform. If you want to create a cross-platform game you should make sure everything compiles and works on both the Windows and the Xbox 360 platforms. You will continue to do that throughout this book.

At the end of this chapter you will quickly develop a fun Breakout clone game. It will be a lot easier than in the previous chapter because you will write all the helper classes first. For example, sprite rendering is very easy with the help of the SpriteHelper class. You can find more helper classes and game components to improve both the Pong and Breakout games in the next chapter.

... less

This chapter covers the... more

This chapter covers the Game class and the game components you can add to it. To get your graphics engine up and running in the next chapter, you still need some new helper classes before starting with 3D concepts. The BaseGame class is used to implement more features and to include all the other classes you have written so far. It is derived from the Game class to take advantage of all the existing XNA features. In the same way our main test class TestGame is derived from BaseGame to help you execute static unit tests in your game. Then you will add the TextureFont class to your Helpers namespace to allow you to draw text on the screen, which is not possible out-of-the-box in XNA. Finally, you also add some of the existing functionality from the previous chapters such as input, controller handling, and sound output into special classes to make it much easier to write a new game. Instead of speaking in the abstract, this chapter provides a concrete example game.

In contrast to the previous chapter you are not going to write any helper classes first, but instead you are going to write the unit tests and the game class first and then add all the game components you need to your project. In the last few projects, the problems were fairly simple and once you resolved them there was no need to go through them again. For the game you are going to develop in this chapter many improvements can be made and you will see this becomes even more true the bigger the game projects become. Refactoring is still the most important thing you have to remember when working over existing code and improving your game. Sometimes you will even see the code used in the unit tests ending up somewhere else in the final game code.

For an example, I'll use a simple Tetris clone. It will feature a big play field with colored blocks falling down, support for keyboard and gamepad input, a next block field showing you what comes next, and a little scoreboard containing the current level, score, highscore, and lines you destroyed. If you are a Tetris fan like me and like to play it every once in a while, this game is great fun. Tetris is one of the most popular puzzle arcade games ever. It was invented by a Russian, Alexey Pazhitnov, in 1985, and became very popular after Nintendo released it on the Game Boy system in 1989.

... less

In the first section of this book you learned all about the XNA Framework and rendering 2D graphics with the help of the... more

In the first section of this book you learned all about the XNA Framework and rendering 2D graphics with the help of the SpriteBatch class. You also made some fun games. Now it is time to explore the much more exciting world of 3D graphic programming. Creating 3D games is a lot more work than just putting together a 2D game, but many games would not be possible without the great advances in 3D graphics technology. Some games such as strategy games are also possible in 2D, and the most successful strategy games of all time (StarCraft, WarCraft, Command & Conquer, Age of Empires) show that 2D games are still very popular. But if you take a look at shooter games, they would just not be possible without 3D graphics, and the better and more realistic the graphics get, the more fun the games often are. Other game genres such as beat-’em-ups, adventures, sport games, and so on have also benefited from the advancements in recent years. Sure, Pong and the early tennis games were a lot of fun 10 or 20 years ago, but they don’t compare in any way with today’s sport games.

XNA is a great framework for quickly creating 2D games. Even without a team of people behind you, you will probably be able to quickly throw together a game idea, make some graphics, or find someone to make some graphics for your game, and then program the whole game in a matter of weeks or months.

However, most game programmers are much more excited about creating 3D games, and a common mistake almost everyone makes is to compare their own game ideas with the most successful AAA titles that took big game studios many years to create. As an individual, you will probably not be able to compete with the next EA game, which will have had an experienced game studio with more than 100 people working on it, even if you think that their game is not as good as it could be in your opinion.

But this does not matter; most of us got into the game development scene because we like creating games and often because we think we can make it much better than all the other guys.

The good thing is that although it is hard to create a full-blown 3D game that can compete with AAA titles, you have to start somewhere, and getting into the world of 3D programming is getting easier and easier.. Many great websites, tutorials, frameworks, and books are available to quickly guide even very inexperienced programmers through the first steps of creating 3D graphics for games.

Because there are already so many resources available I will not focus on the math basics, how to work with matrices, or other 3D graphics basics. It would just be boring for many programmers who already know about it and it would take away many pages for more interesting projects in this book. The same way I told you in the first chapter that you should start by reading a C# book first if you are inexperienced with C#, I suggest that if you really want to know all the basics about 3D graphics, pick up a book for that. If you have worked with Direct3D or OpenGL before, you are good to go and should know all the basics already (let's hope that covers most of the readers here).

This chapter takes the classic approach of first writing down the requirements and creating the unit test for that and then goes into detail for every required new class you need. Your goal is to create your own graphics engine and the basic framework for all the projects and games for the rest of this book. The Tetris game from the last chapter already had many useful helper classes and some new graphics classes that will be refactored in this chapter. You will also add some new classes. Refactoring means that the classes will be rewritten to fit your new requirements.

... less

With the basic graphics engine now up and running you can focus on shader development for a while. As mentioned in the last... more

With the basic graphics engine now up and running you can focus on shader development for a while. As mentioned in the last chapter, everything that is rendered in XNA is done with the help of shaders, even if you don’t interact with shaders directly when using the SpriteBatch class or the SimpleEffect class to simulate fixed function behavior. This chapter goes through the whole process of writing a shader from the ground up, and then you learn all about vertex buffers, the vertex shader process, and how pixel shaders finally bring the pixels on the screen. If you are already a shader expert, you probably want to skip this chapter or just quickly fly over it. But because the next chapters all rely on a fundamental knowledge of shaders, I want to make sure everyone is on the same level.

Because shaders are so very important in XNA, you should really try to follow all steps in this chapter if you don’t have a strong foundation in shaders yet. The chapter is designed to let you follow every single step, and by the end of the chapter you will have written your first shader and you will not only understand all the steps in the process of shader creation, but also how to use them easily. Then you will be ready for the next chapters and you will be able to write your own shaders easily.

Before starting with cool normal mapping effects or post screen shaders in the next chapters, you have to learn the basics first. Shaders are not just used for high-quality effects; they also replace very simple rendering processes that were used in the days of the fixed function pipeline. After learning a little bit about the history of shaders and graphic card developments, you will go through the process of creating a simple shader just to render an example 3D model with per-pixel specular lighting and then import the shader into your graphics engine. To create shaders and test them out before you even start putting more code in your engine, you'll use FX Composer from NVIDIA, which is a great tool to get started and play around with your own shader ideas.

... less

The really cool advantage of using shaders is that every step of the rendering pipeline can be customized. For Pixel Shader... more

The really cool advantage of using shaders is that every step of the rendering pipeline can be customized. For Pixel Shader version 1.1 (GeForce 3), you have just eight instructions available. As such, the programmable pipeline is not so great because all it does is emulate the Pixel Shader instructions with preprogrammed hardware. Pixel Shader 2.0 is much more flexible by allowing many more functions (as you saw in the previous chapter the normalize and pow methods are only available for Pixel Shader 2.0 and up) and enabling you to write more instructions (the limit is 96 here, but some methods require more than one instruction).

Pixel Shader version 3.0 is even better by enabling better flow control, which means you can exit the shader code based on programmed conditions to optimize the performance. Complex shaders in Pixel Shader 3.0 can have up to 512 instructions, and even with very fast graphics hardware, this is a lot. When rendering many millions of pixels it takes a lot of time to execute that many instructions for every single pixel, even when you have 16, 24, or 32 pixel shader units working in parallel. The new NVidia 8800 GTX graphic card has even more shader units working in parallel—it has 128. Sometimes you might want to skip complex calculations if a pixel is not affected by several lights or doesn’t lie in the shadow. This way you can still achieve great looking and expensive Pixel shader effects, but you limit them to where they are required. Sounds great, but in reality most new games just use Pixel Shader 2.0 because it is supported by many graphics cards. Most games do not support the more expensive graphics hardware.

While the Shader Model 4.0 was introduced with Direct3D 10 in early 2006, the first graphics hardware (GeForce 8800) to support it wasn’t available until the end of 2006. Meanwhile, Direct3D 10 only works on Vista, and the hardware is quite expensive. It will take a while until game developers can fully utilize shader model 4.0. XNA currently only supports shader models 1.1 up to 3.0. Shader Model 4.0 allows even more instructions and introduces geometry shaders that manipulate and add geometry data before your vertex and pixel shaders are executed. All shader units are also unified in Shader Model 4.0, which means you can use them for whatever you want. There are no longer just 8 vertex and 16 pixel units; you have 128 shader units and they all can be used for geometry, vertex, and pixels shaders. This is great for amazing effects such as displacement mapping and level-of-detail effects. In 2007, you may see some cool demos, but games will probably not use geometry shaders until 2008 or later.

... less

Well, it was fun to write the graphics engine the last couple of chapters, but where is the next game? Don’t worry, in this... more

Well, it was fun to write the graphics engine the last couple of chapters, but where is the next game? Don’t worry, in this chapter a really cool game will be examined: Rocket Commander. The original version was released in March 2006, when the German www.Coding4Fun.de site went online and Visual Studio 2005 came out in Germany. One month and many thousands of played games later, the English Rocket Commander Tutorial Videos were created and two additional mods were released with it. Half a year later, 100,000 games were played online—even more if you consider the number of people who were playing offline. Many other mods were also created and the engine proved to be reliable enough, even for two commercial games that were released with the Rocket Commander engine: Pizza Commander and Rocket Racer.

The Rocket Commander game and the complete source code are free to download, and you are encouraged to play around with it or even use it to create your own games. I received many nice stories via e-mail of people learning C# for the first time, and they were able to create their own engines and games in a short time thanks to the Rocket Commander and the video tutorials on the German and English Coding4Fun sites.

Let’s just say the Rocket Commander game was a success. I didn’t get rich or anything, just famous. In December 2006, the final version of the XNA Framework and XNA Game Studio Express were finally released and I was working hard on the release of Rocket Commander XNA, a complete port of the Rocket Commander engine to XNA to make it possible to play the Rocket Commander game on the Xbox 360. The performance of the XNA port is great; it runs even better than the old version and the game has no problems with thousands of asteroids rendered at the highest detail level with anti-aliasing in the highest HDTV resolution (1920 × 1080, which is a pretty big screen resolution) on the Xbox 360. One major improvement of the new version is the support for multiple cores, which is important for both the Xbox 360 and today’s PCs. The game now calculates all the physics, collision testing, and other game data in an extra thread that is executed on another CPU core (if available, as on the Xbox 360) than the rendering thread, which is always busy pushing data to the GPU.

Before you get into the Rocket Commander game you are going to learn all about post-screen shaders first, which are also a major part of Rocket Commander in addition to the powerful rendering engine and the physics. For more information about physics, please read Chapter 13. Most information about the shaders for the 3D objects were already discussed in the previous chapters and if you are interested in the game logic, take a look at the source code or watch the Rocket Commander Video Tutorials.

For the rest of the book you will, of course, still use the XnaGraphicsEngine, but any improvements such as the heavily optimized render system in Rocket Commander XNA or the physics system can still be used for future projects. Most importantly for the look of all upcoming games, including Rocket Commander, will be the many pre- and post-screen shaders that are introduced in this chapter. Pre-screen shaders are executed before the 3D scene is rendered and allow you to render textures, sky cubes, and other effects in the background. Writing such a shader is quite easy.

Post-screen shaders, on the other hand, are much more complex and they are executed at the very end of the frame rendering process. They take the fully rendered scene as a texture on a render target and modify it in several steps to output the post-screen shader result on the screen, which the user then finally sees. Getting this render target right is not a piece of cake, but once you’ve got the system up you can easily plug in more post-screen shaders and play around with effects. Don’t overuse bloom and motion blur effects; it is cool to use those kinds of shader effects, but overusing them will not make your game better. Try also to make sure that the post-screen shaders run as fast as possible because they can heavily reduce performance on high resolutions, especially if you have five or more passes and modify every single pixel on the screen.

... less

This chapter takes a closer look at XACT. XACT is the name for Microsoft’s Cross-Platform Audio Creation Tool, which allows... more

This chapter takes a closer look at XACT. XACT is the name for Microsoft’s Cross-Platform Audio Creation Tool, which allows you to create audio projects for the Windows and Xbox 360 platforms. It is actually the only way to play sounds in XNA on the Xbox 360. It doesn’t matter so much for the Windows platform because you can plug in any other sound engine you want (DirectSound of DirectX, OpenAL, FMod, and so on) and play sound or music this way. It is not that easy on the Xbox 360 because you can use only the XNA Framework here and it is absolutely not possible to use any other framework for playing sound but XACT because you cannot use any unmanaged code in XNA. To play sound or use any low-level hardware on the Xbox 360, you would need unmanaged code to access it. For the same reason you cannot use any other graphics or input engine than the one XNA provides for you.

XACT was implemented into XNA to make sure it is possible to use the same sound content and sound playback code for both the Windows and the Xbox 360 platforms. For example, the Xbox 360 supports only XMA compression; the PC uses other compression formats for sound and music such as MP3, OGG, ADPCM, and many other custom compression formats, but only ADPCM and uncompressed sound files are supported in XACT. Voice-over-IP applications often use their own proprietary sound compression format because the human voice can be compressed better than music, for example. Luckily, XNA does allow you to use Voice via Xbox Live and Games for Windows Live services in the new XNA 2.0 networking API (for more details see Chapter 14). Sound effects are very short and small anyway, but as a game developer, you want the highest quality possible for sound effects. Therefore, sound effects are often uncompressed or use lossless compressions. Music, on the other hand, takes up a lot of space. If your game is on a DVD or you have plenty of hard disk space you can waste, you could just store the music as uncompressed .wav files or directly on the CD or DVD. For XNA games this is not an option because you can’t access the DVD on the Xbox 360, and wasting a few hundred MB for just the music is not a good idea for your game.

In the past, with DirectX or Managed DirectX applications, you would most likely use DirectSound for the sound playback or use other frameworks such as OpenAL or commercial sound engines like FMod (but FMod is free for personal use or open source projects). Even with these frameworks you will still have to do a lot of custom code; you have to decide which sound format is the best for you and you will have to worry about sound compression yourself. Additionally, you must implement a way to play music yourself, too. For example, DirectSound is really not usable for music — it just supports .wav files — but if you want to play MP3 or OGG music files, you have to use other frameworks such as DirectShow, Windows MCI, ActiveX sound playback codecs, or other free and commercial frameworks and sound engines. Yes, you are right, this sounds like a lot of work. The actual code to play back sounds or music is very simple for most games. It gets a little bit more complicated if you want to use complex 3D sound calculations and if you want to support surround sound, but it is still way easier to program these things than to develop your 3D engine.

More information about the improvements of XACT in XNA 2.0 will be provided later in this chapter. For the games in this book, it does not matter if you are using XACT from XNA 1.0 or the version from XNA Game Studio 2.0. The source code of the games for this book will be updated when XNA 2.0 final comes out, but the general way to play back sounds will stay the same as described in this chapter.

... less

This chapter takes a closer look at the... more

This chapter takes a closer look at the Input class that has been used so many times now. Then it discusses the ways to implement a good graphical user interface (GUI) for XNA Shooter. Handling the user input is very simple in XNA because, thanks to the Input namespace, you can easily get the mouse, keyboard, and gamepad states with just three lines of code:

mouseState = Mouse.GetState();

keyboardState = Keyboard.GetState();

gamePadState = GamePad.GetState(PlayerIndex.One);

If you don’t have the XNA Input namespace added to the file you are currently working on, go with the text cursor over Mouse, Keyboard, or GamePad and press Ctrl+., which automatically adds the following line to your using directives:

using Microsoft.Xna.Framework.Input;

Now you can use these states and check if the gamepad is connected at all, if the spacebar is pressed on your keyboard, or where the mouse position is currently. This is exactly what you did in the first and second chapter when you wrote your first XNA game.

The more complex your games become, the more often you will have to repeat the same code over and over again. As with the classes in the graphics engine, you often do not add more functionality, but instead you make the existing functionality easier to use. For example, the Texture class was used to store the XNA texture, the texture size, and whether or not it has alpha; it also contains many useful methods to render the texture directly on the screen with the help of the SpriteHelper class.

All this is possible with the standard XNA Framework, too, but you will have to write more code. If you just want to put one single texture on the screen it would not make sense to write all these helper classes, but if you write many projects and use hundreds of textures you will probably thank yourself for all the helper classes you wrote earlier. Only by simplifying the texture, shaders, and materials is it possible to write complex graphics code in a few lines of code, as you can see in the unit tests of the graphics classes.

The same logic applies to the Input class, too. The advantages are not that obvious, but you will notice after a while that writing new UI (user interface) code for your custom buttons or menu controls gets much easier thanks to the many helper classes, including the Input class.

Just writing a helper class is kind of boring, and you already know how to use this Input class because you already used it so many times. To get something useful done for your next game, XNA Shooter, you will also program all the UI classes and see the menu logic for the more advanced games shown in this book. The idea here is to reuse the existing Rocket Commander XNA game screen classes for newer projects. Some classes have to be removed and you might need a new class here and there, but the overall program logic is pretty much the same.

The game itself shows the user interface (ammunition, health, points, and so on) in the Mission class just like Rocket Commander did. For more complex games, like the racing game in the next part of this book, the game logic and the UI rendering code is separated into more classes. As with unit testing, you should always make sure that writing your game code is as simple as possible, but not simpler. It does not make sense to write 30 helper classes if all you want to do is to output “Hello World” on the screen.

Game UI and especially menu UI is a big topic for games. There was a time a few years back when almost every game had very complex menu animations or even 3D graphics, but they were very hard to use. You should try to keep things simple, not only for you as the programmer, but also for the user. You learn about a good menu design at the end of this chapter.

... less

In this chapter, I want to guide you through the creation of XNA Shooter, a little shoot-’em-up game, which is actually quite... more

In this chapter, I want to guide you through the creation of XNA Shooter, a little shoot-’em-up game, which is actually quite fun to play. It looks and feels better than the usual boring arcade games thanks to many cool effects, nice looking 3D models and a 3D landscape in the background with houses and plants, real-time shadow mapping, a cool sound track, and nice sound effects. I did not really expect to get such a great game when I started programming XNA Shooter (as you can probably guess from the name, which is not that great). But after I added shadow mapping, which is also used in the racing game in the last part of this book, the background and the 3D buildings looked very nice. The nice UI from the previous chapter and some cool post-screen shaders (see Chapter 8) also help.

This chapter allows you to follow every step in the process of creating XNA Shooter. The basic game was coded in two to three days and only some of the more advanced classes such as the EffectManager and the shadow mapping needed some additional tweaking. Shadow mapping is one of those things that is not only hard to implement at first, but you can spend days or even weeks tweaking it over and over again to make it look a little better and fix some issues (and there are always issues). XNA Shooter is completely based on the XnaGraphicEngine from Chapter 5 and on Rocket Commander XNA from Chapter 8. Only in this way is it even possible to create such a good looking game in that short timeframe.

It didn’t require a great deal of work to create the 3D models because I already had most of them from older projects. Thanks to the simple camera, which is fixed and always looks down on the ground, some 3D classes such as rendering sky cube maps or lens flares could be ignored. The camera also simplifies the way you can do the shadow mapping because you always see about the same 3D area in size.

The game logic itself is handled in the following four classes:

• The Player class, which you already know from the Rocket Commander game, is even easier to use here because you only need to keep track of the current time, score, health, and the selected weapons.

• The Unit class handles all enemy units. It updates their positions and AI and renders them on the screen.

• The Projectiles class is used to keep track of all the weapon projectiles you or any enemy unit shoot out. This includes plasma balls, your rockets, fireballs, or enemy rockets. Instant weapons such as the MG or Gatling-gun do not have projectiles; they hit the target immediately and you see the effects directly on the screen.

• The Item class is used to drop items after killing transporter or rocket frigate ships and allowing the player to pick them up by flying over them. Items can be health, EMP bombs, or simply one of the four weapon types.

The game logic is a little bit more complex than the logic for the Rocket Commander game. After you go through all these classes, you can see that the code in the Mission class is really easy. Then, after you put everything together, the game is almost complete. Just a little bit of play testing and fixing bugs and the game is ready.

... less

To create the last big game for this book, the XNA Racing Game, we are going to explore some of the more advanced topics... more

To create the last big game for this book, the XNA Racing Game, we are going to explore some of the more advanced topics of game programming in the next chapters like 3D landscape generation, physics, more complex controls and shadow mapping algorithms.

This chapter covers the whole landscape generation and render techniques as well as the track data for the roads in all levels. The next chapter takes a closer look at the physics engine required for the racing game. In the final chapter you learn all about the game screens, game logic, and fine-tuning of the racing game, and you get some final tips about game development. The game that is covered in this book is a complete racing game, but it shows you only one track and a simplified game principle. The complete XNA Racing Game is available as a starter kit for the XNA Framework by Microsoft at http://Creators.xna.com. The complete game covers more missions, more cool features, several cars, more cool looking 3D objects, which you can download and watch to learn more. We are going to cover all the basics to allow you to create a cool game like the Racing Game, but I want to cover more than just one game with the game engine we have written so far. It is not only possible to create game modifications of the Racing Game, but as we saw in the previous chapters it is helpful to have developed a full game with the game engine before starting with the next game

Before you go ahead and design your little racing game, you should think a little bit about what exactly the game should be capable of. Thanks to the many available racing games, especially on the console platforms, it is not very hard to figure out what these games need. Most racing games have great looking cars and show nice scenery around the road itself. The games themselves are often very simple, but the game designers take great care in fine-tuning the controller input and adding small features to make the racing games more fun.

After you are sure in which direction your game is heading, you can think about the required 3D models, textures, effects, and other data such as the landscape and track data, which will become very important for your game. I spent more than half the development time just getting the landscape rendering and track generation right. You will see later in this chapter why there was so much work involved and why several new shaders for the landscape and road rendering were required. When I say “so much work,” I mean relatively speaking. Keep in mind that the racing game was developed in a few weeks and is similar to Rocket Commander in that it’s a nice looking game, but you cannot compare it to an AAA game title that took years and many people to develop. Console games especially are developed by big game companies with 100 people or more.

The time is over when one man could code, design, and test his game in a few days or weeks as in the seventies or eighties (see Figure 12-1). But wait, there is XNA now and it is possible again to create your own games in short time frames. And if you think about it, the past was not really friendly to game developers. You had to implement your own routines to even get a pixel on the screen. I’m better off not mentioning that this most likely involved a lot of assembly machine code just to get it to work on one single hardware configuration. If you take a look at the Dream-Build-Play XNA Game Studio Contest of Microsoft at www.dreambuildplay.com, you can see many impressive games that were created in relatively short timeframes with XNA—both by hobbyists and professionals. The contest winners were announced at the Gamefest in August 2007 and while most games were in 2D, they all look very colorful, have refreshing game ideas and really unique styles. Let's hope that XNA 2.0 will bring even more skillful developers to the table and allow even more complex and bigger games in the future.

... less

The use of physics in games has become quite popular in recent years. It is not as if older games do not use physics engines... more

The use of physics in games has become quite popular in recent years. It is not as if older games do not use physics engines, but recently many shooter games have complex physics systems that are only possible because of the immense increase in computing power and multi-core systems. Even hardware PPUs (physics processing units) are available today, similar to GPUs that just handle graphics. These processors are just for calculating physics.

The games that use physics the most are first-person shooters, especially if the games permit a lot of freedom and enable the player to walk around freely and interact with the scenery. One of the most popular games, Half-Life 2 (launched in 2004), used a lot of innovative physics techniques and also involved physics in the game play and mission design.

Half-Life 2 uses the commercial physics engine Havok internally, but there are several other physics frameworks, which are discussed in a short while. Sadly none of these frameworks work on the Xbox 360 with the XNA Framework because they all use unmanaged code, which is not allowed on the Xbox 360 when you develop games with XNA. On the PC you can use whatever you like, and this chapter discusses which framework might be the best to use right now. The Racing Game that you are currently developing will not make use of any advanced physics framework for that reason. It is also a lot of work to implement and test such a powerful framework, and most of the physics engines are expensive to license. In Half-Life 2, the engineers spent several years tweaking and fine-tuning the physics until they were pleased with the result.

Physics always comes along with some heavy mathematics. It is certainly possible to use a physics framework or apply a simple formula such as the famous F = m * a without knowing much about physics or math. However, as soon as you want to develop your own physics system for your game, you will need at least a basic understanding of Newton’s laws of motion. Having a physics formula book nearby, or at least having Google at your fingertips, for help is also a good idea. Figure 13-1 shows a typical example of a physics problem involving several objects, transmitting forces, gravity, and so on.

When you talk about physics you just have to mention Isaac Newton, the apple, and the tree. You know the story. Physics has evolved quite a bit since then. There are many theories about the extremely small world of atoms, quarks, electrons, and so on. Of course, many other theories exist about the macro cosmos, the solar system, stars, planets, and so on. But for most games, you usejust a bunch of simple physics formulas to help you accelerate and decelerate objects. It is just not practical to work on a smaller scope due to limited processing power. In addition, it just has to look good, so you don’t need every virtual atom to behave as it would in the real world.

While formulas such as Newton’s laws of motion are heavily used, you are going to spend most of the time with collision issues, such as those in the Rocket Commander game (Chapter 8). At least physics are fun. Unit testing enables you to quickly try things out. Be aware, however, that you can spend a lot of time with physics without seeing the results of your work if the world of your game does not allow much interaction. It is nice to have real physics for a puzzle game, but if all you can do is click on objects to be removed, you really don’t need a complex physics engine. Just fake it!

... less

You are finally going to learn about all the details of the Racing Game here. In this chapter, you learn all about the game... more

You are finally going to learn about all the details of the Racing Game here. In this chapter, you learn all about the game screens used in the racing game and the game logic, the scoring system, and everything else you need for the game itself. Most of the rendering techniques for the landscape and the track were already discussed in Chapter 12, but this chapter shines a little more light on the whole shadow mapping thing. Thanks to the previous chapter, which covered everything about the game physics and car controlling, you should now be able to plug in this code and start actually testing out the game itself.

The whole purpose of this chapter is to get you familiar with the racing game and the underlying code. At the end of this chapter you should know everything you need to create your own game modifications (better known as mods) of the racing game. A game modification can be as simple as just changing a couple of graphics and 3D models or it can change the whole game logic in a way that it is no longer a racing game. The Rocket Commander game, for example, was also mod-able, but the game logic and the rendering code itself were pretty much fixed. You could more or less just change the models and add a little bit of game logic. Although most Rocket Commander mods looked quite different (see Figure 14-1), the game logic was always similar. The game principle in Rocket Commander is always to fly around and avoid colliding with certain objects (such as asteroids) while also collecting items such as health, fruits, pizza pieces, and so on. Some mods had an even faster game speed; other mods were much slower and focused on solving puzzles like collecting the correct ingredients or fruits (Pizza Commander and Fruit Commander). The good thing about creating mods in Rocket Commander was that it was relatively easy to change the original game. If there are just a couple of different 3D models it is simple to change them. It was also not hard to change the game logic because you would only have to worry about the Mission and the Player classes; the rest of the classes were just used for the menu and graphics rendering engine.

The latest mod (at the time of this writing) is Canyon Commander, and it shows that the graphics and game play can be changed quite a lot without much effort. The mod was created by a .NET beginner in Canada and this was his first game project. Quite impressive I would say.

The racing game of this chapter, on the other hand, is a little bit more complex and allows even greater game changes. There is no reason why it should not be possible to take the code and 3D models and make a completely different game out of it. Landscape engines can be found in strategy or role-playing games, but even outdoor shooters or adventures could greatly benefit from an existing landscape rendering engine. It would, however, be a little bit more work to make a total mod and to change the whole game logic and even removing the code responsible for generating the roads when you don’t need it for your mod.

It is obviously a lot easier to stay in the same genre and just change a couple of 3D models and maybe tweak some of the game parameters. This is what you are going to do at the end of this chapter with the Speedy Racer mod, but you are free to implement your own game ideas yourself by then. The Speedy Racer mod exchanges the car model and also makes the road much wider and simpler to drive on, but it greatly increases the car speed. This mod is discussed in detail at the end of this chapter.

... less

This chapter is about multiplayer game programming and networking concepts. This knowledge will help you no matter which... more

This chapter is about multiplayer game programming and networking concepts. This knowledge will help you no matter which kind of multiplayer game you want to write. It does not matter if it is a role-playing game, strategy game or a first-person shooter, the basic knowledge of writing a networking game or application will be very helpful and you can see that most of the classes can stay the same. You just handle the data differently depending on the game structure and game modes.

This chapter is also all about networking, Xbox Live, and Games for Windows Live. It does not matter what kind of game you want to write; if you want multiplayer support beyond split screens, you will need a powerful networking API. XNA 2.0 happens to deliver just that, but at the time of this writing, it is not publicly available. For that reason, you are going to learn all about networking with the System.Net classes from the .NET Framework. The knowledge is applicable to XNA 2.0 networking. You can save some code by not having to write your own messaging and session management classes because XNA 2.0 already handles all that for you, but it does not hurt to know about how they work. While System.Net provides all the low-level classes you ever need on Windows for network programming; it is not supported on the Xbox 360 via XNA yet. XNA 2.0 uses an own networking API and you can only use this API for any network communication on the Xbox 360. If you just want to write a Windows game, you still can use the XNA 2.0 networking APIs, but you are not limited to it. There are also many other commercial and free networking APIs available and many of them have support for .NET and can be used with your Windows game, but this is beyond the scope of this book.

First, you will learn how to write a very simple chat application via UDP Packets. UDP Packets are also used for the XNA 2.0 networking API, but they are hidden and just used internally. All the classes from this chapter will be the basis for all networking code in the later chapters. While some easy unit tests to send some packets around would usually do the job, a more solid approach is chosen here. You can use the networking classes from this chapter in the next two chapters and the resulting game, which makes it even more important to write a flexible code base and offer the capability to easily extend the messages. More on network messages in a little while after you have learned the basics.

The next chapter develops the concept for the role-playing game and covers important game design decisions. This is not only useful for the game screens and required game classes on top of the existing XNA graphics engine you have so far, but it is also important for designing the game messages. In a multiplayer game you have to think about how all connected players stay in contact and communitcate with each other. The next chapter also explains how to add some extra features such as an animation system for models with help of skinning and bone skeletons, and it features an updated UI system for a more complex menu and in-game handling of game events and networking messages.

Chapter 17 finally brings all the new parts together and explains how each part of the Dungeon Quest game fits together. While this book tries to explain as much as possible about the Dungeon Quest game, it is focused on giving you good advice on how to use graphics, sounds and networking in your games. Dungeon Quest is also an open source project that will probably change constantly. More information about Dungeon Quest, the development process, discussions, and new game mods can be found on the official website for the game: www.DungeonQuestGame.com.

... less

This chapter covers role-playing games in general and then explains the concept of the Dungeon Quest game in detail. Not... more

This chapter covers role-playing games in general and then explains the concept of the Dungeon Quest game in detail. Not only are the concept and the ranking and leveling system explained, but we will also take a look at the available player characters and enemies in the game. The chapter ends with some general game logic unit tests and a little bit more about the UI, both in the menu and in game.

But before we get back to coding, let’s first get into the game concept of Dungeon Quest. The very first version of Dungeon Quest was developed in just four days live at the Game Developer Conference (GDC) 2007, in March 2007. The game was part of a contest hosted by Microsoft called XNA Challenge, where four games were developed in four days by four teams directly in the GDC lobby with all the noise and distractions a big conference like the GDC brings with it. But each team managed to finish their game on time. Our team consisted of one programmer (me) and one artist (a friend of mine, Christoph Rienaecker).

The absolutely insane idea was to create a multiplayer role-playing game from scratch in these four days. While the multiplayer part was pretty hard to do on the Xbox 360 console (we tried split screen support, but it never made it into the game logic, just a unit test was written), the rest of the game went as we wanted. This version of Dungeon Quest (see Figure 16-1) featured a third-person view from behind like many current role-playing games, supported skinned animations, and had five different enemies. A player character with five different animations blended smoothly. Then there is the cave, which consists of half a million polygons and uses a highly complex shader (more complex than Pixel Shader 2.0 would allow) with up to six dynamic point lights. All the game entities have collision detection against a lower polygon version of the cave.

But even with all the cool shaders, animations, and effects, everything was just thrown together as fast as we could. The game is not easily extendable and it does not have any replay value, which most role-playing games have in abundance. Once you have gotten through the cave, opened the door to the second level, and found the treasure at the end of the big hall, the game is over and playing it again will not reveal anything new.

For that reason and because we have some better ideas, we’ve decided to remake Dungeon Quest, but this time we are not going to copy one of the popular Massively Multiplayer Online Role-Playing Games (MMORPGs) game principles. While Dungeon Quest is not really a Massively Multiplayer Online (MMO) game anyway, why try to make it similar in any way. It is highly unrealistic that we will create a complex role-playing game in a few days or weeks that took other teams many years, possibly with hundreds of man-years of work behind them. Instead, we thought of the earlier and simpler role-playing games such as Diablo 1 and 2, and Sacred, but also newer games such as Titan Quest or Dungeon Siege. Writing these games is not a piece of cake either, but we always liked the team-play aspect of these games, even if they were originally designed to be played in singleplayer mode. This is where the new Dungeon Quest game comes in, keeping the basic game simple, but allowing it to be extensible both via the source code and via the editor, which allows you to create more maps and worlds. The fun of this game should come from its replay value and extensibility. In particular, more complex maps and quests should be more fun when playing them with a few teammates.

... less

This is the final chapter about Dungeon Quest and also the final chapter of this book. Because of the complexity of a role-playing... more

This is the final chapter about Dungeon Quest and also the final chapter of this book. Because of the complexity of a role-playing game such as Dungeon Quest, we are unable to discuss all of its details here. We will, however, cover all the basics to get you started. You can find additional information about the game, get help with the implementation, and obtain recent updates on the official site: www.DungeonQuestGame.com.

The first part of this chapter discusses the game engine and its features. In the previous chapter, I discussed some of the game engine features. While we are still using the XnaGraphicEngine from Part II of this book, and the parts of the engine from the Racing Game from Chapter 14, many parts have been updated or even completely rewritten. For example, all 3D models use the Collada model format now. This makes it much easier to fix exporting errors, to miss textures, and to import animation data. It also allows a greater range of 3D tools to be used to create 3D models for the game. I am also going to discuss the new shaders used for the maps. In addition, I discuss how skinned animation works and how to use multi-pass shaders for the underground and lighting effects. Most of the engine features are shown with help of the in-game editor Dungeon Quest provides to the player.

In the previous chapter, most player characters and enemy types were introduced. In order to allow them to run around, attack players, and be killed, you need some basic AI (artificial intelligence) for them. The AI engine will still be simple, but it gives you the basic foundation for adding AI to your own games. Luckily for us, the AI for role-playing games does not have to be very sophisticated because most enemies should not be intelligent. Zombies, for example, are expected to be dumb. However, if you want to make the game and enemies appear to be more intelligent, you can add the alert-system to the AI engine. Whenever a monster sees one of the players or gets attacked, the monster will cry and alert surrounding monsters to go into attack mode as well. This is especially important for ranged attacks from the Hunter or Mage because otherwise they could simply kill one monster at a time and have it far too easy.

Later in this chapter, I discuss multiplayer support by introducing all the required steps to make the game a good multiplayer game. In Chapter 15, you saw some of the networking code for the lobby and chat screens. Because we are mainly adding more network messages here, I will discuss the opportunities with Xbox Live via XNA 2.0. Networking is only possible via Xbox Live on the Xbox 360 with XNA 2.0, so we have to investigate it a little. At the time of this writing, however, it makes absolutely no sense to use the networking capabilities of XNA 2.0 for a Windows game because it would require all players to be both Xbox Live Gold subscribers and XNA Creators Club subscribers. Both subscriptions cost quite a lot of money each year. I discuss this issue and what it means for XNA developers at the end of this chapter.

The last part of this chapter focuses on the level editor and all its features that enable you to quickly create new maps and play with the 3D models, adding enemies and the lighting effects. Getting used to the Dungeon Quest level editor is the first step in getting to know Dungeon Quests and building your own modifications. I hope that more players and non-programmers will extend the game and make their own modifications than for the Rocket Commander or Racing Game, which did not include an editor and made it hard for non-programmers to modify the game.

... less

This book has covered a lot of ground. I hope you have learned enough to develop better games. The following resources should... more

This book has covered a lot of ground. I hope you have learned enough to develop better games. The following resources should help you out a little—I’ve included all the links, books, source code, and games that were mentioned throughout the book.

... less