Development Diary – Micro Robot Maze #1

In my last game development post I wrote a little bit about the generalized
game engine that I am fashioning
in Flex AS3.  I was stuck as to exactly how to proceed after
posting that entry. I spent a few days going over the code I had
written and thought of scenarios where it wouldn’t work, etc, but got
to a point where I needed to test it in a real-world situation. So,
since I have a load of unfinished games, and even more unfinished basic
tile sheets that I have created, I decided to make a relatively small
game (re-using some existing IP)  and in doing so, flesh out
the game engine.

I had to first decide what game to make. I wanted to make a puzzle game
because I haven’t made one in a long time. I started thumbing through
some of the books in my game development library and came across the
mention of a game I remember from the early early Mac days – Daleks.
When the Mac first appeared, it didn’t have too many good games. I
didn’t own one back in the 80’s, but they were all over our schools
here in the USA. I think I played an Asteroids clone, a version of
Accolade Hard Ball, and a game called Daleks. I didn’t know anything
about the game then (my apologies if my geek cred goes out the window)
 because I had never seen the Dr. Who show on PBS and was not
keen on the show’s terminology. The game was basically pretty simple.
You played Dr. Who on a large tile-based grid. On the grid along with
Dr. Who were a number of “Daleks”. The Daleks were robots that would
chase Dr. Who to a fault. They were relentless even to the extreme of
running into one another an creating a pile of junk on the screen where
they used to be. The game play was pretty basic. The player moved Dr.
Who up down left or right jumping one tile at a time. Once Dr. Who had
moved, the robots would get there moves. They basically closed in on
Dr. Who and tried to land on the tile he was occupying. If
at any time Dr. Who shared the same tile as a robot, the game
was over. In his defense, Dr. Who had a sonic screwdriver that could be
used to destroy all robots in adjacent squares. We also had a limited
number of teleports available to him. The game basically went on until
Dr. Who was killed and then the player had to start over.   The
Complexity Workshop site has a
really nice set of information on the game and a playable Java version.

Daleks from the http://www.koobifora.com/daleks
site (not the same as the ComplexityWorkshop version)

Armed with my limited knowledge of this game, I decided to use it as
the basis for a puzzle game called Micro Robot Maze. I called it Micro
because it will be a small game, not meant to knock anyones socks off,
but meant to be easily completed in a couple weeks (before Christmas).
  I decided to keep the robots, but place the game in more of
a maze like play field rather  than an open set of tiles. In
my version you will always enter the screen on the right, and the goal
is to exit the screen on the left through a door. Each tile-base level
will be constructed with some wall tiles to provide a puzzle-like
atmosphere for the game play. The robots will still chase the main
character (to a fault) and the player must avoid them,. The player will
be able to use strategy in an attempt to have the robots bump into the
walls or each other. If more than one robot occupies a single square,
they will be destroyed and turn into a pile of glowing material. That
glowing material will replenish the mega bombs (like Daleks sonic screw
drivers) and a teleporting orb that the main character can use to fend
off the robots.  If the robots run into a wall, the player can
collect power cell that is dropped. If the player collects enough power
cells, he/she will gain an extra hero to use in the game.  
There will also be a time clock count down. If the player can complete
the level before time runs out, he/she will be awarded bonus points.

I didn’t want to design all new Sprites for the game, so I dug into
some older pixel art that I had created for a game (a Berzerk-
like  adventure game) that I never completed (two years
ago!!!). I plan to complete that game as the follow up to Micro Robot
Maze as an extension of the engine I create this time around. That game
was never finished because I got stuck on the AI and never got back
into it. All of the sprites for the older game were developed directly
in Flash 8, so I had to save each frame out as a jpg and then open them
up in Gimp Shop. I then combined all of the frames for each into a new,
separate tile sheet and saved them out. At first, I had a little
trouble getting Gimp to save of PNG files with a transparent
background. The trick was to make sure to specify that you want the
background included in the export (that is the default). I had click
off that check box because I figured by NOT saving out the background I
would get transparent sprites. The opposite was true.

Here are the player sprites for left, right, up, and down:

Here are the robot sprites for left, right, up, and down (the robots
are meant to have tank-like tracks that move)

The robots also have a “Cylon” like eye that moves from left to right
when they are moving down.

I also needed to create a basic grid for the game to be played on. I
decided on a 12×12 grid that would give me 384×384 game screen. This
will fix nicely on my 400×400 chosen screen with a little space at the
top (and right) for score and some other basic messaging.  

That was as far as I got with the specifics of the game. I next dove
into my generalized game engine. Instead of simply trying to think up
all of the classes that I will need in a generalized form, I took a
hint from Squize,
and decided to start at the beginning. I first created the most simple
of title screens and a button to click. You will see that unlike Squize’s
beautifully detailed opener,
mine is as bare as can be for now.

The “Go” button is my ultra basic attempt to re-create a Flash tween
will a tile sheet.

After all of this, there was little free time left this weekend to
working on the game engine. Was able to knock out a couple hours
in-between family visits, Christmas shopping, house clean-up and
baby/toddler care to add:
1. a com.8bitrocket.game.GameControl Interface that all game controls
(specific logic for an individual game) will implement. Currently I
have only two methods that must be implemented by any GameControl:
init() and run().

2. a com.8bitrocket.game.Screen Interface that all game screens must
implement. Currently I have only these methods that must be
implemented: init(), run(), show(), hide().

Those both are just at the beginning, so I will need to flesh them out
much more as needed. One of my big problems right now
is figuring out just how generic I want the code to be.
Certainly all games will have a title screen, so do I create
a standard ScreenTitle class that implements Screen but can be used for
any game, or do I create a unique one for each game. I’m not sure and I
guess that probably depends on how much control I give to the
GameControl and how much I give to the View, etc.

I need to put some time into it thought that is for sure. I am happy to
have a simple game to make, it certainly is helping me get moving on
the engine.