Game Development Reference
In-Depth Information
Tile attributes
Inside the
<tile></tile>
data for each tile sheet element, we have defined three different
attributes that describe the tile.
id
: The
id
is simply the tile number, starting at
0
and going up to
31
. There are 32 tiles in
the tile sheet: 4 rows of 8 tiles each. This number is not used by the game code but
rather is a reference for the game developer and level designer to understand where
that tile will be in the one-dimensional array of tile sheet tiles when we get to the game
code.
name
: This represents the type of sprite that the tile is. Some tiles are not sprites, but
they have names too. Those are used purely for reference for the game designer and
programmer. The code we will create in the next chapter will use this name types and
create custom class instances for each based on this name. This makes it easy for the
level designer to place the player tank any place on the level. The same holds for the
enemy, goal, ammunition, and lives sprites. The explosion and missile sprites should not
be placed in the level. They are used for special FX in the game.
type
: There are three different tile types:
sprite
,
walkable
, and
nonwalkable
. All wall
tiles must be set to
nonwalkable
; all road and passageway tiles must be set to
walkable
.
Everything else should be set to
sprite
.
The final two attributes in the XML were not part of the data from Mappy:
<smallexplode tiles="17,18,17"></smallexplode>
<largeexplode tiles="17,18,19,18,17"></largeexplode>
We added these attributes. They describe to the game the tile sequences needed for two different
explosion types using the tiles in the tile sheet. So, for example, the
smallexplode
animation
sequence will play tile 17, then tile 18, then tile 17 again. We will go into detail on these two in the
next section.
How this code works
TilesheetDataXML.as
is a basic global type or static style class that we will never have to
instantiate. The
Game
class will never need an instance of the class because our single variable,
XMLData
is defined as static. This allows the
Game
to simply use this XML data without needing to
instantiate the class directly.
Why don't we just use an XML file and load it in?
The focus of this topic it to create final SWF files
that need no external assets. This creates the easiest game content to spread 'round the World
Wide Web. For this reason, we have gone to great lengths to make sure that the final SWF file
has all of the needed assets embedded without the need to call external files.
Using the tile sheet data in code
We will now create some example code that will be fleshed out in the next chapter. The example
code will parse the
TileSheetDataXML.as
XML data and place it into a one-dimensional array that
can be used to describe the contents of the level XML files file to the Game.
