Thanks! We spent a lot of time to make this one as good as possible.
One gotcha with Flash is the default frame rate is 24 - if you turned that to 60, and bounced a ball around the screen, it should have been reasonably smooth. The smoothing property of an object turns on antialising which helps as you get subpixel movement, which helps too. Also, something about final graphics makes you just not notice as much - alpha blended edges definitely help.
I don't do anything really special. I wrote my own set of libraries, and they're just simple boilerplate that you'd expect. Rendering as in bitblt inside Actionscript would be way too slow, and the Flash render is actually reasonably good at throwing up untransformed images.
Some tips for speed:
* Composite the hell out of everything. Our background is just one 800x600 image, but it looks like there's a lot of variation because it is composited out of different layers (background scenery, large lighting sprite, tiles, decals on top of tiles, free rotated static lights and the walls sprite). You could do all of those as free sprites if you had a 3D renderer (Robokill would chew through maybe 1/40th the juice of my 8800 GTS), but it would absolutely kill the performance of the Flash renderer (and reasonably so - a single x86 core simply does not have the throughput).
* Untransformed images are very, very fast compared to transformed. If you must rotate and scale something, try to make that transform a constant and use the cacheAsBitmap property, which will mean Flash will render it to a cache bitmap making it a simple blit.
A concrete example of this is all of our particles are animated images, which blit untransformed to the game. It works out to about 10x faster than what would be possible if we did rotation/transform on them in real time.
* You can use additive to make stuff look cool with little overhead (the additive formula for pixel blending should be faster than the alpha formula, but who knows with Flash). That's the blend mode that gives you the fire and plasma glow look.
* ActionScript is slow, too, but there are almost always game specific hacks to get the desired performance out of it. Use lazy computation where possible. My enemies use real time pathfinding, because all I do is trace outwards from the player each frame, then reset that when the player changes square. Doing a per enemy pathfind, even using an optimised system such as A star (damn markup), would have been pretty much out of the question.
* Don't forget that you get more of your budget back when the action goes away. You may have noticed the additive lights and idle animations that fade in when the action dies down in a room. It doesn't matter that they're expesnive to render, because they're only there when the enemies (which are more so) are not, but I think they really help the look of the game. Also, our intro just goes over the top using lights like this, since they're the only thing being rendered.
Basically, Adobe Livedocs, and trial and error. Although from a rendering perspective just knowing the theory behind it (write code to just rotate an image without concern for quality and it's instantly clear that it'll always be slow) gives you pretty much everything you need to know - it's just connect the dots from there.
Also, Flex Builder is a bit of a dud, but its profiler is very good. If you can afford it, it will give you very good insight into your code bottlenecks, if the $$ is worth it just for that. I use FlashDevelop to edit in still.
P.S. Sorry if I'm hating on Flash a bit too much throughout my posts. There were a few trivial bugs with serious implications that directly delayed our release, so I'm still quite annoyed. I'm back into Flash for the next project, though, because customers are more important than development comfort!
Thanks for the great information. One quick question... when you say you're "back to Flash" for your next project, are you talking about moving back to Flash (as opposed to Flex) as your dev tool/programming paradigm or did you stray from the Flash engine entirely?
Oops, I should have said Flex. I meant it in the 'oh well, back to the grind' sense. :)
All of our titles have been Flex so far and it will stay that way for a long time yet, I imagine. We started Stunt Pilot in the Flash IDE but it quickly became apparent that it was a really ineffective development environment for what we were doing. Flex has its problems, but at least the core model is more appropriate (i.e. entirely source code, command line compiler).
One gotcha with Flash is the default frame rate is 24 - if you turned that to 60, and bounced a ball around the screen, it should have been reasonably smooth. The smoothing property of an object turns on antialising which helps as you get subpixel movement, which helps too. Also, something about final graphics makes you just not notice as much - alpha blended edges definitely help.
I don't do anything really special. I wrote my own set of libraries, and they're just simple boilerplate that you'd expect. Rendering as in bitblt inside Actionscript would be way too slow, and the Flash render is actually reasonably good at throwing up untransformed images.
Some tips for speed:
* Composite the hell out of everything. Our background is just one 800x600 image, but it looks like there's a lot of variation because it is composited out of different layers (background scenery, large lighting sprite, tiles, decals on top of tiles, free rotated static lights and the walls sprite). You could do all of those as free sprites if you had a 3D renderer (Robokill would chew through maybe 1/40th the juice of my 8800 GTS), but it would absolutely kill the performance of the Flash renderer (and reasonably so - a single x86 core simply does not have the throughput).
* Untransformed images are very, very fast compared to transformed. If you must rotate and scale something, try to make that transform a constant and use the cacheAsBitmap property, which will mean Flash will render it to a cache bitmap making it a simple blit.
A concrete example of this is all of our particles are animated images, which blit untransformed to the game. It works out to about 10x faster than what would be possible if we did rotation/transform on them in real time.
* You can use additive to make stuff look cool with little overhead (the additive formula for pixel blending should be faster than the alpha formula, but who knows with Flash). That's the blend mode that gives you the fire and plasma glow look.
* ActionScript is slow, too, but there are almost always game specific hacks to get the desired performance out of it. Use lazy computation where possible. My enemies use real time pathfinding, because all I do is trace outwards from the player each frame, then reset that when the player changes square. Doing a per enemy pathfind, even using an optimised system such as A star (damn markup), would have been pretty much out of the question.
* Don't forget that you get more of your budget back when the action goes away. You may have noticed the additive lights and idle animations that fade in when the action dies down in a room. It doesn't matter that they're expesnive to render, because they're only there when the enemies (which are more so) are not, but I think they really help the look of the game. Also, our intro just goes over the top using lights like this, since they're the only thing being rendered.