Making a Big Pile of Languages

On November 10, 2011, in King Machine, Technical, by bateleur

It's amusing, looking back twenty or even as few as ten years how peopleStack of books 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?

Tagged with:
 

6 Responses to “Making a Big Pile of Languages”

  1. Paladin says:

    So you're writing your own language ? Excellent news.

    Is it a middle-term project to let the (very) advanced user learn and use KMScript for level editing and modding purposes ? That would be pretty cool. Aside from the big runners (Blizzard RTS games…) which virtually have the number and power to design whatever they want, a successful ex-Indie developper like Nadeo (maker of Trackmania) announced during the Paris Games Week a couple weeks ago that they developped a similar subproject as yours (high level triggers, actions and properties) named ManiaScript, which they want to implement in their current and upcoming releases, for the community to maintain their games living.

    You might start working on the f***ing manual 🙂

    [shameless-advertisement]http://trackmaniaforever.com/ If you didn't check this free game, do it NAO.[/shameless-advertisement]

  2. David Given says:

    Building VMs like this is an ancient and time-honoured tradition. e.g. Infocom's Z-machine, LucasArts' SCUMM, or the myriad of modern games which use Lua to tie together all the low-level bits.

    The tricky bit, of course, is that if you're actually trying to come up with a *programming language* you're going to be tempted to add all sorts of programming-language-like features, and before you know it you're building an even worse copy of Python…

    Given that ActionScript is a pretty decent dynamic language in its own right, it ought to be possible to cheat and use a light wrapper around actual ActionScript. The complicated part is disconnecting your script's flow of execution from your application's flow of execution; you want to execute a couple of VM steps, then go and check for events and do game stuff that needs doing, then go and do more VM steps, etc.

    I don't know ActionScript; Lua lets you do this sort of thing easily via coroutines. Does ActionScript have anything like that? Threads, iterators, etc?

  3. bateleur says:

    @Paladin – I certainly like the idea of opening everything up to players eventually. Whether coding directly in KMScript would be the right way to go, though… not sure. It makes more sense to me to simply give people access to my own level design tools. But yes, sooner or later documentation will be needed!

    @David Given – UnityScript might support this kind of thing, but I'm pretty sure I don't want to go there. That would open up concerns about sandboxing and security. Could some user design a level that hacks the player's pooter? :-O

    Luckily I don't need to write a powerful language. Everything it does can be relatively simple. I'm thinking of a stack-based architecture a little like PostScript, but with a bit more state (sort of like registers, maybe?).

  4. Paladin says:

    "and before you know it you're building an even worse copy of Python"

    Ok, that made me sincerely laugh.

  5. David Given says:

    You might be interested in this:

    http://webcache.googleusercontent.com/search?q=cache:http://angg.twu.net/miniforth-article.html

    (Website seems to be down, but the cache has all the contents.) Page title: "Bootstrapping Forth in 40 lines of Lua".

    Lua's got very similar semantics to Javascript/EcmaScript/ActionScript, although without some of the more insane bits, so everything here should be applicable to you. Although you may not want to go quite so hard-core.

  6. bateleur says:

    That sort of compactness of code is best admired from afar I feel. I once spent half an afternoon completely understanding how TinyWiki works, just because I was impressed by how small it was. I like to think I have learned the error of my ways. 😉

Leave a Reply