I Recently completed and deployed Magic Slots, a mobile game for iOS and Android platforms. Following is a mini post-mortem of this mobile project that was made with AIR using Starling and ANE. While having plenty of mileage with AIR, I had very little prior experience with Starling. I did experiment with starling for a while, but never before used it in a commercial project.
A couple of months ago I needed to create a pitch for a mobile game for a client. We laid out our options: native, PhoneGap or AIR. As it often happens, the client needs to see a working prototype on both iPhone and Android within days just as a proof that the said technology is actually viable.
Next I pulled the Starling code from github and compiled their demo app on an iPhone device. We needed a set of UI components to work with starling – I found Feathers and pulled the code as well (back then it was still called ‘foxhole’). Based on one of the Feathers demo apps, I created a quick skeleton project with a game menu and a placeholder for the game.
Since we had similar elements in an existing Facebook project (AS3 with Flash assets), all I had to do is rip and repack assets into texture sheets. As always, TexturePacker proved to be the right tool for that task. Five days later we had a working demo written entirely in AS3 using Starling, Feathers and TweenMax. In about half an hour it was deployed to an iPhone4 and a Nexus S phone. Seeing the prototype actually running on these two devices, looking almost identical made a big impact on the client and the project was green-lit.
Both Starling and Feathers where changing daily, which posed a challenge. However, the community and forums proved useful in solving all the critical problems I encountered, or at least working around them. This provided me with a sense of confidence, which is not a trivial matter with a new framework.
In the following 4 weeks, the actual game was built by a small team (an artist and 2 programmers). We managed to locate ANEs for all the services we wanted to use: Chartboost, Flurry, In-app purchases for Apple and Google stores. Integrating them into the app was a matter of a few days – this went surprisingly smooth.
We had our share of problems, mainly adjusting to different screen sizes and fitting our asset into limited RAM and texture memory, but with frequent tests on the devices we managed to create a stable build that run in close to 60 fps.
Five weeks into the project we submitted the binary to the app store for review. A week later the Android build was published on the Google Play store – mission accomplished.
Starling is, at its core, is an abstraction layer on top of Stage3D, the Flash interface for OpenGL (or OpenGL ES in mobile devices). In the past I use to do plenty of OpenGL work – and low level OpenGL isn’t exactly a friendly environment for trivial UI coding in the way that Flash is. You could, for example, spend days trying to make alpha blending look right.
As far as 2D frameworks go, Startling is the closest you can get to traditional display list code. This makes for a very quick learning – the replacement classes (such as Startling’s Sprite, DisplayObject, or Image) works exactly as you would expect. This is also one of the weak points – it inherits some of the bad interfaces of the original classes (like MovieClip) and could cause unexpected compile errors since you are not sure if you are in in the ‘flash.display’ or starling.display’ namespace.
As you would in the flash display list, complex compositions are handled the same way – place a sprite or image on top of another with some alpha and your’e done. Transparency and alpha blending work the same way, and they even have some of the blend modes implemented.
It’s so convenient that you can sometimes forget you are working with a GPU, and some restrictions need to be accounted for. First and foremost is texture memory – it is a fixed resource in mobile devices and can crash your app without a warning, if not carefully managed. The TextuteAtlas class does a great job of handling texture sheets through a simple, clean interface.
In summary, Starling proved to be solid and reliable – a real time saver when you need it.
Any game needs some UI components. In this case I used the Feathers component library for the minimal UI in the game. While simple enough to use, I found some of the setup overly complex and the dependency in themes is restricting, making skinning a non trivial task. However, once I figured out how to customize the themes, it was a breeze to use.
The features I ended up using the most where scrollRect and scaled images. Scroll rect works the same as it did on the flash display list, only uses the UV coordinates for a fast and efficient implementation of smooth scrolling. Scaled images provide an extremely easy way to to 3-slice and 9-slice on textures, which is essential when you need to scale elements for multiple screen sizes with a single set of assets.
On some cases, I opted for the simpler Starling classes – for instance I prefer the Starling button and avoided the Feathers button that is a bit over complicated. Overall, Feathers is great – its a solid library and has decent support and frequent updates.
Air Native Extension (ANEs) have been around for a while, but are now becoming an integral part of any mobile AIR project. It’s safe to say that AIR would not be the platform it is now without the addition of ANEs.
These days you can find ANEs for almost anything: ad services, analytics, social APIs, or some native hardware access. To use them effectively, it’s important to choose the right ones – often you can find free, open source and paid extensions for the same thing, with varying quality.
When you drop the ANE into your project, you’d want it to work in ‘default’ mode (ADL debugger) without errors and the binary should be compatible with the latest OS (in my case, iOS 6 and Android 4.2) otherwise your app will break. For that reason, I prefer to have a developer supporting the ANE, answering questions and fixing bugs so my project will not be delayed.
AIR based projects are definitely on the rise this year, featuring some of the chart-toppers on the app stores, for both iOS and Android. No doubt it proved itself as the leading cross platform solution for mobile games. It also reached a point of maturity where knowledge that was build over the last 5-10 years in the Flash platform comes into play – the tools, workflows and techniques give developers a huge leverage.
For a developer like myself, the bottom line is I can get stuff done better and faster.
A lot had happened in the last few months: AIR 3.5 was released (with 3.6 in beta), followed by Flash Builder 4.7 and most recently a bunch of 3rd party open source libraries (including Starling and Feathers) were packaged together by Adobe under the moniker of ‘Adobe Gaming SDK’. We can only hope this trend will keep on in the future and bring more focus to the AIR platform.