We now have three projects in our solution—The Gemstone Hunter game project, the associated content project, and the Tile Engine game library project. The game project itself will be detailed in the next chapter. The Tile Engine project will contain the code for, not surprisingly, the game's tile engine, which will be shared with yet another project, the Level Editor, which we will create shortly.

In step 2, we added a new type of information to our code file called an attribute. Attributes indicate to the Visual Basic compiler that the item following it should be treated differently in some way compared to the norm for that item type.

In our case, we want to be able to save the tile map that we will be creating to a file and then load that file in both the editor and the game projects. To do this, we need to indicate to Visual Basic that the object is serializable—that is, the object can be converted into a byte-stream, which can be stored and reloaded at a later point.

The LayerTiles array stores three integer values representing the tile images on the background, interactive, and foreground layers. Depending on the needs of your game, you could create any number of layers. When we draw them, we will use the index of the layer to determine the depth at which the sprite is drawn, ensuring that they appear in the correct order on the screen.

While building our map, we can associate a string value with each individual map square by setting the CodeValue variable. This variable will allow us to create special features, such as map transitions, traps, and invisible barriers to enemy movement.

Finally, to determine if the map square blocks player movement, we can check the Passable member variable. If it is false, the player cannot move into this square. The default for all MapSquares is to be open to movement (Passable set to true).

Just as we did in Robot Rampage, we will use a Camera module to represent the player's view of our game world and track all object positions in world-based coordinates.

Our Camera module is very similar to the module from Robot Rampage, with only minor changes which are detailed next.

The Transform() methods from the Robot Rampage Camera have been renamed to WorldToScreen(), and a new pair of methods called ScreenToWorld() have been added. We will need to respond to mouse events in the map editor, and the mouse position is reported in screen coordinates. These new methods will assist in determining the map square underneath the mouse cursor.

We saw in Robot Rampage that converting world coordinates to screen coordinates was a simple matter of subtracting the position of the camera from the coordinate. The reverse is also true. To convert from a screen coordinate to a world map coordinate, we add the position of the camera.

The basic concepts behind our original tile-based map engine are unchanged, and indeed most of the code for our new tile engine can be brought over from Robot Rampage. We need to make modifications to the way the map itself is stored, and the way we access (for both reading and setting) map tiles to accommodate the MapSquare class, instead of a simple array of integers.

Before we continue with the implementation of the TileMap class, let's look at the difference we can see so far from the same class in Robot Rampage.

Right from the start, we have a directive that we have not used before: Imports. There are many, many namespaces (pre-defined pieces of code) supplied with the .Net Framework, and everything we have used up until this point has been accessible without using the Imports directive. All Imports does is tell the Visual Basic compiler that we will be using objects from the specified namespace and lets us avoid typing the entire namespace name whenever we want to use one of its components. The System.Runtime.Serialization.Formatters.Binary assembly provides a simple way for us to write our level files out to the disk (and read them back in again), by converting the array of MapSquare objects in memory into a format that can be written to a file.

You may notice that both the declaration and initialization regions are quite a bit shorter than they were in Robot Rampage. In Gemstone Hunter, we will define a tile sheet image that contains the tiles we will use in the game. Unlike our previous games, we will not simply store all of our game's graphics on the same sprite sheet, but break it up into multiple sheets. We have a texture dedicated to the tile images for our game, and each type of game object has a texture file of its own:

By defining a single sprite sheet to hold only tiles for the tile map, we can treat the sheet in a special manner and decide that the sheet will be evenly divided into as many tiles as will fit on the image. Our tile sheet image is 480x480 pixels, and with a 48x48 tile size, we have 10 rows of 10 tiles, for 100 total tiles available to our game. We could always increase the size of the image to add more tiles, though we would want to keep it to increments of 48 pixels in each direction, to make the math easier.

We will number the tiles starting with zero in the upper-left corner of the tile sheet and progressing across a row. When we reach the end of the row, we return to the left side of the image and start a new row. The TilesPerRow property and the TileSourceRectangle method replace the array of pre-defined tiles, by providing a way to locate the source rectangle for any tile we wish to draw on the tile sheet image.

Our map is still represented by an array, but around this time, it is a two-dimensional array of MapSquare objects, instead of simple integers. We have also rearranged our terminology to reflect the more complex nature of our tile map. What we referred to as squares in Robot Rampage, we now call cells. Any of our code that dealt with getting or setting information about map tiles in Robot Rampage will need to be updated to handle the entire MapSquare object in each cell, instead of a simple integer value.

The TileMap itself will include support for being used in editing mode, which can be toggled by setting the EditorMode member variable. While in editor mode, we will draw the contents of the CodeValue member of the MapSquare class on top of each square, so the TileMap class needs a SpriteFont for use with SpriteBatch.DrawString().

Our Initialize() method is greatly simplified by the removal of the tiles array, allowing us to establish all of the mapCells as MapSquares, with empty tiles on each layer. Our tile sheet contains a fully transparent tile in the upper-left corner (tile zero) and a blue sky tile in the third position (tile two), so by filling the map with squares containing tile two on the background layer, and tile zero on the other two layers, we end up with an empty map with a blue sky background. This will simply save time when creating a new map with the map editor, by letting us skip drawing the sky on each map.

Much of the code we need for dealing with the tile map is unchanged from our simpler tile engine, aside from the changes to accommodate our new cell and MapSquare terminology. We also use the MapSquare type when getting and setting the contents of map cells instead of integers.

The SetTileAtCell() method may seem out of place among the methods dealing with MapSquare objects. Its purpose is to provide a way to change the tile index of a single layer in a cell, without repackaging the cell's entire MapSquare object. By passing SetTileAtCell() a cell location, layer number, and tile index, we can change the content of a single layer—exactly what we will need to do when building the map editor.

Because the game engine will need easy access to the Passable and CodeValue members of a cell (without the need to deal with the tile layer values), we have created the shortcut methods CellIsPassable() and CellCodeValue(). When the time comes to move the player and enemy objects during game play, we will make extensive use of these methods to determine what map squares are accessible to game entities.

We are now ready to assemble the code necessary to draw the enhanced tile map to the screen. We need to account for all three layers of the map, ensuring that each will be drawn in the proper relationship to the others—the background layer appearing furthest away, the interactive layer drawn above it, and finally the foreground layer drawn nearest to the screen.

Once again, the Draw() method is very familiar. We still use the position of the camera to determine the range of cells that need to be drawn to the screen, but this time we nest a third loop inside the horizontal and vertical loops, which draws the tiles from each of the three layers.

This SpriteBatch.Draw() call is unlike any of the others we have made, because this time we are specifying a layer depth as the last parameter of the call. In the past, when we have used the advanced form of the Draw() method, we have always left this parameter at a value of 0.

If our tile engine is currently in editor mode, the DrawEditModeItems() method is called after each tile is drawn. This uses the white tile at tile index one to draw a semi-transparent red block over any square that is not passable by the player. Additionally, the method uses SpriteBatch.DrawString() to display the content of the CodeValue variable associated with each map cell, if it is not empty.

By referencing the Tile Engine project from the Gemstone Hunter project, we can utilize the code from the Tile Engine project, by including an Imports directive referencing the Tile_Engine namespace.

During the LoadContent() method, we initialize the TileMap and Camera classes, and add a single tile to the map, so that we will see it when we run the application.

Finally, we see the special form of the SpriteBatch.Begin() call that we need to make, to display the different tile layers sorted in the proper order. In addition to specifying the sort mode, we also need to specify the way transparent sprites are blended together. The default is BlendState.AlphaBlend, which is what we want to keep. Since there is no SpriteBatch.Begin() call that allows us to specify only the sort mode, we must supply the blend mode, even though it is normally the default.

Why go to all of this trouble creating multiple projects and referencing them instead of including the MapSquare, Camera, and TileMap code directly into the Gemstone Hunter project? Since we are going to need to display the tile engine in both the game and the level editor, splitting it out into its own project and referencing it allows us to create only one set of source files for the map components. If we were to include the code directly in the game, we would need to make another copy of those three items for our map editor project. Any time we need to update the entities, we would need to remember to update them in both places, increasing the chance of introducing errors and inconsistencies into our project.

Since we know that we want to create a Windows Forms application for our level editor, it is tempting to use the Windows Forms application template that is included with Visual Studio. However, it is much easier to add a Windows Forms object to an XNA game project than to work the other way around, and try to incorporate all of the components of an XNA project into the Windows Forms template.

Your solution now has five separate projects: the game project (simply called Gemstone Hunter), the game's Content project, the Tile Engine game library, the Level Editor, and the Level EditorContent project. Because we have created a content reference in the Level Editor project to the game's content project, all of the game's content will be available in the level editor as well. We will leave the Level Editor Content project empty, but if we needed content items available in the Level Editor that were not needed by the game, we could place them here.

By setting the Level Editor as the startup project, whenever we execute our code from the development environment, the Level Editor will be the application that starts (as opposed to starting the actual game). This setting is just a convenience for us while we work on the editor:

Just like our Gemstone Hunter project, the Level Editor project contains a reference to the Tile Engine project, allowing it to make use of the tile engine code without duplicating it.

We will begin the construction of the Level Editor by adding a Windows Form to our project and linking it to the XNA Game, to allow the output of the game to be displayed on a PictureBox control on the form.

As it turns out, we can add a form to an XNA Game project in the same way we would add a form to a standard Windows application. The form will not show up by default, however. The Program.vb file is the driver behind the XNA project, and the Main() method gets executed when the application starts.

For a normal XNA Game, the Main() method creates an instance of the Game1 class and calls its Run() method. In order to combine our game with a Windows Form, we have altered this startup process.

Instead of creating an instance of the Game1 class in the Program module (where Main() lives), we create an instance of our MapEditor form class, and then create an instance of Game1 inside the form.

This will simplify addressing components of the Game1 class from the MapEditor form, allowing us to change properties in the game object in response to user interaction with form controls.

We pass the window handle of the PictureBox to the Game1 constructor. The window handle uniquely identifies the display area of PictureBox, allowing our code to redirect XNA's drawing commands from the original game window to the area defined by the PictureBox.

In order to tell XNA that the graphics we draw should be displayed on the PictureBox, we add an event handler to the PreparingDeviceSettings event of the GraphicsDeviceManager class. In this event handler, we simply set the DeviceWindowHandle associated with the graphics device to drawSurface, the value that we passed in when the instance of the Game1 class was created inside Program.vb.

The last thing the constructor does is tell XNA's Mouse class that it should report coordinates relative to the PictureBox that the game will be drawn onto. If we do not make this setting, we will not be able to determine where on our game display the mouse cursor is located.

Alas! We still have a few problems. The most obvious is that there is a big, empty window that shows up on top of our level editor window. This is the window that would normally contain the XNA game. We have moved the output of the XNA drawing commands to a new drawing surface, but the old window still gets created.

The second problem will not be apparent right away, but will cause us trouble when we resize the map editor form while it is running. When the size of the PictureBox changes, we need to let XNA know that the back-buffer size has changed and let our Camera module know that the view port on the display has changed as well.

To address both of these problems, we will add additional event handlers to the system events that occur when the visibility of the game's empty window changes and when the picture box is resized.

At first, the gameForm_VisibleChanged() method may look odd. It may seem that it would prevent the game from ever being displayed, as it sets the gameForm.Visible property to false, if it ever ends up as true.

Remember, though, that the form (or window), which is automatically generated by XNA, will always be empty. Our game's display is now being redirected to the PictureBox on our MapEditor form. This means that we really do want to make sure that the game's form is never visible. Whenever its visibility changes, we ensure that Visible is set to false, to keep it from appearing.

When the size of the PictureBox changes—since it is anchored to the sides of the MapEditor form, resizing the form will resize the PictureBox—we want to update the game's GraphicsDeviceManager with the new size of our display area, and pass those updates along to the Camera module. We need to be careful to check the WindowState of the parent form when processing the resize event. Because the back-buffer width and height must be greater than zero, if we attempt to set them when the form has been minimized, the application will crash.

Clicking on the window close button or pressing Alt + F4 to end the application will no longer work, because the hidden window that Game1 would normally run in will not close automatically.

Right now, we just have the familiar blue XNA window being displayed on our form. We need to add a number of other controls to the form to build a functional level editor.

We now have a standard Windows menu attached to our form with a few entries for our level editor. In order to add code to menu items other than the Exit command, we need to make modifications to our Game1 class, so we will come back to them after we have laid out all of the items on our display.

After executing the project, you should have a scrollable view of the tiles in the tile set in the ListView control in the upper-left corner of the editor window. The LoadImageList() helper method reads the PlatformTiles.png file, and splits it up into tile-sized chunks, which it stores inside the imgListTiles ImageList control.

Notice that we needed to modify the properties of the PlatformTiles.png file so that it gets copied to the output directory, because normally the content pipeline would convert the PNG file into an XNB file, which is unreadable by the standard Windows Bitmap class. The XNB file will still be created and copied, but the PNG file will also be placed in the output folder where our MapEditor code can find it.

As each image is added to the imgListTiles control, entries are also added to the listTiles ListView control. The first and second tiles are given special labels in the ListView (Empty and White), as they will both appear to be empty white squares since the background of the ListView itself is white.

The MapEditor_Load() event handler runs when the form is loaded, as its name implies. We will be expanding on this event handler as we add more controls to the form, since it gives us a convenient place to perform initialization.

We now have scroll bars attached to the sides of the game's display area. When the form is initially displayed, and then again whenever it is resized, the scroll bars will be rescaled so that they cover the entire area of the game's tile map.

We will use these scroll bars to move around on the map while editing, though their actual implementation will again be tied to changes to the Game1 class.

We now have all of the interactive controls that we need for our level editor. The codes drop-down box provides a number of standard code values that we will use during level creation, with the ability to add custom codes, which are entered in the textbox above it.

We currently have a Windows form that contains our XNA Game display, but the two pieces of the level editor application do not yet share any information, or allow the user to actually edit maps. It is time to begin updating our game to support level editing.

To simplify communications between the Windows Form and the XNA Game, we have declared a number of public member variables that our Windows Form code will be able to update in response to user-generated events. We have also loaded a SpriteFont to draw code values with, and a MouseState variable to hold the state of the mouse between frames.

Finally, we declare two objects that reference the scroll bars on the level editor form. We will use these to sync-up the display of the tile map to the location of the scroll bars.

The LoadContent() method is fairly standard, setting the size of the tile map, and loading the tile images and sprite font. The TileMap class spriteFont member is set to the font we loaded, and the lastMouseState member is initialized. Right before exiting, the LoadContent() method calls the pictureBox_SizeChanged() method, to make sure that the graphics device has the proper dimensions for the display window.

In our Draw() method, we have again used the expanded form of the SpriteBatch.Begin() call in order to specify the SpriteSortMode.BackToFront parameter.

The first thing our Update() method does is to set the game's camera position, based on the current values of the horizontal and vertical scroll bars on the level editor form. When we scroll the scroll bars, the game map will scroll as well.

Next, we verify that the mouse coordinates are within the view port of the camera and thus within the PictureBox control on the editor form. If they are, we determine the world-based coordinates of the mouse cursor.

If the left mouse button has been pressed, we update the tile under the cursor on the current DrawLayer with the current DrawTile. The right mouse button is a bit more complicated.

We will use the right mouse button to set two different types of information—either toggling on and off the Passable property of the MapSquare, or setting its CodeValue property, depending on the mode selected on the MapEditor form.

In either case, we will only make a change to the underlying tile if the right mouse button is pressed during this frame and was not pressed during the previous frame. This eliminates updating the same square multiple times on a single button press (which would make toggling passability on and off difficult!) During the first frame after the button is pressed, the MapSquare will be updated. Until the button is released, no other updates will occur.

The HoverCodeValue member is set to the CodeValue of the MapSquare under the mouse cursor. This value will be used by the MapEditor form and displayed on a label on the screen to provide an alternative method of viewing the code for an individual square.

Finally, lastMouseState is updated to the current mouse state, and the Update() method is completed.

As we saw at the end of the last section, attempting to draw tiles to the map at this point only leaves empty spaces. This is because the DrawLayer and DrawTile integers both default to zero, so we are drawing a fully-transparent tile onto the background layer.

Now that we have made the necessary updates to the XNA side of the level editor, we need to flesh out the event handlers for the controls we placed on the MapEditor form to update the control variables inside the Game1 class.

All of our event handlers for the form controls simply pass information along to the appropriate variables in the Game1 class. Selecting a layer from the menu bar updates the DrawLayer value, while the radio buttons toggle the EditingCode variable between true and false. We need to wrap these statements in "If Not IsNothing(game) Then" statements, because the first time these events will be executed is before the game object has been created.

Any time the txtNewCode control's Text property is changed, the current contents of the TextBox are copied to the CurrentCodeValue member of the Game1 class.

In step 11, you probably noticed that the game window does not update the current position when you are scrolling through the scroll bars until you release the mouse button, even though the scroll bar's marker moves the whole time. This happens because the movement of the scroll bar is preventing the game loop from executing while the user is in the process of manipulating the scroll bars.

In addition, the scroll bars do not match up to the map window until we resize the display at least once. This is because the form's Load event happens prior to the initialization of the Game1 instance (if you go back and look at Program.vb, the form is created and shown first, and then the game is initialized), so the WorldRectangle property of the Camera module is {0, 0, 0, 0}. This results in FixScrollBarScales() setting negative numbers for the maximum values of the scroll bars.

We can fix both of these problems by adding a timer to the form that initially calls FixScrollBarScales() and repeatedly calls the game's Tick() method.

Using the scroll bars does not prevent the timer control from firing its Tick event, so by executing the game's Tick() method from within the timerGameUpdate_Tick() event handler, we can force the game's Update() and Draw() methods to run even when they normally would not.

The last item in the timerGameUpdate_Tick() handler checks to see if the HoverCodeValue inside the Game1 class has been updated, since it was last copied to the label displaying it on the Windows Form. If it has, the form label is updated as well.

The last thing we need to address to complete the Gemstone Hunter Level Editor is how we will load and save our map files. There are a number of ways we could store our level maps, but we will implement a very simple method that does not require parsing XML or creating a textfile with a special format to store the map.

When a map is saved, we create a FileStream object, which represents our file on disk. We then create an instance of the BinaryFormatter class and call its Serialize() method, passing in the stream to serialize the data from the object we wish to serialize. In our case, it is the array containing the MapSquare objects that represent our game map.

When loading the map, the process is exactly the same, except that we use the Deserialize() method of the BinaryFormatter class to reverse the process, converting the binary data on disk back into its in-memory representation. By surrounding the attempt to load the map with a Try...End Try block, we can take action (clearing the map to an empty blue sky) instead of simply crashing the level editor.

From the Windows Form side of the system, we call the new LoadMap() and SaveMap() methods, passing in the FileStream object that is created based on the cboMapNumber drop-down list. Our maps will be saved in files named "MAP###.MAP", with the three-digit number taken from the cboMapNumber list. While using our maps in the Level Editor, they will be stored in the same directory our Level Editor executable is running from (normally, the Visual Studio 2010ProjectsGemstone HunterLevel EditorLevel Editorinx86debug folder inside your Documents folder). In the following screenshot, we have created a sample map using the level editor. This map currently has no passability or code information on it, and it contains only tile information for now:

When building maps, we will use the right mouse button to toggle each individual map square as either passable or impassable. When a square is marked as impassable, it will be tinted red by the editor, indicating that both the monster and the player will treat the square as a solid wall, no matter what visual representation the square has.

Without this information, the player would fall straight through the level and off the map—something we will need to account for in the game engine when we build it in the next chapter.

Each MapSquare can be assigned a code value that will allow the game to implement special behavior for that square. We have pre-defined a handful of code values including:

In addition, we will define a special code for map transitions. In the following image, we have a code value of T-001-03-10 on the MapSquare containing the door into the brick building. At runtime, we will interpret this code value to mean: Transition (T) to map 001, at location 03, 10. In this way, we can link maps together and allow the player to move between them:

This image shows the map from the previous section with both passability and code information filled in. In Editor mode, the TileEngine class displays the code values as text blocks on each map square. These codes mean nothing to the editor, so just like passability information, we will need to account for it in the game engine.

Remember way back when we hid the empty Game1 form, the one where we added code to the Exit menu item to properly terminate the application? We can clear up what happens when the user clicks on the X button in the upper-right corner of the window to close the application.

When the form closes, we need to shut down both the XNA game and the overall application, otherwise the system will not release the resources, and the program will still be running invisibly in the background.

The Gemstone Hunter Level Editor project is fairly rough around the edges. It is not exactly a model example of Windows Forms development, but then few purpose-built internal game development tools are.

If you feel like diving further into Windows Forms development, here are a few suggestions for improving on the level editor: