Building A Generalized Flex Game Control Part 3

In part
1, I discussed and mused over
what parts of the MVC pattern (if any) to implement in my Flex game
control.

In part
2, I dug down into my thoughts
on the rendering engine and how I was unable to get anything displayed
on the screen before the pipes burst at my house and I was forced to
continue writing this from a Hotel (now still).

In this 3rd part I have finally made some progress that I am proud of.
I’m not ready to show the code yet, but some tutorials are in the works
on most of the parts of the engine. This part will explain some
refinements I have made and discuss the current, over all vision for
the engine. My hope is that I can use the same concepts in a
Silverlight, Java, Objective C or XNA game engine without too many
changes (other than the actual rendering code and message models).

(ugly static JPG of my limited success so far)

The Overall Game Engine
The game engine so far is made up of three parts.

1. The Main Class. This  is a little like the MVC Controller
class. It contains a simple, elegant game loop state machine based on
the Squize
idea – Instead of constantly looping through a case statement to set run the current state, just run the case statement one time when state
is changed. The case statement will swap out just the function
reference that is called on every frame tick. 

The Main class contains the game loop timer. It is built just like this
one, around the concept pf
active rendering with a sleep based timer to keep frame rates
constant between browsers and players.. 

2. The Model Class. The Model class contains access methods for all
loaded in XML data. This can be for levels, game settings, etc.

3. The Screen class. I struggled with how to do a VIEW properly and
came up with an abstract class called screen. After looking at the
similarities between all of the games I have created over the years,
the concept of screens kept coming back into the fold. Every distinct
game play state (in my games at least) almost universally had a certain
number of unique and shared elements that made up a visual output of
some sort – or a screen.

The screens (currently) have 3 basic states: Transition In, Main
Display, and Transition Out.

The first screen I have created is a very very simple title screen. The
title screen contains two simple elements – A background container with
the game title, and a “Go” button with three states: Off, Over, and
Click.

Because I wanted to be able to render all of my images from PNG files,
I created a set of 4 classes that could service this screen, and
subsequently (hopefully) almost every other screens.

The TileSheet class: The class contains the reference to a Bitmap that
contains one or more tiles.

The BlitObject class: Takes a Tilesheet as a parameter and contains
information about the frames that make up a static blit or animated
blit based on the TileSheet.

The BlitContainer Class: Contains an internal display list of layers of
BlitObjects. This services things like buttons (the three states above)
and also game objects that have layers of display for look and feel.

The BlitCanvas Class: This class extends sprite and is used to house
and display layers of BlitContainers. For instance, this could be used
as a single layer to blit all game objects to: made up of layers of
BlitContainers; or it could be used for a single game object – say you
want a player object to be made up of tiles from a tile sheet, but also
want to make use of the handy Sprite functions like rotation. This
Canvas can be used for both cases – a blit sprite that doesn’t make use of the Sprite Class and also for a real AS3 Sprite..

The BlitCanvas class contains an internal Bitmap object and an
associated BitmapData object for display. Since it’s a Sprite, I was
able to create a click able button with 3 states very easily.

The [GO] button is simply a BlitCanvas with a single BlitContainer
inside. The BlitContainer has three BlitObjects, one representing each
of the off,over,and click states of a button. I just turn these layers
on and off when mouse events are captured by the BlitCanvas (because it’s a Sprite, it can do this).

Anyway, that is a quick run-down of my progress so far. I hope to have
some clean working code and classed to share shortly.