Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
September 2, 2014
arrowPress Releases
September 2, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Developing a game on Adobe Air for iOS.
by Svyatoslav Cherkasov on 02/20/12 06:32:00 am   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


In this article I want to share my experience in developing a dynamic game for iPhone using Flash and Adobe Air platform. But first of all, please sorry me for my English. That’s not my native language.

So, what is Air? Saying in a pair of words it is a platform that makes available to run flash applications on different devices – iOS, Android, Blackberry, even TVs. Beginning developing in Air I didn’t know anything about it. But that’s not a problem because in 95% Air application is similar to an ordinary Flash application.

So, my team and I decided to take our chance in making a game for iPhone. There was no objective to earn money. The first and main objective was to make an experiment and to find out if it is possible to make smooth dynamic games on Air for iOS.

Game idea.

We wanted to make our game as soon as possible, so we wanted some gameplay that:

  1. Would be simple, so we can make our game fast.
  2. Wouldn’t need many animated and moving objects because we was not sure it can be done smooth on iOS.
  3. Would use not common and cloned for 10 times gameplay.
  4. Wouldn’t need to make 100 different puzzle levels because we didn’t want to spend our time on that.

Also, we didn’t want to invent our own gameplay (and also didn’t have time for that), so we decided to clone some game.

After a few days of search we found our victim – game "Axe in Face".

Let the develop begin!

So, we started to work…

Developing on Air was easy. It is a regular Flash development with some minor modifications (in most cases in some device-specific functionality such as multi-touch, accelerometer, etc.)

So, let’s put flash develop apart and focus on iOS-specific troubles and hints.


That’s the main theme. All is about the performance when you’re developing something for a mobile phone. We wanted our game to look like native ones. To make smooth effects similar to other iPhone games. So, we’ve tried different technics and made our best to achieve it.

But, I need to say, that was not possible for everything.

So, we tried different graphics engines to put our sprites…

1. Flash engine, bitmap frames.

First of all, of course, no vector! Vector is very slow. You need to work with bitmaps only.

The first thing we tried was a simple flash movieclip with bitmap in frames.

Surprisingly it worked not so bad, but we wanted more…

2. Bitmap blitting.

Next thing we tried was bitmap blitting. This is a common method for desktop flash games. The idea is to make one bitmapData and to copy all your sprites into it, one by one. And after all show it on the screen.

This method works great on desktops but failed on iOS. It seems that memory operations are quite slow for now.

3. Advanced flash engine.

After some research I found out how to improve graphics performance and why standard flash engine didn’t work well. The idea is that if you want to animate your sprites fast, you need to store all graphics in memory.

When using standard flash engine it takes every new frame to memory every time it needs. So, every frame flash engine disposes old graphics and creates new, for new frame.

But all graphics is re-usable, so there’s no need to dispose it after usage.

First what we did is we loaded all our graphics data in a vector of bitmapData – each frame in its own bitmapData. Then we made Bitmap objects from each of frames and put all of them in our sprite MovieClip. So, sprite contained all its frames in the same time in one single frame. The next we needed to do is to switch visible property for them and to show only one frame a time.

The idea was that all graphics was available at once, and used frames were not killed after showing. So, no creating new graphics and no disposing used.

That worked well but could be improved.

The next improvement stage was that we made a single Bitmap object and just swapped bitmapData field for it. Something like: main_bmp.bitmapData = bd_frame[i].

That worked fine. It made possible to show 20-30 animated sprites on iPhone 4 (retina) at 40 fps.

That was enough for our needs.

Some performance hints:

  1. Use as less dynamically-created objects as possible.
  2. Use as less mouse-interacted objects as possible. Use mouseEnabled and mouseChildren to turn interaction off.
  3. Avoid moving large objects. Especially with alpha.
  4. Use cacheAsBitmap for everything is not animated and not rotated.
  5. Use cacheAsBitmapMatrix for everything else that is not animated, but need to be rotated or changed alpha.
  6. Don’t make plenty of ENTER_FRAME listeners. Make just one.
  7. Always count time in your ENTER_FRAME listener. So, if you’re moving an object by X pixels every frame, make a calculations on the elapsed time from the last listener call.

Platform-specific troubles.

Retina vs lo-res.

How our application behave on different screen resolutions? It’s simple. It scales (but you make to change scene scale mode, of course).

That’s good for developing for iPhone 3/3GS and 4/4S. You just make a retina application and it automatically scales down on iPhone 3.

Of course, you can “read” the scene scale and show different graphics depending on what scale is it, but that seems to be quite tricky, so we left everything by default.

iPhone vs iPad.

Here is the same thing as with retina. Application scales. But in this case the scale factor will not be nice, so you need to make some custom code and custom graphics for iPad games.

That’s why we left our application iPhone-only. Maybe, we’ll make HD version for iPads some time later.


You can compile your Air application to use CPU or GPU for graphics. Using our graphic engine there was not great difference (it was about 10%).

But we’ve chosen CPU because when you compile under GPU you get some limitations. For example, effects don’t work. That mean that all text outlines and shadows wouldn’t be shown. The solution was to make an empty bitmap data object, draw a movie clip there and then put it on the stage. That works because when you use “draw” method, it uses software engine anyway and support of all effects presents.

But that also seemed very tricky and gave no advantage, so we left us at CPU mode.

Some other problems.

Adobe Air is a universal platform. That means that if you need to access some device-specific functionality like GameCenter, you need to install additional “native extensions”. That needs some tweaking building process, but after you find out what is what – everything is quite easy.

Also, the new versions of Air ignore the mute switch on the phone. So, we needed to use an extra native extension for that.

Also, we’ve developed all our game on PC. But on the last step we found out that we need a Mac anyway. The reason is that uploading an application to app store is only possible with an Application Loader software which is only available for Mac OS 10.6.8 and later.

The conclusion.

To write on Flash Air or not to write? I think “yes”. To write.

Of course, there are some troubles and bottlenecks in performance. But Adobe is working on it and promises lots of improvements in near future. Speaking of dynamic games – that’s hard to make one that runs completely smooth on iPhone 4 with retina for now. But iPad 2 and iPhone 4S are much better.

So, we’re looking forward on Adobe and hope that Air will be a real platform for game development.

The result.





(c) 2012 GameJam

Related Jobs

Playtika Santa Monica
Playtika Santa Monica — Santa Monica, California, United States

Sr. BI Developer — Hunt Valley, Maryland, United States

Engineering Manager — Chicago, Illinois, United States

Engineering Manager — Hunt Valley, Maryland, United States

Graphics Software Engineer


Alexander Jhin
profile image
Thanks for the great article! I'm surprised more Flash Devs don't try cross compiling onto iPhone air, especially given the recent so called CopyCat fiascos. A game like Triple Town (with no real time gameplay) could relatively easily have been ported to iPhone using Air.

Mahesh Manni
profile image
So, is Adobe Air is a good choice to develop games for ios devices?

Barna Biro
profile image
I suggest trying out Stage3D or Starling ( in case you don't want to bother with Stage3D directly too much ). Although you said you tried CPU vs GPU rendering by configuring the app to in theory use GPU graphics, I am quite sure you were not using Stage3D and "real GPU rendering" ( please correct me if I'm wrong ).

Your team is surely composed of a bunch of competent people, but somehow I never tend to believe such performance comparisons without seeing the actual code beneath the game... sometimes people "think" they are optimizing things, but in fact they are not. Not saying it's surely the case here too, but just because you tried bitmap blitting and a few other things, doesn't really mean that your team correctly optimized things...

Since you said this was an experiment and you didn't want to make any money, is it possible to share sources maybe so that others just starting out with Air and iOS development can learn form your experience? ( surely you don't need to supply the actual graphics, but some people would surely want to take a peak at your code and optimizations ).


Barna Biro
profile image
Ohh, sorry, I have just clicked the first link and saw you are selling it for 0.99 on iTunes... Forget about the sources thing. I see people complaining about the game crashing on the first level. Any fixes planned?