When I started creating Impulse, I was writing C++ in Code::Blocks and using SDL as a graphics library. Of course, I was writing my own engine because that’s what real programmers do and graphics engine technology is really interesting. Culling, shaders, optimisations and most of the graphics pipeline all had a bunch of really cool, interesting problems to solve. But a few months back, whilst fixing the nth bug in a specific part of my optimisation algorithm that would crash once per 5-10 loads (memory bugs woo!), I figured out a decent question:
Am I making a game, or an engine?

I’d made something that looks a little like a game, sure – it had one level, no menu, no multiplayer, no save function, no level logic and was no fun. But look at the glow function I wrote! It does a full screen glow in real time on HD mobile screens without burning through texel lookups! And horrible memory bugs only crash the user’s device once per hundredish launches.

In retrospective I can see what I was doing, but it was very difficult to notice it at the time, after all I was making progress right? Turns out that making progress on your game engine isn’t the same as making progress on your game – they are separate entities!

As you can guess, I switched to Unity and holy magicarp, game development is fun again! I can just throw in a couple dozen lines to do something I was working on for weeks before. It actually only took about 2 weeks before I was at the same point as I was at in my own engine, and I hadn’t used Unity before, nor had any training. My primary worry when I was switching is speed – I do a lot of ray casts for the physics (4 per car per frame) and my custom solution was lightning fast. It turns out that the developers behind Unity are actually paid to work on improving Unity! Unlike most indie developers, the Unity guys can just pump programmer hours into making features fast and reliable, and that’s exactly what they do. What I’m getting at is that a large, organised team paid to work on a function are probably going to do a better job than 99% of indie developers have time to do. This is particularly true for complex or math-heavy portions like graphics and collision detection.

I don’t really care much for C# (Unity’s language of choice) but it gets the job done well enough, and as an added bonus there’s a wealth of features you don’t need to implement yourself. Want to encrypt your save file? Just drop in 10 lines from the crypto library and you’re using a decent enough implementation of modern crypto – easy and fast.

There are of course a bunch of downsides to Unity, but nothing that really outweighs the advantages; certainly no show stoppers. Probably the biggest downside was the hit to my ego of wasting months of time and some really pretty code. The other obvious downsides are giving up complete control (do you really need it?) and having to pay for pro features like the debugger.

I guess it all comes down to that big question – “Am I making a game or an engine?”. Obviously, I always intended on making a game, but before switching to Unity I was getting really bogged down with the details of the engine. Now that I can focus on actually finishing a game and making it fun, it feels fantastic. Sorry if this post feels like I’m a Unity salesman; realistically all decent engines are going to have the same benefits.