The Golem – Open Playtesting

On January 31, 2019, in projects, by bateleur

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. 🙂



On March 30, 2016, in Uncategorized, by bateleur

LibraryEarlier this month I got a telephone call from Unity. After blowing the dust off my phone and a brief struggle to remember how the thing worked I found myself talking to an articulate woman with a Danish accent who, after collecting all the usual data from me, wanted to discuss discoverability. Had I heard of "Made With Unity"?

Yes, yes, of course. It's a hashtag that comes round every Friday. I may be in my forties, but I'm down with the Twitters. Brief confusion follows and I learn that it's also a website. With my free hand I type into my web browser and it turns out to be some terrible Christian site. Actually it might not be terrible, but God and I don't really get on. Turns out where I really want to be is – ah, good, discoverability is solved and we can all go home!

I spent about an hour looking around the site, but after the first thirty seconds I knew it wasn't going to be any help. The problem? It was showing me things, not asking me questions.

Discoverability seems to be a widely misunderstood problem. It's not about showing players a few games they might not have seen before at random. There are far too many games now for that to be helpful, if it ever was. At its heart discoverability is about matching players to games they might like.

The current state of the art seems to be "genre". And if that provokes an immediate rolling of the eyes I suggest taking a quick look at the world of books, in which genre is still the most widely used approach to finding things to read. Nonetheless, the problems are obvious. I recently added King Machine to the vast repository of knowledge that is IndieDB. The "genre" field is mandatory and none of the options were even defensibly close to the game's actual content. I resisted the tempation to classify it as a Noire Car Combat game, because that's an actual option. So is Mafia MOBA. I mention this to make clear that it's hardly light on options and adding more really doesn't make genre work any better.

If books and films and music suffer from the same problem then there must have been serious attempts to make progress, right? Yes, indeed so. In 2006 Netflix offered a prize of $1M to anyone who could significantly improve their algorithm for recommending movies to users. Being something of an algorithms person I had a quick go myself and very quickly concluded the problems were too far from my field. The money was eventually claimed in 2009 by a team which only cleared the 10% improvement threshold by a whisker. Netflix remains, to this day, bad at recommending movies. But at least it's 10% less bad.

To be clear, the problem Netflix had wasn't ultimately algorithmic in nature. The problem was that the ratings data users provided didn't actually contain enough information to predict what they'd like with anything approaching reasonable accuracy. So if genre doesn't work and extrapolating from other preferences doesn't work then what does?

Another well known matching problem – and very extensively studied – is dating. At first glance it may seem radically different. After all, the most common version of the problem involves searching for only one partner. It seems to me there are a lot of similarities, though. In particular, people don't know what will make them happy. They think they do, but they're often wrong. The data from dating sites is incontrovertible in this respect, but for games it's equally obvious. Most players claim to want good gameplay, then assess what to play based on brief snatches of video.

The rise of "let's play" videos addresses this part of the problem. At the expense of a few spoilers, the viewer gets to see games as they really are. Not quite the same as playing yourself, but decently close. So is this a solution? Unfortunately not. Let me tell you a story…

Back in 2010 a game jam was held in Cambridge, UK. TIGJam UK 2 was primarily a meetup for members of the TIGsource game development community. I'm an early riser and grew up in Cambridge, so arrived early on the second day and headed upstairs in CB2, plugged in my laptop and got on with coding. Five minutes later someone else arrived, looking like he was probably a games person, and came over to introduce himself. We chatted briefly about his recent resignation from and his game, Minecraft. He was surprised I'd heard of it and seemed quite pleased. Four years later he would buy a mansion in Beverly Hills with the proceeds from the same game, largely thanks to (by his assessment) YouTube videos. The point being this: let's plays are a great way to take your playerbase from thousands to hundreds of thousands, but by the time they're getting made your game has already been discovered. Even for Minecraft, that initial discovery was a hurdle.

Don't you only need one player to go viral? Well no, not really. Viral content is largely a myth. It exists, of course, it just doesn't spread in the way you might imagine. The graph of shares is actually very flat. Vast reach is achieved mainly via a very small number of nodes (people, sites) with individually vast reach. In other words, virality does not provide discoverability.

Before I talk about how we might improve discoverability, I should briefly address the "good game" myth. Every so often someone will try to claim that discoverability isn't an issue and that all you have to do is make a "good game". Sounds like sensible advice – after all, who wants bad games? – but unfortunately as well as being useless advice it doesn't work well. I recommend Alexander Bruce's outstanding GDC talk "Antichamber: An Overnight Success, Seven Years In The Making" for anyone who thinks this way. Although perhaps a simpler example still is J.K. Rowling's experience with her book "The Cuckoo's Calling". Written pseudonymously as Robert Galbraith, she hid her identity when approaching publishers and got the same dismissive rejection letters than any unknown author is familiar with. After publication the book sold only around 1500 copies… until her identity as the author was revealed and then suddenly it was Amazon's #1 bestseller. Was it a "good book"?

So how can we improve discoverability for games? From my perspective: better communities. Replacing bulletin boards (before you were born, kid) and forums with social media has a lot of upside, but the serious downside is that our conversations about games are hidden, or at best compartmentalised. I see a lot of creative people frantically accumulating Twitter followers, but for those who take it seriously it's thousands of hours of work for very little payoff.

If tens of thousands of players had access to the firehose of game releases that journalists are perpetually swamped by, we'd have the capacity to sort through it, to find our own ways of classifying things and getting them in front of people who want to see them. YouTube and Twitch handle presenting games fairly well, so that just leaves the finding part. And that's why you need a community of some kind, because when you find interesting things you need ways to share what you've learned. Even more so once you get as far as playing something.

There was a brief moment in 2012 when it looked as though major progress was being made in terms of distribution. I went to a meeting in London hosted by Steam, where they told us about their plans for their new Greenlight service. And last week when King Machine went up on Greenlight I got a glimpse of how things could work. Fifteen hundred potential players in two days! And they liked what they saw, with many positive comments and the all-important votes coming in thick and fast. Then, like every game on Greenlight, the traffic stops. Not because of anything I did. Not because of anything about the game. That's how the system works. Valve give you two days of traffic for free and then you're done.

Never mind games trying to get into Steam. What if we did something like this for all games? And what if it wasn't just for two days? Any time you felt like playing a new game you could just ask the site to show you one. And another. And another. Everyone's games, without limitation. And a place to discuss and share recommendations. Honestly, I'd build the site myself right now if not for one minor problem…

…nobody would know it existed, so they wouldn't use it. You know, discoverability.


King Machine Launch!

On March 23, 2016, in King Machine, projects, by bateleur

Having failed to do any regular blogging during the development of King Machine, I should at least announce that King Machine launched yesterday!


Here are a couple of links…

Buy King Machine (or download the free demo) on King Machine on

Vote for King Machine on Steam Greenlight (if you'd like to play it on Steam): King Machine on Greenlight


IGC 2015

On March 10, 2015, in Events, by bateleur

Last week I went to the Indie Games Conference 2015 in London. I wasn't just there for the free food kindly provided by Microsoft, or even for the talks (which were very good, even the ones not particularly aligned to my interests). Byron Atkinson-Jones had kindly let me have a speaking slot. Since most of you probably weren't there – it's a much smaller event than GDC – here's a video version of the talk I gave. It's about puzzles.

…now to get back to finishing the King Machine beta. It's pretty close to done! 🙂

Tagged with:

We Need To Talk About Spiders

On November 28, 2014, in King Machine, by bateleur

Spiders! King Machine is for the most part not a game about "enemies", but there are some characters in the game besides the player. One such character type are the mechanical spiders which cause problems for the player on some of the levels. And recently they've been causing problems for me too. They're fixed now, but it took a ridiculously long time (nearly a month) so I thought I'd write about this a bit. This is probably mostly of interest to other game designers, but there may be a bit of crossover into other kinds of programming.

So what was the problem? Well, in King Machine the player can alter (and even outright create) bits of the environment. The spiders have to traverse this environment correctly no matter what shape it is. Algorithms aren't something I find difficult, so I happily sat down and wrote a thing which treats the level like a graph and has the spiders traverse it. Easy! Took about an afternoon. Then the problems started.

First problem is that the spiders walk by raycasting possible leg placements. This looks great a lot of the time, but breaks horribly in a few cases. In particular, if something blocks the spider's body but none of the legs are touching it, the spider just gets stuck. Imagine a spider running like crazy, with its forehead pressed against a telegraph pole. Fixing this requires forcing the spider to walk on any surface which obstructs it.

Not that all the problems were with the legs. Next, imagine a sequence of cubes arranged into a path. The spider navigation algorithm easily plans a route along this path. Try it with the spider and it works. But what happens if you put a flat, square board over one of the cubes? Now the spider walks the same path, but when it tries to walk on the cube under the board it never reaches it because the board's in the way, so it just carries on walking. This is a problem with the pathfinding – it assumes that given two touching objects one is always reachable from the other, which is clearly wrong. Fixing this involved a massive increase in complexity as the spiders started looking ahead a bit to what they could actually reach and trying to walk around obstacles. And "around" itself is hardly a simple concept in 3D space!

Now if you're an experienced software developer you're probably already rolling your eyes by this point. And maybe also muttering things about complexity creep and keeping things simple. Maybe you'd recommend fundamentally changing how spiders move to something more manageable? Maybe you'd recommend throwing them out altogether and picking something easy? Good advice. Good advice.

So why didn't I? I see the problem the same way, but I don't agree with the objective. King Machine has been full of problems like this. Things which are awkward and complex and take far longer than they should. But if you go through a project and discard any interesting feature that is hard to implement, what you end up with isn't the thing you were trying to make. Some developers don't have a choice but to pick easy paths and ship as fast as possible. Given that I'm fortunate enough to have the option, I want to use that flexibility to make games other designers can't make.

That's not to say the spiders were really a good idea. A problem which King Machine has had all along is that the version of the game in my head was too complex for a one person team. I didn't know – and still don't know – how a really stripped down version of the game would work. Attempts to reach for a minimum core gameplay just looked too much like puzzle games. I like puzzle games, but King Machine isn't supposed to be one. Perhaps ultimately a certain amount of complexity is needed to support creativity?

Tagged with:

The Right Mouse Question

On February 7, 2014, in King Machine, by bateleur

Two MiceInternet, I have a question for you: is it OK to implement "look around" in a 3D game by having the player drag with the right mouse button held down?

Now to be clear, I'm not asking whether this works as a control scheme. I already know it works. But it might still not be OK. Let me explain why…

I'm a great believer in playtesting. An important principle of good playtesting is that if a playtester raises something as a problem, then there is a problem. King Machine has been in development for a long time now and been through many control schemes, but one thing playtesters have quite often asked at the start of their very first play is "Why isn't mouse look always on?". So I explain that it's not always on because you need a mouse cursor. Why? For manipulating objects. For interacting with menus. "Why not lock the mouse cursor to the centre of the screen and get rid of the menus?" is usually the followup question. Well, if the bot turns at a reasonable speed that makes the cursor move uncomfortably fast for object manipulation. Also, some object actions look weird with the camera moving about. Also, the menus are a good way to control… blah, blah, blah…

But here's the thing: no matter what my reasons are for the design they won't stop every single new player potentially feeling the same way, which is a problem.

"New player"? Well yes, because here's the thing: after a player has been playing for a while, the problem goes away. How long this takes varies with (I suspect) how accustomed they are to FPS controls. The control scheme works pretty well using right mouse.

So here's why I'm posting this: I'm getting towards the later stages of development now and I really need to stop changing the controls and focus on finishing the levels and suchlike. Also, it's really hard to write the help system when the controls keep changing! The question is, what should I do with mouse look?

* Change it so that mouse look is always on. Effectively sacrificing quality of control for accessibility (and possibly ease of use in some cases).
* Leave it unchanged, trusting players to settle into the controls rather than giving up 30 seconds in.
* Have both schemes available, with a toggle in the options somewhere (which still leaves the question of which should be default).
* Some other solution, such as having mouse look toggle on/off with a key.

Votes and opinions encouraged! Of course, the natural response to that is "I'd have to play it and see how it feels". Reasonable… but actually wrong. The thing is, even by reading this post you already know too much! Most players won't have read this post and won't be thinking about the same issues at all as they play for the first time. And of course, as with anything, nobody reads the instructions!

Tagged with:

Alpha Release

On January 14, 2014, in King Machine, by bateleur

So, I decided that King Machine was just about at the point where it made sense to open up preorders. And indeed, as is fairly standard now, preordering will get you access to an alpha version which I plan to update regularly as development continues.

More details on all this later, but for now you can watch the nice, shiny video tutorial for the alpha sandbox…

Tagged with:

King Machine Trailer

On October 3, 2013, in King Machine, by bateleur

So, having been quietly working away at the game for some time now, I thought it was about time for a proper trailer. (Looks a bit fuzzy here because it has to be squished to fit on the page. You can watch it in 720p on YouTube if you prefer.)

Special thanks to Ed Fry (@Aeronic) for the music and Emma Newman (@EmApocalyptic) for the voice clips!

I need to have a proper think about whether to have some kind of alpha release and, if so, how soon. Might also mean I start using this blog a bit more. But then, I always say that. 😉


Tagged with:

How To Not Make Bad Games

On January 6, 2013, in King Machine, by bateleur

It is a well known and widely accepted thing amongst game designers that extensive playtesting is important. In fact even if you thought you already knew this, there's a fair chance that playtesting is more important than you think it is. But there's another aspect to playtesting which is less often discussed.

First, let's have a King Machine screenshot:

KM Screenshot

It's changed quite a bit since I last posted here. The actions available to the player have changed a bit and the interface to them has changed massively. Also, the player's robot now has cute little feet. That last is by far the least important change. But still… CUTE LITTLE FEET!

So here's the thing about playtesting: everyone knows you have to do some. Most people know the testers have to be people not on the design team. But what isn't nearly so widely recognised is that if you testers flag up a problem you have to fix it. Or more precisely, you have three options:

  1. Fix it.
  2. Decide not to fix it because different testers disagree over whether it's a problem or not.
  3. Ship a bad game.

Maybe you're laughing at option 3, but it's a lot more popular than you might think.

A big problem with playtesters is that they're often too polite. They say "I had some difficulties" when then mean "this stinks" or "perhaps it would be better if" when they mean "the current approach is beyond terrible". Fortunately there is a known fix for this problem: watch people play.

About five months ago, I spent some time watching people play King Machine as part of the UI redesign. What I learned was that the game was really annoying. Players mostly knew what they were trying to do quite quickly, then spent literally several minutes fighting with the game to let them do it. At the time I'd been thinking the game needed a better help system, but that wasn't really it. The problem was that even the redesigned UI was too fussy. It was very precise, but it was the bad kind of precise that forces you to care about exact control and play extremely patiently. Players seemed excited by what they could do in the game, but the act of doing it wasn't much fun.

What I did about this was simple: I rebuilt huge sections of the game. It took about six months, on top of the UI redesigns I'd already done.

The problem with this sort of thing is that it's enormously expensive (taking a long time), not very sexy (I haven't been blogging about the process for this reason) and if you get it right then nobody will ever notice. Which is why developers sometimes don't bother and just kid themselves that everything will be OK. But once the game releases, players are consistently unforgiving of bad designs.

Is King Machine's interface good now? Actually, despite all the rebuilding I still don't know. It's definitely a lot better, but more – hopefully minor – changes will likely be needed before it reaches its final form. Fortunately everything gets easier from here. I'll be blogging a bit more about the development now that it's mostly back to more interesting areas and in a couple of months or so there should be some kind of demo release so that people can finally get their hands on the game.

Not that this means the game is close to release yet. Feedback from more people is something I'm really looking forward to, but between then and release the aim is to refine the game further based on their comments. Because releasing bad games really isn't in anyone's interests.

Tagged with:

How Would You Like It To Work?

On December 1, 2011, in King Machine, by bateleur

I spent last week fixing my pooter, which was generating pretty regular blue screens of death thanks to a dying motherboard. I'll spare you the details. Suffice to say it works again now!

This week, I've been improving King Machine's basic building UI.

Building a fence in King Machine.

This is a process I've left much longer than I should have done for the simple reason that the old UI worked. I could build more-or-less anything I wanted with it. As a result, improving it didn't seem like a priority. Also, perhaps more relevantly, improving it was less fun for me than designing levels, making machines, creating artwork or coming up with new machine parts.

The problem is, there's a big difference between being able to make something with the old UI and the process actually being smooth enough to be fun. Players in King Machine will need to build a lot of stuff and if that process is fiddly and demanding it's not going to make for good gameplay.

So what have I changed?

The main difference now is that there's no need to use the menu at all to line up objects in basic ways. Clicking on the edge of an object will align the edge of the object you're holding with it and pull those two edges together. This makes it far, far quicker to build walkways and surfaces your bot can travel along. Clicking on a face of an object will align the closest face of the object you're holding to it and pull those faces together. This makes it much easier to build complex structures with all the relevant parts lined up correctly.

I'm also experimenting with automatically switching between grab mode and build mode. I have mixed feelings about this. On the one hand, it's quite common to grab something, carry it for a while, then want to build with it at the far end. On the other hand it's annoying to have the game switch modes when you didn't want it to. I'll probably need to wait for playtest results with this feature to work out if I want it.

Next step is to rethink how wiring and logic work. These are the aspect of the game most strongly tied to earlier versions of King Machine, so I've been reluctant to mess with them. On the other hand, you know what they say about sacred cows.

They go "moo".

Tagged with: