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.
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".
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!
