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! 🙂
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:
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:
- Fix it.
- Decide not to fix it because different testers disagree over whether it's a problem or not.
- 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.
In the announcement post for King Machine I promised a big, long waffly post about the game and my plans for it. So here it is…
Machines Want To Be 3D
In the past I have actively avoided developing games with true 3D gameplay because with relatively few exceptions the games I enjoy playing the most have all been essentially 2D even when employing 3D graphics. So when I was learning Unity 3 I spent a lot of time thinking about which kinds of gameplay really worked well in 3D. Exploration games are good – and I love the idea of doing a really good 3D maze game – but that doesn't make a good first project because there's a huge amount of art and level design to do and not much game design or programming. Racing games and first person shooters aren't really my thing (and arguably aren't 3D anyway, but I'll try not to get too sidetracked).
It was when I started thinking about the third dimension as a way of not getting things tangled up that I ended up thinking about connecting things and wires and machines. This wasn't much to do with game design at first. Some of my PhD work involved automated layout of wiring for digital circuits… it gets pretty nightmarish in 2D! But then I remembered the old 2D versions of King Machine had similar problems. Not surprising really, since 2D spaces are just difficult generally. If you like fiction that makes you think I recommend A.K.Dewdney's 'The Planiverse' for some great discussion on this topic.
Machines seem like they naturally want to be 3D. So I had my project… sort of.
Too Big To Be Small
There was one big problem. For some time I've been working as a freelance programmer, working on games projects for as much of my time as I could get away with. Like most designers in a similar position I've been trying to gradually transition to full time games work. Generally this is all good, but it does place a strict constraint on my projects: any big project must be commercial. King Machine has, historically, been my favourite example of the kind of game I personally love but which could never possibly be commercial because it's just too geeky and inaccessible.
It was a conversation with my sister Josie which changed my perspective. I'd lent her my copy of Logicomix (because it's excellent – you should read it) and while we were chatting about it I offered to explain to her some stuff related to Gödel's incompleteness theorem. I tend to feel that the way mathematics is approached in academia makes ideas much less accessible than they could be and that most concepts can be explained to anyone reasonably bright provided you don't mind sacrificing a little bit of the rigor expected of actual proofs.
Later it occurred to me that this same attitude is something I should apply to games. King Machine is a huge amount of fun. So, as a game designer, I should be able to take the game and present it in a way that makes it comprehensible and accessible to a much wider audience. A combination of good user inferface design, gradual introduction of concepts and comprehensive help resources should be enough to get pretty much anyone playing and enjoying the game.
Finding the Core Gameplay
The first step in making a complex game as accessible as possible is to decide what it's really about. At first King Machine seemed pretty easy in this respect, since I knew I wanted it to be about building machines. The problem with that is that building machines isn't a goal as such, it's a means to an end. This begs the question of what that end should be. Of course I could make the game a pure sandbox, but that feels lazy to me. I want to let players play in a sandbox style if they choose to, but for some players that's just not satisfying.
Machine-based play is ridiculously versatile, so as I began to make notes about possible goals and play styles the list just got longer and longer and picking the right option started to look a bit hopeless…
…until I realised I was looking at the problem the wrong way. Instead of picking one goal I could pick all of them. The danger is that doing this sorts of thing inhibits the player from learning, but I don't think that needs to be the case. If each level gives the player a new kind of task and then provides them with the support they need to discover the solution that should keep each experience fresh whilst gradually teaching them what they can do with their machines.
That just left difficulty levels. The word "accessible" has a bad reputation in certain quarters these days because it's seen as a euphemism for "easy". I don't think that's right, but certainly the two can be related in the sense that it is difficult to find ways to present hard challenges without causing bad play experiences for some players. In the case of King Machine the approach I feel most inclined to adopt is optional challenges on the same levels as compulsory problems. That way the player can give some thought to anything they can see but doesn't need to feel as though they're stuck. Also, having seen a challenge, the player can always come back later if they have a flash of inspiration or simply learn a new trick which they think might help.
Was That Waffly Enough?
Hmm… I still have over a dozen more things I wanted to talk about. Maybe trying to fit all this into one blog post isn't such a great idea? The rest can wait for now, I'm off to do some more programming!
OK, let's talk about gameplay!
Knights and Ruffians – my new game – is about trying to bring to video gaming the kinds of experiences I used to enjoy from the skirmish scale adventure games I used to play as a kid. Possibly you're scratching your head at this point. Surely "skirmish scale" should be followed by "wargames" not "adventure games"? Well, therein lies an interesting quirk of the history of adventures…
I'm not quite old enough to have been around for the birth of pen and paper roleplaying games, but I found the hobby soon enough afterwards to experience old school roleplaying first hand. We taught ourselves roleplaying with those games as a framework, but really they were wargames. The interesting part was, they were cooperative wargames. In recent years cooperative gaming has really become a hot area, but back in the early 80s we spent all day doing exactly that without really being conscious of it. Later roleplaying systems dramatically reduced the wargaming aspects, although they never fully disappeared, as a consequence of which this style of gaming was almost lost.
I also played a great many Games Workshop games, from Warhammer and 40K to the excellent Space Hulk. However, Games Workshop were always more interested in selling miniatures than making great games. When they got rid of Richard Halliwell – who was full of incredible ideas that he was never allowed to develop – I started to lose interest. Still, games like Space Hulk and Advanced Heroquest remain important landmarks in my gaming history and are sources of inspiration for Knights and Ruffians.
Not all of the ideas behind Knights and Ruffians come from the tabletop world, though. The old C64 game Laser Squad was a pure wargame, but its mechanics set the standard for turn based play in video games. Also, whilst I don't really play RTS games, ever since Warcraft I've had my eye on the genre for its attempts to give players a high level of control without resorting to turn based play.
So what's wrong with turn based play?
The primary problem is that it encourages a glacially slow pace of play. Players will always find more things to think about. There's a reason why Chess needs clocks! Real time play also isn't right for the style of play I want. The trouble with real time is that either each player must be limited to controlling a single character or the behaviour and interactions of their characters must be simplified. Not that simplification is inherently a bad thing. But the kind of game I'm aiming for wants rich, interactive, moment-by-moment tactics. If a player is controlling multiple characters it must feel more like the way a good sports team interact than like a herd of sheep.
Knights and Ruffians is going to use a compromise between the two approaches. It will have turn-based play, but with a very short turn timer. Players will have enough time to do things with several characters each turn, but only if they issue orders fairly quickly. I'll write a whole entry sometime about my plans for the UI. It needs to be very good, because otherwise the fast turn cycle will be irritating rather than being a source of good gameplay.
In theme terms the game is going to be about looting rare and valuable treasures, many of which will also be useful items. It's going to be about fighting off enemies and rivals and monsters. It's going to be about characters and stories and mysteries and… Actually, I don't even know all the things it's going to be about because I'm going to have some assistance on the writing side. More about that another time.
Also, since this is a development blog I really ought to get around to talking about the technical side of things. Soon. Very soon.
My experience of game design as an activity has always been that it is easy to have fun with. This is a good thing, of course, but it also gives rise to a problem. If you spend your time having fun it makes it easy to avoid being critical of what you do. This is particularly true of video games, because most developers seem to enjoy the design work more than the implementation and both of those more than polishing or debugging. Therefore during the early stages of a project there is a temptation to make grand plans likely to take years to complete. During implementation, the huge size of the project becomes a burden and – as is well known – few reach completion. Experienced developers then tend to drift towards shorter and shorter projects for the simple reason that they come to value their ability to complete them. Very reasonable. But maybe still bad. Indie designers have become good at finding games they are able to make at the expense of making the games they want to make.
In this context, let me talk about my new project!
What I realised, just before starting it, was that I was about to make what I call a Three Bears mistake. You know the story of Goldilocks and the Three Bears, right? Well, my previous two projects were two of the bears. Vgypt was extremely large and ambitious. I was very excited about it and developed all kinds of clever tech for it and developed enough to submit a prototype to the IGF last year. The problem was, the project was too big. It got to the point where I was having performance problems and needed to rewrite the entire game engine and probably switch language too. I decided I couldn't justify the cost of doing so and reluctantly put the project on hold. The Unicyclist was my next project. It was much less ambitious and I completed it easily. It's good, if I say so myself, you should play it! The trouble is, it's too small to do well commercially. I got some good sponsorship (from teagames.com) but free games just can't pay enough to justify the kind of development time involved. So, time for a new project that was bigger than The Unicyclist but smaller than Vgypt. Time for Baby Bear's game, the size of which would be just right.
Or maybe not. Because that's the Three Bears mistake. Having identified two problems at opposite extremes, it does not follow that the best strategy is the average of the two bad ones.
The real problem with Vgypt was not that the game was too big, it was that the software required to implement it was too big. If I were to go ahead and write a medium sized game I might well complete it, but I'd leave myself with an awkward marketing problem. Like Terry Cavanagh's VVVVVV my game would be seen as too small for a commercial release whilst at the same time being too big to finance as a free release. (Incidentally, VVVVVV is very good and I personally found it well worth the price even at launch.) Also, who wants to start off a game design with a size constraint before you even have a concept? That can't be good.
The real lesson of these designs has to do with risk. At the start of a project the question to ask is: "What is most likely to go wrong here?". The trick is to make sure that the foreseeable problems are all things you can handle. Working as an indie designer has many positive points but one of the biggest negatives is that you're very vulnerable to risk. I'm lucky to be in a position where I can have an unprofitable year without needing to pack it all in and go and work in a bank.
My new game, as you may have guessed by now, is actually a bigger project than Vgypt. In fact it's easily the biggest game I've worked on. It's the reason this development blog has made it's appearance. I want to talk about the gameplay too, but I think that deserves its own entry.
