We will be learning about level editing in this chapter, which is a subset of a larger field called tools programming. A simple review of the employment statistics reveals this truth: tools programmers are among the highest paid people in the game industry, commanding salaries far greater than that of game designers, gameplay programmers, and even engine programmers. So, what does a tools programmer do? This is a high-demand skill set simply because it is not taught in schools, and few programmers have found a need to develop this particular type of skill in their daily activities. A “tool” in this context is any program or script that is needed during the game development process. Examples include Max and Maya scripts, file format converters, workflow pipeline programs, automated build scripts, and yes, even level editors.
We are going to focus on the level editing aspect of tools programming in this chapter. You will learn how to build a simple tilemap level editor. But first, I must disclaim something: we are going to use the C# language rather than Basic for this one. Most standalone tools are built with C#, so I want to give you a real-world experience using one of the “tools of the trade.” That is not to say we could not build the editor in Basic—of course we could, as there are only cosmetic differences between C# and Basic. However, this editor will be useful for more than just one game genre.
The level or “game world” defines the rules of the game and presents the player with all of the obstacles that must be overcome to complete the game. Although the world is the most important aspect of a game, it is not always given the proper attention when a game is being designed. This chapter provides an introduction to world building, or more specifically, map editing. You learn to create the game world for Celtic Crusader, as well as levels for your own games, using a custom level editor. We will explore the features of this level editor to gain some insights and inspiration for creating our game levels.
Here’s what we’ll cover in this chapter:
We’re going to build a custom level editor for Celtic Crusader so that we have full control over the tile format. The previous edition of this book used an off-the-shelf (so to speak) editor called Mappy (http://www.tilemap.co.uk). Mappy works well and has been used by many game studios for professional games, especially on handheld game systems like Nintendo GBA and DS. But, despite industry adoption and the popularity of Mappy, we will need our level editor this time to save tilemap data in such a way that it can be loaded into the game without too much effort. Previously, when using Mappy, we had to export tilemap data into a custom binary file and then write Basic code to load that binary data file, which was not easy!
So, let me explain the editor a bit. First of all, this is not a production editor yet. Since we’re building it from scratch it will need to evolve to meet the needs of the game as the Celtic Crusader engine code takes shape. Nothing in this creative industry is ever finished, but we can make a solid effort to make the first iteration of the editor as useful as possible with the understanding that it will change over time to provide new features as needed. The first version of our editor must give us the ability to create and edit tilemaps using a fixed tile palette, and save the tilemap data using an .xml file. It is shown in Figure 10.1. An improved version of the editor with more features will be covered in Chapter 13. By presenting the editor in stages like this, you can see how it was developed from the earliest stage to a more complete version later in the book.
The tile palette is fixed for now with the tiles I plan to use in the game, but since the palette is a PictureBox with an associated Graphics and Bitmap object, we can modify it as needed—adding tiles, removing tiles, and so on. The tiles are fixed at 32 × 32 pixels since that is an assumption made for the game. There’s no reason why we can’t use a different tile size, since the source code can work with 32 × 32 or 64 × 64 or any other reasonable dimension as a variable just as well as a hard-coded pair of numbers.
The source code for the level editor is too long to list here, so I will instead recommend you open the editor project in the chapter’s resource files (www.courseptr.com/downloads). In any event, the editor source code is a bit too much to cover in a single chapter, and this isn’t a tool programming book either! The user interface has many complex controls such as splitters and panels to make the editor work correctly when the window is resized. We will not be building the editor GUI here either, because that would be a daunting thing to explain step by step, if it’s possible at all. I’ll presume you have the project open while going over how it works. Figure 10.2 shows the editor in the form designer of Visual Studio.
On the left is the tile palette. This is the collection of source tiles used to create a game level, and each tile is 32 × 32 pixels in size. There is also a one-pixel border separating each tile in the palette. If you create your own palette or add to this one, be sure to maintain that one-pixel border between each tile because the editor (and the game!) counts on that space being there to work correctly. If you want to replace the palette image, just open up the PictureBox control’s properties and choose a new image using its Image property. The height may be shorter or taller, but it’s very important that you maintain the same width as the one currently in the editor! The current one has five tiles across. Just be sure any replacement palette image you want to use has the same five tiles in width and the replacement palette image should work fine!
This early version of the editor does not know how to query the user for the filename when loading or saving a level file, so it just uses the same default filename when loading and saving. That filename is tilemap.xml, and it is located in Level EditorinDebug. To create a new tilemap file, just rename tilemap.xml to a new filename and start up the editor to create a new tilemap.xml file automatically. Unfortunately, this is pretty typical of an early alpha version of a tool—it is functional but sorely lacking in usability features. The finished version in Chapter 13 has load/save dialogs that come up, among other useful features.
There is a single menu on the toolbar: File. This menu has several menu items under it:
Save Editor Palette BMP (165 × 960)
Save Tile Palette BMP (512 × 512)
Save Level BMP (4096 × 4096)
Load Tilemap XML
Save Tilemap XML
The first option, Save Editor Palette, saves the tile palette image (the tiles on the left side of the window) as a new bitmap file. The filename will be palette.bmp, and is shown in Figure 10.3. This file is useful if you want to edit the palette by replacing tiles or adding new tiles to it. If you want to do that, then the only way to import the new palette image is via the PictureBox control (the manual way). This shouldn’t be much of a problem because the tile palette does not often change.
The second option, Save Tile Palette, exports the same tile palette image in a different format—a 512 × 512 bitmap file. This is useful in some cases because some game engines do not like bitmaps with odd dimensions. A Direct3D texture, for instance, works best with uniform dimensions like this and might have difficulty loading a texture with a size of 165 × 960, which is the native size of the palette image. Figure 10.4 shows the exported texture file.
The third option, Save Level, will export the entire tilemap as one huge bitmap! This is a pretty interesting option that lets you see the whole game level as one huge image, but I’m not sure if it’s very useful in a game since it’s so large. Beware, the file is 4096 × 4096 pixels—uncompressed it takes up 65 MB of memory!
The tilemap level files are saved in .xml format. XML stands for Extensible Markup Language, and is similar to HTML (the language used for websites), in that it is a text format that you can open and read with a simple text editor. The following listing shows the first and last tiles in the tilemap.xml file saved by the level editor. Every tile is contained in a tag called “tiles,” with an opening tag, <tiles>, and closing tag, “</tiles>”. Within the tag are four properties: tile, value, x, and y.
<?xml version="1.0" standalone="yes"?>
<DocumentElement>
<tiles>
<tile>0</tile>
<value>119</value>
<x>0</x>
<y>0</y>
</tiles>
.
.
.
<tiles>
<tile>16383</tile>
<value>56</value>
<x>127</x>
<y>127</y>
</tiles>
</DocumentElement>
As work continued on the level editor, I realized that the x and y values are completely unnecessary because the tile positions never change, and are based solely on the tile property. There are 128 × 128 tiles in a whole level, for a total of 16,384 tiles. That means there are also 16,384 <tiles> records in the .xml file. The value property is the key to the whole thing—that is the tile palette number, representing the image that should be shown for that tile.
This chapter moved rather quickly through a brief tutorial on level design, which provided a working understanding of how a level editor should work to allow creating and editing game levels as tilemaps, before moving on to designing our own custom level editor for Celtic Crusader. The tilemap is the most important part of the game because it is the foundation—literally, it is the world on which our characters will walk. You can create a large, vast desert or a lush green world and populate it with vegetation and roads and even buildings. In the expanded version developed later, the editor will support collisions, portals, and additional data fields for each tile. But we have to start somewhere! It’s my hope you will appreciate seeing the editor in this early state of development, and note the differences in the improved version.