Since I spend most of my work time making videogames, last year I thought I'd relax a bit in my time off by making a videogame. The reason was simple: I wanted to make a puzzle game and doing so is a famously difficult way to pay the bills.

So why make a puzzle game at all? On the various game developer forums I frequent I find myself mainly doing two things: answering people's programming questions and playtesting their puzzle games. It's a particular kind of testing, too. I get bored of most games and give up fairly early, but when I find a puzzle game I like then I'm that one playtester who'll make it through the hardest levels and be grumpy about the slow difficulty curve. This isn't some kind of public service, it's my idea of fun. But despite this and being a games programmer, I rarely make puzzle games myself. The last was UpBot Goes Up – in the early years of this century – which was a collaboration with Luke Davies and Craig Forrester. The former came up with the mechanics, the latter made the gorgeous XBLA version and I coded the web and mobile versions and did a lot of the level design. Then before that my previous puzzle release was the Amiga game Dozer in 1993.

The idea for The Golem arose from a discovery I made whilst testing Alan Hazelden's outstanding Sokobond. It turned out that most players approached levels – even very hard levels – via experimentation. They would shuffle pieces around, making literally hundreds of moves, trying to discover a path to the solution. This couldn't be more different from my usual approach, in which I mostly sit looking at the puzzle and thinking about it, making actual moves only when my ability to visualise what I'm planning fails. The Golem was my attempt to design a game which encourages this style of solving. The aim was to have puzzles with strong key ideas to reward thinking and which were as hard as possible to solve via experimentation alone.

I wrote the game, made some levels and ran a closed playtest across 2018. I was moderately happy with it, but there was a problem: the game was too hard. In particular, because individual levels were extremely taxing to solve, the data showed players would play the first few levels until they found one that was difficult for them and then one of two things would happen. The first was that many would give up, particularly those who weren't keen puzzle players in the first place. The second was that the player would keep going until they beat the level they were stuck on and then give up. Nearly half the game remained untested.

The plan I came up with was to run an unusual kind of playtest. It would be completely open – effectively releasing the current version of the game for free – and would be spread out across an entire month, releasing only one level per day. That way it was more likely that players would still attempt later levels even if they hadn't beaten all the earlier ones and the game would hopefully be able to reach the kinds of players capable of taking on the tougher challenges.

The month in question was January 2019 and the last puzzle went up this morning, so here are some brief thoughts on this form of testing and how it all went…

First, the daily release schedule: this was very successful. A lot of players played every day or nearly every day and being stuck on a level did not prevent them from attempting later levels (sometimes successfully). Also, player numbers slowly increased overall, with new players still attempting the first level three weeks into the month. The whole game got tested in the end, which was the main goal. The main downside was that it meant I was sometimes releasing a level on a day when I was busy. Puzzle playtesting with clever players always carries the risk that someone will "break" the level, completing it in a degenerate way that undermines the intent of the puzzle. This happened many times, but on days when I wasn't at my keyboard ready to address problems rapidly it was awkward.

Second, the testing itself: Excellent! Much credit here must go to the denizens of the 'thinky-puzzle-games' Discord channel. I was invited to post the daily puzzles there by Alan Hazelden (who runs it) and in the end three of my four top solvers were members of that community. Better still, it has been a source of outstanding feedback in terms of getting into the details of which puzzles work best and which don't work well and why.

Finally, the game itself: Surprisingly well received for the most part. It has two and a half major problems and innumerable minor ones, but nothing that can't be addressed. By far the trickiest problem to deal with is avoiding execution tedium in multi-stage puzzles. To explain: an ideal puzzle should be fairly quick to complete once one has the correct solution in mind. Unavoidably, some puzzles stray a bit from this ideal and it can take the best part of a minute to complete a large puzzle. This would still be fine, but what isn't fine is when a solution turns out not to quite work and it takes the best part of a minute to find out and then you end up replaying the first 3/4 of the level several dozen times in the search for a fix.

The second major problem is that the mechanic for one of the level sets turns out to have the potential to be quite annoying if you don't know the solution to the level. And since the point of puzzle games is that you don't know the solution, that's what one might call an issue. This also relates to the half-problem: making a game where players are encouraged to think rather than experiment is all very well, but they will experiment anyway. And when they do, if the resulting experience is no fun then you've still made a game in which people are not having fun. A measure of ingenuity is required here. The game must find ways to encourage players not to rely on experimentation rather than just hoping they do not because it won't work. The reason I describe this as only half a problem is because in fact some of the game's levels appear to already succeed in this respect.

So, what next? One thing the playtest didn't resolve for me is what to do with The Golem as a game. I have got as far as ruling out "bin it" as an option, but that still leaves a lot of choices. More level design and discarding or reworking weak levels seems likely. Do I add in more of the unused mechanics from my design file? Some of them don't seem deep enough, but maybe it's OK to have some mechanics only used for a few levels rather than the sets of eight the game currently has. That might also be the fate of the occasionally annoying 'statue' mechanic used in the last set of levels.

The question of whether to make a shiny version – with improved graphics and sound and maybe a story – is trickier. It would take a lot of time and there's no real chance it would pay enough to be worthwhile… but there might be other reasons to do it. Looking at my other projects and the general state of my TODO list makes it seem like a questionable decision, but maybe as a long term side project? Maybe.

Last but not least, many thanks to everyone who played The Golem this month, whether you completed zero levels or all of them. The experiment worked because you made it work!

PS. Astute readers may be wondering what happened to the 32nd level. Today's level (31st January) is actually the final level. The original level 31 remains unpublished. It was my least favourite in the game, so I decided the world could do without it in the interests of fitting within the month. 🙂