libGDX

Road of Kings is built on top of a third party library known as libGDX, and I think it’s worth taking a moment to give the maintainers of that project their proper due. I happened upon libGDX quite by accident. Originally I started writing code for this project in java only because I had the vaguest idea that Android phones used java code. I chose Android as a target because that was the phone in my pocket, though to be honest, I think ease of developing code was one reason I chose an Android phone in the first place. But I digress…

When the code base first formed up it was just game logic, a simple combat emulator run on the command line. I started very early with a strong model-view-controller architecture, knowing I would want to replace the IO down the road. Eventually I did this, adding a Swing based UI so I could render the earliest map. Still I kept the game logic (model) very separate from the rendering (view) and user input (controller) portions, and one day I finally decided it was time to port to Android.

I looked into some of the Android docs, and quickly realized the complex UI system used by most Android apps was overkill for a game. I wanted something that would just let me blit images to the screen. So I hunted for a library that would do that, and discovered libGDX. I started playing with it and it seemed easy to use, and so the game soon had a third view/controller scheme based on libGDX. It would take a while before the console and swing alternatives would completely die, though once they did some bits of libGDX did seep into the codebase at large. I still keep my model pretty pure, though libGDX’s pool based collection objects did seem like a good optimization over the standard java.util packages.

I had no idea the many further benefits libGDX would bring, and these days I think if I were starting a mobile game fresh I would certainly choose libGDX as my engine. Here’s why:

1. Abstraction – What originally brought me to this library is still worth quite a lot. Having an abstraction layer between your game and the hardware is key for porting. The good news is, libGDX provides several already functioning ports, including desktop builds for Win32, linux, and OSX, Android, and HTML 5 (GWT). iOS is still a work in progress (see below). Plus, it wraps all the bits you’d want in a game: rendering, audio, input, file i/o, and even network communication.

2. UI – Wow, the 2D ui code that comes standard with libGDX is fantastic. It’s scene graph based, it includes an html table-like layout system, support for 9-patches, and skinning. I’ve worked with many less robust UI systems, and certainly few as elegant.

3. Animation – I was tempted to include this under UI, but it’s worth calling out on its own. Nate has implemented a very sweet system for moving actors around the scene using standard transformations including translation, scaling, rotation, etc. all easily modifiable by a pluggable interpolator to give non-standard motion over time (eg. sine waves, bouncing, etc.) You want an image to swoop in from the side and scale in, with a little bounce at the end? It’s about one line of code. And as it’s all built into the 2D scene graph, it’s just as easy to do that to a whole chunk of UI as it is to a single image.

4. Tools – Besides some helpful utility classes (hello xml and json parsing), there’s also some very nice support tools. For example, there’s a very nice tool for packing many small images into a single large texture. It’s even clever enough to determine that two images are identical and only actually pack a single copy and create two differently named references in its metadata. And then there are some approved optional extensions to the library that add some nice flourishes like loading and rendering TTF fonts.

5. Free – Yeah, it costs not a dime. Also, that means you have full source access so when you discover some little “I wish they did…” it’s actually pretty trivial to just go change it yourself.

OK, lest I come off as a complete fan-boy, it’s worth noting there are a few detriments:

1. Programmer Oriented – Those sweet UI and animation systems are great, provided you don’t mind layout out your UI and specifying your animation sequences in code. You want artist and designer friendly tools for this stuff, you’re going to have to write them. Good news is, you can write them, and I’ve found I can even add some libGDX rendering to a swing JPanel to use convenient swing UI stuff for the heavy lifting but still have a WYSIWYG display.

2. Early iOS Support – This is a big one, but the iOS support is pretty new. The current system is based on Xamarin (née MonoTouch) which requires a pretty hefty licensing fee (about $500). The maintainers seem to want to move away from this and are actively working on a new backend based on the free RoboVM, but that’s only started in the past month or two. I’m really crossing my fingers they get this stable by the time I need it, but if I have to I guess I’ll fork over the dough for a Xamarin license.

Well, there you have it, libGDX. I really can’t recommend these guys enough. If you’re thinking of making a mobile game and you’re not keen to jump on the Unity bandwagon, definitely check these guys out. You won’t be sorry.