Technical Dev Blog #3: Engines & Frameworks

By @ 07/17/12 in techblog

So, after we had our technical and design documents laid out and the contracts with our friends at Epiphany signed, we had to make a few decisions: what engines, frameworks and languages were we going to use?

Initially, we’d pitched the game as an iOS-exclusive title, and so that meant we’d most likely be working with Objective-C, most likely – that being the native language of the platform – but it’s always good to think carefully about your options.

Rather than attempting to make a game as efficiently, quickly and cheaply as possible,  we made goals which were slightly more long-term.

Our project is not small, and the engine required to do it is actually quite complex (…as we found out later – Leigh). An isometric engine with large, interesting worlds that you can explore and build in is nothing to sneeze at, especially compared to the kind of thing we could have ended up making – say, a level-based endless runner or platformer.

Above: Our engine has very different requirements to the one pictured here.

One of the decisions we made based on this was that the engine should be re-usable. In fact, we very quickly ended up figuring out a few other potential titles we could use the engine (and even re-use some of the assets) for after we’re done. This way, we could plan around our game not selling particularly well, and leverage our first title to make our future titles that much easier to do in the event that it doesn’t earn us enough money to fund our next title.

So, we had the following basic requirements: we wanted a re-usable, fast, isometric engine. While we’d originally intended iOS only, we also knew that we wanted to leave our options open to port to other platforms with some ease.  So cross-platform got added to the list. Another requirement was that we didn’t want to be beholden to others. Not in terms of money (we have purchased utilities and software for Flat Earth, so buying a license for an existing framework or engine wasn’t written off) what concerned us was being beholden to someone else to fix bugs.

In short: we didn’t want anything where even part of the source code was closed off to us. Between us and Epiphany, we have some experienced developers and it wasn’t completely outside the realm of possibility that we’d end up working on some low-level stuff in OpenGL (in fact we’ve already done so, just a few months part-time into coding the project).

This ruled out things like Unity (although honestly, it wasn’t something which seemed ideal for a 2D game engine, anyway) and left us staring at things like Moai, SIO2 and even Corona. There’s no shortage of cross-platform game engines these days for mobile development, and the feature-bases overlap so much first-hand testimony by folks you know or actually just working on a tiny project with a trial copy sometimes seems to be the only way to actually make this sort of call.

For these kinds of professional-grade frameworks/engines you’re looking at anywhere from a few hundred bucks to a thousand bucks, and in some cases (like the drool-worthy Moai framework) an ongoing fee for the services they provide.

Most of these require you to pay extra to get full source code access too.

While iOS is our primary platform, we had always intended to do a desktop version as well, and unfortunately this little additional requirement knocked out even more of our options – many of the cross-platform mobile frameworks aren’t also portable to desktop – at least not without doing the port yourself.

So, with our list getting smaller and smaller, we came to our final decision – code in C++ (no scripting language atop it for game logic) and use the Cocos2D-X framework.

Cocos2D-X is a port of the particularly neat Cocos2D framework to C++, and works on almost every platform you can shake a stick at (and some you can’t, like “MeeGo” and “Bada”… whatever they are). It’s been used enough on various successful iOS projects that I didn’t fear any nasty surprises as a result.

Other deciding factors were that it’s fully open-source, so when we found bugs we could fix them and push them back into the project without issue (in fact, we’ve already done this)… and the other, really big reason Cocos kept our attention over other languages… experience. Some of us had used the thing before, and we knew this would seriously reduce the “grace period” before we started turning out useful stuff in it.

It doesn’t surprise me that this ended up being the deciding factor for us. Almost every indie developer I know has chosen their platform of choice (XNA, Unity, Cocos) because of prior experience in the platform – in many cases, it’s what they’d learnt at university or TAFE. In our case, it’s what we’d used for various contract projects for clients.

So far, our decision seems to have been a good one. We’re at technical milestone 1 (that is, we’ve implemented about 1/4 of the features we need in our game engine) and have had no show-stopping issues – just minor ones.

Next up on our tech blog: I’ll talk about the issues we *have* had, and some of the few annoyances and regrets about our choices.


Comments are closed.