During the last month or so, whenever I could spare an hour, I’ve been working on a port of my game, Gridshock HD, from Adobe AIR to Ansca Corona so that I could release it for iPad. If you’re not aware, Corona is a mobile development platform that can target iOS and Android. It was created by some folks who were once involved with Flash Lite, so it’s quite relevant to Flash developers. It’s not perfect, but there are a few useful features that Corona offers and AIR is missing. I want to use my experiences to make some requests that I hope Adobe will address in upcoming versions of AIR.

Language

I, and I think many Flash developers who have been around for a while, kind of miss dynamic languages. I often hear that Flash isn’t as “fun” as it used to be. I can relate. It would be great if we could use something less strict than ActionScript 3 in our Flash projects. Yes, I know I can turn off strict mode, but if I’m going to use ECMAScript, I want AS3’s dialect to be updated with features that have been added since ES4 was dropped by the committee. There’s some cool stuff coming in Harmony.

Corona includes Lua, which is my new favorite language of the moment. It’s super flexible and a lot of fun to work with. If there were a way to compile it down to bytecode that could run in Flash, I’d consider switching to Lua over ActionScript 3 for much of the Flash content I create. AS3 is good for Flex apps, but for games, web experiences, and stuff like that, a dynamic language like Lua (or modern ECMAScript) would be more fun for me, and enjoying my work is a top priority.

For reference, this is a minor need compared to the ones that follow. I can live with AS3 for all my Flash development. It’s a decent language, but I simply desire a little more choice. If you look at JVM or other runtimes, they all have extra languages beyond the main one(s). I want to branch out more, and it would be awesome if I could keep a foundation in Flash.

Graphics

Corona offers OpenGL-accelerated graphics. I had no rendering performance bottlenecks, and it was a dream. However, we all know that AIR will be getting Molehill hardware-accelerated APIs in an upcoming release. Corona has the advantage now, but it may not be for long.

Libraries

Corona includes out-of-the-box support for OpenFeint and Game Center. These services are considered a requirement by many mobile gamers these days, and they’re sorely missed in mobile AIR game development.

Developers simply need a way to run native code with AIR. There are compelling third-party services that only provide native libraries, and we can’t use them if we want to develop with AIR. Even worse, many are unlikely to be added to the runtime, so without native libraries, we’ll never be able to use them. In addition to game leaderboards and achievements, I know many would like to access things like in-app advertising and custom hardware or accessories. Moreover, being able to use native libraries will help us avoid rewriting existing libraries that are already working well in a native form. It expands the reach of AIR and saves time and headache. Native code would be a major win, for sure.

Runtime

Everything you need for Corona is included in the output. There’s no separate runtime. I suppose it’s similar to how AIR app work on iOS. Developers like me want to include the AIR runtime with Android apps too. I strongly dislike requiring my users to install a runtime before they can play my games. It’s an extra potential point of failure, and it feels somehow unprofessional as a potential source of annoyance for the user. While you’re at it, allow me to include the runtime on Windows, Mac, and Linux as well.

The age when separate app runtimes were a valid choice for targeting consumers is gone. I know games are a big focus for Adobe right now. Flash Player is a huge target for casual games. I’d love to use AIR to release commercial desktop games that are more polished, bigger, and better than my free web games. However, asking potentially-inexperienced users to install or update AIR is a big reason for why I’m not exploring AIR on desktop for games. Adobe has probably done the best it can to make the install experience painless, but I just can’t get over being wary.

As for updating AIR, let’s be honest. The latest version of AIR doesn’t get installed as quickly as Flash Player. I’ve never heard Adobe talk about stats for AIR runtime installs. Given how often Adobe presentations include the graph with Flash Player installs, I refuse to believe that they wouldn’t be sharing AIR install graphs too… unless they’re just not impressive. Let me package in the runtime, and I’ll never need to worry about the AIR runtime version. I’ve heard that a ton of Java apps package in the Java runtime now for similar reasons, and I’m sure that’s way bigger than AIR, so let’s get with the times.

Mobile is still a new frontier, and closer to the casual experience on the web, so I’m tolerating a separate runtime on Android, but my feelings are much the same as with the desktop runtime.

A Tight Race

In a follow-up post, I take a look at a few things that I don’t like about Corona. Yes, the coin flips both ways. Corona has some advantages that made it an obvious choice for my iPad game… today. However, AIR is not that far behind Corona in this particular race. In some ways, AIR is much further ahead. To put it simply, I was willing to make some trade-offs in development comfort to get the features I wanted. I didn’t like that, but I sucked it up and only grumbled to myself.

I know both technologies will be improving over time, but I think that Corona is going to need to fight harder to stay on top in the situations where it holds my interest right now. So far, I’m only interested in Corona for iOS support. That’s a precarious place to be when there are a variety of pros and cons on both sides.