3D game Programming

What you're probably thinking now is "What files?" Aside from the fact that numerous levels are included on the accompanying CD, I haven't yet mentioned how these files would be constructed. In Appendix A, "Developing a Level Creator," you will see an application that will act as the level creator for this game. Obviously, level creation is an important aspect of creating a top-notch game, but it isn't central to the 3D game development aspect this book covers, so it resides in the appendix. You might also notice that you never actually check whether the file exists. Add this public method to your class so the game engine can detect whether a given level exists before it tries to load it:

public static bool DoesLevelExist(int level)
{
return File.Exists(GameEngine.MediaPath +
string.Format("Level{0}.lvl", level));
}

The file format itself is a relatively simple binary file. The first four bytes of the file are the maximum time (in seconds) you have to complete the level. It is stored in a float variable, and the constructor creates a new byte array of the size of a float variable. This is the code that required the use of the unsafe keyword. After that byte array is filled, the BitConverter class is used to take that array and convert it back to the float value it is intended to be.
Although multiple parameters are read from the file, each is read in the same way described in the last paragraph. Next, the maximum number of moves to complete the level is read in as an integer, followed by how many colors are used for the level. It should always be at least two and a maximum of four. Recall that the BlockColor enumeration from the last chapter was derived from the byte data type, so after creating an array of the appropriate number of colors, you can read in each color individually, a single byte at a time. You do the same with the final color, which is the next piece of data read in.
Next you need to determine whether the colors will wrap or not and read that in as a Boolean value. The block array size is always the same size, and the next 169 bytes of the file tell you everything you need to know about the blocks themselves. Each byte is either the index into the color array you just created or 0xff, signifying that there is no block at this location. First, create your array of blocks of the appropriate size, and then for each block you find that is a real block, create a new Block class, passing in the array of colors, the color index of the current block, and whether the block colors should rotate. You then assign it a position based on a simple formula using the starting location, the spacing constant, and the row or column index.
After each of the blocks is created, you need to store the index of the block the player is currently sitting on. Because the player is actually on a block now, you want to update the block's color to the next available color. The UpdatePlayerAndBlock method moves the player to the correct position as well as updates the block's state. You find the implementation of this method in Listing 8.3.
Listing 8.3. Updating Player and Blocks

private bool UpdatePlayerAndBlock(bool force, int newPlayerIndex)
{
// Get the block the current player is over
Block b = blocks[newPlayerIndex] as Block;

if (force)
{
// Move the player to that position
currentPlayer.Position = new Vector3(b.Position.X, 0, b.Position.Z);
}
else
{
// Move the player to that position
if (!currentPlayer.MoveTo(new Vector3(b.Position.X, 0, b.Position.Z)))
{
// The player can't move here yet, he's still moving,
// just exit this method
return false;
}
}

// Update the color of this block
b.SelectNextColor();
return true;
}

This code assumes that the player index is only on a currently valid block. Later, outside of the call to this method in the constructor, you will be checking for valid moves anyway, so the only time it's possible for this index to be invalid is in the constructor. Considering it comes from the file that describes the level (and the level creator does not allow the starting position to be an invalid block), this shouldn't be a problem. The force parameter is only used during the constructor, and it signifies that you want to move the player instantly to the position if true. Otherwise, the MoveTo method on the player is called, and if it is not successful, it returns that "failure" to the caller of this method. At the end of the method, the selected block is moved to the next available color. If the move was invalid, the method will have already returned and will never get to this code. The constructor ignores the return value because there is no way for the method to return any value other than TRue if the force parameter is true.