Development Diary – Micro Robot Maze #2

A few weeks back I started to make my Generalized Flex Game engine built around blitting and a
modified Model View Controller / State Machine structure. I needed a reference application to build on top of the engine, so I chose to make a version of the classic
Daleks game.

A couple days ago I wrote about my progress with the game engine. I think I
have most of the bugs ironed out of the 4 main classes used for display, but I
am waiting for the reference app to be complete so I can test it out. I did
post the code for the TileSheet class, but I am holding off of any more code
posts until the game is complete. So, in lieu of more posts on the game engine,
I will be posting my about my progress with the reference application. In case
you are interested, I am going to spend a good deal of time porting the
reference app to other game development languages and systems in an attempt to
learn each (if possible).   It doesn’t hurt to be well rounded
now-a-days.

Micro Retro Robot Maze
Unfortunately, there isn’t a whole
lot to show right now. There is a basic title screen and when the game play
starts, the user can click on any square directly adjacent (up,down,right,or
left, no diagonals yet) to the green hero to move him to that square. This won’t
impress anyone, but I will go into the code and design of the system because it
is more complicated (maybe exceedingly so) than it first appears.

http://downloads/blog/2009_micro_robot_maze/Microrobotmaze_v1.swf

The GridButton Class
Each of the 144 grid squares is an
instance of my GridButton class. The GridButton is a class specific to this
game, but it inherits from the com.bitrocket8.game.AnimatedBlitButton. This is a
BlitCanvas child that allows the developer to assign different TileSheets,
BlitObjects, and BlitContainers to the states of a button. Hence, when the mouse
rolls over, out, and is clicked on a grid square, the square changes in
appearance.  You can read more about the basics of my

display classes here if you are interested. Since the BlitCanvas is a
child of the the Flash Sprite class, it can dispatch button events and use the
nifty hand-cursor.  There should be no way for the user to tell that this
is not simply a 12×12 cell grid of GotoAndStop MovieClips, rather than the set
of 144 BlitCanvas instances using a tile sheet for state look changes.

The grid button instances use this tile sheet for their states:

Custom IDEvent
The game is controlled by one of my VIEW
state classes called ScreenGamePlay. This is a class that controls the look and
actions needed for the actual game to run.  Because there are 144 squares,
all with the ability to be clicked, I created a custom event that fires off when
any is clicked called an IDEvent. This event passes the ID of the square back to
the event listener method. The ScreenGamePlay listens for this event and then
checks to see if the square is a valid move for the player.

When the GridButton instances are created, they are all given an _id value that
represents the col_row (x_y to be specific) as a string. When a GridButton is clicked, I check to see
if the move is valid (meaning in a square adjacent to the player). If it is, I check to see what the next col and row will be
for the user. Once that is complete I set the _moving variable of my GridButton
to true and set a dx and dy value. With _moving set to true, on the next frame
tick the update() method of the GridButton (called through an update
event) will apply dx and dy to the nextx and
nexty values of the player. If there was to be collision detection, it would
then be checked using the nextx and nexty values. When the render event fires, the GridButtons set x and y to
be the nextx and nexty respectively and the player sprite is moved accordingly.

The player sprite will then continue to move (and animate) until it reaches the
the next square and stop. Once stopped, it goes back into toe tapping stopped
mode.

The Player class
Just like the GridButtons, the Player class
is derived from my BlitCanvas class. That means it is an actual Sprite that must
be added to the display list (just like grid squares). I did this for simplicity.
The player could have been blitted to a blit layer, but I wanted to test out
creating a BlitCanvas that moved and animated. I will be creating a FX layer to
overlay the grid and player Sprites. This FX layer will be a full blit layer.
This will simply be  a BlitCanvas class instance that is the size of the entire play screen.
It will be used for blitting explosions and particles, etc. 

The player’s look and feel is made up of this set of tiles:

The final two are the STOPPED state where the player waits and taps his foot
while the user decides what his next move will be.

The next steps in the game
I have created a preliminary
tile sheet for the walls, the power-ups and the goal for each level. These are
pretty simple, and are about the best I can do with my limited technical drawing
skill (and time):

The first three tiles are for placement only. I will use Mappy for level
creation and the red squares will represent open, walkable tiles for the player
and the robots. The player tile is used by the level designer (me) to designate the
starting spot for the player in a level. The robot tile is used to place the
starting spots for the robots. The blue walls will be used to add non walkable
tales to the grid. The final 5 tiles of row 4 are the goal tiles for each level. The goal is a little animated  tile that the user must get to to finish each
level. Finally, the final yellow/orange tile is a power-up. It gives the user
one bomb and one teleport.

Well, that’s what I have so far. Tomorrow I am back to doing a Flash Game
Development Interweb Mash-Up, and hopefully the weekend will afford me some time
to work on this game engine some more.