In a meeting last week, I wrote CARNAGE HEART in giant letters in my notebook. I forget why – but it’s how I ended up thinking about “games about programming”, in its loosest possible sense.
Do you remember Carnage Heart?
I don’t blame you if you don’t. From the outside, it looks like Another Japanese Mecha Game. In fact, Artdink’s 1995 title was one of the most marvellously strange strategy games of the nineties. In it, you command armies of mechs – “Overkill Engines” – on the moons of Jupiter.
Except you don’t take direct control of them. Instead, as well as the usual mech-construction and resource management… you have to program them. You’re responsible for both hardware and software. Once you’ve programmed them, they enter battle, and you have to watch as your crudely constructed AI walks in circles and jumps every time it gets hit by a missile.
Of course, this is a game, not work, so it’s not like you program them in a language that requires typing. Oh no; Carnage Heart uses a system of “chips” to create a spatial programming language.
Like that. It’s a grid, that executes from the top-left until a signal leaves the board; usually, signals follow a green arrow, until they meet the conditions of a chip, at which point they fork and follow a red arrow. The spatial constraint means that subroutines become areas on the board, re-used again and again as code “flows” back into them. The twenty-four minute video tutorial that came with the game is still available to watch online. (And, if you want to play it, it’s surprisingly easy to track down – whilst the PS2 and PSP sequels only came out in Japan, the original came out in both Europe and North America, and can easily be found on eBay).
Anyhow. When I thought about that, I thought about the long chain of games that are really about programming, and it felt like a list worth collecting.
The obvious precursor to Carnage Heart starts with RobotWar family of games: games about programming virtual robots to fight in real programming languages. Although RobotWars used a dedicated language for it, it quickly evolved into CRobots (based around the C language) and onwards into projects like RoboCode. All are built around the same principle: a “robot” is a single file that uses a stripped-down instruction-set enabling it to move, shoot, and scan its radar. All robots are “built” equally; their only differentiator is the AI you program for them. And then: you load up the arena with all manner of .c files, and watch them fight.
It teaches some tough lessons about AI programming – after all, if your “clever” code is being beaten by a robot that does nothing more than walk forward, shoot, and turn 90º if it doesn’t hit anything… surely you’d be better writing something simpler?
The *Robots genre even moved – a little – into the mainstream with titles like Maxis’ RoboSport, which was more GUI-driven and much more user friendly, but the same basic game.
Enough fighting robots. There are now two directions we can go: more geeky, and more mainstream.
So, the former first: a few more games for programmers. A much more abstract – and, in some ways, interesting – game for programmers is Corewar. Here, you’re not programming virtual robots; you’re just writing a program that executes within a very simple virtual machine. The catch is: another player’s program is executing at the same time. You win by removing every trace of their program from the virtual machine’s memory. So you’re not using guns or bombs: you’re using code itself, storing itself in memory, shifting itself around, overwriting adjacent addresses to try to locate and flush out the program. There’s a visceral thrill watching the visualisation, knowing that you’re genuinely eradicating the opponent from memory, slowly stopping it working. There’s a mass of documentation and strategy about the game, and – if this sounds interesting – it’s all worth a squint.
There are more social games about programming, too: Code Golf, for instance, in which programmers “compete” – or challenge one another – to solve problems using as few characters as possible. Enter clever algorithmic tricks, masses of obfuscation, complete illegibility, and deep knowledge of strange character-saving hacks within your language of choice. This reaches its zenith in competitions like the International Obfuscated C Challenge, in which, over the years, programmers have competed to write C programs that are as unreadable, stylistically unpleasant, hacky and witty as possible (whilst still executing entirely correctly). And hence: maze games whose source code is a maze. It’s an acquired form of wit, for sure, but still a kind of social competition.
That may not be your kettle of fish. But you can find elements of programming-like games in very mainstream titles:
Final Fantasy XII introduced a system of “Gambits” which allowed players to program companions AI behaviour. It took some of the slog out of combat, instead allowing players to ensure that allies would behave sensibly with no attention. Levelling up allows characters to have more gambits running at once – helping their automation.
The gambit system takes the form of simple statements made of a condition paired with an a action; “if health is below 50%” “cast heal“. Frustratingly, each condition and action must be purchased individually (although you quickly discover they cost next-to-nothing to buy). And yet this one change it makes combat less of a discrete activity to be engaged in, and more a system to be prepared for: you counter it by simply having sensible routines stored up. And that couples neatly with the game’s shift towards combat being something that occurs within the same environment as exploration: you counter the idea of combat occurring anywhere by making sure the player always has an automated response available.
And, of course, that’s something ripped straight from the interface of MMOs like World of Warcraft – namely, macros. Somewhere between customising the interface from a menu, and writing a plugin in Lua, lie macros: sequences of in-game commands that can be bound to a key. They’re useful for automating dull sequences that you discover to be effective – for instance, for Hunters, the sequence of different “shots” that need to be tossed out in order to maximise damage and recovery. Why click on five things in sequence when you could just bind a macro to one button that performs the correct action each time it’s clicked? They also serve useful social purposes – attaching conversation to actions to keep your raid group co-ordinated. And so, like so many office workers discovering the depths of Excel, WoW players running up against the limits of their own dexterity dive into macros, and take another step closer to being programmers.
SpaceChem is only loosely about chemistry, but it’s very definitely about programming. In constructing machines to bond atoms into molecules, and synthesises molecules into larger molecules, it pushes you through several levels of understanding that are familiar to a new programmer. First, understanding how to phrase intent in a limited instruction set. And then: slowly scaling up your ambitions, from single routines to interconnected ones; understanding loops and iteration, and how to induce asymmetry into routines; forcing you to find your own names for certain constructions, which become vocabularies of patterns that you can use again and again. As you play it, the unintuitive becomes second nature, and you learn to think within the system.
Totally a programming game.
Space Alert is a co-operative, real-time strategy boardgame. It’s a bit like the combat sequences in a Star Trek episode. An audio CD plays for ten minutes, listing threats coming into the ship, letting players know when communications are down (and they cannot speak); meanwhile, players arrange cards on tracks that represent the actions they will take in the future. The game lasts for ten minutes, real time – and then at the end, the players resolve their actions to see what actually happened. And of course, everything goes spectacularly wrong. (There’s a nice explanation of the game – with play examples – by Quintin Smith, here).
Instruction sets that get resolved later: this is a programming game, where the players are programmers at first, and then take the role of the compiler in the resolution phase, turnings their lists of actions into a series of events. And, of course, there’s the threat of race conditions: one player’s actions resolving too soon (or too late, if they tripped in the dark), causing the whole course of events to turn to disaster. It’s a planning game, and one about co-ordinating multiple series of events – which feels like certain kinds of programming to me.
And, of course, there are also programming toys: who can forget the Big Trak, which despite its limited instruction set and lack of sensor input introduced the joy of repetitive typing on tiny keypads to thousands of children.
These kind of games and toys do not appeal to all; I genuinely believe that it comes down to how your brain is wired. Some players love tangling their heads around problems like these, building systems to take other systems apart; some don’t know (yet) that they will. Some will never got one with them. And that’s OK: this type of thinking is hard, and strange; it is genuinely unnatural.
Still: there’s no better medium than a systemic one for making games about systems. As such, worth collecting some of them in one place, I felt.