Codetopia

This ZIP archive contains source code from the book, XNA Game Studio Express: Developing Games for Windows and the Xbox 360, by Joseph Hall. The following paragraphs describe the changes that have been made to the code since it was first released with the book.

Hefty File Warning

The source media for this project bloats the size of the download to nearly 48MB. If you're not terribly interested in seeing how poorly I applied the XNA Framework's audio APIs to this example, feel free to save me from bandwidth overages by not downloading this ZIP file. Of course, if you're going to actually use the code, please feel free to click the link. I'll try not to make you feel guilty. And I won't complain. Much.

New Version of XACT

In addition to numerous changes and additions to the XNA Framework, the XNA 2.0 release also brings a new version of the XACT utility. Upgrading your existing XACT projects is as easy as opening them in the new version of the tool, and clicking "Save".

You'll need to put your XACT project files (the *.xap files) in the Content folder off your project's root directory. As with the earlier versions of XNA, you'll also want to store your source media in the same relative location as your XAP file. That means that your WAV files will live in the Content directory as well. The Content Pipeline doesn't process WAV files directly, though. So you'll need to tag your XACT source media with a "Build Action" of "None", and a "Copy to Output Directory" of "Do not copy".

You may be asking why you should bother to include the source media in your project at all. After all, the Content Pipeline only needs the XAP file to kick off the content build. As long as the source media lives on the file system in a path that the XACT project can access, the build will work just fine without "polluting" the project with unbuildable (as far as Visual Studio is concerned, at least) files.

The short answer is that you don't (as far as I know) have to include the files in your project. The main reason that I suggest including them in the project is to make life easier when you're working with a team that takes advantage of source control. The new XNA release supports all flavors of Visual Studio 2005, and all but the Express version support version control. When you open a project for the first time from source control, Visual Studio will download all the files that are associated with the project -- including the "don't build me" files.

Of course, you could also build the XNA-friendly files within XACT, and import them into your project as normal "copy me when you build the project" content as well.

Changes to the Source Code

Since I moved the XACT project file into the Content directory, I also had to update the code that references the output of the XACT project. The original code to load audio content for this chapter's game looked like the following snippet.

    // initialize our sound objects
    m_audio = new AudioEngine("example.xgs");
    m_wave = new WaveBank(m_audio, "example.xwb");
    m_sound = new SoundBank(m_audio, "example.xsb");

During the conversion, I changed those lines to the following logic.

    // initialize our sound objects
    m_audio = new AudioEngine(@"Content\example.xgs");
    m_wave = new WaveBank(m_audio, @"Content\example.xwb");
    m_sound = new SoundBank(m_audio, @"Content\example.xsb");

So, with all the breaking changes that were made to XNA in this release, why didn't the XNA team switch to a model where audio content is loaded just like any other media content -- something like 'm_audio = Content.Load<AudioEngine>(@"Content\example.xgs");'? Beats me. 

New Game1 Member Variables

The Microsoft.Xna.Framework.Game class now has a SpriteBatch member variable, named "spriteBatch". We don't need to add one, so you can replace any reference in the text to "m_batch" with the provided member variable, "spriteBatch". Of course, this means that you'll want to remove this auto-generated SpriteBatch logic for game projects in which you won't be using any sprites (which is the case with the example 3D code in Chapter 06).

The Game class now provides a member variable (called "Content") which exposes the ContentManager class. We don't need to manage our own reference to the content manager now, so you can replace any reference in the text to "content" with the provided member variable, "Content" (notice the change in capitalization).

The Game class also provides a member variable (called "GraphicsDevice") which exposes the GraphicsDevice object which represents the active graphics device. You can replace any reference in the text to "graphics.GraphicsDevice" with the provided member variable, "GraphicsDevice". You'll see this change in the auto-generated Game1 class when you create a new XNA 2.0 game. The spriteBatch member variable is initialized using "new SpriteBatch(GraphicsDevice);" rather than the previous "new SpriteBatch(graphics.GraphicsDevice);".

LoadContent vs. LoadGraphicsContent

The LoadGraphicsContent and UnloadGraphicsContent methods of the Microsoft.Xna.Framework.Game class (technically, they're members of the DrawableGameComponent class, from which Game is derived) have been replaced with the LoadContent and UnloadContent methods. The old content management methods still work, but the compiler will generate deprecation warnings for them, and there's a good chance that the old methods will be removed from future releases of the XNA Framework.

Content Folder

All content is now stored under the Content folder of your project. Prefix any content subdirectory names in the code with "Content\". For example, most of the book's examples store game media in the "media" subdirectory, which is located just off the root directory of the project. An image named "myImage.png" within that subdirectory would have been refered to as "media\myImage" in XNA 1.0 and XNA 1.0 Refresh. In XNA 2.0, that same resource would be refered to as "Content\media\myImage".

The Content folder actually represents a subproject called "Content" which manages the building, converting, and importing of media for your game. Any media that is accessed via the ContentManager class should live here. This includes items such as textures, models, and XACT projects. Any game-specific content data that you manage manually, such as level data and persisted game data, is not housed within the Content directory.

Intuitive File Names

I used longer, more descriptive filenames for the solution files, project files, and directory names. The new names make it much easier to locate the source code for a specific chapter. This may cause issues if you do your development in a deeply-nested subdirectory, like the default Visual Studio project folder of "C:\Documents and Settings\{username}\My Documents\Visual Studio 2005\Projects\".

I suggest creating a folder off the root of the drive from which you wish to develop your XNA games. I use "C:\projects\" on my laptop, and "E:\projects\" on my desktop.

ZIP Anatomy

All of the ZIP files which host the book's source code use a parallel directory structure. I expect the user to download the ZIP files into a common directory, then extract the files from each ZIP directly into that directory, preserving the ZIP file's internal directory structure. For example, if you download PT1_CH04.zip, PT1_CH07.zip, and PT2_18.zip into the "C:\projects\" directory on your local PC, and then extract the files to that same folder, you should have the following directory structure on your local drive.

   C:\projects\Part 1 - Introduction\CH04 - Graphics 2D\
   C:\projects\Part 1 - Introduction\CH07 - Input GamePad\
   C:\projects\Part 2 - Genre Studies\CH18 - Board Games\