Flex Game Development: When a blank screen equals success
The is part 2 of my series on designing a generalized game control in Flex.
The control is actually in AS3, and will have no MXML, so it can easily be
modified to work in the Flash IDE as well as Flex. I'm not even using Flex
Builder, but an entirely free environment centered around Flash
Develop (donate
to them).
So, when exactly does a blank screen equal success? I'll get to that soon
(you can skip ahead if the wait is killing you). First, if you are unfamiliar
with what I am doing, you can check out part 1
of this series from early December. That is one clue as to why a blank screen
equals success – it has been over a month since I have posted about this game
control. During that month I have had numerous time wasters get in the way of me
working on this control and the game that goes with it as a test (Micro
Robot Maze) – The holidays, my day job, Xbox 360 (now with Netflix), Guitar
Hero World Tour, World Of Goo on the Wii, family, and now a GAPING HOLE in the
ceiling of my kitchen that will keep us in a Hotel for the next two weeks (at
least) while a crew comes in a assess then fixes the damage done by a broken
water pipe!!!
With all of that going on, I have found a few minutes here and there to
continue on my quest to create generalized game control. When we left off on
part one, I was trying to decide what parts (if any) of the Model View
Controller pattern to utilize in my game control. Well as it turns out, "none"
was the answer. Well, that is a little misleading, I haven't thrown out the MVC
pattern altogether, but I decided to concentrate of the render part of the game
control and forego the object model decisions a little while longer.
The renderer, you ask, well, Jeff, now we're talking, enough about your
fooking plumbing problems, get on with the show. Ok, yes, the renderer is part
of a package called com.bitrocket8.display. The bitrocket8 was one of the
reasons a blank screen is a success, so if you are keeping score at home (and
please, no wagering, keep it family oriented) it took me at least 3 hours to
figure out that you can't have a number at at the beginning of your package name
nodes, so "8bitrocket" was changed to "bitrocket8".
So, how does the "renderer" work so far? It isn't completely finished, but
what follows is the general structure. It is based around my own use of Flex by
which all graphics will come from PNG files (for the most part) and not from
embedded swfs created in he IDE. For that reason, I started the basic structure
of the display package with a tilesheet.
The Display Package Structure
Keep in mind that this is still far from even being a beta, and most of
the code and ideas are still swimming in my noggin next to Xbox 360 game demos
and water logged kitchen cabinets.
The Tilesheet class holds the definition for a single set of tiles.
It could be used for a 1024×1024 image housing a set of 32×32 tiles for every
character in a game, but for the most part I decided to have it represent a
subset of the tiles needed for a single character's unique animation. For
instance, I plan to have a tile sheet definition for the main character's walk
left animation be a separate png file from the right animation and thus, a
separate TileSheet instance.
This class holds a reference to a BitmapData object, the width and height of
the sheet and the width and height of each tile. That's basically it.
The BlitObject is the second from the bottom in the display object
hierarchy. It is passed a reference to a tile sheet and contains
information on what the start and end frames of the animation (if any) are and
what the delay if between the frames when animating. It also contains both a
Rectangle and a Point instance for for copy pixels operations. It start and end
frames are important if the passed in tile sheet represents more than one sprite
or more than one state or movement of a sprite.
The BlitContainer is the third object in the hierarchy and it represents a
real game object of some type. It would be a sprite type if I was using that
sort of naming. It isn't exactly the same as a sprite though. Besides containing
actual display information like x,y,dx.dy (center versions of each) and hit
testing offsets, it also holds an array of BlitObjects in is own internal
display list. This is just an arrays with my own access methods and NOT a Flash
Display List. The layers in this array turned on and off and have transparency.
So, a BlitContainer is basically a state machine of the look and feel for a game
object. The need for this came from the Pumpkin Man and Jack's Beach Blitz
engines. The player's look changes state a lot in those games and the code in my
Player object was a complete joke by the time the gamse were complete. To combat
that I decided to make a state machine for look and feel of a sprite built-in.
The Final class in the Display Structure is the BlitCanvas. The
BlitCanvas contains an actual Bitmap object and a BitmapData object to blit to.
The Bitmap object is added to the Display List of the output swf. This
BlitCanvas also holds and array of BlitContainers, but unlike the container
which is supposed to represent a single display object the same size as a single
tile in the tilesheet, the BlitCanvas is meant to be a game play or other screen
that can hold 100's or 1000's of object to blit in it's own array (much like a
display list).
Those are the 4 main classes. Along with those, I started to create something
called the BlitButtonCanvas. This class actually extends a real Sprite
and is used for displaying a button on the screen with multiple states
(up/down/over, etc). Unlike a normal sprite though, this object holds the
BlitContiners, BlitObjects and TileSheet references for blitting rather
than using the Sprite's Display List.
Why a Blank Screen Equals Success
All five of the above classes, plus a main loop, and a TitleScreen
class (the VIEW if you feel like MVCing this) were written in 3 separate
sessions of about 4 hours each without testing out any of the code. I never once
hit F5 to build it, but spend most of my time thinking and refining my ideas.
This resulted in 1033 lines of completely untested AS3. The first time I hit
Build, I got the above package naming error (8bitrocket in not a good package
node name). I then spent about 3 hours repeatedly building and fixing every type
of error you can imagine. When it was finally compile error free I started to
get run time errors for things in Flex that I have never experienced before. Did
you know that png files that are embedded in code are NOT an instance of
BitmapData like their cousins that are Emdedded ina Flash library? That are
actually a BitmapAsset, which is a subclass of the Bitmap class? I didn't,
anyway, but I will never forget now.
Anyway, after hours of this kind of stuff, I finally hit Build, and got
no run-time errors, but I GOT A BLANK SCREEN. My images were not showing on my
title screen, but at least there were no errors. Just then, water started to
pour out of a light fixture in our kitchen and I ran from the computer to see
the source of my wife's screams. No more code would be written on this one
today, but after all of that at least I don't have any more compile-time errors
or runtime exceptions. There are some logic errors in my code that are
preventing the screens from showing, but those (hopefully) will be easy to fix.
The kitchen ceiling will NOT be easy to fix. After finding the water main shut
off (look for yours now if you don't know where it is), calling "experts",
mopping up water, and trying to find a place to stay for the next week (maybe
two), I never got back to fixing my code. So, for today at least, I will
have to consider a nice, peaceful blank screen with no errors or warnings, and
absolutely no water damage a overwhelming success (or at least a moderate one)