Despite picking up a bunch of must-play AAA titles and experimental indie games during the recent Steam sale, I’ve spent the majority of my play time on a game about programming a fictitious computer from the dawn of the age of technology. TIS-100 is a puzzle game at heart, but what captured my attention was the need for having to work within limitations. Anyone writing code in a modern high-level language will be able to attest that nowadays are we rarely concerned with the same low-level optimizations and tricks to go beyond the capabilities of the underlying hardware which used to be necessary before high-speed computing power and vast amounts of memory became ubiquitous. This game however brings back that sense of pushing against limitations in all of its monochrome glory and forces you to think about problems in a different way.
Upon starting the game, you are confronted with a boot screen that indicates that the TIS-100 is somehow broken and it is up to you to fix it by repairing its operating system. You are then invited to review the manual – an authentic-looking PDF that includes handwritten markings from a previous owner – to learn about the capabilities and the made-up history of the computer. There isn’t a lot of hand-holding here and you are expected to read the whole thing to be able to actually play the game, although you can return to the manual at any time.
Back in the game, you are then shown a list of 25 puzzles, most of which are inaccessible at first and only unlock once you have solved a sufficient number of easier ones. Most of the problems revolve around transforming a set of input values in some way, and then checking against an expected output set – I know, sounds riveting, doesn’t it? There are only a handful instructions that you’ll need at first and the game does a good job at slowly ramping up the difficulty: for example, the first problem has you simply relaying the input values through a set of nodes to the output to teach you about how information flows within the system. These nodes, which are found in every puzzle, are capable of storing and processing data – in parallel, if desired – but are limited to 15 instructions each.
Later puzzles include some well-known computer science problems like merging two lists into a single sorted list and finally also generating graphical output. Once each puzzle is solved, you get to see a statistics screen that compares the number of cycles, instructions, and nodes to those of other players. There is also an overarching story that can be explored via the contents of corrupted nodes found in each of the puzzles. While the story adds some flavor, it isn’t necessary to solving the game – in fact I found myself often not solving puzzles in story order after unlocking more and more of them.
The game has all the charm of an excel sheet – so why does it work? Well, for me it was the addictiveness of the puzzles – there were numerous times where I just needed to figure out how to squeeze one more instruction in to make my solution work. The game rewards unconventional thinking: for example, there is an opcode that lets you jump to an arbitrary instruction within the same node, and at first I didn’t really know how to make use of it. After reading some posts on the Reddit group dedicated to the game, I came to see that this one instruction made it possible to have nodes control the execution on other nodes, which completely changed the way I solved the puzzles from them on.
At this point I’ve got only two of the advanced puzzles left and I’ve gotten way more of the game than I had expected. I’ll need to check out the follow-up title Shenzhen I/O next – it appears to be similar but instead of writing software this one is about building hardware circuits. Oh, and final note: if this review sparked your interest in what actual programming at the limits of hardware was like, I highly recommend the GDC talk by David Crane on how he created the game Pitfall for the Atari 2600 – good stuff.
Leave a Reply