Developing Efficient Adboe AIR (Flash) Games for iOS or “The Secrets behind Hungry Choo-Choo”

Actually – I’ve already told you the first secret behind Hungry Choo-Choo: it was built using Adobe Flash.

It was around February 2011 when Lee Brimelow came to Israel and opened our eyes to the possibility of developing to iOS with Adobe Flash. He warned us about performance issues, but we love Flash so much that we had to accept the challenge.

We held a brainstorming meeting in which we decided to go for a small project – two or three weeks – to test the technology and make our first entry in Apple’s App Store.

In practice – the project went so well that we decided to extend it to 4 months (part-time), and we came up with Hungry Choo-Choo (http://www.hungrychoochoo.com), a smooth action game which feels like a native iOS app, with beautiful MultiTouch behaviour. Nobody believes it’s Flash.

Hungry Choo-Choo wasn’t that efficient in the first runs, but we used our experience in code optimization, and we just made it fly. It worked great even when we still used version 2.5 of the Adobe AIR Packager for iPhone, which was significantly slower. During the development of the game, Adobe released version 2.6, which seems to have improvements in performance.

So now, having this coding experience in my resume, I am glad to share some of the main optimization secrets that I used in Hungry Choo-Choo.

1)     Bitmaps beat Vectors:

Vector Graphics are good to keep app size small and development process comfy, but they consume lots of device resources, since they work like recipes for creating bitmaps, while bitmaps are ready-made for drawing on the display. Choo-Choo was graphically designed in Flash, and though it could be very easy to use the Vector MovieClips as is, we had to export them as bitmaps, and then reimport and place them. Quite a hassle, mainly for porting to various screen resolutions, but the results worth it.

Leave aside some texts and transparent objects, 95% of the pixels in the game are from raster bitmap images.

2)     Preload Images and use sprite sheets for Animations:

Loading image files, even when embedded in the SWF, is an expensive process. So when the app starts, we load all the images which take part in the game to the RAM.

[added July 12] Forgot to mention important issue we had to deal with. By default, the image data is read only when the image is first used. This process may cost in a delay of animation, if you call a large image while you’re doing animations. The way I solved it was to copy a small rectangle of the pixels from the image to some unused bitmap. I did this to the images when the app is loaded, and that way I force them to read the image data. But later I found out that there’s a property called imageDecodingPolicy to the LoaderContext object of the Loader. This can be set to ImageDecodingPolicy.ON_LOAD and will solve the issue.

Another challenge was dealing with animations. Flash developers are usually accustomed to working with frames and tweens, but these are also slow, and you will surely notice it when you develop for iPhone. The best solution is blitting, or sprite sheets: this is a technique where you export all the frames into one big raster image, load it in advance, and while in action, copy the relevant pixels to the screen.

Lee Brimelow has posted a very nice video about this technique: http://www.gotoandlearn.com/play.php?id=140

3)     Don’t Smooth:

Bitmap smoothing, which can be controlled in the Flash IDE and in AS3, uses an image processing algorithm that requires some CPU. Having cancelled this option almost anywhere in Choo-Choo improved the game’s performance. This may of course cause image distortion, so we kept all images in their original scale and rotation, except some minor cases – for example, when food items grow or shrink, but these happen so fast, that nobody could notice the change. Only one image is smoothed in Choo-Choo:  the hint arrow that shows the swipe direction. This image can be rotated freely and is not moving fast, so we had no choice.

4)     Nothing’s New:

Avoid instanciating new items during animation as much as possible. In Choo-Choo I used the AS3 new command only on app startup. Well, to be honest, I do create new Event Items and cheap objects, but the main graphic and game objects are created only once, and then reused. Only 7 food item objects exist in the game, and they are used over and over again.

5)     Keep Your Stage Clean:

When making a Flash app for the web, I usually don’t care too much about addChild() and removeChild(), as long as I can see the objects I want where I want them. But those objects that are hidden in lower layers or live outside the boundaries of the stage may still require processing power – either for rendering or handling display list events. So in Choo-Choo, everything is in control. I kept track of every object and every pixel, frame by frame, and made sure that all unnecessary objects are removed as soon as they are no longer needed.

Another important issue is removing event listeners which are not in use. Again, in normal Flash apps we sometime forget to stop listening to buttons when they disappear, and that’s okay when your machine is powerful – but in this case, when developing for iPhone, I kept removing every single event listener that’s no longer relevant.

6)     One Frame Handler, No Timers:

I used only one listener to the ENTER_FRAME event. This listener calls a single update() function, which calls other update() functions, which may call some others, in a tree flow pattern.
I once read somewhere that having many ENTER_FRAME listeners is bad for performance, and I’ve been using this technique ever since, though I have no proof it really helps.

Another piece of advice I got (also has never been proven as far as I know), is to avoid AS3 Timer objects. I don’t use them, and if I need something to work in time intervals, I manage my own time-by-frames counters in the update() functions that I’ve just mentioned.

Having those practices utilized, I gave myself a nice playground for lots of action, and I could easily manipulate many objects on the screen without the fear of reaching low frame rates.

Naturally, I followed all the classic C++ optimization rules (like keeping whatever possible outside of the loop), but in general, most things you do in AS3 which are not related to the graphics have quite a small influence on the game’s performance. There are around 500 lines of code that run on every frame, with about 200 if statements and 30 for loops, and they all pass like a ghost.

Bottom line, clear and simple, is that Flash is a great tool for iPhone development. And if Adobe keep up the efforts they’re making in this direction, it may even break in and become a standard and a leading platform for developing Mobile apps.

Watch Hungry Choo-Choo In Game Trailer

Tomer Reiss, KWAZI.