The XML and the Level Editor

When you create a game that has multiple levels, each of which reuses the same graphic assets, it makes sense to build a level editor. The goal is to represent each level using XML-formatted data. That way, you can create as many XML files as you like (one for each level) without having to edit the game itself. You can use a level editor to visually build what the level will look like and to generate the XML used to represent that level. This is the simple, top-level process for building a level:

1. Open the level editor (we will talk in detail about this and the next step later).

2. Build the level.

3. Click the Generate XML button.

4. Copy the XML generated in the Output window and paste it into a new text file.

5. Name the text file using the appropriate or subsequent level number (level1.xml, level2.xml, level3.xml, and so on).

Before we get to exactly how to use the level editor, you should be familiar with the XML format chosen for this game.

The XML Format

For more information on XML, see Appendix D.

You may be thinking, "I have a level editor, so why do I need to understand the XML?" Well, you have a point. If you only want to make levels using what I have provided in this game, you don't need to understand the XML. But if you want to modify or extend this game idea to include more features, then you will need to understand how the XML is formatted. If you were to add, for instance, a second type of enemy, you would need to add some extra attributes to the enemy nodes to specify the type of enemy, or create a new section of the XML document. Or even if you want to do something simple like specify the background or the music to use for each level, you need to understand how the XML is set up so that you can modify it to include this information.

Here is the basic format, with no actual data being stored. I'm initially showing it to you like this so that you can have an overview of the entire document. You will see some real data farther down.

 1   <level>  2      <blocks /> 3      <grounds /> 4      <baddies /> 5      <collectables /> 6   </level> 

As you know, every XML document must have exactly one root node. For us, with this game, that's the <level> node. It will be used to store the position of the flag that must be captured (it will store that position as attributes). The <blocks> node will store the positions and properties of all the three types of platforms (cubes, ice platforms, and trees). It will store information for each of these platforms in <block> nodes, which are children to the <blocks> node. The <grounds> node stores child nodes that describe areas of the ground. To put it another way, every area of the ground that is not contained within the <ground> child nodes of the <grounds> node is a gap in the ground. The <baddies> node stores <baddy> child nodes that represent the enemies. Each <baddy> node contains the position of the enemy as well as its speed and the initial direction in which it will walk. The <collectables> node simply stores the positions of each of the collectable movie clips the ice cubes in separate <collectable> nodes.

Here is an example that has very few nodes but contains actual level data:

 1   <level flagx="1742" flagy="332" > 2      <blocks> 3         <block x="340" y="210" type="solid" graphic="cube"            container="true" containerCounter="3" /> 4         <block x="385" y="210" type="solid" graphic="cube"            container="false" /> 5         <block x="430" y="210" type="solid" graphic="ice platform"            container="false" mover="yes" xspeed="2" yspeed="0"            maxxmov="150" maxymov="0" /> 6         <block x="475" y="210" type="cloud" graphic="tree"            container="false" /> 7      </blocks> 8      <grounds> 9         <ground xstart="0" xend="940" /> 10        <ground xstart="1020" xend="4800" /> 11     </grounds> 12     <baddies> 13        <baddy x="646" y="330" breadth="200"            start_direction="right" speed="2" /> 14        <baddy x="1362" y="330" breadth="100"            start_direction="left" speed="1" /> 15     </baddies> 16     <collectables> 17         <collectable x="362" type="ice cube" y="193" /> 18         <collectable x="405" type="ice cube" y="192" /> 19         <collectable x="451" type="ice cube" y="191" /> 20     </collectables> 21  </level> 

In line 1 you see that we have two attributes within the <level> node flagx and flagy. This is where the flag will be positioned in the level. In lines 3 6, four platforms, each slightly different, are described:

Line 3 describes a cube platform that will contain three collectable items. The container attribute indicates whether the platform will contain a collectable item, and the containerCounter attribute indicates how many items this platform will contain. Line 4 describes a basic cube platform, containing nothing (so the container attribute is false). Line 5 describes the ice platform. We give it an attribute of mover with a value of "yes", meaning that the platform will move. We also give it several attributes that contain how the platform will move. The attributes xspeed and yspeed control the speed at which the platform will move in those directions. The maxxmov and maxymov attributes specify how far the platforms will move in those directions. Most commonly, maxymov and yspeed are 0, so the platform only moves horizontally. Line 6 describes a tree platform. I usually give the tree platform a type attribute of "cloud". That is so the hero can jump from underneath (if the tree is set up over ground) through the leaves and then land on top of the tree.

Lines 8 11 describe the valid pieces of the ground. In line 9 the <ground> node contains two attributes: xstart, with a value of 0, and xend, with a value of 940. This means we are defining a valid walkable area that spans x = 0 to x = 940. Before x = 0 (that is, <0) there is no ground. In line 10 we have a <ground> node that specifies valid ground between x = 1020 and x = 4800. Putting both of these pieces (lines 9 and 10) together conceptually, we can see that we are defining ground between 0 and 4800 with a gap in the middle between 940 and 1020.

The enemies are defined in lines 12 15. Each <baddy> node must contain these attributes: x, y, breadth, start_direction, and speed. The x and y values specify the enemy's starting position. The breadth attribute tells how far the enemy should walk before turning around and coming back. The start_direction tells which direction (either "left" or "right") he should start moving in, and the speed attribute specifies the speed at which the baddy should move.

In lines 16 20 we describe where all of the collectable items should be. Each collectable node contains three attributes: x, y, and type. The attributes x and y specify the collectable item's position; the type attribute specifies which collectable item you would like to use. In this game we are using only one collectable item, but it is easy to modify the game to add more. The ActionScript uses the value of the type attribute to pull a movie clip from the library (the linkage identifier has the same name as the collectable). So you could easily add a movie clip to the library, give it a linkage identifier, and then specify it here in the XML file.

Code-Graphics Independence

Throughout this book I have been pushing the idea of not tying your ActionScript specifically to one movie clip or graphic, and have pointed out several advantages of this method along the way. If you play around with this XML file a bit, you'll find another advantage. As you can see above and from playing the sample Ice World game, cubes tend to be "solid" and can sometimes contain collectables. Ice platforms tend to be solid and to move. Trees tend to be clouds (meaning there is only detection from above). However, there is nothing in the XML to stop you from making a tree move, or from turning a cube into a cloud. I didn't tie the code to any specific graphic, so you can come up with many different combinations if you want to. For example, sometime you might only want one little tiny cube to movie vertically, not the whole clunky ice platform.

The Level Editor

As I mentioned earlier in this chapter, we are storing the data used to build each level as separate XML files. The level editor's purpose is to assist in the creation of these XML files. With this level editor, you can visually drag and drop elements onto the game world. Once they are in the world, the properties of these elements can be edited. When you are happy with what you see, you can generate the XML, copy it, and paste it into a text file.

Open platform_editor.fla in the Chapter15 directory. I will not discuss the ActionScript in this file, but rather explain how to use it. Press Ctrl-Enter (Windows) or Command-Enter (Macintosh) to watch this movie in test mode. (As it currently stands, this file must be used in Test Movie mode because the XML that is generated is displayed from a trace action in the Output window.

You now have the SWF running in Test Movie mode. Before launching into the details of how to build a map, let me take you on a quick tour of this simple interface. In the top-left corner of the screen you can see the level dimensions written out. The level is 4800 wide and 4000 tall. These dimensions are not configurable, but you don't have to fill the space completely, either. (I didn't completely fill in any of the sample levels on the CD.) To the right of the dimensions are some directional arrows. By clicking the arrows you can move the level around so that you can see other areas of it. That navigation can become frustrating when you're trying to move large distances, so I also included support for the keyboard arrow keys. I suggest using the arrow keys for easy level movement. On that note, skip over to the bottom-right corner of the screen just for a moment, to the reposition button. When you click that button, the world moves back to its starting position.

To the right of the directional arrow keys are four items, each of which is draggable. You can click and drag any item over the level and then release it. Note that you can only drag these items into the area within the black lines on the stage. The first item has the word "gap" written on it. By default, the entire ground from x = 0 to x = 4800 is a walkable area. To add areas of no ground that is, gaps you drag and drop this movie clip. You should note that a gap has no y position, so when you drop this movie clip onto the stage, you don't have to worry about placing it exactly over the ground; all that's necessary is to place it horizontally where you want it. There are three buttons on the gap movie clip: a left arrow, a right arrow, and a minus sign. The arrows are for controlling and adjusting the width of the gap: The left arrow shrinks the movie clip horizontally. The right arrow makes it wider. The minus sign is something you'll see on all four of the elements. It allows you to remove an item from the stage. If you placed the item but no longer want it on the stage, click the minus sign button and the item will be removed.

The next element is the collectable ice cube item. This is an easy one, as it has no configurable properties. Just drag it to the position where you want it.

Then we have the platform movie clip. Notice that there is only one of these, not three. That is because this one movie clip can be configured to display any of the three types. Drag the clip out onto the level. Click the i button on it (the i stands for "info"). This opens an information-display window, where you can edit all of the <block> node attributes. The graphic field can contain any of three values: "cube," "ice platform," or "tree." The type field can contain either of two values: "solid" or "cloud." (The behavior of the rest of the attributes was explained above in the XML.) As soon as you click the update button (or press the Enter or Return key) the element is updated and the display window closes. The platform will not start moving on the stage (if set to move) but will display the correct graphic.

Finally, we have the enemy movie clip. Drag one onto the stage and click the now-familiar i button. There are only three editable fields for this movie clip: the direction for it to start walking, its speed, and its breadth.

Remember that when the flag is captured, the level has been completed. The flag is already on the stage, since there can only be one flag. You can drag it to any position.

Notice the Generate XML button in the bottom-left corner of the screen. When clicked, it takes all of the level data and generates an XML-formatted document for that level, and displays it in the Output window. You can then copy it from the Output window and store it in a text file. You can name that text file anything you like (such as level1.xml). When testing new levels, the procedure I usually follow is this:

1. Rename level1.xml to something else (like level1_.xml) so as not to ruin the original.

2. Build a level using the editor, and copy the XML.

3. Without closing the level editor, open a text editor and paste the level XML data into it, and then save it as level1.xml.

4. Open the ice_world.swf file (the standalone one, not in Test Movie mode) and test this level. It is quick and easy to test, because it is now level 1.

   

   Note that while you are testing the game, it will appear to be playing more slowly than you would expect. This is because the editor is still open.

5. To make any changes, close the game and go back to the editor, which is still open. Since the editor was open during the testing period, capturing all key presses, chances are good that the level's position is not where you left it. Click the reposition button to reset to the starting position. You can then move the level to the area that you want to edit. Once you have edited the level again, return to step 3.

6. Repeat steps 3 5 as needed. When you are happy with the level, do a Save As, using the real level number that you want for this file (for example, level7.xml). Then rename level1_.xml back to level1.xml.

One major deficiency of this level editor is that it doesn't load in level files that you can then modify to create a different level file. You must start from scratch every time. Other than that problem, this level editor should provide you with everything you need to create some very interesting levels!