Rabid Lion Games

Start your engines

January 17th, 2013

I’m still a couple of months off starting/ restarting my game in earnest, but I’ve started planning out how I’m going to keep development time to a minimum.

My biggest consideration is the engine I will use. Here, I’m fighting a battle.

I’m a programmer, and although I’m working hard at being a better game designer, I will always enjoy writing my own tools and engine from scratch. The goal of using an off-the-shelf engine is the complete opposite of that, to leave me needing to write as little code as possible. But I love writing code.

So it’s been a struggle to objectively evaluate the engine options out there. I’m hoping that going through my thought process out here in the open will keep me honest, and stop me from straying from my objective: actually finishing a game.


So what are my requirements for an engine?

Essential criteria:

1) Has to handle ‘proper’ 2D – Whilst  2D can be ‘faked’ with a low FOV perspective projection I’m aiming at pixel perfect platforming, which is significantly harder without an orthographic projection

2) Must support 2D physics

3) Has to use either C++ or C# as the development/ scripting language – these are the two languages I know the best, and becoming proficient in a different language would eat into development time

4) Must have tools that either provide the facilities I need to place arbitrary sprites and colliders in the scene and to create/ edit an arbitrary 2D surface for the ‘ground’ – or else needs to be easily extensible for me to quickly code these facilities myself (or that I can add through 3rd party plug-ins).

5) Must be robust – As a one person team with a full time non-game job my time for supporting the game and bug fixing will be limited, so I’ll need a base that I can be confident isn’t full of bugs.

6) Must be able to handle per-sprite shaders for certain effects that are integral to the gameplay.

7) Must be able to handle large numbers of particles.


Desirable Criteria:

1) To support custom post-process shaders.

2) To be cross-platform.

3) To use a familiar API.

4) Is used ‘in the wild’ so that obscure bugs that only occur in certain hardware configurations are already documented.


The contenders:

There are 3 paths I’m considering:

A. Unity3D

B. SunBurn

C. Rolling my own using DXUT, and DirectXTK

I’ve already eliminated other engines that don’t really meet my essential criteria. But I’ve kept option C, which technically doesn’t meet any of the options since it doesn’t exist yet, but it could meet all but number 5, and given that I will know the source code, bugs in the engine code are not as terminal as they are with a 3rd party binary only engine.

It should come as no surprise, given my introduction to this post that my heart is screaming to go with option C. But, in the spirit of trying to be objective, let’s have a look at each option in turn against my criteria.


Essential criteria:

Unity can handle orthographic 2D out of the box. 2D physics seems to work just fine by adding constraints to the existing 3D physics engine. C# is the recommended scripting option. The tools are easily extensible, and in fact between the 2D toolkit and smooth moves plugins I might not even need to build custom tools at all. It certainly seems robust (and the bugs that do exist are usually well documented given the sheer number of users Unity has). It has support for per sprite shaders in it’s material system. It has a built in particle system, but it’s performance is unknown to me at the moment.

So that’s 6.5-7/7 on essential criteria (the half is for the particles since it’s an unknown).

Desirable criteria:

Custom post-process effects are a pro – only feature – I won’t be paying $1500 dollars for pro just for those unless I feel the game *really* needs them. Unity is the definition of a cross platform engine. The API is brand new to me, so I will be starting from scratch there. It is commonly used, so I’m hopeful that obscure bugs will be google-able.

Score: 2/4

Not bad overall, but let’s have a look at SunBurn.


Essential Criteria:

SunBurn is perfectly capable of orthographic 2D. I could either use a constrained BEPU or integrate Farseer Physics for 2D physics. It’s C#. The tools are not straight forward to extend, but they are extensible – it’s just some work, and there are no existing plugins providing the functionality I need. It seems robust and the team has a strong middleware history. Per-sprite shaders are straightforward. It’s high performance, so lots of particles should be fine, but again it’s untested for me.

Score: 6-6.5/7

Desirable criteria:

Custom post-process effects are available. SunBurn is sort of cross-platform at the moment and they’ve hinted other platforms are in the pipeline. The XNA part of the API is familar to me, but the rest isn’t. It’s not that widely used, certainly not to the same extent as Unity, and even less so on PC.

Score 2/4

That’s pretty tight between SunBurn and Unity. There’s also nothing in cost between them, as I already have a SunBurn license and I’d be using Unity’s free version.

Finally, rolling my own:

Custom engine:

There is no point comparing this against the criteria. With a blank piece of paper it could go above and beyond all of the essential criteria, even robustness, given enough time. It could even meet most of the essential criteria, baring the ‘used in the wild’ criterion. But that’s the point. The purpose of using an engine is to save time. To roll my own when there are existing engines that can do exactly what I need, or can be made to with little effort, is just unjustifiable.


Between Unity and SunBurn, there’s not a lot in it. Overall I’m drawn to Unity as it’s more commonly used, and for a smallish investment I could save weeks, if not longer, on writing my own editor and 2D extensions.

Despite this, I’m drawn heavily to rolling my own engine. At my core I think I’ll always be a programmer and want to get elbow deep in code. And, if I’m honest, I think it would be more fun.

But fun isn’t my goal, getting a game finished and out the door is. I suspect that I’ll pick up a side project of writing my own game engine (something of a resurrection of the Alta Engine that I started this blog to write about all that time ago!) but my focus will be on getting my game done in Unity.

Development  is due to start in April, and I’ll be blogging every step of the way.

Watch this space!

Leave a Reply

× 7 = twenty eight

Proudly powered by WordPress. Theme developed with WordPress Theme Generator.
Copyright © Rabid Lion Games. All rights reserved.