Lately I’ve been spending a lot of time developing mobile games with the Corona SDK. The idea behind it is that you code once and deploy to many targets like iOS, Android, Nook, etc. Also, Corona seems to be targeted at games and while they do have some samples of companies that did other kinds of apps, their core community seems to be mosly using the framework to develop mobile games.

Let me begin with the first thing you encounter while working with the Corona SDK; the Lua language.

The Lua language

It is clear why they chose Lua for their language and there are many articles on the web that state the benefits of it. It’s extremely easy to learn, easy to embed, and executes fast. On the other hand if you are used to doing object oriented design in C++, Objective-C, Java, or even “easier” languages like PHP or javascript, working with Lua will be analogous to being kicked in the balls repeatedly by a football player wearing cleats. Oh, and the cleats have rusty nails and broken pieces of glass glued all over. To me, programming in Lua feels like programming in LOGO (remember the turtle?). Everything is extremely basic and I find that everything I can do with other languages, I can’t with Lua. Sorting stuff in general is a pain (say, an array of objects). Well, when I say array I mean a table since Lua seems to only have tables. Every stone you pick up in Lua has a table under it and the only object you will ever work with is some sort of Frankenstein’d table. I’m not saying this is bad. I mean, you can’t compare a scripting language like Lua to a motherf***r of a language like C++. Apples and oranges. They were not created with the same goals in mind so it’s useless to compare them. To compare it with PHP would probably be a bit fair since they are both scripting languages which have at least one design goal in mind: to be powerful yet easy to learn. Still, apples and oranges.

So, on with the stuff that pissed me off about Lua…

Attempting to do object oriented design in Lua is like snowball fighting with a monkey, except instead of snowballs you use the monkey’s shit; you will eventually end up with the kind of mess that you will want to wash off as soon as possible. Is it possible? Yes, sort of, but not in the sense of “oh, I’ll just solve this by implementing the Disjointed Kangaroo Turd Fist” Let’s pretend the Disjointed Kangaroo Turd Fist is a well known Design Pattern by the Gang of Four. It’s not, but for the sake of argument let’s pretend it is. Well you won’t be able to implement it in Lua because there is no such thing as inheritance. You can do composition but that’s about it. Also, in Lua every method/property is public. I’ve spent a lot of time reading blog posts about how to do OOP in Lua and while there are some interesting reads out there, I found none of them to be practical for my applications. If the language mean to have people doing OOP there wouldn’t be so many blog posts -each with their own take- emphasizing that you can do OOP. You don’t see any blog posts trying to convince you that you can do OOP in Java because it becomes painfully obvious in the first 2 minutes of using the language. In a blog post that I will paraphrase and not link to (to protect the innocent) the guy said “why do you need to declare private methods? If you don’t want other objects to see them just don’t call them from other objects. Simple as that.” My point here is that the language is so simple that it’s being used by a lot of people who don’t know about good programming habits, have not worked in teams, and don’t know what maintaining code in the long run is. So even though the community itself if very prolific, they seem to be split in two categories. The first one being the “let’s code a game or two” guy, and the second one being the “I need to release this game FAST. What’s the easiest and fastest game dev framework around?” guy/company. Neither is too concerned with good programming habits, code readability, etc, so they just plod on and are not bothered much with the Lua kinks because they haven’t been exposed to other languages that were designed to be powerful and even better beautiful.

The framework itself

This is where the SDK shines. The API is incredibly simple yet powerful and it’s very well documented. The forums are crawling with people who take what they do seriously and are willing to help. Rarely do you see some troll or smart ass who tells other people to RTFM. The Corona staff post to the forums regularly and I think this is extremely important since it raises the quality of the answers considerably; on your average forum search, odds are that what you are looking for has been answered by one of the support staff. They also screen the posts for actual bugs and create tickets for them. This has happened to me personally and have seen it happen with other people too. They have a good policy of reporting and fixing their own bugs. If you are a subscriber you have access to the daily builds and in more than one case I’ve seen the bug fixed the following day. Getting your bug fixed the next days is one mother of a huge plus.

The framework also includes libraries like the Box2D (physics), Flurry (analytics) and many many others. Since they are wrapped in Lua, the implementation is not exactly the same as what you’d find in the libraries’ docs. Fortunately the Corona people have thoroughly documented these libs and you can find anything you need to make them work in the Corona docs too.

The code samples

The Corona docs have a lot of useful examples that are short and sweet. Each feature has and example with only what you need to make it work. They don’t include extra stuff. You want to draw a physics body? Here’s the code to do JUST that. Very cool. They even go a step further and often publish Tutorials that deal with more complete examples that go into much more detail on each subject.

The IDE

This part gets ugly again. I’ve got a copy of Lua Glider 2 which is basically a skinned up Netbeans but with 4 times the memory footprint and 10 times the bugs. Lua Glider 2 leaks memory like a mother. At the end of my work day, the stupid IDE will be eating up 4Gb of RAM. Mind you that I usually have no more than 4 files open at a time and the only “feature” that I use is the debugger. How on earth that can eat up 4GB of RAM is beyond me. So why not just restart it once in a while so that it frees up some RAM? Well… every time I close it I can’t open it up again because it freezes. This is the only app on my Mac that does this. I have to reboot in order to be able to open it up again.

I also tried Sublime editor which seems to be all the rage nowadays and the Corona SDK has an official plugin. It’s ok but I don’t seem to understand it quite well. It’s a text editor, really, not an IDE so a lot of features are great for a text editor but horrible for an IDE (autocomplete for starters). Sublime’s debugger also has one thing that annoys the crap out of me: you have to start it twice because it has an implicit breakpoint in line 1 that you can’t remove. But after using PhpStorm, any other IDE just doesn’t seem right. Of course you can install a plugin to get PhpStorm to do some Lua syntax highlighting but the debugger doesn’t work and that’s a deal breaker for me. I’ve tried a couple of the other suggested IDEs but they were soooooo bad that they weren’t even worth mentioning. I will stick to Sublime. A lot of people I respect swear by Sublime so I’m open to giving it another chance.

Game design tools

A good part of creating a game is spent outside your IDE in all sorts of small utilities that prepare your assets so that they can be consumed by your game. This is probably the major pain point I found so far. Most of the tools are designed by individuals or by very small companies. This is ok except that usually individuals can’t provide enough support (they have lives to live) and most of the small companies I’ve dealt with just didn’t care. Also, the Corona SDK moves pretty quickly. I mean, they update it constantly, which is good, but sometimes external providers/authors have to keep up with this, and I found that for a lot of game tools, this was not the case.

For example, let’s look at level editors…

If you are doing a game with levels or stages you will most likely be working with an external editor that has some sort of GUI to speed your workflow up. More often than not you will be working with Tiled Map Editor or Tiled for short. This great tool that allows you to import a tileset and draw your maps. It’s a project by an individual and has been alive for many years. I’ve requested features to the author and after they have been backed by other users, they have found a place in the software so it’s great to see that the author listens to users. But Corona itself can’t open Tiled maps alone; you need some kind of library. This is where it gets ugly.

Trying to find some kind of level editor for the Corona framework is easy. Trying to find one that a) works, b) is documented, c) actually speeds up your workflow, d) doesn’t make your balls hurt, e) works in OSX… well, this is next to impossible.

First there’s Level Director by Retrofit Productions. This only works for Windows so I didn’t even try it.

Then there’s Lime which allows you to open up your Tiled maps on your Corona app. This looked great except for the warning in the home page:

This leads me to think that Lime is not maintained anymore otherwise the sign would read something completely different. So, we can scratch Lime off our list.

Then there’s SVG Level Editor. The idea behind it is beatiful: take SVG graphics and turn them into physics bodies. As I was trying to purchase a license from the project’s website I realized that the PayPal button was leading to a 404 error page. Hmm… so I Googled it and found that BinPress was selling it too so I got my license there. As I was trying it out I realized that I was getting more errors than results. Even the bundled examples din’t work. I contacted the author and after a couple of emails he told me that he couldn’t make the examples work either and this was due to a change in Corona’s API. He said he would try to update the library but after a week he said that he would need to make too many changes and that he didn’t have enough time to tackle this. BinPress kindly game me a full refund. This was very unfortunate as I have found no other library/tool that was as flexible as this one.

Wait, but didn’t the Lime warning point to another tile engine? Yes it did, and it’s called Million Tile Engine (or MTE). The only place where MTE was being sold was at Gumroad. This was a single page with only the bullet points of what it could do and nothing else. No links to API reference, documentation, examples, FAQ, or forums. Nothing. So I hesitated and kept looking but it was clear after a couple days of Googling that most people were using MTE and swearing by it so I decided to give it a go. When I went back to the Gumroad page to buy my license… it was not available anymore. Back to the Corona forums (and fast forward a week). It turns out the author of MTE decided that the project was taking up much of his time and leaving to little money (completely understandable) so he was discontinuing it. Now this stirred up the forums and many people started giving the author ideas on how to make money from -or open sources the engine- and people were also asking for the product to become available again even without support (myself included). After a couple of days, MTE became available again and I could get my hands on it.

MTE came in the form of a ZIP file with many code samples and code-complete projects. It came with a few pages of tutorials/FAQ and a basic API reference. It does what it is supposed to do and it does it well. I have -obviously- very little experience with it but most people regard it as a mature project even though the version number doesn’t reach 1. Still, would you start your next project with a tool that you know is dead? Yes, it might be working right now but what happens when Corona decides to change it’s API? What happens when you find a bug?

Another engine I tried is the Dusk Engine. This one was made by a 14 year old developer who will probably be working at Google in a few years. The code is impressive and it is very easy to use. You export your Tiled maps as either .json or .lua and you open them up in your app. While I couldn’t get the .lua maps to work, I did manage to get the .json ones working properly. The documentation is… getting there. I mean, there is an unfinished HTML version of almost half the API. After your retinas get adjusted to the white-and-yellow-text-over-black-background shock (which I immediately changed in the CSS) you can see that there is some effort put in the docs generation. Of all the engines, this one has a more “regular” API documentation look. There are some tests included in the documentation (which no other engine had) and a utility to manipulate tilesets (like performing extrusion on them). I couldn’t make the extrusion tool work for the life of me and my tiles still look jagged in the edges when scrolling. This is not an issue of Dusk, by the way, but rather an issue of using tiles themselves. Still, other people have been able to use this tool successfully so most likely I was not doing things right. The Dusk author posts in the Corona forums quite regularly and happily answers most of the questions he is asked.

Finally there is Corona’s very own Composer GUI which is a visual level editor of sorts. It’s still in early beta and when I tried it, it crashed a lot and when it didn’t I got the app in un unstable state many times. So it is unfair to compare it to other solutions out there. It reminded me a little bit of Flash. Why is it that every time that I think about Flash I get this mental image of dismembered bunnies covered in blood?

Final thoughts

So if you are still reading this completely biased and half-assed Corona review, here are my final thoughts on the matter.

Developing with Corona SDK

Pros:

• Very easy to learn.
• Going from idea to prototype is extremely fast.
• Thorough documentation and online resources available.
• Great and active community.
• Access to daily builds if you pay a fee.
• Non-developers can get up to speed really fast (this also leads to one of the cons listed below).

Cons:

• Most of the tools you use to work with it are unreliable either because they are unmaintained, dead, or simply supported by their single author (you need to wait for the guy to come back from holidays or their day job to answer your questions). To me this weighs A TON and takes away they joy of the framework massively.
• A lot of people who code Lua have never programmed a “more serious” programming language or have never worked as developers and the “solutions” they provide in blogs or forum posts while workable, are not necessarily maintainable or promote good coding practices. “But it works!” is sometimes not good enough if you want to do things right and produce beautiful code.
• The Lua language while easy to work with, is extremely limited when it comes to traditional Object Oriented Programming and will require devs to re-think how to architect software. Your precious Design Patterns (or most of them) fly out the window and you have to re-invent the wheel a lot of the times. If you have previous software architecting knowledge be prepared to go back to the stone age.