Monthly Archives: May 2011

Adventures with Corona, Part 2: Where Corona Needs Improvement

In my first look at Ansca’s Corona SDK, I mentioned several features that Corona offers where Adobe AIR is currently lacking. These were compelling enough for me to rewrite my tablet game, Gridshock HD, with Corona for the iPad version. That said, it wasn’t all sunshine, lollipops, and rainbows. Some of Corona’s core APIs and functionality can feel a bit half baked in places. Let me share some of the places that seem, to me, in most need of some love.

Platform API Support

In Corona, there are a number of features that are currently only supported on iOS. Among the most compelling features, I noticed that In-App Purchase and OpenFeint are both marked iOS-only, and there are some others too. In particular, OpenFeint’s leaderboards and achievements are a big reason for why I chose Corona for Gridshock HD on iPad. I know that players demand OpenFeint and/or Game Center, and I simply cannot use either in AIR right now. As great as it is to see OpenFeint available in Corona, I’m not a big fan of runtime-included features that aren’t cross-platform.

On the other hand, the ability to extend Corona with native code would be awesome, just like it would be awesome to have the same thing in AIR. If native extensions existed, the power would be in my hands to choose whether I want to (or am even able to) implement a feature on a specific platform. The development effort for robust extension APIs is, of course, a big task, and I understand that a young platform like Corona might want to include a few high-demand third-party features out of the box before they get around to more daunting things.

Regardless, I’m sure that there are constantly feature requests for Corona to include an API for <insert personal favorite library here>. If native extensions were available, individual developers would be free to add two very valuable types of functionality:

  1. Highly specialized features that few other developers need.

  2. Features that might be coming the future, but there’s an immediate need that cannot wait.

With those out of the way, Ansca can focus on core APIs that work well across all supported platforms and that are useful to the largest majority of their customers—making everyone happier. In addition to native extension support in the runtime, a place to share (or maybe even sell) extensions would be ideal so that folks like me, who never want to touch Objective-C, can look through what others have already built.

Simulator

In the simulator, what you see on your PC may not be what you see on the device. Sometimes, that’s impossible to fix, since some features just can’t work on desktops (Although, I’d like to see more console output that basically says, “you called function X correctly, but it cannot be used in the simulator. Please test on device”). Sometimes, though, the simulator can do things that device builds cannot. In my opinion, that’s much worse. For instance, I saw multi-line text working in the Windows simulator, but discovered that an iOS build only displayed a single line. With simulators, it’s best not to get my hopes up.

The Mac version of the simulator has skins for iPhone and iPad. It makes sense, on one hand, because the Windows version can’t output iOS builds due to Apple’s stupid rules. However, I can’t be the only Corona developer who codes on Windows and builds on Mac. Even if it requires extra notification that I can’t build for iOS, those skins would be super helpful. Alternatively, I would like to be able to add completely custom device skins. In the latter case, all I really care about is specifying a custom screen resolution for the device. If I can get 320×480 or 640×960, then I simply don’t care if the skin looks like an iPhone or not.

Finally, the console output for runtime errors in the simulator always seems to get cut off. On Windows, at least. I can’t remember off-hand if the Corona Terminal on Mac has the same problem. Anyway, I can live without a debugger, but then the stack trace must be as detailed as possible when that’s the case. Half missing information could be the difference in finding an error in seconds versus finding an error four hours later. I’m sure you can guess which I’d prefer.

Language

Lua’s standard library is probably as stark and barebones as you can get. Basically, it provides some math functions, some string functions, and a few functions that turn a table (usually called an object in other languages) into an array by adding and removing from numeric keys. Some of the most basic things I’ve come to expect from a standard library just aren’t there. For instance, how often do you call indexOf() on arrays? I do it all the time, and I was forced to write my own version in Lua. It may not be optimal, and I’d rather use something that a dedicated person or team has vetted better than I could with my time constraints.

On one hand, the small standard library makes sense. The language itself is tiny, and that’s a big advantage. On the other hand, I wonder if the wheel has been reinvented tens of thousands of times by various Lua developers. From what I can tell, there isn’t one true community-supported standard library out there, like I would have expected. Maybe I missed it. Honestly, though, I get the impression that most people throw the Lua interpreter into their C++ games and write super short scripts that don’t need much supporting utility code. Anything complex just goes in the C++ layer.

Corona is different. In Corona, all your code except the super low-level stuff is written with Lua. Corona developers have a more pressing need for a robust standard library that is closer to what’s available from the top-level classes and functions in JavaScript or ActionScript. If Ansca has big dreams for much larger game projects built with Corona, they need to spend some time filling in the gap here so that developers aren’t bogged down in low-level implementation.

Moreover, if Ansca wants to support any kind of open source community, a standard library declared from on high will nip a couple of potential problems in the bud. Since I’ve yet to see any Lua code that uses some sort of namespacing, name collision is pretty much inevitable. Likewise, duplicate functionality will be rampant as everyone includes their own flavor of the missing core library. For anyone that wants to mix and match third-party libraries, that’s going to be a mess of headaches. As Corona-targeted libraries get more complex, the chances of this happening grow exponentially.

Choose the Best Tool for the Job

I enjoyed porting Gridshock HD to Corona. I learned a new language that I hope to develop with again in the future, and I was able to take advantage of features that aren’t available to me in my usual environments. It has given me some inspiration and expectations that I intend to take back with me to Flash. I might be a little more harsh on Adobe’s runtimes when I give feedback now, but any criticism I make will be because I want to see Flash Player and AIR continue to be the best at what I use them for.

Am I now a Corona developer? I’m certainly not leaving Flash behind. However, I’ll be keeping an eye on Corona to see where it ends up. I don’t have current plans for more Corona games, but I may change my mind if certain features are compelling enough, or if I decide that I haven’t played with Lua enough lately. We’ll see. It’s another useful tool to have at my disposal. I’m very glad that I spent some time learning to use it.

Adventures with Corona, Part 1: What Corona offers that’s better than Adobe AIR

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.

Lua logo

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

OpenGL logo

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.

OpenFeint logo

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.

Adobe AIR logo

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.