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