I feel that it is the 'up' part of 'bottom-up' that existing games miss, but that is a topic for another day. In short, we believe in top-down design, but bottom-up learning for understanding. But until one gets to that point, we insist that information hiding gets in the way of understanding. Information hiding is a useful productivity enhancement technique after one understands what is going on. We do not endorse today's popular information hiding approach when it comes to learning. As Patt and Patel say in the preface to Introduction to Computing Systems (1st ed): I think that such simple tools are essential for a game that works as I've proposed here. All interactions are visible, so an unexpected occurrence is explained implicitly by watching it happen. All that is needed is to show the machine in action, possibly slowed down. Nothing is hidden from the player, so there is no need for extensive debugging capabilities. In the design games, simple tools leave little room for misunderstanding. Brainfuck was designed to require a very small compiler. The Turing machine is simple so that it can be described completely in a few pages. Most importantly they are simple to describe and understand.

'From these inferior tools, what can you create?' Programming in brainfuck is a game much like the engineering games I mentioned above. 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. 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. While all Turing complete languages are in some sense capable of describing any computation, that is not sufficient for a language to be useful. This is the concept of the Turing tar-pit, 'in which everything is possible but nothing of interest is easy'. 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.Д¬onstructing complex behavior with overly simple tools has an interesting parallel in computation. You find that something as easy to describe as 'reverse the symbols' involves a very complex set of simple actions. The machines you construct become much more convoluted, components end up doing double-duty to save space or to compensate for missing functionality. Generous as the vast empty grid seems to be, you eventually find space to be an issue. The tools, while often increasingly powerful as the game progresses, are not particularly well-suited to later problems. The challenge of these games comes later. 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. To accomplish the given task, you must use the tools you are given to construct some machine on the grid.

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. As much as I'd enjoyed the previous games, they had some major interface issues, and almost all of these seem to be resolved.Дesign 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.

Of course it is much more as well: more mechanisms, and loads more polish. 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. The game is played by designing nano-scale machines to assemble various chemical compounds. I have recently been enjoying the design puzzle game SpaceChem.

Spacechem no need for introductions