The Golem – One Month On

On October 11, 2020, in Uncategorized, by bateleur

The Golem has been out for just over a month, so now seems like a good time for a blog post about how it's all gone.

The best thing about the game has been that – unusually for me – I still like the game and the ideas behind it after release. What's been really interesting to see is that the game's central idea, that players be forced to think about solutions rather than discovering them experimentally, has proven to be much more radical than I would have expected. A number of players have commented that they hadn't seen this approach before, which considering the huge number of puzzle games that already exist is quite surprising.

There is a significant downside to this kind of puzzle, though. I was aware of this before launch, but: the game is hard. This wasn't intentional as such, it simply arises from the fact that thinking about things is hard and humans – even very clever ones – just aren't very good at it. The problem being, of course, that if a game is hard enough it limits who can play. But there is an upside to it too: when a player sits down, thinks about a level and beats it they know they've really achieved something. They come away feeling good about their success and also often with an appreciation for the puzzle design itself.

Speaking of completions, exactly one month after launch the first player that I know of outside the playtest team completed the game! Before launch I wasn't completely sure anyone would do so, but I'm very happy about it. In fact in terms of player progress generally I'm pretty satisfied with the shape of the curve. Not only is there no one difficulty spike, but no clear patterns are emerging in terms of where individual players get stuck, either for short or long periods.

I learned something about puzzle design from watching players and reading their comments. It is well known amongst puzzle designers that good puzzles should not contain things irrelevant to the solution. This seemingly absolute rule can get complicated in practice. If a room is ten columns wide by the leftmost is never used, should it be shrunk? If a wall contains a bump, should that bump be removed if it is not a part of the solution? The Golem adopts an unusually relaxed stance on this issue and focusses on two goals. First, that minimalism should be avoided where it might play the role of a spoiler; giving away the solution in a manner less interesting than letting the player think about the problem. Second, that puzzles should be based around a single core idea and that all other puzzle elements should exist to provide the best possible presentation of that idea. A consequence of this which seems to have caused surprise is that some puzzles even support solutions that leave a block completely unused. Heresy! But in fact there is a simple and important reason for this: if a player has understood the key idea behind a level then I want them to complete it. I don't care if there's a clever way to do it with two blocks. I'll happily give them three if it means that the solution becomes less fiddly to execute.

Of course, there are dangers in extra material. The first is that the player might find an unintended solution that bypasses the key idea. This happened a lot during playtesting and a few more have been found (and fixed) since release. And the other major problem is that extra material can introduce distractions: things which appear to be possible paths to a solution, but which lead nowhere. Such distractions are bad, so care must be taken to avoid them.

Here's what I learned: extra material is not the main cause of such distractions. Not by a long way! Both broken solutions and nasty distractions are caused by levels which give the player lots of power and lots of freedom. Which is a considerable design challenge, because to some extent powerful tools and freedom to use them are fun!

The Golem has some failings in this regard, but they're not nearly as bad as they might have been thanks to an early decision I made to take playtesting seriously on this game. For previous puzzles I've always gone with the usual approach of letting a bunch of people play a beta version for free, listening to their feedback and looking at the analytics. This time, I hired two A-list solvers to go through the entire game finding problems. They did an outstanding job and I would recommend this approach to anyone trying to make a puzzle game of this complexity. (And just a reminder that the game had a separate prototype phase, which also helped a lot with understanding how to build good levels in the first place.)

Just a few more things…

First, given that I'm selling this game a few people have been confused by my description of it as a "recreational project". What this means, in practical terms, is that the game doesn't make enough money to pay my bills. Indeed, after a relatively successful first month it has nearly paid for its own development costs assuming I pay myself zero dollars. My expectation is that future sales will leave total profit from the game somewhere in the low four figures. This isn't any kind of problem, it's just the nature of the games business where niche games are concerned. That's why most of the work on The Golem was done during evenings and weekends.

Second, one thing I didn't expect but maybe should have done is that the puzzle community – particularly other game developers – have been immensely supportive of the game in all kinds of ways. Around 27 years since releasing my first commercial game I'm still not over that feeling you get when people turn out to like it, but what's possibly even better is when you get the feeling or being part of a creative community who are collectively trying to get better at making things. The Golem arose from my wanting to say something about puzzle design. So now I have I get to watch other designers taking the best bits and using them to make even better games, which I will one day get to play myself.

Finally, the single most tweeted thing from The Golem wasn't any level, it was the little passage of text on the About page. In particular, the last two lines "Not everyone will overcome all the puzzles, and that's OK. No matter how great or small your accomplishments, to take time to think about a difficult problem is a beautiful thing." Puzzle friends, I'm glad you feel the same way. ♥


Designing The Golem

On September 10, 2020, in Uncategorized, by bateleur

The GolemThe Golem, my block-pushing puzzle game, was released today on Steam and I want to talk about the design of the game and about puzzle games generally and how they've changed over time and where I hope they're going next.

My previous blog post (over a year ago!) was about the open playtesting process for The Golem, which was a surprising success. At the time I speculated about the possibility of turning the game into a small commercial project. I did indeed end up working on it in my free time as a side project, but the arrival of the worldwide COVID-19 pandemic in 2020 disrupted my work enough that I decided to put my main project down and work on The Golem full time for a couple of months to get it ready for launch this year.

As mentioned previously, my initial motivation in designing The Golem was to create a puzzle where the solution could not be found by fiddling around with the puzzle pieces and simply stumbling upon solutions. This being a very negative thing, I eventually focussed more on a more positive goal: that each level should be built around a single key idea and solving the level should be primarily about discovering that idea. This proved to be a very powerful way to design puzzles, but not entirely without controversy.

Before I talk about why this approach is good I want to talk about what you lose. There are puzzles one can design in The Golem which involve a precise set of moves with multiple pieces interacting in very complex ways that are challenging to find, but which cannot easily be described in terms of a single, core idea. These are what I think of as "micro" puzzles (although they need not be physically small), with the idea-based puzzles I favour being in the "macro" category of puzzles which are more about strategy and do not in general require precise moves. There is nothing wrong with micro-based puzzles. Some players enjoy them and The Golem's ruleset definitely supports them well. There are none in the game because of my rule that all puzzles must have a core idea.

So why is this approach good? The main reason is because it eliminates so many weak level designs before they're even created. I've noticed a tendency for puzzle games to often contain levels which functionally duplicate previous levels or even levels which are little more than doodles in the game's level editor. Whilst it's possible to defend this sort of thing I'm personally not a fan since I feel it's disrespectful of the value of the player's time.

Another reason, perhaps even more important, is that occasionally one comes up with an idea before it's even clear if such a thing can be designed at all. Each level of The Golem began as a single sentence in a text file. In two or three cases it took literally hours of design (once all the iterations and bugfixes were taken into account) to turn that one line concept into a working level. If I'd made levels by sitting down and opening a level editor I don't think those levels would ever have been made.

The Golem is a difficult game, but not intentionally so. Or at least, it's intentional in the sense that I've been aware of it throughout the project and have chosen to leave it this way. It's not intentional in the sense that I don't think a more approachable version of the game could be as good. I don't mean this as some kind of puzzle-solving elitism. It's simply that the game is about thinking deeply about things and humans aren't very good at that. During playtesting my levels were repeatedly broken by playtesters. A few of these breaks were, of course, stupid errors on my part. But most were because the complexities of my own game were just as challenging to me as to anyone else. Equally, I also found it very enjoyable to watch replays of ingenious but unintended solutions enacted by playtesters, watching for the moment when some clever play unravelled all my intentions and left my level in ruins! A puzzle game is a dialogue between designer and player, but when a level breaks it is the player who speaks and the designer who listens.

It is interesting to me to examine the changes in puzzle games over time, both in terms of the games themselves and the attitudes of the community who play them. Many of the early puzzle games I loved had no undo function, whereas now I won't even bother to play a game without undo in most cases unless it's very short or it's a prototype and the designer plans to add one later. Likewise I used to expect puzzle games to be mostly filler, with maybe only a tenth of the levels being both good and original, whereas now I quickly get bored of repetition and busywork (and to their credit most modern designers avoid it).

More subtly, modern puzzles seem to have a much better awareness of player experience. Who is the game for? What does the target audience actually enjoy? The Golem is a puzzle game for people who already play puzzle games and it makes no effort to appeal to a wider audience. That's OK as far as it goes, but I think the most interesting unexplored design space in puzzle games lies in making games which bring the experience of thinking about interesting puzzles to a wider audience. I'm not talking here about casual games. I'm talking about games which offer serious challenge, but do so in a highly approachable way, welcoming inexperienced players and teaching them.

Another game which released today – A Monster's Expedition (Draknek and Friends) – takes new steps towards that goal. If I make another puzzle game in the future it will very likely be something inspired by that approach to design. The Golem is a love letter to the puzzle community, but maybe it's time to share our fun with everyone?


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: