Isometric
Grid Development
by senocular
At this point, another choice is at
hand. Depending on the extent of your isometric endeavor, you will need to
decide on an approach to handling the programming and the objects involved.
Should basic functions run isometric handling? should everything be controlled
through extending the MovieClip object with prototypes? Should an isometric
object class be created for all isometric handling?
The level of depth can be quite
intimidating. I'll try to cover both a simple and a more complex example of
isometric handling in these manners, though first lets go off on another tangent
and look back at some grid handling.
Before you start moving around and
interacting in your isometric world, you will first need to define it. This is,
of course, handled through grids. First off, lets consider what exactly we need
to define. Again, the depth of your isometric project will be reflected in what
goes here, but some things may include:
- the extent of the grid and the space it occupies (not extending to
infinity)
- the visual objects that exist on the grid
- the suitable placement for objects on the grid, either allowable over
other visual objects in the same grid position or not
- important points of action in the grid. For example a stairs tile. If an
user controlled character lands on this grid space, the action of changing the
scene from floor 1 to floor 2 would be executed.
Each determination of these
correspond to a grid location or coordinate or a group thereof. For example,
think of a treasure chest sitting on the floor. Firstly, you have to know where
on the floor its sitting - the grid space at which it exists so you know where
to put it when it needs to be put. This you don't necessarily have to do through
code, but rather, it can be done directly in Flash by placing it on the screen.
And this is fine, but know you have the option of doing it through scripting as
well. Once that chest is on the screen, you have to make sure user controlled
(or AI controlled for that matter) characters don't walk through it.
You could use something like hitTest
here, but managing it through programming within our grid space is easier and
yields better results which conform more to the "isometric way." Also, since
this is a chest we're dealing with, we may want to open it. In that case, we
would need to define where a character may need to be (what grid space) to open
it and what action will occur in the event that they try. Will the chest open or
will a message pop up informing that the chest is locked an unable to be opened?
To handle these, you would need to define values that correspond to each
position in the grid representing the state which exists there. So if that chest
is on grid space (2,3), you'd need to set a value to that space which more or
less says, "Player cant move here if he/she tries." How this is done is through
using 2D arrays.
Arrays are adequate because they can easily hold a a lot of information and are
number based, just like a grid is. Using 2D arrays (arrays containing arrays)
give us a way to contain information about the whole grid in one variable, being
able to reference any value for each grid position with the coordinates of that
position. This functions much in the same way the loops did earlier in making a
grid, only this isn't generating a grid, but rather holding information about
it. In fact, the loops will be what are used to extract this information.
Here's an example of a 2D array for
collisions in a 5x5 grid system:
The odd formatting helps to
visualize how the spaces will correspond on the screen making it look more like
an isometric grid. After all, here, the array going across left to right
actually represents the y and up and down is the x, which itself seems
counter-intuitive, though this makes it work more intuitively when we actually
work through arrays like this with loops, especially when using the Cartesian
plane method of y navigation.
When this array is translated to the
screen with the 1's representing points of barriers or impassible objects, you
get something like this, where the red represents the impassible tiles:
For a collision array such as this
one, you don't need to loop through it value by value when you need to check to
see if a space is a valid grid space for movement or not. All you need to do is
check the array position that relates to the grid square at the x, y coordinate
you need to check using
collisions[x][y];
If that value is true, or 1, then
there would be a collision in that grid space making a move there invalid. If
the value there is 0 (false), then there is no collision and moving to that grid
location is acceptable. When it comes down to it, you'll actually be checking
for the 0 value, not necessarily the 1. This being the case, you might want to
actually replace the 1's with 0's and vise versa, though as I see it, 1's
function better visually as being impassible and 0's seem more like floor tiles.
Of course you could just as well use 4's and 7's, and at times, may need to if
dealing with flat walls, but I don't think Ill get around to covering that; not
here, not today.
Dynamic Grid Creation
Often grid spaces are created dynamically. This is done through loops (as
previously seen with the text fields in a normal grid), looping through
attaching a squares or 'tiles' as it progresses through the grid layout of the
scene. An advantage of this is that it allows an easy way to associate a unique
grid position with each tile. Once a tile is attached, it can be told where it
was attached so if you'd want to use that grid as a button, for instance, it
would know exactly where it is when you clicked on it.
For example:
What this does is attaches a
movieclip linked from the library with the linkage ID "tile" (a single isometric
square) to the current movieclip and positions it using the formulas described
earlier so its... isometric. On top of positioning it, the clip is given x and y
variables which equal the grid x and y position which it occupies. Then an
onRelease method is set so that when the clip is pressed, it traces its grid
location. Instead of a trace, this could be used in other ways such as a command
to tell a movie clip to move to the position clicked.
|