28 Years Later, I still haven’t finished my games

When I was eight years old, I used to make games.

Well, that’s not entirely true. I used to start making games.

I’d come up with some elaborate idea, spend hours getting the first level working, and then immediately start thinking about all the other things the game needed. More levels, more enemies, more weapons, more complicated mechanics. Eventually I’d get bored, encounter something I couldn’t work out how to build, or come up with another idea that was obviously much better.

And then I’d start again.

Twenty-eight years later, I’m pleased to report that absolutely nothing has changed.

I’ve got better at programming. I’ve learned new languages, picked up proper game engines, discovered design patterns and acquired a frankly unnecessary understanding of software architecture.

What I haven’t learned is how to stop turning a perfectly reasonable game idea into a project that would require a team of 40 people and a modest publishing deal to finish.

The main difference is that eight-year-old me would get stuck trying to make a game and give up. Thirty-six-year-old me gets stuck trying to make a game and decides the solution is to build an entire software development kit to make the game easier to build.

Which is obviously much more sensible.

So, in the spirit of celebrating nearly three decades of making the same mistakes, here are three games I’ve started, loved and eventually put on the shelf.

The Ninth Host

Ocarina of Time, but with Vikings and a possessed arm.

The Ninth Host was one of my earliest serious attempts at building a 3D game in Godot.

I’d grown up loving Ocarina of Time and Majora’s Mask, so naturally I thought I’d have a go at making something along those lines myself. After all, Nintendo managed it in the late nineties. How difficult could it be?

The premise was that a Viking becomes stranded on a mysterious island, where an evil spirit possesses his arm. This is understandably quite alarming, but it does come with some benefits. The arm grants him necromantic powers, allowing him to raise the dead and cast supernatural spells.

I liked the idea of a character who wasn’t necessarily comfortable with the abilities they’d been given, but gradually learned to use them to survive. There was something appealing about a fairly traditional Viking warrior wandering around with an increasingly unnatural collection of powers.

The game was intended to be a mixture of exploration, combat and environmental puzzles, with new abilities opening up previously inaccessible areas. Very much in the spirit of those N64 Zelda games that had inspired it.

I actually got a reasonable playground working, including experiments with raising the dead and some of the other abilities. It was enough to demonstrate that the core idea could be fun.

Unfortunately, I’d overlooked one fairly significant detail.

Making a 3D adventure game requires making an entire 3D adventure game.

I was still learning Godot, and suddenly found myself dealing with character controllers, animation, lighting, physics, cameras and the small matter of constructing a believable world.

In my head, I was making Ocarina of Time. In reality, I was spending an evening trying to work out why a character was falling through the floor.

It became increasingly obvious that the scope was completely unreasonable for my experience at the time.

Eight-year-old me would probably have drawn another level on a piece of paper and then started something else. Adult me spent considerably longer trying to solve the problems before eventually arriving at exactly the same conclusion.

The Ninth Host went on the shelf.

But it hasn’t disappeared entirely. Some of the exploration ideas, environmental puzzles and technical systems have since found their way into Pine, another project that’s still, in the loosest possible sense, in active development.

I’d love to revisit The Ninth Host one day. I still think there’s a good game in there.

I just need someone else to build the 3D world.

Mark of the Twelve

Baldur’s Gate meets XCOM meets Yahtzee meets a complete inability to control scope.

One of my earlier projects, Carve the Fate, involved Yahtzee-style dice mechanics. I really enjoyed the idea of turning random rolls into strategic decisions, and started wondering what else I could do with the system.

A sensible person might have made another small dice game.

I decided to make Baldur’s Gate.

Mark of the Twelve was intended to be a party-based RPG with tactical combat inspired by XCOM, but with attacks and abilities determined by Yahtzee-style dice combinations.

Players would roll dice and assemble combinations to activate different attacks, spells and abilities. Each party member would have their own characteristics, creating different tactical opportunities depending on who was in the party and what dice were available.

You’d also have to consider positioning on the battlefield, making decisions about whether to settle for a reliable attack or gamble on a more powerful combination.

I still really like this idea. There’s something satisfying about combining the randomness of dice with the deliberate positioning of a tactical RPG.

And unlike The Ninth Host, I wasn’t particularly worried about whether I could build the core mechanics.

I was worried about everything else.

RPGs need a ridiculous amount of content. Maps, NPCs, conversations, quests, branching dialogue, encounters, character progression and all the little interactions that make a world feel alive.

So I came up with a plan.

Rather than spending ages manually building all that content, I’d create an SDK that made it incredibly easy. A visual editor for maps and locations, tools for dialogue and quests, systems for configuring NPCs, encounters and character statistics.

Once it was finished, I’d be able to create the game at an incredible pace.

This is where the story becomes depressingly familiar.

I spent an enormous amount of time building tools to help me make Mark of the Twelve, and comparatively little time actually making Mark of the Twelve.

Every time I was ready to start building content, I’d realise the editor needed another feature. And because the whole point of the editor was to save time, it made perfect sense to spend another few evenings implementing it.

I had essentially invented an entirely new game development engine as a prerequisite for making one game.

Eight-year-old me would have been delighted. He loved making level editors and coming up with systems for games that didn’t exist yet.

Thirty-six-year-old me should probably know better.

Eventually I had a substantial technical foundation, an increasingly complicated SDK, and not very much actual RPG.

Mark of the Twelve went on the shelf too.

Of all three projects, this is probably the one I’m most tempted to resurrect. I still think the dice-based combat has real potential.

But if I do, I’m starting with one encounter, a handful of characters and absolutely no custom development tools.

I give that resolution about three days.

Cycic Citizen (FPS)

Because apparently using an existing game engine would be cheating.

Cycic Citizen has a slightly longer history than the other two projects.

The original was a top-down spy game I made as a child, heavily influenced by Metal Gear Solid and GoldenEye. I only ever made one level, which involved infiltrating a base and stealing a tank.

Presumably because I’d played GoldenEye and decided that was what spies did.

Years later, I thought it would be fun to revisit the concept as a retro first-person shooter, inspired by games like Doom and Wolfenstein 3D.

But rather than using Godot or another existing engine, I decided to build my own raycasting renderer in SDL.

Because why make a game when you can spend weeks writing the technology required to display a wall?

To be fair, this was probably the most successful of the three experiments.

Raycasting is a fascinating technique. By casting rays through a two-dimensional map and calculating where they intersect walls, you can construct a convincing first-person environment without a conventional 3D renderer.

There’s something incredibly satisfying about getting that working from scratch. Suddenly you’re walking around a world that exists entirely because of some maths you’ve written, rather than because a game engine has done all the difficult work for you.

I ended up with a genuinely good working prototype, and learned an enormous amount about rendering in the process.

Naturally, I also started thinking about building tools to make level creation easier.

Some things really don’t change.

But unlike the other projects, Cycic Citizen wasn’t really abandoned because I’d become overwhelmed by the scope or buried under development tooling.

Something else simply caught my attention.

I’d achieved a lot of what I originally set out to do. The raycaster worked, the prototype was playable, and the technical challenge had been immensely satisfying.

Then another idea came along, and I wanted to work on that instead.

Which, now I think about it, is probably the most authentic continuation of my eight-year-old development process imaginable.

The More Things Change…

It’s funny looking back at the games I made as a child and realising how little my approach has changed.

I still get excited about mechanics before I’ve thought about how much content they’ll need. I still start imagining enormous worlds before I’ve finished the first level. And I still have a tendency to convince myself that building a complicated editor is somehow going to be quicker than just getting on with making the game.

The only real difference is that I’ve now got 28 years of programming experience to help me make the same mistakes considerably more efficiently.

But I don’t think any of these projects were a waste of time.

The Ninth Host gave me ideas and systems that have survived in Pine. Mark of the Twelve taught me a huge amount about tactical mechanics, RPG architecture and the dangers of overengineering. Cycic Citizen taught me how to build a raycasting engine from scratch, which was enormously rewarding in its own right.

And perhaps most importantly, all three were fun to work on.

I think there’s a tendency to judge game development projects purely by whether they get finished. If something never makes it to release, it’s easy to think of it as a failure.

But sometimes the point is simply to experiment, learn something new and see whether an idea works.

These games might never be finished in their original forms, but bits of them will almost certainly keep turning up in whatever I build next.

And who knows? Maybe I’ll revisit them one day.

For now, I’m concentrating on finishing my current projects, keeping the scope manageable and resisting the temptation to build unnecessary development tools.

In fact, I’ve recently been working on a rather elaborate map editor and SDK for Static, which should make developing the game much easier.

I’m sure this time it’ll be different.