Essential Flash Games Book, Chapter 11 – An Optimized Scrolling Blaster

Essential Flash Games Book, Chapter 11 – An Optimized Scrolling Blaster

Chapter 11 is by far the longest chapter in the book so far and will probably remain so. There is only one more chapter and Steve and I want to keep that one under 40 pages. It was due yesterday and took much longer than I thought it would to write this one up. I spent about a week making the game, Blaster Mines, a Geometry Wars style blasting contest. I decided to use the mouse for control and in the middle of development downloaded the latest Flash 10 players for XP and Windows 7. To my horror, the mouse would not work while the game played at a high frame rate (it had worked fine on all of the previous player versions on all systems). This had to do with a bug in the Flash player when updateAfterEvent is turned on while using the Sleep-based Active Render Timer. The timer skips rendering on frames to keep a constant frame rate, but on older systems it seems to also omit some mouse movement detection. The first thing I did was remove the updateAfterEvent from the timer, which worked fine, but the game looked a little choppy at high frame rates. The problem was solved by lowering the frame rate to 30. At that frame rate, the updateAfterEvent would work also.


Blaster Mines In Action

I wasn’t satisfied though, so I added a render profiler to what I call the AdvancedTimer class. This timer profiles the player’s system before the game runs and picks a suitable frame rate that will hopefully run the game with mouse control intact. I did this because I wanted the game to be able to take advantage of newer systems that can sustain higher frame rates, and also very old systems that cannot. This set me back about a week as I played with multiple different timers and profilers, but was never satisfied with any game timer other than the Sleep-based Active Render Timer.

The book covers this subject by offering 2 alternative timers (neither quite as speedy), and also the profiler and AdvancedTimer. The best bet for all games that use the mouse and require a lot of moving objects is to lower the frame rate (to about 30) and turn off the updateAfterEvent. But, if you like to push the envelope, the profiler will help you do so. The profiler uses a new FrameTimer class that also displays the current memory pages in use (a little like a baby version of ActiveGraph). This allows the game developer to see if all of the garbage collection is happening properly and to test for more than just the standard Flash player memory leaks. When combined with the AdvancedTimer, the FrameTimer will also display the current frame rate relative to the maximum profiled frame rate. This is key to testing whether render hiccups are caused by giant pages of memory being re-collected.

The game is a pretty standard Geometry Wars / Asteroids scrolling blaster. The game world is set on an 800×800 BitmapData canvas. A scrollRect of 400 x 400 is used to display the viewable area of the scrolling game world. Every in-game object is a vector drawn shape that is drawn into a BitmapData and then rotated or faded with a Matrix transformation to create arrays of BitmapData animations. The vectors for rotational movement are stored in a look-up table, and many memory and processor saving hints are thrown in for good measure. I cover object pooling, event reuse, “pools of one”, and much more. The pool size for particles and the number of particles per explosion can be set be dynamically based on the profiled frame rate. This way users on better systems can get more ZarJaz out of the game. There is a lot more in this chapter such as a new object hierarchy for objects blitted from arrays, and a library class that creates those rotational arrays of blitted objects and alpha fade-outs. This chapter also covers small things such as adding a universal pause and mute functionality to the frame work. All of the classes and explanation necessary came out in just under 80 MS Word pages. I have no idea how many that will be in the book. I assume more.

We have one more to go, and then it is re-writes and “what the fuck were we thinking back then” questions as we re-read and revise the whole thing multiple times for release.

Should be fun…

If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.

Leave a Reply

Your email address will not be published. Required fields are marked *