Essential Flash Games Book Chapter 12: A Viral Game In A Day

I know a lot of people do it, but I have never really been a “game in a day”
kind of guy. With my day job, kids to play with, books to write, games to
review, etc, I usually don’t have the time to devote enough hours in a single
day to make a 24 hour game…until yesterday. Actually it was a 24 hour span
from Tuesday Noon until Wednesday Noon. I needed a game for the final chapter of
the Essential Flash Games book, but it couldn’t be too complicated. The final
chapter is on viral games. It begins by discussing how to take all of the code
created in the first 11 chapters and organize it into a re-usable framework and
package structure. Next it takes the structure and creates a simple game using
it. Finally, we add in both a Flex SDK pre-loader and an Flash IDE pre-loader,
as well as Mochi ads and leader boards.  On Monday, everything was complete
but the game, and I was under the gun to get something new coded FAST. Since the
chapter is on viral games, and most likely those games are completed at a very
rapid pace  (a couple days maybe), my production time and schedule would simply
mirror the production time that a viral game developer might employ. This would
also give me an interesting angle for the chapter copy.

[Tunnel Panic In Action]

I chose a 24 hour period so I could authentically write about how to create a
small, quick viral game.  The game I created will not win any awards for
originality. It is called “Tunnel Panic”. The Tunnel Panic portion of the
chapter is going to be written in more of a narrative, story-style form that
describes what a 24 hour game development cycle is like and  how using a
pre-existing framework, package, and template structure can aid in rapid game
development. The game is one of those “fly through a tunnel and dodge
everything” type of games. Your ship is always moving forward and gravity is
always pulling it down toward the bottom of the screen. The player only needs to
press the space-bar to thrust up. There are no other controls. The game lasts
for roughly 60 seconds, but it will not be going into the Mochi 60 second game
competition because it doesn’t have any chance of winning.

To finish in 24 hours (only about 8 of them were spent on the actual game), I
had to limit the game-play and cut a lot of corners. I am no artist anyway, but
the graphics in Tunnel Panic are even simpler than my normal routine 8-bit fare.

The scrolling is created by simply moving a pool of obstacles from right to
left at a rapid pace. The player’s ship is a vector shape drawn into a simple
Sprite that stays in the middle of the screen  (horizontally) all of the time (moving up and
down). The obstacles are simple Sprites with a single pixel BitmapData object
inside each. The Bitmap holder for the BitmapData object is scaled to the width and height
needed for the object  and setPixel32 is used to change the color as
needed – the obstacle colors change as the game gets progressively more difficult. This gives is a little bit of and Atari 2600 feel.

The exhaust for the ship is created as pool of particles that blit to a
separate canvas (used solely for them). They blit from an array of alpha faded
BitmapData objects that is pre-created at the init time for the game. The
collision detection is simple “hitTestObject” (and it shows). I did this because
the scaling of the Bitmapdata inside the obstacles made Bitmapdata.hitTest
impossible. The music and single sound effect (there is only one) were pulled from the pre-existing
library of music and sounds that we have created over years.

The Flex SDK pre-loader was a stretch. It uses the Flash Develop model which
works great, but requires a compiler directive to fake the Main class starting
in frame 2. It’s quite a little trick that I didn’t know about until a couple
days ago. The Flash IDE pre-loader is a three frame model with the library assets
not exported in the first frame, and an asset holder on frame 2. The Main class
pre-loads the movie on frame 1, then plays the play-head passed frame 2 (the
assets from the library are there) and stops on frame 3.  In this IDE version, the
pre-loader is a STATE that can occur after the Mochi ad, but before the 
title screen STATE.  It is needed even if the Mochi ad preloader is turned on because it acts as the actual asset library instantiator and not just as a pre-loader. This is not needed in the Flex SDK version so the pre-loader process is optional if Mochi ads are turned on in that version.

The flex version requires the preloader class to take place
of the “document” class that was originally the “Main” class. This model requires
Main to no longer be the “always compile” class, but instead be added to the
display list of the Preloader shell class at run time in a “fake” frame 2. In
any case, each version still produces a single game output swf file. Aside from
handling assets embedded at compile-time, this was one of the few real
differences I found throughout the entire 12 chapters where the IDE and Flex SDK
are concerned. The code and structure of the pre-loader needed to be completely
different to support the two different application development models.

So, chapter 12 will be complete in a few days, and then it is back to the
re-writes and “what the hell were we thinking” changes that go into re-reading
something from 6 months ago. I already found a problem with the Pause function
created in chapter 11 and have to re-write that one ASAP.