Technology choices

Decisions are hard. They’re hard because you can almost never foresee how the result will pan out until you’ve fully implemented them and by then the effort is spent and you’re going to have to start from scratch with hours or days wasted from your schedule.

I’ve restricted my game idea to something I can technologically implement myself, has minimal art requirements (at least with the first release) and I can complete in a matter of months (how many months depends on how smoothly things will go, which they no doubt won’t, but I’m guesstimating around 6). With that in mind, even if the design changes I have a rough idea of the kind of things I’ll need to implement or otherwise acquire.

The list currently stands at:

• Graphics engine
• Sound engine
• GUI
• Font renderer
• Level editor
• XML level importer
• Touch interface
• Camera movement and zoom
• Multi-platform considerations

The big decision here is how many of these do I write myself and how many do I try to find some middleware or libraries for? I’ve not yet decided how much to say about the game, but what I’m trying to do graphically, whilst not particularly complex, requires low level interactions with OpenGL and based on previous implementations of the core mechanic, even writing in Objective-C turned out to have too much overhead (the overhead was the message passing of method parameters, with lots of small functions called many times per frame, switching to C++ doubled the framerate in places. See here for someone else’s comparison). So I’m stuck with C++ and OpenGL, which doesn’t mean I can’t call through to Objective-C (or many other languages if required) but it makes sense to keep going in this vein unless there’s good reason not to, especially as OpenGL and C++ are fairly platform independent (they’ll work for pretty much everything apart from Windows Phones and Microsoft Surface and those might catch up at some point).

Having the graphics engine in OpenGL means any library for the GUI (which would hopefully encapsulate font rendering and multi-language support) would have to play nicely with OpenGL, would most likely be in OpenGL and would need to not cause problems when I’m displaying their GUI in the foreground whilst still running my game in the background (or not cause enough problems if I had to switch between the two). If it was simply displaying some clickable buttons I’d be very tempted to write this myself and reinvent the wheel one more time (which can make sense if you want to really ensure that the wheel fits nicely to your car), but it would certainly be preferable if I could find a free-to-use library that took care of the GUI and would happily display any UTF-16 encoded languages I threw at it. The decision then becomes do I try to find some SDK that can do most of the above list for me or use libraries by part and hope they all play well together, as well as with my current codebase.

In terms of SDKs, the only one I’ve found so far that’s lets you have low-level control of OpenGL and allows you to write in C++ is Marmalade SDK. My main problem here is finding out if their GUI system will play happily with my use of OpenGL i.e. with both displaying during the same frame. No-one has answered this question anywhere in the Marmalade forums (which seem to worryingly have a lot of unanswered questions), but there is a 30-day trial version I can use to answer it myself. The other advantage of Marmalade is that it offers cross-platform support, so will, at least theoretically, allow me to target Android alongside iOS.

There are a few more options for a free-to-use (LGPL or freer) GUI library. Clutter is the main one that springs to mind, but there are others such as kivy and apparently cegui can work on iOS, though it isn’t officially a supported platform. It seems that, after many Google searches, there is sadly no plug and play, well tested, cross-platform, free, OpenGL C++ GUI. It’s almost as if there’s no-one out there willing to do all my work for me.

So tomorrow I’ll start by downloading a free version of Marmalade and see how easy it is to get my game up and running on it, then see what their GUI will do when it’s running over the top displaying Japanese. If that fails I’ll try Clutter. Clutter is free (as opposed to Marmalade’s $149 per year) but if it gives me Android for that price, it’s a price worth paying.