What if I suck at game development?

So this is kind of a followup to the last post on switching to Unity. Basically I’m now making an actual game in Unity, instead of making an engine for a game in C++/OpenGL. It’s massively changed what I’m doing day to day; instead of implementing new engine features (collision detection, graphics pipeline, etc) I’m adding new game features. I can see pieces falling together so much faster, but of course there’s a massive catch; what if I’m not as good a game developer as I was an engine developer? It’s not unlike moving to a completely new role at work. I was quantifiably good at writing game engines – my code worked, mostly followed best practices, very few bugs, appropriate optimisations… all of the desirable qualities. But I’m not an engine programmer any more, I’m a game developer or something!

Here’s a good example – I recently completely removed a collectible resource from my game – water was identical in every way (turned into biowaste by people, replenished by food synthesisers) – so there was literally no point to having it. Was that the right thing to do? Would it have been better if water acted differently – if it was turned into sewage that had to be treated separately? What if there was a slight drain so the player was always under some pressure to get more? I have theories about how these alternatives would play out, but I chose what I thought to be the best option. I will literally never know if that was the right choice. At least with engine design I could quantify my options – one method uses X more texture lookups but needs Y% less CPU cycles for example.

The answer is probably in making smaller games, or even game jams, as an exercise in understanding game design and development. I find these super hard to work on though, particularly as I just can’t art so I feel that everything I make looks shitty, which evolves into thinking the game itself is shitty. I probably need to just get on with it and stop complaining!

I guess I’m just scared because whilst this is new territory, I’ve been on the sidelines looking in for the last decade and I think that I should know exactly how it all works. Or maybe I just know enough about game design now to also know how bad at it I am? The really scary part is that I’ve defined myself as a game programmer for a couple years, I can’t imagine what I’d think of myself if I sucked at it.


Are you making a game or an engine?

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.