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!
