Datasheet

Don’t get me wrong — the basic idea of game components is really great. There was a small webcast

from Mitch Walker, the Program Manager of the XNA Framework at Microsoft, at the time the first XNA

beta was released about the game components and how to combine them. At first I was not very sure what

to think of the content pipeline and the game components idea; it looked cool in the webcasts, but when

I started coding my first game projects in XNA I did not find it very useful to work with the designer that

was presented in the first beta. In the second beta and the final release, most of the initial game component

code was removed as well as the graphical designer component in XNA Game Studio. This happened

because Microsoft was not able to find a way to implement the designer and game components idea in a

useful way for the Xbox 360 console. (It had only worked on the Windows platform before.) See Chapter

4 for more details about game components..

While it can be a hassle to implement the UI and menu logic yourself, it makes game menus more

unique. Almost every game implements its own UI. But if you think about it, a standard menu system,

as Windows uses for every app, is boring; it is always nice to see the ways in which menus are presented

in new games. You can still extract code very easily and create your own game components if you want

to create a new game, and then you can just reuse the code (for example, the

SkyCubeMapping class).

Some game components, such as the camera and screenshot capturer classes from Chapter 4, are good

examples for components that can be reused in many other games, but almost everything else in the

games from this book is implemented without using game components.

One of Microsoft’s goals with this application model is for the community of game developers to create

and share their game components quite easily and improve the community aspect of XNA. As you

can see from the many XNA game development sites and the projects on open source sites such as

www.codeplex.com, the community is very active and willing to share, but it might not have much

to do with the application model. Check out the links later in this chapter for more information.

Content Pipeline

The content pipeline is used to import, compile, and load game assets such as textures, 3D models,

shaders, and sound files to your game project (see Figure 1-6). It greatly reduces the amount of custom

code you have to do to get graphics, 3D data, and shaders into your game. For example, if you drop a

model file into your project and it uses two textures and a specific shader, the content pipeline will

process your model file and automatically find and add the required textures and shaders. You don’t

have to do this for yourself; the content importer “compiles” the data into a binary format and, in the

process, it picks up everything you need.

Say the shader you added through the model you dropped into your project contains an error. In the

past you would have to start your game project, and then get an exception telling you that the shader

could not be compiled and the game would crash. Now the shader is compiled in the build process and

you don’t have to start your game to see that it does not work yet. You can quickly fix the error through

the line and error message from the build output in XNA Game Studio Express and then rebuild.

The content pipeline does not just consist of one dll; there are five different dlls:

❑ Microsoft.Xna.Framework.Content.Pipeline.dll contains the basic functions for the content

pipeline.

❑ Microsoft.Xna.Framework.Content.Pipeline.EffectImporter.dll is used to compile and import

shaders.

Part I: XNA Framework Basics

61286c01.qxd:WroxPro 1/21/08 3:44 PM Page 8