Why Monkey Isn't A Terrible Choice

Psst... this is a big post. I get that you're a busy person avoiding lots of important tasks by reading this blog post. If you're desperate to get on with avoiding those tasks elsewhere I'd suggest at least reading the last entry.

Monkey is a cross-platform language that I've been using for games coding for around a year now. The general idea is that you write code in Monkey and then that code is translated to a "native" language for a specific platform, so Objective C for iOS, Java for Android, AS3 for Flash, C# for XNA etc. I picked up the demo not long after release and bought a full license a little while after. In the time I've been using it I've ported two physics libraries (Fling and Box2D), released my own JSON library and I'm nearing completion on my first game based on my own framework.

For a while now I've been considering posting about Monkey (and its general development environment) but I've held off doing so. The reason being that I am, by nature, fairly critical.

I'm not as bad as this guy. He sucks at being critical.

I like to think that I'm at least as hard on myself as others but even if I am it's not necessarily much comfort to those others. Monkey has been going though some growing pains and, while I'd always give an honest opinion if asked, I didn't want to broadcast negatives about an immature product. Now though I feel that I've added a fair amount to the Monkey community to offset any negative views. Also, it has been a year and Monkey should be able to stand some criticism.

However, before I start picking holes in the product, I want to lay some positive foundations. So that's what this post is - a set of reasons to give Monkey a shot that I can point to in the future when people accuse me of being negative and spanking the Monkey, so to speak. On with the Monkey love:

Hot.

Reason 1 - Mom 'n' Pop Service

Mark Sibly at BRL

Monkey is developed by Blitz Research Ltd (BRL). It's a very small company with pretty open access. Got a problem with Monkey? You can email Mark Sibly, the programmer and el queso grande of BRL. Something wrong with the provided Monk editor? The guy who writes the editor is on the forums. If you like dealing with small companies rather than large corporations or amorphous open-source organisations then Monkey gives you that level of personal interaction.

Reason 2 - It's The New Thing, Same As The Old Thing

In a good way.

If you're a programmer who is seriously intending to create games then attaching yourself to a new technology stack is fraught with dangers. The investment in learning that stack and the time/effort value that will exist in the code you write to run on that stack is considerable. In a worst case scenario you can end up throwing away weeks or months of effort. I will admit that I was highly dubious about Monkey but there are some facts that  persuaded me that it was at least worth a look:

BRL has a history of creating high-level game-friendly programming languages going back to the days of the Commodore Amiga. I'm old enough to have briefly used Blitz Basic back then in some early dabblings with graphics coding. So, the company has past form in terms of creating and maintaining these products and they've done it successfully enough to still be doing it.

The Monkey language, while bringing a bunch of new stuff to the table, is still in that same family of BASIC-ish languages. The language offers familiarity to many people and a relatively readable syntax to beginner programmers - unless you really hate BASIC, that is. I'm on the fence as to whether I hate or loathe BASICs, but it's not an unknown landscape to me and that has value when faced with so many other unknowns.

Reason 3 - It's Cheap, But Not Too Cheap

Monkey is currently 120USD for the full license. That's a one-off charge with no annual support fees or royalty cuts. Price-wise it undercuts the commercial competition by some margin (Although it also provides fewer features. I won't claim that it's a direct replacement for Unity, for example.)

On the other hand, 120USD isn't peanuts. I'm a big fan of open-source and HaxeNME is coming along nicely and that does mostly the same and is free. Surely free is better than 120 dollars? In the wallet, sure, but when there's something to be said about the value of a product that you know someone is invested in for their livelihood. Sometimes open-source projects are amazingly high quality and the teams are responsive to their users' needs and sometimes they really aren't. I don't know which one HaxeNME is or will be but you might consider that 120 dollars is a fair price to be able to at least imagine that you are understood to be a customer.

Reason 4 - It's Not a Black Box

Some cross-platform solutions are very jealous of attempts to peek at the workings or they force you to publish via server processes that they control. Monkey does none of this. If you want to get into the workings of things then you can.

Monkey coding is this manly.

The language itself is public domain and source for everything is openly provided in the distribution. The translation process spits out readable(ish) code in the target's native language and even creates IDE project files for many of them.

This means that, if you're willing and able to, you can operate directly on the native code using native tools (e.g. profilers and debuggers). You can even change the Monkey language itself if you want and are willing to carry the burden of maintaining the branch.

Reason 5 - It's Not Horrifically Slow

...considering what it is

Performance was a concern for me. Mobile devices are amazingly powerful these days but you're still dealing with some compromises and an abstracted rendering layer and translated language are compromises on top of those.

I've been pleasantly surprised though. There's no doubt that you would get more performance by working natively but Monkey's overhead isn't going to stop you from creating attractive 2D games. At some point I'll see about making some comparisons if I can find simple game-y demos to reproduce but for now I'll just offer mostly anecdotal reassurance and my one data point about my Box2D port to Monkey only being half as fast as libGDX (honestly, that's not terrible!).

Reason 6 - It's Not a Toy

But it's fun

I'll be honest. In the early days of using Monkey I really thought it was a dead-end for me. I pretty much immediately started writing framework code and converting the Physaxe library and it was obvious that nothing substantial had been written in the language during beta testing. Blocking issues with the compilation tool-chain flaking out were a regular occurrence and after working in C/C++, Python, Ruby, Java and C# the language seemed inconsistent and under-powered in a design sense.

I think I turned a corner on my plans to jump to Unity, Corona or Haxe when Monkey implemented interfaces. Initially, when asked about adding them the response was bluntly that they wouldn't happen until there was a larger rewrite and that was "at least a year" away. That was no good to me and I started looking around for options. Then, for whatever reason, interfaces were added. They were somewhat broken at first but it rescued my sense that the language could support what I wanted to do (without excessive frustration). Since then, as I mentioned at the start of the post, I've written thousands of lines of fairly structured code and nearly all of them work.

Monkey isn't a power-house of language features, "enterprise-ready" or a startlingly elegant example of language design but it is capable of supporting the creation of reasonably complex software without it collapsing into a ball of mud. It manages to avoid the trap of attempting to be easy to use at a beginner level at the expense of being able to support growth into a more expert programmer and software designer.

Reason Everything - Fear Not The Future

Because the future will be this awesome.

Monkey offers out of the box (some assembly required) push button compilation to HTML5, Flash, iOS, Android, WP7(XNA), XBox(XNA),Windows(XNA/GLFW) and MacOS(GLFW). I won't claim that it's perfect or without complications but, for the most part, you can write code once and then just compile to the platform you're interested in.

There's no doubt that this is the actual reason I picked it up in the first place and the reason I stuck with it. The other reasons listed above all together aren't as important as this one. I wanted to try creating and selling a game but I was unsure about which platforms to target. I was especially concerned with the possible need to push out a Web version as well as a mobile version and to be able to hit both iOS and Android. As a solo coder, the thought of having to create a cross-platform game in C/C++ and maybe port that to Flash/HTML5 to create a promotional web version was daunting. It would have also front-loaded a bunch of learning and costs (if I wanted to write for Android and iOS then I'd need to buy an Android device, an iPhone or iPod Touch and a Mac of some sort from the start). By going with Monkey I could push nearly all of that back and just get on with writing the game.

It gets better though. Monkey doesn't solve all of the cross-platform issues, just most of them, but for the ones it doesn't solve it provides pretty easy routes for you to solve them yourself. Writing native extensions is quite simple. Monkey also generates working projects for the platforms so you can, if you want, just open up the translated code in XCode , Eclipse or VS and add platform-specific features.

But there's more. We're in an era of platform proliferation and shifting ground. Windows 8 is around the corner with Metro-based tablets and Microsoft's own concepts of an app store. Will MS relent and allow XNA? Will HTML5 be a realistically performant target? Panic? Probably no need if you're using Monkey. When the smoke clears on the tech side (and if Metro doesn't flop) then BRL or someone else will put together a target for it and you'll recompile. No reason to panic at all.

Always carry a towel. Coding in Monkey helps too.

But what if they don't? Or what if BRL goes bust or Mr Sibly gets bored or something? Still no reason to panic. As I mentioned above, the Monkey language is actually public domain. Only the graphics, sound and input abstraction library -- mojo -- is under a commercial license and the source code for everything comes with the installation. As such it seems highly likely that a community effort could quickly be put in place to keep the language and tools going.

Even if, for the sake of argument, you decide that you absolutely must jump ship then you still have the ability to compile your Monkey code to one of the targets and use that as a base for your next step. The translated code isn't pretty, but it's munged in a predictable way and I doubt it would take more than a week or so over a project to tidy it into something perfectly reasonable.

Ultimately that's what I feel Monkey gives me: options and the ability to delay decisions with minimal cost. There's no guarantee that Monkey is the perfect choice for any given project but it is certainly one of the least binding imperfect choices you can make.