Game Development Reference
In-Depth Information
Reading the tile sheet data
This first set of code for GameDemo.as is used to read in and evaluate the tile sheet data. In the
previous section, we examined the structure of the TileSheetDataXML.as file. In the preceding
code, we create the first version of the GameDemo.as class that we will be using to demonstrate
functionality for our future game, No Tanks!. None of this will go to waste, as we will be using the
exact same code with some minor modifications in the next chapter as we build the game.
The constants
You will notice that we create some constants at the beginning of the code. These will be used in
place of plain old integers to describe the contents of the tiles in the tile sheet. The only two basic
background tile types are TILE_WALL and TILE_MOVE . These will be the lowest level components
on the background of our game level. A tile can only be one or the other, but cannot be both. Any
tile with type="walkable" in the XML will be designated with the TILE_MOVE value. Any tile with
type="nonwalkable" in the XML will be designated with the TILE_WALL value. Any tile that either
describes an interactive object or other game object that is not strictly used for creating the
background of a level is give the type="sprite" value in the XML. Those tiles will be evaluated
based on their name= XML attribute values.
The next seven constants ( SPRITE_PLAYER through SPRITE_LIVES ) are used to describe the sprites
used in the game. Each sprite will use the tiles associated with it in a slightly different way. The
name= attribute value in the tile XML will be used by the game engine to make use of the sprites
for the game.
Player: The player is the sprite that the user will control in the game. The array of tiles
for the player creates the movement animation of the tank track that will simulate tank
movement. The look of the player sprite is a series of tile sheet frame numbers that are
all stored in the array, playerFrames . The game will assume that the tiles for the player
are in the correct order on the tile sheet already. As the code reads in the tile sheet XML
data, when it encounters a tile with type="sprite" and the name="player" , it will add that
tile to this array.
Enemy: All of the enemy sprites will share the same look. The tiles for the enemy will
be stored in the enemyFrames array and function exactly like the player tiles. The game
engine assumes that the tiles are in the correct animation order on the tile sheet
already. The code looks for type="sprite" and name="enemy" and adds all of those
tiles to the array.
Missile : Both the player and the enemy will share a single tile for the missile. The code
will look for type="sprite" and name="missile" . When it finds a missile tile, it will add it
to the missileTiles array. Even though our game uses a single tile, we store it in an
array so it can easily be swapped out to a multiframe animation with ease.
Explosion : There are three tiles that are designated as type="sprite" and
name="explode1" , "name="explode2" , and name="explode3" . These are handled
differently than the other sprites in the game. We are going to allow game programmers
to make use of these three tiles in any way that they desire. We have two arrays that we
filled with actual tile numbers to create two different explosions.
Search WWH ::




Custom Search