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