AIR Post Mortem – Pros and Cons of Flash Dev – Part 1 of 3


This is a write-up of our (Monster and Monster’s) two Flash/AIR projects so far. We’ve learned a lot by completing these projects and we’re feeling so badass about it that it’s put us in a mood to share.

This article is mostly written from my POV (Dan – the techy one) but Dave has agreed to add his tuppence where he feels it’s appropriate [ Which I'm getting all editor like by adding comments like this – Dave ]. As a result this post is going to be mostly code-y and technical.

I’ll start with some generalities that will probably answer most questions right off the bat and then I’ll get down to the specific projects which both panned-out rather differently.

Tools, Frameworks Etc.

As you probably know, both Zombies and Winter Walk are AIR apps. AIR is essentially just a wrapper for Flash content. What you have, more-or-less is a file that looks to all intents and purposes like a native executable, but hidden inside is a SWF file, exactly like the ones you’d normally embed in a web page.

AIR apps get a bit more functionality than SWF files because the AIR wrapper provides access to some of the target platform’s native functionality.

The primary tools we used in development of both apps were:

  • Flash Professional CS5.5 (which is the first version to support the iOS packager) – generally referred to as the Flash IDE
  • FlashDevelop – I upgraded to the latest stable version just before embarking on Zombies version 2 so I could use the AIR 3 templates – FlashDevelop is the most amazingly awesome thing – once I finally got it set up so I could build from FlashDevelop rather than the Flash IDE I actually fell back in love with game coding
  • A bunch of arty programs that Dave used – mostly he supplied me with either bitmap files or FLA (Flash IDE) files so I don’t know exactly what he used or how he works his magic [ For ZHP:DX and Winter Walk I mostly used Photoshop CS5 along with a little bit of Illustrator CS5.Something or other - Dave ]
  • PxTone, Audition, Reaper and Audacity for sound and music

In terms of frameworks etc. I used my own (very simple) framework that I’ve been building up for years. It was originally designed to supply some common functions for game development (menu screen handling, pop-ups, preloading, game loops, local save data and similar) and to provide a consistent way of working around some of Flash’s quirks, eventually I added support to simplify the process of building multiple versions of a SWF file for the various web arcade sites that have their own APIs for scoring, achievements, in-game ads etc. (MindJolt, Kongregate, Mochi).

Pros and Cons of Flash / AIR Development


  • Not quite ‘one click, deploy anywhere’ but damn close
  • The Flash IDE is one of the best animation environments around – once the animator has created the animation it appears ‘as-is’ in the game engine with no messing around with exporters and convoluted workflows – you can even give the animator your in-development FLA file and let him delve in and tweak as he sees fit
  • Flash’s animation support is perfect for creating slick and responsive menu screens and HUDs – I would love to see a Flash layer added to other game creating frameworks such as Unity!
  • Very easy to create a web demo or ad-supported version of your game and release it virally on the internet in addition to your mobile versions
  • The Flash community has created a lot of free tools, libraries and engines. Finding help, tutorials and example code is dead easy
  • With the right approach and level of experience Flash is a true Rapid Application Development tool (see the Winter Walk section!)


  • Flash’s renderer is s-l-o-o-o-o-o-o-o-w… It’s easy to understand why the vector renderer is slow – I think, in fact, the vector renderer must be incredibly well optimised, it’s just the nature of vector renderers to struggle with large numbers of moving objects. For mobile game purposes most of your assets are going to be bitmaps or at least cached vector objects (i.e. the vector is rendered to an off-screen bitmap first). However, the bitmap renderer is also, rather unaccountably, very, very slow
  • ActionScript 3 is slow (at least compared to languages such as C/C++). To be fair, ActionScript is essentially a scripting language and with that in mind it’s blisteringly fast. From a game programmers point of view though you’re going to want to keep it simple. In most cases you’ll find that the core renderer is so slow that code execution time is hardly ever a factor anyway
  • ActionScript 3 can prove difficult to learn. It throws-off hardcore programmers by looking a bit like C++ but then acting completely differently and it confuses designers with ActionScript 2 skills because suddenly they need a computer science degree to make head or tail of it
  • Sound engine is appalling. It’s kind of shocking that a ‘multimedia’ platform could overlook sound. If you’ve never worked in Flash before you will be genuinely shocked how bad the sound support is – even things that are ostensibly supported (such as detecting when a sound has stopped) don’t work properly. Any realtime sound processing is likely to be so processor intensive that you won’t be able to run game logic/rendering at the same time. Anyway, this is why we didn’t do anything too complicated in Zombies or Winter Walk sound-wise.
  • The Flash IDE sucks for compiling large projects. It takes forever, compiles every class, even the ones that haven’t changed since the last build and I’m pretty sure there’s a resource leak in the compiler that means for big projects you keep running out of memory which requires a reboot to fix – my advice is don’t compile in the IDE. Ever.
  • I mentioned that the AIR runtime supports some functionality of the native platform. AIR does more than just build to mobile platforms, you can also create Windows and Mac executables with it, and they too get native platform support – it’s actually a very powerful system. The problem is AIR has been designed to work as seamlessly as possible across all these platforms, which means the core API can only really support the common functionality. This limits access to a lot of iPhone and Android specific features. A big one for us was that we couldn’t get to the Apple GameCentre. You also have the problem that you can’t use OS specific pop-ups and menu features so your app will never look properly ‘native’. On the plus side you could put your game on Steam as well with Windows and Mac versions released simultaneously! Note: I’m kind of ignoring the new AIR feature called ‘Native Extensions’ for now in this discussion since I haven’t used them in a real project yet – I have evaluated Milkman Games extensions for GameCenter and In-App Purchasing and will be using them in our next project (Deep Loot)
  • If you plan to use the Flash IDE it is expensive!
  • Flash is quirky as Hell! I’ve worked with it for 8 years now and it still throws me the odd curve-ball and when that happens it can cost you DAYS of work – not to mention sanity!
  • Flash is dead… …Hahahahaha only fooling!

Ok, so the cons list is pretty damn long. Don’t let that put you off if you’re considering doing a Flash/AIR project though. I still love working in Flash!

Check out part 2 where we discuss Zombies Hate Pumpkins DX.