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?
Internet, 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!
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…
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.
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".
It's amusing, looking back twenty or even as few as ten years how people
seriously used to debate whether high level languages were a good thing. Programmers – and not just the sort with big beards who wore sandals in winter – would sometimes claim that C was just fine and there was no reason for anyone to use anything else. C++ had rather more advocates, but even they were keen to stress that the overheads introduced by their more expressive language were very small. If you did things "right", you were still in some sense writing assembler code. Allegedly.
But all along there have been people who have been quietly doing different things. Even back in the 90s, Tcl/TK could be used to build a fully functional UI for something in under half an hour. PERL has long been used to do all sorts of text-related things with incredibly short dev times. And ultimately even some of the C++ programmers started to bind Python and Lua to their C++ projects. "Scripting" was the word used for these secondary languages, because to admit that they were being used for programming would be to admit defeat.
Now environments like Flash and Unity take things a bit further. You write essentially your whole program in the local ECMAScript dialect (or something similar) and all the C++ is stuff that someone else has written, somewhere in the library layer. Like a kind of OS. Or, if you prefer, like the CPU's microcode somewhere in that layer you probably never even think about. Not that this is really new either. People have been doing approximately the same – albeit without garbage collection – since the 8-bit era.
But what is new is that programmers are finally realising that this is programming after all. In fact, not only is this programming, it's the bit of programming we really care about. Getting things done!
Guess what I'm doing to King Machine this week? I'm adding another language to the big stack of languages.
KMScript is, despite the obvious sounding name, not really a scripting language. What it actually does is to behave like a little virtual machine inside the game. Does that sound completely insane to you? Particularly for a game that's "almost finished"! (In quotes because of course these projects never are.)
In fact this is not some kind of absurd complexity creep. It's the opposite. King Machine's codebase is a huge, sprawling mass. In order to fully debug it and stabilize it ready for release I have to clean it up. But due to the ad-hoc way it has grown that isn't an easy process. I've spent a long time looking through it, searching for ways to simplify it. My conclusion is that there are very few functions that can be shared further and very little complexity that can be removed. However, most of the game's code I don't need to look at most of the time. When it occurred to me that this was rather like having two layers of functionality, I knew what I needed to do…
Within the game world, things happen like a block is created, aligned with another, activated, rotated by 30 degrees or whatever. These are simple things, but currently they are not simple to work with at the code level. So what I need to do is add a new layer of abstraction. So, for example, instead of having a class for "push beam" blocks that inherits from "block" and implements the push beam effect when used such a block should instead be a block containing a small code fragment in a new language internal to King Machine. In that language, a beam within the King Machine world is a known kind of thing and a "push" is a known action, so the behaviour of this block is very simple to express.
So far so not-very-interesting. But the real payoff here is that things like save files and replays can be encoded in this same language. This unifies all the data in the entire game and means I no longer need to add support in four different places for every feature in the game and keep them carefully synchronized. Even better, testing and debugging becomes so much easier because the level of code sharing will be far higher and all the code will be exercised more often.
OK, I lied, that's not the real payoff. The real payoff is that it's going to be fun! What's the point of being an indie developer if I can't have fun, eh?
On Monday I entered King Machine into the 14th annual Independent Games Festival – "the IGF" to its friends. Here's the trailer I made for the submitted version:
You may have noticed two exciting announcements hidden in there…
First, the talented Ed Fry (@Aeronic) has been persuaded to compose and produce all the music for the game! And yes, this is the same Ed Fry who did the music for Sophie Houlden's Swift*Stitch. I'll make a separate post about the game's music at some point because, as good as it sounds in the above video, there's some even cooler stuff going on with it that video cannot capture.
Second, the game now has proper voice acting thanks to some amazing work by Emma Newman (@EmApocalyptic). Best known as a fiction author, Emma also does voice work for audio books. Being an experienced roleplayer, she wasn't too hard to convince when I suggested she branch out into a spot of voice acting! The voice clip in the video above is possibly a slight plot spoiler, but again I think I'll leave discussion of how the game got its plot for a future post.
Last but not least, a hat tip to all my playtesters and to the numerous people who offered to playtest but whom I haven't yet taken up on it. I still plan to. The game may be getting a beta release of sorts in the next few months and there will need to be a lot of testing of things between now and then… including a lot of testing of stuff I haven't written yet. Speaking of which – back to work! 🙂
It is well known amongst programm
ers that the first 90% of a project takes 90% or the time and then the last 10% takes 90% of the time too (originally observed by a chap called Tom Cargill at Bell Labs, I'm told). King Machine is, I think, just approaching the edge of that last 10%… or should that be "last 90%"? All the basic gameplay mechanics are there. I've been designing tutorial levels for the last couple of weeks. The game runs well even on less powerful machines.
But… from Tom Cargill to Helmuth von Moltke, who said "No plan survives contact with the enemy". Very early playtests (with friends, not enemies) turned up a critical problem: positioning objects was far too hard. I'd noticed this a long time ago when trying to build scenery, but my solution was to add special purpose tools to make scenery easier to build. What I failed to notice was that I'd become very good at the basics of the game to the point where I wasn't really conscious of the extent to which fundamental actions were still quite hard.
My usual approach to UI design is to ask the player, immediately after they experience difficulty, what their ideal interaction would be to solve whatever they're trying to do. The trouble with moving things in 3D is that their answers were along the lines of "I want to put that there!". That's an objective, but isn't an action any UI can support directly because it's too high level. So more questions had to be asked and more frustrating failures had to be watched until I had a better understanding of the problem. The main diffculty, it turned out, wasn't so much transforming objects as working out where they were in the first place!
The typical solution to this is to use shadows – and that's certainly some use – but there are two problems with this. First, it means that the game is really limited in how it uses light sources, because slightly weird lighting conditions could make object positioning hard again. Second, shadows are only available in Unity Pro. This is a piece of software I definitely want to invest in when I have the opportunity, but right now King Machine has no development budget at all. However, shadows do provide a clue as to how best to proceed.
The key observation is that intersection between objects is already quite easy to spot, so the main problem is in visualising non-contact relationships. These matter mainly when the player is planning to drop something. But dropped objects – in King Machine at least – always fall downwards. So what matters most is the relationship between the held object and what is below it. A bit of playing about with different kinds of HUD and similar gadgets quickly convinced me that the answer needed to involve rendering something within the 3D game space. A visible guide downwards from the centre of the object helped a bit, but a few more playtests showed it wasn't solving the problem. Two difficulties remained. First, if the centre of the object wasn't above anything then it was just as confusing as ever. Second, the angle of the held object made no difference.
The current (final?) solution involves guides at all corners of the held object, with the bases linked to give a better sense of their relative positions. Will this be good enough? I won't know until it's been tested…
In the meantime there are sound effects to sort out. And the artwork needs improving. And I need to design some more levels. And I have something fun planned for the help system… but it's only five and a bit weeks until the IGF deadline. It would be nice to enter if I can get the game ready in time. Or at least 90% ready!
Tuning joint behaviour in King Machine is difficult and not very sexy, but now everything's working to my satisfaction I can make cool things like this:
Work on King Machine has been very busy for the two months since the last demo. A lot of that has been boring stuff like fixing bugs, but there are exciting new features too. Here's another demo video showing off some cool stuff you can do…
(Or watch on YouTube in HD.)
Just need to fix a few more particularly hairy bugs and I can get on to the fun business of level design!
