Several months ago I prototyped a basic skeleton for a game idea I had in Love2D, a Lua scripted game engine for desktop computers. Love is an excellent piece of software,
that isn’t what a typical professional studio would choose, but is honestly one of the best software pacakges I’ve ever come across. It works flawlessly on Windows, OSX, and Linux.
It works identically on all systems, and deployment to any system is as easy as bundling up a zip file of Lua source code and having the operating system open that with the
binary, which can be done by stuffing it in an OSX app’s resources directory, a simple .bat or .sh script, or a handful of other ways. Love is incredibly well documented, to boot.
Every function is documented correctly, and not only does their docs explain how each piece is used, but also how to fit together the pieces to make a game.
So several weeks ago, when I decided to try to port this game concept to a full game being released on Android and iOS, I naturally wanted to stick with Lua. The language is a
little quirky in that it’s over-liberating, but it’s very functional, and a staple in the professional game world. It’s written in pure ANSI C (excepting it’s dynamic library
loading, which there’s no ANSI C way to do), meaning it runs on pretty much any processor/environment made in the past 80 years, and it’s very quick, especially when it comes
to bridging C/Lua data and functions. Knowing I wanted to port my previous Lua code, continue honing my Lua skills, and keep my cross platform options open, I started looking
at mobile game engines that targeted Android and iOS. What follows are some notes from late nights of hair pulling and anaylyzing my options.
I’ll note here that I was/am looking for a free, open source solution. If you’re looking to get running fast, you probably don’t want that. Paid software does have its
benefits and perks, primarily when it comes to support, documentation, and things working on the first try. I’m willing to take the extra effort to learn an Open Source
package, for some rather philisophical reasones pertaining to “owning” my own software.
Arguably one of the most used options, and almost definitely so if you’re going by paid-subscription model, Corona is a very well rounded package. Their included simulator
is quick to get running, and there’s countless book, tutorials, and blog posts about how to use it. I only tinkered briefly though, as I knew I didn’t want a paid solution.
An even bigger turn off was that the software uses their servers to build the final project, even with the higher-end licenses. Only the top tier “Enterprise” level accounts
have the ability to do offline local builds.
Gideors was a package I liked even more than Corona. It has a bit less built into the core libraries, but has a fairly extensive number of 3rd party plugins to cover that gap.
Corona’s plugin library is still larger, as it’s it’s core set. Where Gideros really shined was on device testing. Gideros ships with it’s own host app, and the IDE will deploy over wifi
to a tablet or phone for real world testing. Because this concept of a core host implemented in native code is really at the heart of any Lua game engine, there’s no performance
penalty compared to a real instance of the same app being deployed, save for perhaps shaving off the http host running in the background. It’s built in sprite editor is not bad,
but if you’re used to any specific tools you’ll honestly stick to those most likely. In the end though, it was once again the financial cost and commercial license model that
turned me away.
Moai is what I spent the most time with, and what I felt looked the most promising. I was able to implement up to where I was in Love, and I was pleased with the result, and how quickly I was able to get there. In the end though, my frustrations with some issues proved to be irreconcilable. For one thing, the documentation is nowhere near where it needs to be. Some functions aren’t documented
at all. My code ran quickly, even churning out lots of physics collisions, and complex camera transforms. Also, unlike Corona and Gideros, the fully open source nature means not only are you allowed to tinker with the C++ host/bindings, it’s encouraged. Adding new features in C/C++
doesn’t require a special license. Ultimately though, it was a let down, once I dug past the inital tests.
The engine’s documentation is dated in some areas, and borderline non-existent in others. The build instructions on the main page rarely work. The majority of functions will list the parameters and returned result’s class, but nothing else. The entire Box2D documentation just says “see Box2D documentation”
(referring to the docs of the actual library). The Chipmunk physics library is even worse - every math function in Lua uses radians. Every function in MOAI uses degrees - not
terrible, converting isn’t hard –EXCEPT FOR CHIPMUNK. Why? These small inconsistencies proved to just be too much.
Moai looked promisisng. It’s marketed as “The mobile platform for pro game developers”. It’s used by Double Fine extensively. But it really is for pros, and not hobbyists. Depending
on how you count, there’s 4-5 different branches in the github repo for v1.5. 1.5 development, 1.5 stable, 1.5 master (which is apparently neither stable nor dev). Then there’s
the forks from 1.5 that are listed in the documentation, as if they’re official. Furthermore, there’s no release schedule or information. 1.5 is 1.5, and 1.4 is 1.4. There’s no
third digit, or date in versioning, and if you download the repo a few weeks apart, it’s pretty likely there will be minor differences. In my case, even my detailed notes on how I got
it to build didn’t work a month later, and I ended up thumb-driving it from one computer to another to ensure I was on the same version.
There is an excellent book, Developing Mobile Games with Moai SDK, by Francisco Tufro that is definitely worth picking up if you decide to go with Moai. It’s especially worthwhile
if you’re new to Lua gamedev, as it covers some basic patterns for structuring the flow of a game’s codebase.
MOAI is made for studios who are going to be implementing their own Lua host anyways. If you’re doing that, excellent, it’s a wonderful option for the final bridge to your Lua
environment, but if you’re a one man shop who doesn’t want to deal with that set of issues, keep shopping.
I’m not trying to fault anyone here, or offend anyone. Moai is developed by a game studio (Zipline) - they’re in the business of making games. Making their tool open-source was a gift to the
community, and I don’t want to look a gift horse in the mouth. I do want to warn other first time devs to not get discouraged if they run into the endless sea of issues I have had with MOAI.
I originally looked at Cocos2d-x a little over a year ago. It’s based on Cocos2d, an Objective-C based library/framework, but ported to C++. As of the 3.0 release, it now supports Lua, as
Cocos2d-x is possibly the most used mobile game library out there, with Unity and Corona not far behind. It’s mature, stable, and well developed. It’s not without issues, I also ran into build
issues with it, but the community is significantly larger than MOAI’s which makes finding fixes a whole lot easier. Like MOAI, it suffers from sometimes sparse documenation, but like the build
issues, the larger community really helps out. Really, that’s what it comes down to in the open source world, is the community behind the project. Moai’s community was great, an incredibly
kind and helpful crowd, but it wasn’t the size needed for the amount of problem solving that a fledging young game engine needs.
So far, I’m still pretty fresh. Cocos2d comes with a bit more than Moai out of the box, including built in scene management. It also has it’s own IDE and toolset now, but I’m avoiding those
for the time being. Chipmunk is built in, which is an improvement from 2.x which had no built in physics, but having Box2D as an option would be nice.
So with that, I’m out to try some more testing. I’m sure I’ll be back with more notes in the future.