Before Jestermen was even conceived, I had created a relatively simple Flash game that we have since renamed “The Infernicore”. I actually finished it in one week flat, and immediately uploaded it to Newgrounds. At the time it was just a small personal project based on what I thought was an interesting game mechanic. I didn’t even plan on converting it to a mobile app, much less make any money off it. So there it sat (and still sits!) until Matt and I decided it would be a good idea to push that sucker onto an app store.
Naturally, I figured that since the game was already done in Flash, and Adobe started supporting publishing for Android and iOS directly, I would just use the intended workflow to publish an app file using AIR in the Flash IDE. Long story short, I was quite disappointed to see that the performance on my Motorola Droid was far less than satisfactory. I spent hours trying to optimize the game, eventually coming to the realization that the problem most likely was not in my code; rather, it seemed to be that the graphics were not rendering fast enough. The slow frame rate completely eliminated the possibility of using AIR for Android with this particular application. Now, I’m not going to claim to be an expert on the subject, but I think I was diligent enough in my research that I could safely disregard the Flash/AIR route without any regrets.
Nope, didn't work.
With the project deadlines looming (yes, multiple deadlines; we set high standards for ourselves!), it quickly became less and less of a good idea to continue spending time trying to fix the Flash/AIR problem when I wasn’t even sure the problem could be fixed. So I decided to take my chances with a completely different engine. The only question was, which engine should I choose?
A quick Google search turned up a myriad of Android game engines, each claiming to be the right tool for the job. Among the more popular options included AndEngine, cocos2d, libgdx, Corona, Google App Inventor, and, of course, Unity.
AndEngine, cocos2d, and libgdx are purely frameworks; they’re code bases that will appeal only to those who are comfortable with programming. No visual IDE is included with them, which would have been fine except for the fact that proper documentation was either non-existent or perpetually out-of-date. Since the repositories are updated almost daily, bad timing could spell disaster for those who want to learn how to use them without having to spend hours sifting through old video tutorials and forum posts that may or may not be relevant to the current builds. Unfortunately, such was the case for me. Of course, I could have just opted to use a previous, more stable version of any of the repositories, but I decided to keep shopping around for the time being.
Also no good. Curse you, Flash!
Corona is also just a code repository, but publishing using Corona comes at a premium. When I first learned about it I didn’t realize that it was possible to download the SDK for free, but by the time I learned that, we had already chosen Unity as our new engine. In any case, Corona may offer some potential, but it’s going to have to sit on the sidelines for now.
Google App Inventor was really user-friendly and simple. It used a completely visual, browser-based interface (no coding at all). In lieu of programming it offered a “blocks” UI, wherein the user simply created and snapped together blocks that represent variables and functions. But despite the satisfaction that came with the clicking digital jigsaw pieces into place, Google App Inventor had (at least) one fatal flaw: the inability to create objects at run-time. Obviously, such a limitation is a deal-breaker if one desires creative freedom in his or her games.
Finally, we’re left with Unity. There are many reasons that Unity stood out amongst all of the other engines, and I’ll get to them in my next post.
The end-all be-all of mobile game engines?