Unity vs Adobe Air, or As I wrote the first mobile game


Today I would like to talk about the first experience of writing a game for mobile devices. I'm a flasher by profession, and making games, although simple, is not new to me. However, mobile development is different and is fraught with a lot of unknown.


How did it all start? That's right, like many interesting and not so stories, with dismissal from work. Time was free, and it was simply necessary to occupy oneself. Since Flash has not been very popular recently, it was decided to try Adobe Air and its cross-platform.


Paradoxically, I am not a big fan of playing games, with the exception of "racing" and "something simple and funny." Naturally, the first idea was something like "an exciting race-trip on an SUV." Then, inspired by a game like Color Zen , I wanted something “interesting, beautiful and soothing.”

But, as they say, the 8-bit past took up and it was decided to make a parody of the recently deleted and hated by many Flappy Bird. Not a trivial parody, no, it was decided to let users let off steam - create a new character who would blow everything to hell with her grandmother. The name was found quickly - Rocket Toads, and there were two main characters (to make the name of the game in tune with the famous 8-bit game). The goal of the game was chosen - to destroy as many pipes as possible, just throwing dynamite, and at the same time stay alive, dodging fragments and explosions.


Characters, background and basic elements of the game were drawn quickly, because no high design bars. As, in fact, in the game on which the parody was made.


Background and main menu

The following were selected as the engines:

- Starling (rendering graphics using the GPU)
- Nape (the fastest physics engine)

If I didn’t worry about Starling and its speed, then the speed of rendering physics was worrying - it was planned that there would be up to 30 40 objects - fragments from blown pipes. I was also worried about the speed of execution of the ActionScript code, in particular, the algorithm for breaking a pipe into fragments.

First tests

When the main part of the game was ready, the long-awaited moment of testing on a real device came.
Samsung came into the hands with one processor at 1000 MHz and the Andreno 200 graphics accelerator. In general, by its low characteristics, this is what is needed for tests.

The game started perfectly, the hero joyfully flew through the pipes, and the FPS stayed around 60! But I didn’t have to rejoice for long, after some time I tried to spool dynamite, and the game began to slow down very much, precisely at the moments of pipe rupture into fragments and with a large number of physical objects, which I was afraid of.

The next few days, setting physical. the engine and code optimization have failed. The profiler (Adobe Scout) explicitly indicated that the speed of execution of ActionScript code is a stumbling block.

ANE, Unity2d and Haxe

Mourning Adobe Air, I went and buried it in my garden and began to look for alternatives. As promising options for improving performance have surfaced:

  • ANE - Native Extensions for Adobe Air
  • Haxe + Haxe version of Nape
  • Unity3d with built-in Box2d as a physical. engine

According to the first option, nothing really was found, because there wasn’t found that “good man” who would make a full-fledged two-dimensional physics engine on ANE.

The second and third options were good and it was decided to do physical tests to evaluate the performance.
As a result, Unity won, and if memory serves, with a similar FPS, the results are approximately the following:

  • Adobe Air + Nape - 50 Dice
  • Haxe + Haxe Nape - 70-80 cubes
  • Unity - 300 Dice

Unity2d - rewrite the game again

Mastering Unity was relatively easy. Switching from ActionScript to C # turned out to be easier than you saw at the beginning. The Unity editor was also a pleasure. Among the lessons I would advise:

- Creating a 2D game with Unity
- Fundamentals of creating a 2D character in Unity 3D 4.3
- Official video tutorials The

large community of Unity developers was also pleased, thanks to which there is a normal answer to almost any question that arises.

Testing again

Well, the first test results were encouraging - there were no strong brakes, and I began to confidently finish the game to the end. Subsequently, some interesting bugs were found that slowed down the game:

- “The first explosion” - the first execution of the script that destroys the pipe was about 300 ms, subsequent calls up to 20 times faster. I had to make the first explosion automatic outside the camera (outside the user's eyes), while the player was still clicking the menu.

- “Tightness” - since some parts from blown pipes remain static, and some turn into dynamic fragments, there are times when dynamic fragments are sandwiched between static ones and generate a lot of collisions and provoke “brakes”. I had to make a counter, which, with a certain number of collisions in a static fragment, turns it into a dynamic one, and the clamps are eliminated.


  1. The game is ready and even posted on Google Play. The speed of work on medium and advanced devices inspires optimism.
  2. Gained experience with the wonderful Unity engine.
  3. Unity vs Adobe Air - friendship won. Using my game as an example, of course, Unity was out of competition, and I would recommend it for the performance-critical code and physics of mobile games. However, it is not perfect either - for example, Unity WebPlayer and its periodic crashes, mouse button malfunctioning in Chrome, the editor freezing upon closing, impossibility of fast and high-quality publishing in Flash and some other things. Also, judging by the rendering speed, Unity loses Adobe Air + Starling in some places . So, if you decide to write a less demanding game and publish it for Android, IOS or a Flash player, Adobe Air + Starling will be a good solution.

Also popular now: