Game Development Reference
In-Depth Information
< wall spriteClass= " StandardWall " x= " 9 " y= " 0 " / >
< wall spriteClass= " StandardWall " x= " 9 " y= " 1 " / >
< wall spriteClass= " StandardWall " x= " 9 " y= " 2 " / >
< wall spriteClass= " StandardWall " x= " 9 " y= " 3 " / >
< wall spriteClass= " StandardWall " x= " 9 " y= " 4 " / >
< wall spriteClass= " StandardWall " x= " 9 " y= " 5 " / >
< wall spriteClass= " StandardWall " x= " 9 " y= " 6 " / >
< wall spriteClass= " StandardWall " x= " 9 " y= " 7 " / >
< wall spriteClass= " StandardWall " x= " 9 " y= " 8 " / >
< wall spriteClass= " StandardWall " x= " 9 " y= " 9 " / >
< /walls >
< /level >
In the opening tag of the XML, the width and height of the level
and the pixel size of each grid square are set. In this case, the level
is 10
10, with a square size of 50 pixels. This GameBoard will
ultimately be 500
×
×
500 pixels. In the first set of nodes, I define
which asset SWFs the level will use. The engine will load these files
before parsing the rest of the level. Whenever a node makes refer-
ence to a class, it will be defined and contained within one of the
asset SWFs. I
ll shortly outline the creation of these asset SWFs.
The next individual node defines the player class and start posi-
tion. Note this x and y will not translate directly to an x and y on
the Stage, but rather the corresponding grid reference in the level.
To match the arrays that will eventually exist to house the grid, the
x and y coordinates are 0-based. Thus, the player
'
s start position of
(2, 0) will actually be in the third column at the top. The next two
sets of nodes follow the same pattern, just with enemies and items.
Items have a couple of extra attributes, including the type (so the
engine knows how to use the item), a unique name (so that the
item can be tied to functionality in the game), and a point value.
Note that the key is not worth any points, but will be a require-
ment to exit the level.
Next in the file are any portal nodes. This level has only one,
and its destination attribute designates that it will go to the next
level. Portals also have optional requirement nodes; these are
things that must be done for the portal to be active. In this case,
the item tagged with the name
'
is required to have been
picked up in order for the portal to be used. With this structure,
you could theoretically have multiple requirements, such as
destroying all enemies on a level or gathering all the treasure.
Finally, the file ends with the wall definitions. Each of these
nodes defines a grid square that holds a wall. The player will not
be able to move into these squares. Every one of these wall squares
will look the same, but you could, in fact, define a different asset
class for each of them. This would allow you to create grid squares
that seam together to form larger images.
key1
Search Nedrilad ::




Custom Search