The obvious first question is, Why did I choose Corona? The project — a fairly simple game for a major high-street brand, which hasn't gone live as of the time of writing and which I therefore cannot name, so well call it Basket Bash for now — needed to be developed for both iOS and Android in a short time frame (or at least, that was the original intention. Our deadlines have a habit of slipping…). There was also going to be a certain amount of design iteration along the way (meaning that we didn't actually know what we were making when we started. Again, standard operating procedure). After wasting some time trying to put together a simple 2D GL engine of our own, I gave up and started looking for something a little higher level. Cocos2D was considered, since there is now an Android port, but this would mean writing two versions of the game, one in Objective-C and the other in Java. What we really needed was a write-once solution, and this is what Corona ultimately offered us.
So would I recommend Corona? With certain reservations: yes. Much as I enjoy writing code just for the satisfaction and challenge of it, there's a lot also to be said for simply making stuff, and occasionally limiting or inelegant as it is, Corona generally gets out of your way and lets you concentrate on doing just that. The development language is Lua, which if you've never used before you'll find is simple, easy to pick up, and does just about everything you need it to do with a minimum of fuss.
My main reservation in recommending Corona — probably because I was bitten by it only very near the end of development and so the memory is still painfully raw — is Android device support. As of a few months ago, Corona does not support Android devices running ARMv6 CPUs. As of only a few weeks ago, this was not mentioned anywhere obvious in the documentation, such as alongside the Android v2.2 requirement. Since ARMv6 phones include the HTC Wildfire S, apparently the cheap handset de jour which I'm seeing advertised just about everywhere at the moment, this could be a problem. (I'll admit that I share the fault for not discovering this earlier. When builds wouldn't install on our test Wildfire, I put it down to a combination of un-optimised assets and my inexperience with Android. If I'd taken the time and dug deeper I would have found this enforced limitation — which at that stage would probably have lead us to abandon Corona, although for what alternative I have no idea.)
My other reservations probably come from the way the Lua runtime is implemented. Lua has a rich library of code available to it, but Corona will not work with any of the many binary libs. In our case, this lead to us having to abandon interfacing with a web service using AES encryption. In general, you are restricted to whichever advance features the development team have included and exposed. This includes OpenFeint, Flurry, and an older version of the Facebook Connect library. For Twitter or Facebook using OAuth you'll have to roll your own solution (unless I decide to share mine…). There is support for a selection of native widgets, although this is naturally less fully-featured than that available through the native SDKs. I have yet to attempt to use Corona to build an app with a native UI look and feel.
Be warned that debugging can be a nightmare. The SDK comes with its own simulator, which simulates the differing screen sizes of iPhone, iPhone 4, iPad and half a dozen Android devices. (You'll probably find that supporting different screen sizes is the biggest challenge in cross-platform development. Corona is pretty helpful here, if you're willing to cede a certain amount of control. It offers a number of content scaling modes and supports automatically loading assets based on the scale factor between an arbitrary content size of your choosing and the actual screen size of the device. This is basically the iOS-style @2x, only far more flexible, allowing you to specify many different asset sizes.) The simulator provides console output and a debugger. It cannot, however, run native UI widgets such as web views. For these you will have to build the project for either the iOS simulator or a handset. Which is where things get complicated. I've been unable to get console output from any of these devices. You think debugging with
printf() statements is fun? Try debugging with pop-up alerts.Builds are carried out on the Corona servers, meaning you need an internet connection at all times. For Android that's all you need (saving access to the SDK later to allow you to create a distribution key pair), but for iOS you'll need Xcode 3 installed. A paid subscription is technically only required to build App Store or Market versions of the final app, but I'd probably recommend getting it as soon as you've decide to commit to Corona, since it also gives you access to the daily builds, which in my case fixed a few compilation problems I came across.
In general, I think Corona is a great system for doing a certain subset of cross-platform development. It has the enormous potential to allow you to quickly assemble and test projects and deploy them for both iOS and Android. It's probably not a good fit for apps — as opposed to games — although I say this more out of the opinion that native apps should be built with native SDKs, rather than any kind of hard-won experience. If you are aware of Corona's limitations and manage expectations accordingly, you should find using it to be an incredibly productive experience.
No comments:
Post a Comment