In order to port your XNA games from your computer to your Zune player or Xbox 360, you must establish a connection between them. This is done using the XNA Game Studio Device Center. Instructions for setting up these connections was provided in Chapter 2. Once you have established connections to these devices, assuming you have both, you should see them listed in the XNA Games Studio Device Center window, as demonstrated in Figure 11.1.

Figure 11.1. An example of a computer with connections to both an Xbox 360 and a Zune player.

The most common approach to developing games for the Xbox 360 and the Zune player is to create your games and get them working correctly on your computer and then to port them over to other platforms, adding platform-specific features and code adjustments. A big reason this approach works so well is that between 95 and 100 percent of your program code will work just fine with no changes required. However, sometimes you will have to make changes or additions to your code. The primary purpose of this chapter is to identify these types of situations and to provide you with guidance on what you will need to do. If you prefer, you may of course start out developing a game for a specific platform without first generating a Windows version.

Creating a Platform-Specific Game

If you only want to create a game for a specific platform, you can do so by clicking on File > New Project and then selecting either Xbox 360 Game (3.1) or Zune Game (3.1) from the available list of new project templates, as shown in Figure 11.2.

Figure 11.2. Creating a platform-specific game.

Next, enter a name for the game and then click on OK. In response, XNA will create a new project for you. It will include all of the expected methods (Initialize(), LoadContent(), UnloadContent(), Update() and Draw()). At this point, you can go ahead and begin developing your game.

Hint

There is one small difference between the code that is automatically generated for a Zune game and that of a Windows or Xbox game. Specifically, an extra comment and code statement is included in the Game1 class defined at the beginning of the program file in Zune games, as shown next in bold.

public Game1()
{
    graphics = new GraphicsDeviceManager(this);
    Content.RootDirectory = "Content";

    // Frame rate is 30 fps by default for Zune.
    TargetElapsedTime = TimeSpan.FromSeconds(1 / 30.0);
}

Remember, the Zune player redraws its screen at a default rate of 30 frames per second, not 60 like on Windows and the Xbox 360.

Converting a Windows Game to Another Platform

Although you can start out creating a game for a specific platform as just described, a more commonly used approach is to start out creating your game for your computer. Once you have the core of the game developed and have tested and debugged any problems that may have occurred, most XNA developers then create a copy of the game for either Xbox 360 or the Zune player (or both) and then finish up by making any needed platform-specific adjustments to the game.

When you follow this Windows development first approach to game development, you will have a single project to manage as you begin game development, as shown in Figure 11.3.

Figure 11.3. An XNA game made up of a single project.

Once you have the game up and running properly on your computer, you can make a copy of it for the desired target platform by right-clicking on the project name in Solution Explorer, as shown in Figure 11.4, and selecting either Create Copy of Project for Xbox 360 or Create Copy of Project for Zune.

Figure 11.4. Creating a copy of a game for the Xbox 360.

Hint

Note that if you began game development by creating a project for either the Xbox 360 or the Zune player, you would see an option to Create Copy of Project for Windows.

Once done, a second copy of your project will be added to Solution Explorer, as demonstrated in Figure 11.5. The new copy of your game project contains a complete copy of all of the files that make up the original project.

Figure 11.5. An XNA project with code for both Windows and Xbox 360.

Note that any changes you make to one project are also made to the other project. Therefore, if you create a project for Windows, then make a copy of the project for Xbox 360, and then make a change to the Xbox 360 copy of the project, the changes are made in both the Windows and the Xbox 360 project. You can work around this restriction by embedding platform-specific code statements inside conditional compilation symbols, as discussed later in this chapter.

Also note that when working with multiple projects, only one project at a time can be set as the startup project. This is the project that is compiled and executed when you run your game from within the IDE. To specify which project you want to make the startup project, right-click on the project name and select Set as Startup Project, as demonstrated in Figure 11.6.

Figure 11.6. Setting a project as the startup project.

Once you have specified which project should be the startup project and are ready to test its execution on the target platform, click on Debug > Start Debug, and XNA will attempt to compile the application. If compilation is successful, it will connect to and install the project on the specified target platform (assuming that you have connected the target device to your computer and that it is powered on and ready to go).

Trap

To connect to and deploy an application to a Zune player, add the device to your computer using the XNA Game Studio Device Center as was explained in Chapter 2. Don’t forget to make sure your Zune player is turned on. To connect and deploy to Xbox 360 you must start the XNA Creators Club software on your Xbox 360 to put the device into connection mode and add the device to your computer using the XNA Game Studio Device Center.

Once deployed, your XNA game will automatically start on the specified target platform. Since the game is installed on the target platform, you can play it whenever you wish. On the Zune you will access it from the Games menu. On the Xbox 360 you will access it by opening the Xbox Game Library.

Okay, so now you know how to create platform-specific applications and how to convert applications from one platform to another. You also know how to deploy your XNA games to Xbox 360 and the Zune player. Now it’s time to consider different platform issues that you need to address to ensure that your games will run just as well on the Xbox 360 and Zune player as they do on your Windows computer.

if (GamePad.GetState(PlayerIndex.One).Dpad.Up == ButtonState.Pressed)
{
    //The player wants to move up
}
if (GamePad.GetState(PlayerIndex.One).Dpad.Down == ButtonState.Pressed)
{
    //The player wants to move down
}
if (GamePad.GetState(PlayerIndex.One).Dpad.Left == ButtonState.Pressed)
{
    //The player wants to move left
}
if (GamePad.GetState(PlayerIndex.One).Dpad.Right == ButtonState.Pressed)
{
    //The player wants to move right
}

paddleX = paddleX + (paddleXSpeed * gamePad1.ThumbSticks.Left.X);
paddleY = paddleY + (paddleYSpeed * gamePad1.ThumbSticks.Left.Y);

if (GamePad.GetState(PlayerIndex.One).Buttons.A == ButtonState.Pressed)
{
    //The A button has been pressed
}

MediaLibrary zuneLib = new MediaLibrary();
SongCollection songList = zuneLib.Songs;
MediaPlayer.Play(songList);

As has already been noted, XNA allows you to add platform-specific programming logic by embedding code statements within conditional compilation symbols. A conditional compilation symbol is a set of characters that mark a set of code statements that are indented for specific platforms. As such, only statements applicable to a given platform are compiled into a specific platform’s copy of your XNA game.

XNA automatically defines default conditional compilation symbols for each platform that you add to your XNA projects. To view the conditional compilation symbols for an Xbox 360 version of a project, click on Project > Xbox 360 Copy of Xxxxxx Properties (where Xxxxxx is the name of the game). In response, the screen shown in Figure 11.7 is opened in the code editor window.

As shown in Figure 11.7, XNA generates two conditional compilation symbols for Xbox 360 that are used to mark platform-specific program code. These symbols are XBOX and XBOX360 respectively. XNA generates a single conditional compilation symbol for both the Zune and Windows. These are the ZUNE and WINDOWS symbols.

Figure 11.7. Viewing the conditional compilation symbols for Xbox 360.

The following example demonstrates how to use conditional compilation symbols to adjust an application’s screen size.

#if !ZUNE
    graphics.PreferredBackBufferHeight = 600;
    graphics.PreferredBackBufferWidth = 800;
#else
    graphics.PreferredBackBufferHeight = 320;
    graphics.PreferredBackBufferWidth = 240;
#endif

In this example, a screen size of 600 × 800 is used if the game is compiled for Windows or the Xbox 360 and a screen size of 320 × 240 is used if the game is compiled for execution on the Zune player.

The most common error you will come across is syntax errors. Syntax errors occur when code statements fail to conform to C#’s rules. They often result from typos, such as when you mistype a keyword or omit a required parameter.

The Visual Studio Express IDE highlights syntax errors in your program code by underlining them, as demonstrated in Figure 11.16. This makes them easy to locate and fix. Syntax errors are also visible in the Error List window, as seen at the bottom of Figure 11.16. This window is automatically displayed if you try to run an XNA application with syntax errors. Each error message includes a description of the error and shows the line number of the statement that generated the error. If you double-click on an error, the IDE will locate the statement where it resides.

Figure 11.16. The compiler highlights syntax errors by underlining them.

A logical error is caused by a mistake on your part. For example, suppose you write a statement that adds two numbers together that you really meant to subtract. As far as XNA is concerned everything is okay. However, the output won’t be what you want.

The IDE cannot identify logical errors for you. The best way to prevent them is to take a little extra time to plan and formulate your program logic. Also, make sure you organize your applications into methods and that you limit your methods to specific tasks. Also set aside plenty of time to test.

A third type of error is a runtime error. These errors occur when a statement tries to do something that is impossible. For example, a runtime error will occur if your game performs an illegal operation like dividing a number by zero.

The compiler won’t flag a runtime error. You have to compile your game, run it, and then do something to make the code containing the runtime error execute in order to find it. As such, runtime errors can easily be missed if you do not take the time to test your XNA games, in which case players will be left to discover your runtime errors, which is the last thing any game developer wants to let happen.

If you come across a runtime error when testing an XNA application, you’ll get an error message like the one shown in Figure 11.17. If you fail to find and fix a runtime error during testing, the release version of your game may or may not display an error message when it executes. Instead, it might simply stop responding or even lock up the player’s computer.

Figure 11.17. An example of a runtime error message.

Runtime errors can occur if the player provides your game unanticipated input, especially if keyboard input is involved. It is essential that you add logic to your applications that validates user input whenever possible. Unfortunately, there is no way to completely do away with runtime errors. Sometimes hardware fails or networks crash. If your game needs access to these resources, a runtime error will occur. Fortunately, as you will soon learn, you can create exception handlers that can recover from or gracefully respond to unavoidable runtime errors.

To configure a breakpoint in your application, locate the line where you want to place it and then click on the left-hand margin of the code editor beside the line. Once set, a circular marker is displayed in the margin. In addition, the specified line of code is highlighted, as demonstrated in Figure 11.18.

Figure 11.18. Adding a breakpoint to your application.

You should place breakpoints within your applications at places where you suspect problems. There is no limit to the number of breakpoints you can set. When you run your application execution pauses when a breakpoint is reached. In addition, the breakpoint’s circular marker changes to an arrow, as demonstrated in Figure 11.19.

Figure 11.19. The IDE highlights the active breakpoint.

You can gain a lot of insight into the execution of your application by establishing a breakpoint and examining property and variable values. As an example, look at the bottom of Figure 11.19 where you will see that the Locals and Immediate windows are displayed. The Locals window displays values and their type. If you want, you can modify a variable’s value in the Locals window to see what effect this has on the application.

You can use the Immediate window to examine any variable, array, or property value. If you look at Figure 11.19, you will see that the value assigned to name-Array[0] was checked entering a question mark followed by the array’s name and the index position of its first item.

Another important debugging feature provided by the IDE is the ability to step through the execution of program statements. This way you can set a breakpoint at a section of code where you suspect an error and then step through the execution of statements that follow the breakpoint a line at a time.

The Visual Studio IDE supports three different ways of stepping through program code, as listed here:

You can switch between these three options as needed when debugging an application. The easiest way to work with these options is to click on their icons located in the IDE’s standard toolbar, as shown in Figure 11.20.

Figure 11.20. The debug icons give you control over application execution when debugging your applications.

If you find a statement with an error when debugging, the usual thing to do is stop the debugging session and fix the error, after which you can execute the application again to see the result of your changes. However, Visual Studio Express has a feature called Edit and Continue that lets you apply changes to the application when paused at a breakpoint. You can then resume execution to see what effect your change had.

To execute this feature, locate the yellow arrow that identifies the next statement to be executed and place your cursor over it. A transparent arrow will appear. Drag and drop the yellow arrow to a previous location in your program. This way you can resume execution from a previously executed statement. You can now apply your correction and click on the Step Into button to resume execution and see if the change fixed things.

Microsoft’s recommended approach to developing exception handlers is the try…catch…finally code block. It allows you to enclose statements where errors may occur and then to handle them.

To set up a try…catch…finally code block, place statements where you think an exception might occur inside the try block and then add programming logic to handle the exception in the catch block. If more than one exception is possible you can add additional catch blocks, each designed for a different type of exception. You can also include an optional finally block. If included, this block will always execute even if an exception does not occur or even if a catch block executes. The finally block always executes last.

To better understand how to work with the try…catch…finally code block, let’s look at the example shown here:

protected override void Update(GameTime gameTime)
{
    // Allows the game to exit
    if (GamePad.GetState(PlayerIndex.One).Buttons.Back
      == ButtonState.Pressed)
        this.Exit();

    string[] nameArray = new string[4];
    nameArray[0] = "Alexander";
    nameArray[1] = "William";
    nameArray[2] = "Molly";
    nameArray[3] = "Mary";

    nameArray[9] = "Jerry";

    base.Update(gameTime);
}

Here an array named nameArray is defined. The array has been defined as being able to store a maximum of five items (e.g., at index positions 0 – 4). However, the last statement shown in bold attempts to access an array element that is outside the range supported by the array, generating an IndexOutOfRangeException runtime error, as shown in Figure 11.21.

Figure 11.21. An example of an IndexOutOfRangeException runtime error.

The occurrence of this runtime error brings application execution to an immediate halt. Using a try…catch…finally code block, as demonstrated in this next example, you can trap and prevent the error from terminating the application’s execution.

protected override void Update(GameTime gameTime)
{

// Allows the game to exit
if (GamePad.GetState(PlayerIndex.One).Buttons.Back
    == ButtonState.Pressed)
    this.Exit();

string[] nameArray = new string[4];
nameArray[0] = "Alexander";
nameArray[1] = "William";
nameArray[2] = "Molly";
nameArray[3] = "Mary";

try
{
     nameArray[9] = "Jerry";
}

    {

    }
    catch (Exception ex)
    {

    }
    finally
    {

    }

    base.Update(gameTime);
}

Here, the statement that generates the error has been placed inside the try block. A catch block is then added that executes if an IndexOutOfRangeException runtime errors occurs. Note that a variable named ex has been defined. This variable provides access to an Exception object that is automatically generated. The object’s properties contain information about the exception.

A second catch block has been added to handle any other type of exception. The finally block will execute every time the Update() method executes, even if you fix the code statement so that the exception no longer occurs.

Trick

You can view a complete list of exceptions by typing catch in the code editor followed by a variable name and the keyword as, as demonstrated in Figure 11.22. Note that all exception names include the word “Exception” at the end of their name.

Figure 11.22. There are many different types of runtime errors.

In this example, no statements have been placed inside the catch or finally blocks. As a result, no recovery actions are taken as would normally be the case. Instead, the application handles the runtime error by simply ignoring it. Although this example is admittedly simple, it does provide you with a template that you can use as the basis for creating more complicated exception handlers.