XNA 4 3D Game Development by Example: Beginner's Guide: Create action-packed 3D games with the Microsoft XNA Framework with this book and ebook.

You have now successfully installed the Windows Phone SDK, which includes Visual Studio 2010 Express, the XNA Extensions for Visual Studio, and the Redistributable Font Pack provided by Microsoft for XNA developers.

We now have the skeleton of a project upon which we can build the Speller game. Each of the major XNA methods is declared, usually with no additional code except the execution of the method's base. We will examine each area of the XNA game template as we create the pieces necessary for Speller.

We have now added both an image and a font to our content project. We will see how we load these assets into the game at runtime and how we can use them during gameplay.

The SpriteFont file that we created in step 6 and the XML document mentioned in step 7 actually load an XML template that describes how the content pipeline should create the resulting .xnb file. In this case, the default values for the SpriteFont template are sufficient for our game. This resulted in the Segoe UI Mono font (added to your system when the Windows Phone SDK is installed), with a value of 14 points being used. As we will only be using the standard A to Z character set, we do not need to make any changes to this template for Speller.

We have declared all of the member variables we will need for the Speller game. The letterFont member will hold the sprite font object that we added to the content project earlier, and work in conjunction with the predefined spriteBatch object to draw text on the screen.

The square image that will represent the player will be stored in the Texture2D member called playerSquare. We can use the Texture2D objects to hold graphics that we wish to draw to the screen using the SpriteBatch class.

The playerPosition Vector2 value will be used to hold the positions of the player, while moveDirection stores a vector pointing in the direction that the player is currently moving. Each time the player picks up a correct letter, playerScore will be incremented. Hitting an incorrect letter will cost the player one point.

An instance of the Random class, rand, will be used to select which word to use in each round and to place letters on the screen in random locations.

In order to keep track of which word the player is currently working on, we store that word in the currentWord variable, and track the number of letters that have been spelled in that word in currentLetterIndex.

The letters that are being displayed on the screen need several pieces of information to keep track of them. First, we need to know which letter is being displayed; next, we need to know the position the letter should occupy on the screen. Finally we need some way for our code to recognize that after we have hit an incorrect letter, we lose some of our score for it, but that we may spend several game update frames in contact with that letter and should not lose some of our score more than once for the infraction.

All three pieces of information are wrapped into a child class of the Game1 class called GameLetter. If we were not intentionally keeping everything in Speller in the Game1 class, we would most likely create a separate code file for the GameLetter class for organizational purposes. Since Speller will be very straightforward, we will leave it inside Game1 for now.

As the GameLetter class defines a letter, we need a way to store all of the letters currently on the screen, so we have declared letters as a .NET List collection object. A List is similar to an array in that it can store a number of values of the same type, but it has the advantage that we can add and remove items from it dynamically via the Add() and RemoveAt() methods.

Finally, we declare the playerSpeed variable, which will indicate how fast the player's cube moves around the screen in response to the player's input. This value is stored in pixels per second, so in our case, one second of movement will move the character 200 pixels across the screen.

The only initialization we need to do is set the player's score to zero. Even this initialization is not strictly necessary, as zero is the default value for an int variable, but it is a good practice not to assume that this work will have been done for us.

The default Content object can be used to load any type of asset from our content project into an appropriate instance in memory. The type identifier in angle brackets after the Load() method name identifies the type of content we will be loading, while the parameter passed to the Load() method specifies the asset name of the content.

Asset names can be set via the Properties window in Visual Studio, but would default to the name of the content file, path included, without an extension. Since all of the content objects will be translated into .xnb files by the content pipeline, there is no need to specify the format that the file was in before it was processed.

In our case, both of our content items are in the root of the content project's file structure. It is possible (and recommended) to create subdirectories to organize your content assets, in which case you would need to specify the relative path as part of the asset name. For example, if the Segoe14 sprite font was located in a folder off the root of the content project called Fonts, the default asset name would be Fonts\Segoe14.

The last thing our LoadContent() method does is call the (as yet undefined) checkForNewWord() method. We will construct this method towards the end of this chapter in order to generate a new word both at the beginning of the game and when the player has completed spelling the current word.

During each frame, we will begin by assuming that the player is not pressing any movement keys. We create a Vector2 value called moveDir and set it to the predefined value of Vector2.Zero, meaning that both the x and y components of the vector will be zero.

In order to read the keyboard's input to determine if the player is pressing a key, we use the Keyboard.GetState() method to capture a snapshot of the current state of all the keys on the keyboard. We store this in the keyState variable, which we then use in a series of if statements to determine if the up, down, left, or right arrow keys are pressed. If any of them are pressed, we modify the value of moveDir by adding the appropriate vector component to its current value.

After all the four keys have been checked, we will check to see if the value is still Vector2.Zero. If it is, we will skip updating the moveDirection variable. If there is a non-zero value in moveDir, however, we will use the Normalize() method of the Vector2 class to divide the vector by its length, resulting in a vector pointing in the same direction with a length of one unit. We store this updated direction in the moveDirection variable, which is maintained between frames.

When we have accounted for all of the possible inputs, we update the player's position by multiplying the moveDirection by playerSpeed and the amount of time that has elapsed since Update() was last called. The result of this multiplication is added to the playerPosition vector, resulting in the new position for the player.

Before we can assume that the new position is ok, we need to make sure that the player stays on the screen. We do this by using MathHelper.Clamp() on both the X and Y components of the playerPosition vector. Clamp() allows us to specify a desired value and a range. If the value is outside the range, it will be changed to the upper or lower limit of the range, depending on which side of the range it is on. By limiting the range between zero and the size of the screen (minus the size of the player), we can ensure that the player's sprite never leaves the screen.

Finally, we call two functions that we have not yet implemented: CheckCollisions() and CheckForNewWord(). We discussed CheckForNewWord() in the LoadContent() section, but CheckCollisions() is new. We will use this method to determine when the player collides with a letter and how to respond to that collision (increase or decrease the player's score, advance the spelling of the current word, and so on).

When using the SpriteBatch class, any calls to draw graphics or text must be wrapped in calls to Begin() and End(). SpriteBatch.Begin() prepares the rendering system for drawing 2D graphics and sets up a specialized render state. This is necessary because all 2D graphics in XNA are actually drawn in 3D, with the projection and orientation configurations in the render state to display the 2D images properly.

In our case, the only graphical image we are drawing is the square that represents the player. We draw this with a simple call to SpriteBatch.Draw(), which requires the texture we will use, the location where the texture will be drawn on the screen (relative to the upper-left corner of the display area), and a tint color. Because our square image is white, we could set any color we wish here and the player's square would take on that color when displayed. We will use that to our advantage in just a moment when we draw the text of the word the player is trying to spell.

After the player has been drawn, we loop through each of the letters in the letters list and use the SpriteBatch.DrawString() method to draw the letter at its position, using the letterFont we created earlier. Normally, we will draw the letters in white, but if the player runs into this letter (and it is not the letter they are supposed to hit) we will draw it in red.

Next, we need to display the word that the player is attempting to spell. We display the text Spell: near the bottom center of the display, using the bounds of the current window to determine the location to draw.

In order to colorize the word properly, we need to split the word into different parts as what the player has already spelled, the current letter they are targeting, and the letters after the current letter. We do this using the Substring() method of the string class, and then draw these three components with different color tints. We utilize the MeasureString() method of letterFont to determine how much space each of these components occupies on the screen so that we can position the subsequent strings properly.

Finally, we display the player's score at the upper-left corner of the screen.

In step 1, we generate a random number using the Next() method of the Random class. Given an integer value, Next() will return an integer between zero and that number minus one, meaning we will have a return value from zero to fourteen. Using a select statement, we return the randomly determined word. Note that we should never hit the last return statement in the function, so if we are ever asked to spell the word BUG, we know something is wrong.

The FillLetters() method is used to populate the letters list with letters and their locations on the screen. We could simply generate random locations for each letter, but then this would leave us with the potential for letters overlapping each other, requiring a check as each letter is generated to ensure this does not happen.

Instead, we will generate a list of potential letter positions by building the locations list. This list will contain each of the possible places on the screen where we will put a letter by spacing through a grid and adding entries every 25 pixels in the x and y directions. The exception is that we define an area in the center of the screen where the player will start and we will not place letters. This allows the player to start each round without being in contact with any of the game letters.

Once we have our list of locations, we clear the letters list and generate 20 letters. We start with the letters required to spell the target word, pulling letters from the currentWord string until we reach the end. After that, the letters will come from the alphabet string randomly. Each letter is assigned one of the locations from the locations list, and that location is then removed from the list so we will not have two letters on top of each other.

Lastly, the CheckForNewWord() method checks to see if currentLetterIndex is larger than the length of currentWord. If it is, the player's position is reset to the center of the screen and a new word is generated using PickAWord(). currentLetterIndex is reset, and the letters list is rebuilt using the FillLetters() method.

CheckCollisions() loops backward through the letters list, looking for letters that the player has collided with. Going backwards is necessary because we will (potentially) be removing items from the list, which cannot be done in a foreach loop. If we were moving forward through the list, we would disrupt our loop by deleting the current item, which would cause it to skip over the next items in the list. Moving backwards through the list allows us to remove items without adjusting our loop's logic.

In order to determine if we have collided with a letter, we build two rectangles. The first rectangle represents the position and size of the letter we are checking against, by using the letter's Position value and the size of the letter calculated with MeasureString(). The second rectangle represents the area occupied by the player's sprite.

The Intersects() method of the Rectangle class will return true if these two rectangles overlap at any point. If they do, we know we have hit a letter and need to take action.

If the letter impacted is the next letter in the word that the player is spelling, we increment the player's score and remove the letter from the list. We also advance currentLetterIndex so that when Update() next calls CheckForNewWord(), we will know if this word has been completed.

If the letter is not the player's current target, we check the letter's WasHit value. If it is false, we have not run into this letter, so we reduce the player's score and mark WasHit to true. If WasHit is already true, we simply do nothing so as not to deduct from the player's score multiple times while the player passes over an incorrect letter.

When the rectangles do not intersect, we know we are not currently in contact with this letter, so we set its WasHit variable to false. This has the effect that once we leave an incorrect letter, it becomes re-enabled for future collisions (and point deductions).

Speller is a pretty simple game, but could be enhanced to make a more full-fledged game, by including the following, depending on your level of experience with 2D XNA development: