I've written the same game four times.

As with film trailers, a brief glimpse of a game is often more exciting in our imaginations than the reality. Puzzle classic The Incredible Machine was like that for me. It was a long time before I got to actually play it. By the time I did, the gap between the game itself and the way I'd imagined it spoiled most of the fun. Fortunately, one of the upsides of being a game designer is that if someone else has inexplicably failed to make the game you wanted to play, you just make it yourself.

I first wrote King Machine in BBC Basic on the Acorn Archimedes in 1993. The idea was to make a game that really was about machines. Not just interactive scenery, but machines that really did things. In King Machine the game board was a grid. Each cell of the grid was a machine part. You could only do one thing to a machine part: "use" it. The simplest parts, wires, responded by using another adjacent machine part. Other parts rotated or moved one another or shot beams across the map which did various things to whatever they first struck.

The first King Machine was a lot of fun, but tremendously slow to play. Each team controlled small, furry, bipedal characters who could carry machine parts around. We only ever played one proper match. During this match, one team built a machine that flew along a short way above the ground, pulling each block below it up by one cell. This strategy was devastating, leaving the other team in a – literal and metaphorical – hole from which they had no chance of emerging.

The reason the game was only played once is because it obviously needed tweaking in some way to prevent the "earthquake machine" strategy from dominating. In the process of thinking about what needed to change I realised that the game needed a concept of a composite object. That is, it needed to be possible to stick things together. To get that kind of power back in 1993 meant I was going to have to rewrite it in ARM Assembler.

The second version of King Machine took a while to debug, but by the time I'd finished it the game was easily the best thing I'd ever written. We played it exactly once. It was great! But again the game's first play exposed a serious problem: building things took too long. Each team built a machine, they clashed, then the game was effectively over as soon as one machine couldn't fly anymore because rebuilding was so clearly impractical.

It was a while before King Machine 3 was written, but by the time it was complete it was miles ahead of KM2 in terms of technology. It was faster, supported far larger maps, included a 'factory' system allowing complex machines to be constructed in a single turn within each team's factory area and had a much better UI. We played it exactly once. Two expert teams faced off. The game took several hours. It lasted only one turn. One team built a giant robot which completed all their objectives in a single move! Everyone agreed the game was a lot of fun, but that it would have to be tweaked in some way before it could be played again.

Many years then passed. My interest in King Machine returned as the era of free-to-play internet games arrived. For fun, I began developing an updated version of King Machine in Java. This one was played zero times. It reached a fully working state, but still more alpha than beta. However, by this point it was much harder to find time for the kind of deep playtesting the game needed. Before testing was complete I shifted my work life to full time game development. King Machine development was paused for the simple reason that after working on games all day I didn't particularly want to spend my evenings working on a different game.

The key new feature of KM4 was mini-maps. An entire machine could be stored in a single map cell, with inputs and outputs interacting with the main map. This greatly improved the depth of gameplay, meaning that machines which did logically complex things no longer had to be physically large.

Perhaps most interesting from a design perspective, though: even having never played KM4 I was on some level aware of problems. A couple of years later I was explaining KM to a friend who had never seen it. He asked why I didn't ever go back and release it. I didn't really know at the time, but I thought about it afterwards. The reason is: even KM4 still had gameplay which was too much about the details of how the machines worked. If your opponent was doing something you didn't like your first recourse was to pull chunks off their machine. If you wanted to defend what you were doing, the main strategy the game rewarded was to build big walls and keep the enemy away. "Good" machines weren't usually clever, they just did simple things fast.

I've written the same game four times, but I still haven't got it right.

So why tell this story now? As you've probably guessed, this is the secret project I mentioned in my previous entry. King Machine is coming back. The details can wait for next year, but suffice to say that this time I'm doing what I explictly declared to be impossible previously: making it a commercial project. Not that I've changed my perspective on the subject significantly. There's a good reason why this is now possible. All will be revealed!