Adam's Blog

Machine Languages

I have recently been enjoying the design puzzle game SpaceChem. The game is played by designing nano-scale machines to assemble various chemical compounds. The design feels like a "best of" collection of elements from earlier Zachtronics games: the factory and grabbers of Manufactoid, the chemistry and rotation of Codex of Alchemical Engineering, and the layered circuit drawing of KOHCTPYKTOP 1. Of course it is much more as well: more mechanisms, and loads more polish. As much as I'd enjoyed the previous games, they had some major interface issues, and almost all of these seem to be resolved.

Design puzzle games like SpaceChem, along with the predecessors I mentioned, and similar games such as PleasingFungus's Manufactoria, all involve a similar flavor of gameplay. You begin with an empty grid, perhaps with a few fixed points for inputs and outputs, and a simple description of what you are to accomplish, usually in terms of inputs and outputs. To accomplish the given task, you must use the tools you are given to construct some machine on the grid. Tutorial levels will only ask you to do what is directly possible with straightforward application of the tools; for instance Manufactoria's first level only asks that you build a conveyor belt to move objects directly from the input to the output.

The challenge of these games comes later. The tools, while often increasingly powerful as the game progresses, are not particularly well-suited to later problems. Generous as the vast empty grid seems to be, you eventually find space to be an issue. The machines you construct become much more convoluted, components end up doing double-duty to save space or to compensate for missing functionality. You find that something as easy to describe as "reverse the symbols" involves a very complex set of simple actions. SpaceChem's inputs and outputs can be deceptively simple; to coerce the proper behavior out of the tools on hand requires great feats of design.

Constructing complex behavior with overly simple tools has an interesting parallel in computation. This is the concept of the Turing tar-pit, "in which everything is possible but nothing of interest is easy". While all Turing complete languages are in some sense capable of describing any computation, that is not sufficient for a language to be useful. A programming language is more than a way to tell a computer to do something, it is an intermediary between the mind and the machine. The language brainfuck is Turing complete, yet if anything it is actually more difficult to use than Turing's own minimal notation, which even Turing had to supplement to make explanations tractable. Programming in brainfuck is a game much like the engineering games I mentioned above. "From these inferior tools, what can you create?"

Simple tools have benefits, however. Most importantly they are simple to describe and understand. The Turing machine is simple so that it can be described completely in a few pages. Brainfuck was designed to require a very small compiler. In the design games, simple tools leave little room for misunderstanding. Nothing is hidden from the player, so there is no need for extensive debugging capabilities. All that is needed is to show the machine in action, possibly slowed down. All interactions are visible, so an unexpected occurrence is explained implicitly by watching it happen. I think that such simple tools are essential for a game that works as I've proposed here. As Patt and Patel say in the preface to Introduction to Computing Systems (1st ed):

We do not endorse today's popular information hiding approach when it comes to learning. Information hiding is a useful productivity enhancement technique after one understands what is going on. But until one gets to that point, we insist that information hiding gets in the way of understanding. …

In short, we believe in top-down design, but bottom-up learning for understanding.

I feel that it is the "up" part of "bottom-up" that existing games miss, but that is a topic for another day.

[1] Note 2015-11-10: I have to add that SpaceChem also pulls in the interactive boss battles from Zach's Bureau of Steam Engineering. This oversight has been bothering me for years, whew.

Comments:

Tobu says:
September 14, 2012 at 11:48 am

Thank you for writing this (and mentioning it on the gamasutra postmortem comments). I think the rawness of the manipulators was excused by the chemistry premise (even though it's avowedly the fake kind). This kind of optimisation design exists in real life; chemistry, pharmaceuticals, dna life, all feature neat solutions emerging from blunt mechanics and hacky repurposing. That's what makes spacechem rewarding for me personally.