New AIR game - Saturate: A bullet-storm survival shooter

Question

Hi all,
I've been working for over a year on game with a publisher (not this game!), and it is still many months away from release.  In the meantime I was anxious to get something released to the public in the short term, so two weeks ago I started Saturate: A bullet-storm survival shooter as a tribute game to one of my fav PC games, Mono by Binary Zoo.  Written in AIR 13 for iOS, Android and Facebook (iOS under review, and FB coming in a few days), with IAP for those who don't want to earn credits the hard way . I'll update the links as the other platform versions become available:
Available for Android right now!
Pixelthis website
Pixelthis Facebook page
Saturate is a Geometry Wars style two-stick single-screen bullet-storm survival shooter.  There are lots of control schemes to try (and more coming).  Keep in mind that this was a 2-week 'get it out there' marathon, so there are still plenty of features in the pipes (like highscore tables, sharing screenshots to FB and setting them as your wallpaper/bg, different game modes).
The aim of the game is to saturate the screen with color.  Your score is the % of the screen that you fill when you die (and you will die).  The enemies are R, G and B, and they splat the screen with color when they explode.  There are some cool power-ups, and tons of weapons to collect. The sound track is pretty awesome too.
Some background: Pixelthis just turned 10 years old a few days ago, so we've been around the block!  We started with Flash 4 and then Flash Lite 1.1 (way back when) on Nokia and Sony-Ericsson phones.  Saturate is developed using AIR, using our proprietary games platform.  The core of the system is a rasteriser that turns vector graphics to bitmap at runtime (including filters) so that we can run in GPU mode with very good performance, and a callback-based event and tweening system for very fast game loop, animations and messaging.  Saturate uses Milkmangames ANEs for StoreKit and Android IAB, and GoViral for social integration. 
The biggest challenges in development were (1) counting pixels to determine % of screen filled so that it didn't impact negatively on performance, and (2) tracking down and elliminating memory allocations during the game loop.  There are still some optimisations to do, but I think it went pretty well!  Unfortunately it runs a bit too slow on iPad1 when teh action hots up, so that device has been elliminated.  A bug in Adobe AIR that has not been addresed yet also prevents facebook from working on iOS5.1.
Enjoy!
Peter

Answer 1

Thanks lars. Appreciated.
I can't post actual code of the libraries (because it is our 10yrs worth of IP and it's what allows us to make games that run well accross devcies etc) but i can share the basic principles etc!
This is what some example code looks like for making a 'RasterSprite':
// Import the assets from a swc library that contains graphics.
// These are movieclips with a graphic on each frame
import assets.CharacterAssets;
import assets.UIAssets;
// Initialise the rasteriser just once when the game is started, with a ref to stage
Rasteriser.init( stage );
// Rasterise the graphics (this technique is synchronous/blocking) but
// there is another process that is for larger amounts of graphics.
// First we set the 'scale'. This determines how big to rip the graphics so that they
// are always the correct size for the screen/device they are running on.
Rasteriser.scale = scaleOfGame;
Rasteriser.rip( CharacterAssets );
Rasteriser.rip( UIAssets );
// At this point, each frame is 'ripped' to a bitmapData that is cached in a vector
// When we need to create a RasterSprite, we use the following technique, which
// grabs one from a static object pool within RasterSprite:
var character : RasterSprite = RasterSprite.create( 'CharacterAssets', 12, 15 ); // frames 12 to 15
character.gotoAndStop(3); // This would be frame 14 of the CharacterAssets clip
addChild( character );
var titleGraphic : RasterSprite = RasterSprite.create( 'UIAssets', 7 );
addChild( title );
// When we don't need them anymore:
character.recycle(); // Removes from display list and places back in object pool
character = null;
title.recycle();
title = null;
The Rasteriser is a static class that handles ripping the graphics and caching them.
The RasterSprite is a Sprite that contains a Bitmap.  The bitmapData is one from the Rasterisers cache.
The Rasteriser rips any graphics to a bitmapData at any scale, including any transformations, color transforms, filters etc. Everything maintains the correct scale (e.g. if you rip a graphic at scale 5.3, then the filters are also scaled by 5.3).  This is the magic that both allows the games to run on any resolution screen, and also allows the game to use GPU mode while effectively maintaining filters.
This is the basic process for ripping the vector-based graphics to bitmapData.
here we assume that the clip (if it is a movieClip) is 'stopped' on the frame you want to rip:
1) Step through each filter and scale it's properties to the desired scale
2) Add the clip to a container sprite (We rip the container. This is what preserves the clips transformation, alpha etc.  If we rip the clip directly all that stuff is ignored).
3) Find the 'bounds' of the graphics within the container INCLUDING filters.  This is important because if a graphics are 100px wide, the content is not always from x=0 to x=100. It may from x=-26 to x=74.
4) Create a new BitmapData the correct size (of bounds)
5) Create a matrix to offset the content so that it IS at 0,0
6) Use BitmapData.drawWithQuality to draw the container to the BitmapData
7) Create a bitmap with that bitmapData, and offset the bitmap to counter-act step 5 and place graphics back at correct spot
8) Optionally, scale all teh filters back again so that the original clip is not affected
9) Remove the clip from the temporary container
Anything specific you'd like to know?