We have built the basic structure of the Robot Rampage game, loading the sprite sheet and title screen graphics, and creating a SpriteFont that we can use to display text later.

In order to create our viewport into the game world, we will define a Camera module that will represent the view the player currently has of the game world. At its most basic, a camera is really nothing more than a vector pointing to the camera's location. In order to provide some additional functionality, we will add several other properties and methods to the Camera module.

The first thing to notice about this code is that we have included compiler directives to define code regions. These directives (#Region and #End Region) instruct the Visual Studio development environment to treat these code areas as blocks that are collapsible as a related unit. You can click on the little minus sign on the left side of the screen at the beginning of a region to collapse it, hiding the code and leaving behind just the region title. We will include region declarations in all of the classes in Robot Rampage as an example of their usage.

Our Camera module only needs three pieces of information to operate. The first is its position within the game world. This vector points to the upper-left corner of the viewing area represented by the camera. That is, if you think of the game world as a huge grid of pixels, the pixel pointed to by the _position vector is the pixel that will be drawn in the upper-left corner of the display area, when the camera is used to draw a scene.

The _viewPortSize vector represents the number of pixels to the right and down from the camera position that are covered by the viewing area. While this size defaults to zero during our game's initialization, we will set the size to match the size of the game's client window in the LoadContent() method. Together, the _position and _viewPortSize vectors can be thought of as defining a rectangle that represents the portion of the game world that is currently visible on the screen.

The last piece of information the Camera needs is the size of the game world itself. Unlike our other two variables, we have not created a backing field separate from the property declaration we wish to use. Instead, we simply declare the WorldRectangle property without a Get or Set block. This indicates to Visual Basic that we want to use an auto-implemented property. In the background, the Visual Basic compiler will create a backing field for us, by prefixing an underscore to the name of the property (_WorldRectangle in this case). We could use this field in our module code, if we wished to do so, even though we have not explicitly declared it.

The auto-implemented property will act as if we had created a full property with a simple get and set pair that returns the underlying field directly, and allows outside code to directly set the value of the field. In fact, the single line we have above is equivalent to:

Private _WorldRectangle As Rectangle = New Rectangle(0, 0, 0, 0)
Public Property WorldRectangle As Rectangle
Get
Return _WorldRectangle
End Get
Set(ByVal value As Rectangle)
_WorldRectangle = value
End Set
End Property

So, why not declare the other two values as auto-implemented properties? After all, it saves quite a bit of code! In this case, we need to place limits on what can be stored in the _position field, and we will not be directly exposing the _viewPortSize variable to outside code.

The WorldRectangle property defines the space in which all the objects in the game world will exist, and it is measured in pixels. Again, this value defaults to a zero-by-zero pixel game world, but will is set to our desired world sized in the LoadContent() method of the Game1 class.

Because the _position vector actually represents the upper-left corner of a rectangle (the visible screen) instead of a single point, we want to make sure that position remains not only within the game world, but also does not get any closer to the right or bottom edges of the game world than the width and height of the viewing area. In other words, if the game world is 1000x1000 pixels, and the display screen is 800x600 pixels, then the largest values we ever want for the components of the position vector are 200 for the X position and 400 for the Y position. If the camera were allowed to get closer to the edge of the game world, we would not have anything to display to the right or bottom of the game world's edges.

To enforce this limitation, we use MathHelper.Clamp() in the set portion of the Position property. This ensures that a full display of the game world will always be visible on the screen.

While external code could directly set the position of the camera through the Position property, we will generally prefer to use the Move() method to relocate the camera relative to its current position. Even though the Move() method is a member of the Camera module and could access the _position member directly, it uses the Position property just as external code would, allowing us to maintain the limitations that Position imposes without having to rewrite them in the Move() method.

When a game object is going to be drawn, we can check its display rectangle against the ObjectIsVisible() method of the Camera, to determine if any pixels in the object would be visible on the screen based on the camera's current position. If ObjectIsVisible() returns false, there is no need to draw the object, as all of its pixels are off screen. We will build this check into the updated Sprite object we construct, so that each sprite will check its own visibility and skip drawing itself, if it does not appear anywhere on the display.

Lastly, we have a pair of methods named Transform(). Given either a pixel location (as a Vector2) or a rectangle, the Transform() methods subtract the camera's current position from them and returns the result. To visualize the transformation of world coordinates into screen coordinates, let's return to the world and camera diagram we saw previously, with the addition of an object in the game world:

Here, we can see that the Sprite object's world coordinates represent its absolute position within the context of the game world. On the right side of the previous diagram, we can see that if the Camera Position vector is subtracted from the World Coordinate Vector, the resulting vector has the same direction and length as the Screen Coordinates vector. When this vector is placed relative to the upper-left corner of the screen, the position of the object in screen coordinates is given.

By storing the location of all of our game objects in world-based coordinates, the Camera's Transform() methods will provide screen-coordinate locations for the SpriteBatch.Draw() method, to display them in the appropriate locations.

This world coordinate focus means that the Sprite class we built for Asteroid Belt Assault will not work directly in the world of Robot Rampage. While all of the concepts are still valid, we need to build in ways to account for the world's camera and a game world larger than the screen. It is possible for a sprite object to be completely on screen, partially on screen, or completely off-screen.

In addition, while the sprite's world location may remain constant, the game's camera may move, requiring the on-screen location of the sprite to be adjusted to compensate for the camera's new position.

The Sprite class is presented in one large block here, because most of the code should be familiar (if slightly reorganized) from the same class in Asteroid Belt Assault. A few updates have been made to the code, however, so let's go over those changes in detail.

To start with, we have made use of auto-implemented properties wherever we can, including the WorldLocation property, which has replaced the Location property from the previous version of the Sprite class. The renaming of this property really just serves as a reminder that the coordinates are world-aligned instead of screen-aligned.

Several new member variables and properties have been added to the class as well. Animate and AnimateWhenStopped are checked during the sprite's Update() method. If Animate is false, the sprite will not advance frame animations. If AnimateWhenStopped is set to false, the sprite will not advance its frame animations, if the Velocity vector is equal to Vector2.Zero. This simply means that when the sprite is moving, its animation will play (assuming Animate is true). When the sprite is not moving, its animation will not play.

If Expired is set to true, the sprite will not be updated or drawn. In addition, the BoxCollision() and CircleCollision() methods will always return false for expired sprites. If the Collidable member is set to false, both of the collision methods will also return false.

The WorldLocation property has a new counterpart called ScreenLocation. This property uses the Camera.Transform() method to return the screen-based location of the object and is used in the Draw() method, to determine where on the screen the sprite should be displayed.

Similarly, the Destination property (which, in Asteroid Belt Assault, returned the rectangle on the screen that the sprite was drawn to) has been split into WorldRectangle and ScreenRectangle, and the Center property has been split into WorldCenter and ScreenCenter.

As a helper to assist in calculating the center of the sprite object, the RelativeCenter property has been introduced, which returns a vector equal to half of the width and height of the sprite's frame rectangle. This vector points to the center of the sprite relative to its own upper-left corner.

We now have both of the components we need for a "larger than the screen" world for our game, so let's add a few lines of temporary code to our project to get a feel for how they work together. Throughout the project, we will be expanding on or adding new temporary code segments to see the objects we have implemented in action.

If you play with the previous temporary code for a few minutes, you will see that the W, A, S, and D keys move the first sprite (the green tank base) as expected: A moves left, D moves right, W moves up, and S moves down. There is no way to directly move the second sprite (the blue tank base), because the temporary Update() method does not define a set of controls for tempSprite2.

Using the arrow keys moves the camera instead of either of the sprites. In world coordinates, the second sprite is always stationary. It only moves on the screen, because the camera is panning around, altering the player's view of the game world. You will also notice that you cannot move the camera left or up from the starting position. This is because the camera is clamped to the world area, and starts out in the upper-left corner.

A tile map is composed of a grid of squares, each one containing a reference to the tile that we wish to display in that map square. The tile itself is simply a rectangular texture that contains the visual representation of a terrain or background type.

In Robot Rampage, we will only need a handful of tile textures. We will have a few variations of floor textures to represent the factory floor, and a handful of wall and machinery textures to represent barriers:

As before, we will use a single texture sheet that will contain all of the images used by our game. The first row of images on the SpriteSheet.png file represents floor tiles, while the second row represents wall-type images. When we generate a game map, we will select a random floor and wall combination for each level.

From an XNA standpoint, we will define each of the tiles available to our tile map as a rectangle. These rectangles will be stored in a numerically indexed list. This allows each of the tiles to be referenced by their index number.

Since we can refer to an individual tile by using its tile index number, our tile map can be represented as a two-dimensional array of integers, with each integer corresponding to the index of the tile associated with that map square.

We have four different floor textures and four different wall textures, so the values stored in the tile map array will range from zero to seven. Any value greater than three will be treated as a barrier, while tiles zero through three will not block movement or shots:

In the previous diagram, mapSquares is a two-dimensional array of integers. A zero value in the array corresponds to the empty floor tile, while a four corresponds to a wall tile image. When the map is drawn, each integer in the array is examined, and the image corresponding to the tile index is drawn to the screen to occupy that square's display area.

Most of the declarations for the TileMap class are constants that define the dimensions of the individual tiles, the size of the map, and the meanings of the tile index numbers.

In our case, each tile is 32x32 pixels, and the map will be 50 tiles wide and 50 tiles high, resulting in 2,500 individual map squares.

The _tiles list contains a set of rectangles that correspond to the locations of each individual tile on the texture image. When a rectangle is added to the tiles list, it will automatically receive an index number. The first tile added will be index zero, the second will be index one, and so on.

It is these index numbers that we will store in the _mapSquares array to indicate what type of terrain should be displayed for each square on the map. When the Initialize() method is executed, eight rectangles are added to the tiles list. Each of these rectangles corresponds to the position of one of the tiles on the game's sprite sheet.

In the declarations area, we determined that the first four tiles (numbers zero through three) would be floor tiles, while the second set of four tiles will be considered wall tiles by the game's code.

After adding the tiles to the list, the Initialize() method loops through each square in the _mapSquares array, and sets it to the first of the floor tile indexes. This way we start with a known, empty map.

We need to make a distinction between squares and tiles as we use them in our code. We will use square to refer to a location within the _mapSquares array, while we will use tile to refer to the index number stored in a particular square.

Our first set of methods for the TileMap module deal with squares, providing methods for locating squares based on pixel positions, and providing locations in both world and screen coordinates for squares on the map.

Our first two methods, GetSquareByPixelX() and GetSquareByPixelY(), allow us to convert world-based pixel coordinates to map square references. Given a pixel reference, they simply divide it by either the width of a single tile (for X coordinates), or the height of a tile (for Y coordinates), and return the resulting value. Several of our other methods will make use of these methods to convert pixel parameters into square references.

GetSquareAtPixel() in fact, does just that. Given a vector pointing to a pixel location, it returns a vector containing a reference to the square within the _mapSquares array that corresponds to that pixel location. Given that our map is 50x50 squares, the resulting vector will contain X and Y coordinates between 0 and 49.

When the time comes to build our enemy AI, the computer-controlled robotic tanks will need to be able to navigate their way between squares. In order to facilitate this, we need to be able to determine the center of any particular square in world coordinates. GetSquareCenter() calculates this vector for us, by multiplying the X and Y square coordinates by the tile width and height, and adding half of a tile width and height to the result.

The SquareWorldRectangle() methods answer the question What pixels on the world map does this square occupy? We will need to know this when the time comes to determine if something has collided with a wall on the map.

Finally, the SquareScreenRectangle() methods provide the same information, but in localized screen coordinates. This information will be used in the Draw() method when rendering each square's tile to the display.

The tile index that a square contains determines what eventually gets drawn out to the screen, when that square is visible in the game window. In addition to simply determining what tile is located in a particular square, we will include helper methods to quickly determine if a particular square contains a wall tile or not.

At the most basic level, we need to be able to determine the tile index associated with any particular square on the map. GetTileAtSquare() provides this information, and the corresponding SetTileAtSquare() allows the index of any square to be changed.

For convenience, the GetTileAtPixel() methods combine the GetTileAtSquare() along with the GetSquareByPixel() methods we have already established. They do not contain any additional processing themselves, but provide more convenient access to tile information rather than having to do the pixel to tile conversions in external code, every time we want to access tile information.

Finally, IsWallTile() and IsWallTileByPixel() examine the contents of the given square, and return true if the tile index is greater than or equal to the first defined wall tile index (WallTileStart). Again, we could do this check externally, but since we will often need to know if a tile is a wall, it is convenient to summarize all of the checking into a single set of methods.

The TileMap module in Robot Rampage will not contain an Update() method because, once created, the map does not change on a per-frame basis. Thus, all that remains to make the class functional is the ability to draw the map to the screen.

The Draw() method begins by establishing four integer variables that will be used to control the loop that will output the tiles to the screen. We normally would not split and create separate variables for these control values. It would be more common to include the calculation directly into the for loop itself. In this case, however, the expressions are long enough that they are split here to make them more readable.

The startX and startY values are simple to obtain—simply divide the X and Y position of the camera by the size of a tile, and you know what tile is in the upper-left corner of the screen. To get the rightmost and bottommost tiles that need to be drawn, we just need to add the width and height of the viewport to the camera position. This will give us the tile in the lower right corner, defining the entire range of tiles that need to be drawn to the screen.

Why not just draw the whole thing? With a map size of only 50x50 tiles, drawing the whole map would be unlikely to have a detrimental impact on the performance of our game, but it would also be unnecessary. The large majority of the draw calls would simply be wasted on squares that are outside the display area. XNA does not have any issue with drawing outside the display—your game will not crash—but if you were to make the game world larger, you would reach a point where drawing the whole map would start to negatively impact the frame rate of the game.

The actual drawing loop checks to make sure that the tile we are going to draw actually exists (it always should since we limit the movement of the camera, but it is rarely a bad idea to verify before attempting the draw) and uses the SpriteBatch.Draw() method to output the tile to the screen.

As it stands, our tile map is just a big empty mass of floor tiles. Since we have not yet generated any walls, there are no barriers to movement. We will introduce a very simple method to generate wall tiles at random locations on the map.

The GenerateRandomMap() method selects one floor and one wall tile to use for this map, resulting in a random combination each time a map is generated. It then loops through each of the tiles on the map and sets them initially to the floorTile value generated previously.

Next, the method checks to see if the tile is one of the outside edges of the map (x equal to either zero or the width of the map minus 1, or y equal to zero or the height of the map minus 1). If any of these conditions are true, the map square is automatically set to a wall tile. Similarly, the second row of tiles around the map (x or y equal to one or the width/height minus two) are skipped over for wall generation, ensuring that the map will always contain a single layer of wall tiles around the outside edge, and a clear layer of floor tiles inside that.

For all other squares, a random number is generated and compared to wallChancePerSquare. If the random value indicates that a wall should be placed at the square, the tile map is updated appropriately.

The Player module will handle both tracking and displaying the player's robo-tank, and dealing with user input. We will start by building the basics to display the two sprites that comprise the player's tank.

Two individual sprites make up the player's tank. The BaseSprite will be drawn to the screen first, with the TurretSprite drawn over it. When the Player module's Initialize() method is called, the animation for the BaseSprite is created normally, and the sprite's AnimateWhenStopped member is set to false. Since the animation associated with the BaseSprite shows the treads of the player's tank rolling, the animation should not play when the player is not moving. In order to prevent the player from having to squeeze tightly between walls, a margin of four pixels on each side of the base sprite is established that will reduce the size of the robo-tank, when we detect collisions with walls on the map.

The TurretSprite, on the other hand, will not animate at all. The multiple frames of the TurretSprite animation actually represent different turrets that we will swap for the default turret, when the player has upgraded their weapons (more on this in Chapter 7, Robot Rampage - Lots and Lost of Bullets). By setting the Animate member to false, the frame displayed by the TurretSprite will remain constant unless we use the Frame property to change it directly.

During the Update() method, after updating the turret sprite, we always set its location equal to the location of the base sprite. This is because we always want the turret sprite to be drawn at the same location as the base sprite. Instead of trying to synchronize their velocities to keep them in the same spot, we just force them to the same location on each frame.

We will be expanding on the Update() method when we add input handling, but the Draw() method will remain as simple as it is now—just passing the draw command along to the sprites composing the player.

The player's movement and weapons fire are controlled separately by using the two thumbsticks on a gamepad. While the gamepad is by far the most comfortable way to control Robot Rampage, we will also include support for the keyboard. After all, not everyone has an Xbox controller connected to their PC.

The whole purpose of the input handling methods is to determine the value of the two vectors declared in step one. The baseAngle vector determines the direction that the player is moving in (and therefore the orientation of the base sprite), while the turretAngle vector determines the direction the player's cannon will face.

The gamepad controls are far simpler than the keyboard controls because the gamepad's thumbsticks already return a complete vector. The only alteration we need to make is to reverse the sign on the Y component of the vector, since negative Y values correspond to the up direction on the screen, but to the down direction on the gamepad.

In the case of the keyboard, pressing the individual movement keys increments or decrements the appropriate component of the vector that will be returned, while pressing the firing keys on the numeric keypad sets the returned vector to a vector pointing in the direction of the firing key relative to the five key (in other words, pressing eight on the keypad fires upwards, while pressing three fires down and to the right).

In the handleInput() method, we initially set both the moveAngle (which determines the direction the player will move in) and the fireAngle (which determines the direction the turret will be facing) to Vector2.Zero, indicating that they are both empty. We need to keep these two vectors separate from their related vectors (baseAngle and turretAngle), because we do not want to modify the angle that either the tank or the turret is facing if the player is not moving the corresponding thumbstick. If we did allow them to reset back to Vector2.Zero in every frame, any time the player was not pressing one of the control sticks, the corresponding part (tank or turret) would snap back to face the right edge of the screen.

By calling the handle...() methods and adding the results to the moveAngle and fireAngle vectors, we now have the two vectors we need to animate the player's tank. We check to see if the local vectors have a value (in other words, are not equal to Vector2.Zero). If so, the vector is normalized and assigned to the corresponding class-level member variable (moveAngle to baseAngle, and fireAngle to turretAngle).

The sprites are then rotated to their appropriate angles, and the moveAngle is applied to the base tank sprite's velocity.

The Update() method calls our new handleInput() method, and then updates the base sprite. The position of the base sprite is then copied to the location of the turretSprite, keeping the two sprites in sync with each other.

As the game stands, you can drive your tank around the game screen easily. Too easily, in fact! You can run straight through the walls and off the screen!

We need to ensure that the player's tank cannot move outside of the game world and that the game's camera follows the player as they move near the screen's edges.

Things are looking a little better now. The player can no longer drive off the edge of the world, and when they reach the bottom or right-hand side, the camera will scroll with them. We can still drive through walls, but we are getting there!

When we apply movement to the player, we call clampToWorld(), which separates the player's location into X and Y components. The MathHelper.Clamp() method is then used to ensure that the components stay within the world's coordinate system. The width and height of the sprite is subtracted from the width and height of the game world, so that the furthest the player's sprite can get to the right-side and bottom of the world is a full sprite's size away. This will keep the sprite fully within the game world at all times.

When the player approaches an edge of the screen, the camera needs to be adjusted to move in the same direction that the player is moving, assuming that the end of the game world has not yet been reached. By defining the scrollArea rectangle, we are specifying that we would like to keep the player in a 500x400 pixel area beginning at (150, 100). This corresponds to the center of our 800x600 screen, with a 150 pixel buffer on the left and right edges, and a 100 pixel buffer along the top and bottom.

When repositionCamera() is called, it checks to see if the player has moved out of the defined scrolling area. Each side of the scroll area is checked individually, starting with the left edge. If the X coordinate of the ScreenRectangle is less than the X coordinate of the scrollArea and the player is moving left, the camera is moved left by an amount equal to the amount that the sprite itself will be moved by multiplying the appropriate component of moveAngle by the moveScale value.

The result is that the camera will move the same distance that the player moves. The player's sprite will appear to stay in place while the game world scrolls around it. Since the Camera module limits its own position to ensure that a full view of the world is always displayed, the camera will simply stop moving when the player is close enough to the edge that it can no longer scroll.

The last limitation we need to account for in player movement is the underlying tile-based map. We want the game to detect when the player is attempting to move into a wall and stop them from doing so.

In order to check for tile-based collisions, we break the process into two steps. First we will check for collisions due to horizontal movement, and then due to vertical movement.

To facilitate this, we begin by establishing two new vectors representing the new locations of the sprite, if only the horizontal or vertical movement was applied.

From these new vectors, we create two rectangles, representing the world location of the sprite's two possible movements. In other words, newHorizontalRect specifies where the player's sprite would be located after moving, if only the horizontal component of the movement is considered, while newVerticalRect represents the new location, if movement occurred only along the vertical axis:

Next, we need to determine a range of pixels to check for tile obstacles. We could simply check all of the pixels inside the two new rectangles, by calling TileMap.IsWallTile() for each pixel in both rectangles. This would return the results we are looking for, but it would cause unnecessary processing, as only the portions of the new rectangles that are not already covered by the current position's rectangle need to be checked for collisions.

Instead, we can use the direction in which we are moving to determine a smaller range of pixels that need to be checked. In the horizontal movement portion of the previous diagram, the new position rectangle mostly overlaps the old position rectangle. We only need to check the pixels between the right edge of the old position and the right edge of the new position, because the old position is already known to be an area the sprite can exist in.

If we are moving to the right, we use the right edges of the old and new positions to define the limits of the area we will check. Similarly, if we are moving left, we use the left edges of the two position rectangles to define the area.

We can then check each pixel in the new area against TileMap.IsWallTile() to determine if moving in this direction would cause the sprite to overlap a wall tile. If any of them do, we set the X component of the moveAngle vector to zero, eliminating the movement in that direction. As soon as any pixel tests true, we break out of the loop, since there is no need to continue testing.

After we have dealt with horizontal movement, the process is repeated for vertical movement, eliminating the Y component of the moveAngle vector if the new Y position would result in a wall collision.