Two and a half years in reflection

I’ve been developing games for quite some time now; I started back when I was in primary school. It started when I typed “game maker” into Google, and 11 years later after developing games between education and work, I’ve released two games: Planet Attack and Dimension Jump.

Recently I tried to make a “big” game. It was called Unearth, and it was ambitious. The worlds were procedurally generated. It had online multiplayer. We were going to generate the stories and quests within the game. The description from the website paints a picture on just how ambitious this was:

Unearth is an action/exploration game featuring infinite and ever-changing worlds. Traverse multiple realities while battling alone or with friends. Discover incredible mysteries, inhabitants and environments while uncovering and casting primeval spells.

The project started when Josh Harvey and myself were experimenting with procedural generation at the very first TIGJam Australia. We continued developing and experimenting with the code we had, and over time the design changed and morphed as we recognised what we could and could not do with the constraints we had.

For all of the technical complexity around this idea, I managed to handle the programming related tasks required; online multiplayer worked smoothly, the game ran on all major desktop platforms (Windows, Mac and Linux) and the procedural generation produced somewhat decent results in a optimized manner (although a large part of the algorithmic work was done by Josh Harvey).

Josh Harvey for the most part handled design, while I handled programming / technical implementation. But we both lacked a skill area which is essential for game development:

Neither of us could draw.

Early on we pushed it over the fence; “we’ll cross that bridge when we come to it” as they say. We figured if we can get something demonstrable and a prototype that works, it’d be much easier to get funding to hire an artist from various government bodies.

But here we made more crucial mistakes:

• We assumed funding bodies would accept and judge applications based on prototypes and demonstrations. When we eventually applied for funding, the primary feedback was that they wanted to see the game at an “Alpha” state, and that it was too early to apply for funding with the game in the state that we had it (as at the start of 2014).
• We never ran the numbers until we started the application process. This sounds stupid, but it’s true. When we were saying to ourselves that we could hire an artist later, we should have been running the numbers then, not 12–18 months later.

In reality, it turns out that while $50,000 sounds like a lot on paper, it’s practically nothing when you start talking $/hour rates for an artist over a 12 month project. And when you throw in co-working space rates, legal and marketing overheads, and general expenses, you start having to seriously reallocate money in the budget so that everything can be afforded.

We didn’t get funding in early 2014. From there on out, things changed considerably:

• For various reasons, Josh Harvey left as the designer on the project.
• As the project required a designer, Josh Bradbury who was the artist at the time, decided to work on the project on a revenue share basis, in exchange for greater control over the game design.

We reflected on the project’s current state, the feedback we’d got from funding bodies, and we set ourselves a goal:

We were going to submit to IndieCade 2014.

We meticulously detailed everything we thought needed addressing and set about completing all of those tasks by the late submission deadline. Our goal wasn’t to get anywhere close to nominated (the game was still far too buggy for that); instead our aim was to receive feedback on the game design.

Perhaps one of the things I’m most pleased about during this period was that Josh Bradbury has a keen eye for polish and detail. Hundreds of “okay but not good enough” issues and bugs were addressed during this period, and by the late submission deadline, the game had made significant leaps and bounds in terms of playability and giving the player goals.

On June 15th, we submitted Unearth to IndieCade. For a week or two we fixed more bugs and added more polish. By this time, we had the Unearth game launcher which could be used to download and update the game as needed. Although we couldn’t radically update or change the IndieCade version, (since judges could potentially play the game at any time), it did give us the breathing space of last minute fixes.

After this however, it was pretty much a waiting game. Josh Bradbury went off for contract work, and I went off to work on side projects and increased hours at my day job.

Eventually when the finalists were announced, we received feedback from the judges on Unearth. Unfortunately the feedback we received wasn’t particularly detailed on the game design elements; we didn’t end up learning anything from the feedback from the judges that we didn’t already know.

This was pretty disappointing and a pretty big demotivator; we felt as though we had sunk a lot of our time crunching for the submission deadline.

We reconvened at the beginning of November, and Josh came back from contract work with a fresh look on the current design of the game and proposed a new, radically different take on the game, and what it means to explore an infinite world.

I want to stress at this point, that I don’t fault Josh for this; given the feedback we’d received and the issues that had arisen in the original design, it’s perfectly reasonable to propose radical changes. On the whole, had we continued and redeveloped the game with the new design, I would have played it (this is my criteria for “am I developing the right game?”)

But it was a radically different design. It would have involved throwing away a reasonably large portion of the technical implementation that had been made over the last 2 years, not least the infinite chunk handling and rewriting the procedural generation.

At this time, I’d also particularly shied away from working on the procedural generation code; after 2 and a half years, changing the procedural generation for things such as terrain were very uninteresting. The prospect of rewriting it was a very large demotivator.

At this point, there were no more options.

If I were to stick with the original design, I’d need to find someone to address design issues, and I’d be back to finding funding for paying an artist. Even if I managed to achieve both of these, it still didn’t mitigate the issues with the original design, which were very real and very difficult to solve.

If we were to go with the new design, we might have been able to push on for a few months, but I would have almost certainly been completely demotivated once we started rewriting the procedural generation.

Thus marked the end of developing Unearth. No option had a reasonable chance of success, and one has to be careful of the gambler’s fallacy. At this point, having already revived the project once, I decided to cut my losses and terminate the project.

Am I disappointed? No.

It sounds strange that throwing away 2 and a half years of work (and a non-trivial amount of money).

But at the end of the day, the skills I’ve learnt from developing Unearth, are practically inenumerable, but a few major technical ones are:

• 3D rendering and shaders. Prior to developing Unearth (and working heavily in MonoGame), I didn’t have a particularly strong grasp of how 3D hardware works under the hood, neither the constraints it imposes nor what optimizations are necessary to gain acceptable performance.
• Decent real-time networking. Although I’d built networked systems before, having to implement network communications that are acceptable for a real-time game is not trivial. Not only do you need to build a protocol on UDP with optional reliability, but you also need to implement and handle input prediction and entity replay.
• Memory management and pooling in C#. It’s seriously easy to file things under “let the GC handle it”. But chunks in an infinite game world consume a lot of memory, and avoiding allocations of these chunks is essential for game performance. I’d still avoid writing games in C++ though (letting the GC handle small and infrequent memory allocations is still far easier than using full memory management).

In terms of non-technical skills, I walked away with the experience of applying for funding, some marketing / social media skills (although this was more handled by Josh Harvey), and plenty of knowledge in having the right tools to aid in development.

There is one glaring omission however.

It’s easy to point at various different events in the project that led to it’s failure, but the root of all causes; the earliest decision which set us on the course of events that played out, was assuming that we (Josh Harvey and myself) could get away without having any artistic skills.

Because we assumed that, it meant we were reliant on funding later on, and because we didn’t get funding, it meant that I had to focus on determining a way for the project to move forward.

Changing designers part way through the project was almost guaranteed not to work, and in hindsight I should have seen that. Josh Bradbury has his own ideas and thoughts around what it means to explore in games, and for the first year and a half that feedback wasn’t present at all. Naturally when the project changed designers, I should have expected the design to change significantly at some point, but at the time I was far too focused on ensuring the project continued, rather than focusing on whether the project could continue successfully.

In recent months I’ve had time to think back on this. The more that I thought about it, the more that I’ve realised my inability to draw has constrained, restricted or contributed to the failure of games that I’ve worked on.

I’m not just talking about Unearth here; there are plenty of previous games that I’ve worked on, that have never been released; that have failed because I’ve been unable to visually convey meaning in what I’m developing. If you’ve ever played Planet Attack or Dimension Jump, the art in those games are very basic and symbolic, but abstract art can only get you so far, and it does have some serious limitations when conveying meaning.

I’ve known this for years, and I’ve never acted on it. Over the years I’ve accumulated skill debt, in the sense that I’ve never taken the time to learn all of the skills I need to make games independently. And like all debt, at some point you have to pay it down.

So that’s what I’m going to do.

With the exception of the Global Game Jam, I’m not going to start development on any more games until I’ve learned how to draw (and to another extent, 3D modelling).

I realise this will take a long time; years even. But if every game I otherwise make from here on out is almost certain to fail because I lack the skill to draw, then years is an acceptable cost.

If you’re still with me at this point, thanks. Reflecting and collating my thoughts on the last two and a half years hasn’t been an easy process.

From here on out, this blog is going to be a collection of things; technical posts, various life events, and hopefully, eventually, at some point in the future, a place where I can post the progress I’ve made.