Jump to content
  • Advertisement

  • Remove ads and support GameDev.net for only $3. Learn more: The New GDNet+: No Ads!

  • 02/01/12 05:49 PM
    Sign in to follow this  
    Followers 0

    Building a Complete Board-based Puzzle Game with Microsoft XNA 4.0

    Graphics and GPU Programming
    GameDev.net

    By Kurt Jaegers

    This article by Kurt Jaegers, author of XNA 4.0 Game Development by Example: Beginner's Guide, introduces a board-based puzzle game called Flood Control. We introduce the XNA Content Pipeline, and build a recursive function to determine the state of the game board while playing.

    This article focuses on the following concepts:

    • Using the Content Pipeline to load textures from disk
    • Creating classes to divide code into logical units
    • Recursively evaluating the status of the game board to check for scoring chains
    • Drawing textures using the SpriteBatch.Draw() method
    • Managing simple game states







      It was just another day at the bottom of the ocean until an explosion in one of the storage bays cracked the protective dome around Deep Sea Research Lab Alpha. Now the entire place is flooding, and the emergency pump system is a chaotic jumble of loose parts.

      0669_02_01.png



      Designing a puzzle game


      The Puzzler has always been a popular game genre. From old standbys like Tetris to modern crazes like Bejeweled, puzzle games are attractive to players because they do not require a long-term time investment or a steep learning curve.

      The game mechanic is the heart of any good puzzle game. This mechanic is usually very simple, with perhaps a few twists to keep the players on their toes.

      In Flood Control, the player will be faced with a board containing 80 pieces of pipe. Some will be straight pipes and some will be curved. The objective of the game is to rotate the pipes to form a continuous line to pump water from the left side of the board to the right side of the board.

      Completing a section of pipe drains water out of the base and scores points for the player, but destroys the pipes used. New pipes will fall into place for the player to begin another row.

      Time for action - set up the Flood Control project

      What just happened?


      You have now set up a workspace for building Flood Control, and created a couple of folders for organizing game content. You have also imported the sample graphics for the Flood Control game into the project.

      Introducing the Content Pipeline


      The Flood ControlContent (Content) project inside Solution Explorer is a special kind of project called a Content Project. Items in your game's content project are converted into .XNB resource files by Content Importers and Content Processors.

      If you right-click on one of the image files you just added to the Flood Control project and select Properties, you will see that for both the Importer and Processor, the Content Pipeline will use Texture - XNA Framework. This means that the Importer will take the file in its native format (.PNG in this case) and convert it to a format that the Processor recognizes as an image. The Processor then converts the image into an .XNB file which is a compressed binary format that XNA's content manager can read directly into a Texture2D object.

      There are Content Importer/Processor pairs for several different types of content--images, audio, video, fonts, 3D models, and shader language effects files. All of these content types get converted to .XNB files which can be used at runtime.

      0669_02_02.png



      In order to see how to use the Content Pipeline at runtime, let's go ahead and write the code to read these textures into memory when the game starts:

      Time for action - reading textures into memory


      1. Double-click on Game1.cs in Solution Explorer to open it or bring it to the front if it is already open.
      2. In the Class Declarations area of Game1 (right below SpriteBatch spriteBatch;), add:

        Texture2D playingPieces;
        Texture2D backgroundScreen;
        Texture2D titleScreen;

      3. Add code to load each of the Texture2D objects at the end of LoadContent():

        playingPieces = Content.Load(@"Textures\Tile_Sheet");
        backgroundScreen =
        Content.Load(@"Textures\Background");
        titleScreen = Content.Load(@"Textures\TitleScreen");


      What just happened?


      In order to load the textures from disk, you need an in-memory object to hold them. These are declared as instances of the Texture2D class.

      A default XNA project sets up the Content instance of the ContentManager class for you automatically. The Content object's Load() method is used to read .XNB files from disk and into the Texture2D instances declared earlier.

      One thing to note here is that the Load() method requires a type identifier, specified in angled brackets (), before the parameter list. Known in C# as a "Generic", many classes and methods support this kind of type specification to allow code to operate on a variety of data types. We will make more extensive use of Generics later when we need to store lists of objects in memory. The Load() method is used not only for textures, but also for all other kinds of content (sounds, 3D models, fonts, etc.) as well. It is important to let the Load() method know what kind of data you are reading so that it knows what kind of object to return.

      Sprites and sprite sheets


      As far as XNA and the SpriteBatch class are concerned, a sprite is a 2D bitmapped image that can be drawn either with or without transparency information to the screen.

      [indent=1]Sprites vs. Textures
      XNA defines a "sprite" as a 2D bitmap that is drawn directly to the screen. While these bitmaps are stored in Texture2D objects, the term "texture" is used when a 2D image is mapped onto a 3D object, providing a visual representation of the surface of the object. In practice, all XNA graphics are actually performed in 3D, with 2D sprites being rendered via special configurations of the XNA rendering engine.


    The simple form of the SpriteBatch.Draw() call when drawing squares only needs three parameters: a Texture2D to draw, a Rectangle indicating where to draw it, and a Color to specify the tint to overlay onto the sprite.

    Other overloads of the Draw() method, however, also allow you to specify a Rectangle representing the source area within the Texture2D to copy from. If no source Rectangle is specified, the entire Texture2D is copied and resized to fit the destination Rectangle.

    [indent=1]Overloads
    When multiple versions of the same method are declared with either different parameters lists or different return values, each different declaration is called an "overload" of the method. Overloads allow methods to work with different types of data (for example, when setting a position you could accept two separate X and Y coordinates or a Vector2 value), or leave out parameters that can then be assigned default values.


    By specifying a source Rectangle, however, individual pieces can be pulled from a large image. A bitmap with multiple sprites on it that will be drawn this way is called a "sprite sheet".

    The Tile_Sheet.png file for the Flood Control project is a sprite sheet containing 13 different sprites that will be used to represent the pieces of pipe used in the game. Each image is 40 pixels wide and 40 pixels high, with a one pixel border between each sprite and also around the entire image. When we call SpriteBatch.Draw() we can limit what gets drawn from our texture to one of these 40 by 40 squares, allowing a single texture to hold all of the playing piece images that we need for the game:

    0669_02_03.png



    The Tile_Sheet.png file was created with alpha-based transparency. When it is drawn to the screen, the alpha level of each pixel will be used to merge that pixel with any color that already occupies that location on the screen.

    Using this fact, you can create sprites that don't look like they are rectangular. Internally, you will still be drawing rectangles, but visually the image can be of any shape.

    What we really need now to be able to work with the playing pieces is a way to reference an individual piece, knowing not only what to draw to the screen, but what ends of the pipe connect to adjacent squares on the game board.

    [indent=1]Alpha blending
    Each pixel in a sprite can be fully opaque, fully transparent, or partially transparent. Fully opaque pixels are drawn directly, while fully transparent pixels are not drawn at all, leaving whatever has already been drawn to that pixel on the screen unchanged. In 32-bit color mode, each channel of a color (Red, Green, Blue, and Alpha) are represented by 8 bits, meaning that there are 256 different degrees of transparency between fully opaque (255) and fully transparent (0). Partially transparent pixels are combined with the current pixel color at that location to create a mixed color as if the pixels below were being seen through the new color.


Classes used in Flood Control


While it would certainly be possible to simply pile all of the game code into the Game1 class, the result would be difficult to read and manage later on. Instead, we need to consider how to logically divide the game into classes that can manage themselves and help to organize our code.

A good rule of thumb is that a class should represent a single thing or type of thing. If you can say "This object is made up of these other objects" or "This object contains these objects", consider creating classes to represent those relationships.

The Flood Control game contains a game board made up of 80 pipes. We can abstract these pipes as a class called GamePiece, and provide it with the code it needs to handle rotation and provide the code that will display the piece with a Rectangle that can be used to pull the sprite off the sprite sheet.

The game board itself can be represented by a GameBoard class, which will handle managing individual GamePiece objects and be responsible for determining which pieces should be filled with water and which ones should be empty.

The GamePiece class


The GamePiece class represents an individual pipe on the game board. One GamePiece has no knowledge of any other game pieces (that is the responsibility of the GameBoard class), but it will need to be able to provide information about the pipe to objects that use the GamePiece class. Our class has the following requirements:

  • Identify the sides of each piece that contain pipe connectors
  • Differentiate between game pieces that are filled with water and that are empty
  • Allow game pieces to be updated
  • Automatically handle rotation by changing the piece type to the appropriate new piece type
  • Given one side of a piece, provide the other sides of the piece in order to facilitate determining where water can flow through the game board
  • Provide a Rectangle that will be used when the piece is drawn, to locate the graphic for the piece on the sprite sheet

    Identifying a GamePiece


    While the sprite sheet contains thirteen different images, only twelve of them are actual game pieces (the last one is an empty square). Of the twelve remaining pieces, only six of them are unique pieces. The other six are the water-filled versions of the first six images.

    Each of the game pieces can be identified by which sides of the square contain a connecting pipe. This results in two straight pieces and four pieces with 90 degree bends in them.

    A second value can be tracked to determine if the piece is filled with water or not instead of treating filled pieces as separate types of pieces.

    Time for action - build a GamePiece class - declarations


    1. Switch back to your Visual C# window if you have your image editor open.
    2. Right-click on Flood Control in Solution Explorer and select Add | Class...
    3. Name the class GamePiece.cs and click on Add.
    4. At the top of the GamePiece.cs file, add the following to the using directives already in the class:

      using Microsoft.Xna.Framework.Graphics;
      using Microsoft.Xna.Framework;

    5. In the class declarations section, add the following:

      public static string[] PieceTypes =
      {
      "Left,Right",
      "Top,Bottom",
      "Left,Top",
      "Top,Right",
      "Right,Bottom",
      "Bottom,Left",
      "Empty"
      };

      public const int PieceHeight = 40;
      public const int PieceWidth = 40;

      public const int MaxPlayablePieceIndex = 5;
      public const int EmptyPieceIndex = 6;

      private const int textureOffsetX = 1;
      private const int textureOffsetY = 1;
      private const int texturePaddingX = 1;
      private const int texturePaddingY = 1;

      private string pieceType = "";
      private string pieceSuffix = "";

    6. Add two properties to retrieve information about the piece:

      public string PieceType
      {
      get { return pieceType; }
      }

      public string Suffix
      {
      get { return pieceSuffix; }
      }


    What just happened?


    You have created a new code file called GamePiece.cs and included the using statements necessary to access the pieces of the XNA Framework that the class will use.

    [indent=1]Using Directives
    Adding the XNA Framework using directives at the top of the class file allows you to access classes like Rectangle and Vector2 without specifying their full assembly names. Without these statements, you would need Microsoft.Xna.Framework.Rectangle in your code every time you reference the type, instead of simply typing Rectangle.


In the declarations area, you have added an array called PieceTypes that gives a name to each of the different types of game pieces that will be added to the game board. There are two straight pieces, four angled pieces, and an empty tile with a background image on it, but no pipe. The array is declared as static because all instances of the GamePiece class will share the same array. A static member can be updated at execution time, but all members of the class will see the same changes.

Then, you have declared two integer constants that specify the height and width of an individual playing piece in pixels, along with two variables that specify the array index of the last piece that can be placed on the board (MaxPlayablePieceIndex) and of the fake "Empty" piece.

Next are four integers that describe the layout of the texture file you are using. There is a one pixel offset from the left and top edge of the texture (the one pixel border) and a single pixel of padding between each sprite on the sprite sheet.

[indent=1]Constants vs. Numeric literals
Why create constants for things like PieceWidth and PieceHeight and have to type them out when you could simply use the number 40 in their place? If you need to go back and resize your pieces later, you only need to change the size in one place instead of hoping that you find each place in the code where you entered 40 and change them all to something else. Even if you do not change the number in the game you are working on, you may reuse the code for something else later and having easily changeable parameters will make the job much easier.


There are only two pieces of information that each instance of GamePiece will track about itself--the type of the piece and any suffix associated with the piece. The instance members pieceType and pieceSuffix store these values. We will use the suffix to determine if the pipe that the piece represents is empty or filled with water.

However, these members are declared as private in order to prevent code outside the class from directly altering the values. To allow them to be read but not written to, we create a pair of properties (pieceType and pieceSuffix) that contain get blocks but no set blocks. This makes these values accessible in a read-only mode to code outside the GamePiece class.





Creating a GamePiece


The only information we need to create an instance of GamePiece is the piece type and, potentially, the suffix.

Time for action - building a GamePiece class: constructors


  1. Add two constructors to your GamePiece.cs file after the declarations:

    public GamePiece(string type, string suffix)
    {
    pieceType=type;
    pieceSuffix=suffix;
    }

    public GamePiece(string type)
    {
    pieceType=type;
    pieceSuffix="";
    }


What just happened?


A constructor is run when an instance of the GamePiece class is created. By specifying two constructors, we will allow future code to create a GamePiece by specifying a piece type with or without a suffix. If no suffix is specified, an empty suffix is assumed.

Updating a GamePiece


When a GamePiece is updated, you can change the piece type, the suffix, or both.

Time for action - GamePiece class methods - part 1 - updating


  1. Add the following methods to the GamePiece class:

    public void SetPiece(string type, string suffix)
    {
    pieceType = type;
    pieceSuffix = suffix;
    }

    public void SetPiece(string type)
    {
    SetPiece(type,"");
    }

    public void AddSuffix(string suffix)
    {
    if (!pieceSuffix.Contains(suffix))
    pieceSuffix += suffix;
    }

    public void RemoveSuffix(string suffix)
    {
    pieceSuffix = pieceSuffix.Replace(suffix, "");
    }


The first two methods are overloads with the same name, but different parameter lists. In a manner similar to the GamePiece constructors, code that wishes to update a GamePiece can pass it a piece type, and optionally a suffix.

Additional methods have been added to modify suffixes without changing the pieceType associated with the piece. The AddSuffix() method first checks to see if the piece already contains the suffix. If it does, nothing happens. If it does not, the suffix value passed to the method is added to the pieceSuffix member variable.

The RemoveSuffix() method uses the Replace() method of the string class to remove the passed suffix from the pieceSuffix variable.

Rotating pieces


The heart of the Flood Control play mechanic is the ability of the player to rotate pieces on the game board to form continuous pipes. In order to accomplish this, we can build a table that, given an existing piece type and a rotation direction, supplies the name of the piece type after rotation. We can then implement this code as a switch statement:

0669_02_04.png



Time for action - GamePiece class methods - part 2 - rotation


  1. Add the RotatePiece() method to the GamePiece class:

    public void RotatePiece(bool Clockwise)
    {
    switch (pieceType)
    {
    case "Left,Right":
    pieceType = "Top,Bottom";
    break;
    case "Top,Bottom":
    pieceType = "Left,Right";
    break;
    case "Left,Top":
    if (Clockwise)
    pieceType = "Top,Right";
    else
    pieceType = "Bottom,Left";
    break;
    case "Top,Right":
    if (Clockwise)
    pieceType = "Right,Bottom";
    else
    pieceType = "Left,Top";
    break;
    case "Right,Bottom":
    if (Clockwise)
    pieceType = "Bottom,Left";
    else
    pieceType = "Top,Right";
    break;
    case "Bottom,Left":
    if (Clockwise)
    pieceType = "Left,Top";
    else
    pieceType = "Right,Bottom";
    break;
    case "Empty":
    break;
    }
    }


What just happened?


The only information the RotatePiece() method needs is a rotation direction. For straight pieces, rotation direction doesn't matter (a left/right piece will always become a top/bottom piece and vice versa).

For angled pieces, the piece type is updated based on the rotation direction and the diagram above.

[indent=1]Why all the strings?
It would certainly be reasonable to create constants that represent the various piece positions instead of fully spelling out things like Bottom,Left as strings. However, because the Flood Control game is not taxing on the system, the additional processing time required for string manipulation will not impact the game negatively and helps clarify how the logic works.


Pipe connectors


Our GamePiece class will need to be able to provide information about the connectors it contains (Top, Bottom, Left, and Right) to the rest of the game. Since we have represented the piece types as simple strings, a string comparison will determine what connectors the piece contains.

Time for action - GamePiece class methods - part 3 -connection methods


  1. Add the GetOtherEnds() method to the GamePiece class:

    public string[] GetOtherEnds(string startingEnd)
    {
    List opposites = new List();

    foreach (string end in pieceType.Split(','))
    {
    if (end != startingEnd)
    opposites.Add(end);
    }
    return opposites.ToArray();
    }

  2. Add the HasConnector() method to the GamePiece class:

    public bool HasConnector(string direction)
    {
    return pieceType.Contains(direction);
    }


The GetOtherEnds() method creates an empty List object for holding the ends we want to return to the calling code. It then uses the Split() method of the string class to get each end listed in the pieceType. For example, the Top,Bottom piece will return an array with two elements. The first element will contain Top and the second will contain Bottom. The comma delimiter will not be returned with either string.

If the end in question is not the same as the startingEnd parameter that was passed to the method, it is added to the list. After all of the items in the string have been examined, the list is converted to an array and returned to the calling code.

In the previous example, requesting GetOtherEnds("Top") from a GamePiece with a pieceType value of Top,Bottom will return a string array with a single element containing Bottom.

We will need this information in a few moments when we have to figure out which pipes are filled with water and which are empty.

The second function, HasConnector() simply returns "true" if the pieceType string contains the string value passed in as the direction parameter. This will allow code outside the GamePiece class to determine if the piece has a connector facing in any particular direction.

Sprite sheet coordinates


Because we set up the PieceTypes array listing the pieces in the same order that they exist on the sprite sheet texture, we can calculate the position of the rectangle to draw from based on the pieceType.

Time for action - GamePiece class methods - part 4 - GetSourceRect


  1. Add the GetSourceRect() method to the GamePiece class:

    public Rectangle GetSourceRect()
    {
    int x = textureOffsetX;
    int y = textureOffsetY;

    if (pieceSuffix.Contains("W"))
    x += PieceWidth + texturePaddingX;

    y += (Array.IndexOf(PieceTypes, pieceType) *
    (PieceHeight + texturePaddingY));


    return new Rectangle(x, y, PieceWidth, PieceHeight);
    }


What just happened?


Initially, the x and y variables are set to the textureOffsets that are listed in the GamePiece class declaration. This means they will both start with a value of one.

Because the sprite sheet is organized with a single type of pipe on each row, the x coordinate of the Rectangle is the easiest to determine. If the pieceSuffix variable does not contain a W (signifying that the piece is filled with water), the x coordinate will simply remain 1.

If the pieceSuffix does contain the letter W (indicating the pipe is filled), the width of a piece (40 pixels), along with the padding between the pieces (1 pixel), are added to the x coordinate of the source Rectangle. This shifts the x coordinate from 1 to a value of 1 + 40 + 1, or 42 which corresponds to the second column of images on the sprite sheet.

To determine the y coordinate for the source rectangle, Array.IndexOf(PieceTypes, pieceType) is used to locate the pieceType within the PieceTypes array. The index that is returned represents the position of the tile on the sprite sheet (because the array is organized in the same order as the pieces on the image). For example, Left,Right returns zero, while Top,Bottom returns one and Empty returns six.

The value of this index is multiplied by the height of a game piece plus the padding between pieces. For our sprite sheet, an index of 2 (the Left,Top piece) would be multiplied by 41 (PieceHeight of 40 plus texturePaddingY of 1) resulting in a value of 82 being added to the y variable.

Finally, the new Rectangle is returned, comprised of the calculated x and y coordinates and the predefined width and height of a piece:

0669_02_05.png



The GameBoard class


Now that we have a way to represent pieces in memory, the next logical step is to create a way to represent an entire board of playing pieces.

The game board is a two-dimensional array of GamePiece objects, and we can build in some additional functionality to allow our code to interact with pieces on the game board by their X and Y coordinates.

The GameBoard class needs to:
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

  I accept

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!