Courtesy of Namco Holding Corp Courtesy of Blizzard Entertainment® Pac-Man and Diablo are two popular examples of tile-based worlds.
A tile also known as a cell is a rectangular (usually square) area of a map. A tile can be any size, but is often set up to be approximately the size of the character you are using, or at least the size of the part of the character that touches the ground, such as feet or wheels. The map is completely made up of tiles. You probably won't be surprised to hear that in Macromedia Flash, a tile is a movie clip. Imagine a top-down view of a ten-by-ten grid of square tiles in Flash. Each tile can have as many frames as you wish. Frame 1 might contain a patch of grass. If the entire ten-by-ten grid were showing frame 1, then the world would look like a big patch of grass, since you wouldn't see a difference between one tile and the next. You might have other frames in this tile for instance, one for a bush or a rock. In this way, you can create your game environment by "tiling" the tile movie clips (just like you would tile your kitchen) and then sending each tile to a specific frame. Perhaps frame 2 is of a patch of grass, frame 5 is a sidewalk, and frame 6 is water. Using these three frames, you can create a TBW that looks like a grassy park with a pond and a walkway meandering through it. And of course you can add many more types of tiles to produce more-complicated designs. By creating a grid like this using tiles that have multiple frames you are creating a TBW! In Shark Attack!, the fish needs to avoid the shark, overcome obstacles, get the key, and unlock the door. The tiles in the world of this game have numerous frames. This simple technique is very powerful. You can create a whole city using tiles for grass, road, sidewalks, bushes, walls, and so on. This allows you to reuse your graphical assets efficiently and conveniently. In the case of puzzle games that use TBWs, such as Pac-Man and Minesweeper, the complexity of the tiles is low. They usually just have a few different items that they need to show, such as a dot to be collected, or a maze wall. These games profit from the use of TBWs mostly because TBWs reduce the amount of processing that occurs by using a simple math trick. This trick is explained in the next section. One of the most convenient programmatic benefits of using TBWs is their ability to easily store information about certain areas of the map. To take advantage of this, I use a two-dimensional array in which each element represents a tile in the world. An object is stored in each element, and then information about the tile that it represents is stored in this object. For instance, if a tile were of a rock, then information might be stored in the object to say there was a rock in this spot and that the character could not move through it. Or if the tile were sand, then information might be stored to specify that the character should be slowed to half its regular speed when passing through this cell. In a game like Pac-Man, in which there might be a 15-by-15 grid, there would be a two-dimensional array with an object that represented each tile. That's 225 (15 times 15) objects. Each object would contain information saying if it was a wall, if it was empty, or if it contained a dot to be collected. How this information is stored (in this case, the two-dimensional array) is called a data structure. A common alternative to the two-dimensional array data structure is to store and name the objects logically. In the Pac-Man example, the 225 objects would be created and given logical names, each based on the cell it represented. So, for instance, the name of the object representing the cell in the third column and eleventh row would look something like cell3_11. This is the way we store data in the example game we're working with in this chapter.
Another very useful feature of TBWs is their ability to store the information needed to build the world in an external file or a database. Using a standardized protocol like XML, you can easily store such information. This is great news, because it means you can create a game and load in an unlimited number of levels! Usually you'll need a level editor an application you build, and that assists you in creating a level. You usually "program" the level editor to output information in savable form, such as an XML document (which is just text) you can store in a file or a database. That file can be loaded into the game, and Flash will interpret it and use the information in it to dynamically build the level. In the final section of this chapter we'll look at a simple example of a level editor. The example mentioned earlier, Shark Attack!, loads its levels from external XML files. You can see them in the same directory. They are level1.xml, level2.xml, and level3.xml. You can open and view them with a normal text editor like NotePad or SimpleText. Board games like chess and checkers are not usually considered tile-based worlds, but they can be treated as such. You can use the same two-dimensional array data structure to store information about the tiles, such as the tile color, or which piece is sitting in the tile. If you are really itching to see how all this looks and works in an actual game, just hang on. In the third section of this book we'll see this information applied in the tile-based game called Don't Fall! |