I'd played SpaceChem long ago, and knew I liked programming-style games generally, but it was only a couple months ago I saw Zachtronics Puzzle Bundle on sale and, in anticipation of Last Call BBS dropping, started catching up on their oeuvre. And wow, I sure have been jumping hyperfixations from one of their games to another since then! I do think that Opus Magnum is by far the most approachable Zachtronics game, and Last Call BBS has a unique charm to its presentation and the variety of games and toys there is great, but I also think there's a fascinating progression from TIS-100 to Shenzhen I/O, and then to Exapunks, the one I completed most recently. They form a sort of unofficial trilogy, the Zachtronics games where the 'programming' part is literal code. But the code you write and the machines it runs on vary in really interesting ways between those games, ways that affect how I feel while solving the puzzles in them.

I wanted to write out some thoughts I had about this progression but ended up having more than I expected to say about just the first game, TIS-100. It's not just interesting as a starting point, but a good example of how the design of a space - the tools at your disposal and limits they impose - guide your hand and tell you something about what kinds of problems you're going to be solving and how you'll solve them before you even know what they are. So I realized, hey. Why not just write about that first? So, while I may write essays about the other games later, here's my first, on the somewhat obscure and obtuse TIS-100.

TIS-100

TIS-100 is a game about receiving a weird, partly-broken computer from your aunt, because your uncle passed away and she knows you like computer stuff too, right, and this was the computer he was working on when he died. It's, uh, probably unrelated to his death, but assuming you bought the game, you probably want to fix it up. To do that, you need to learn how to program the missing sections of the operating system, in an assembly language - a very low-level programming language that tells the processor exactly what to do and where to move numbers in memory.

The game doesn't actually require knowing assembly (though being familiar with programming certainly helps), but if you did you would need to learn this language anyway, because assembly depends on the processor architecture it's written for. Fortunately, the game also comes with a reference manual for the Tesselated Intelligence System architecture as a PDF you can print out, which is a fun recurring feature of this trilogy. Unique to TIS-100, though, is that there are notes scribbled on it already, and passages highlighted, showing you where your uncle has already tried to figure this out.

The architecture

I'm going to resist the urge to describe how it all works in detail, but the really interesting thing here is the structure - you have some number of "nodes", each node has a box you write code into, and it can pass messages to and from the nodes directly up, down, left, and right of it. You're pretty limited in how much code you an put into each node, and in fact you can "save" data into two registers but can only act on one, the "acc" (accumulator) register. The other is just for backing a number up so you can swap it into the acc again later - you can't even add them together, but you can add incoming data to the acc, which has some interesting implications in how you write your code.

See, it's easier to process data *in passing* than it is in one place. Sometimes this means it's easier to just "pass" data to a neighboring node and pass it back so you can do math on it when it comes back. Or to pass it to a neighbor and have it pass back the inverse, or test if number is positive or negative and pass back the result. And like all Zachtronics puzzle games, there are different metrics you can try to improve your score on, and distributing your problem-solving across several neighboring nodes can greatly speed up your data processing. But "neighbor" can also be a limited resource, since you're usually passing data from one side of the grid to the other, and some nodes are corrupted, limiting which nodes have neighbors that can help. The rigid structure of a grid of processors becomes a surprisingly dynamic constraint in each level, based on where your data is coming in, where it needs to go out, and where special nodes like memory stacks or corrupted nodes are.

The story

The way this architecture guides what you can do is also part of the narrative. Yes, it was designed to create interesting puzzles for you as a player; but real computers, real architecture and languages, aren't created in a vacuum. Within the world that the game presents, this computer was created for a purpose, and part of what drove your uncle to keep trying to repair it was figuring out what that purpose was. Apparently this kind of architecture, passing data quickly through distributed processors with limited memory, is very good at processing signals (don't quote me on this but I believe this is how GPUs are designed, for example). As he gets further into the system, and you follow his footsteps and see the notes he left there, seeing what kind of capabilities the machine has and what kind of internal systems you are recreating, he becomes convinced it is designed not for general-purpose computing but for observing and, eventually, displaying a specific kind of signal.

The narrative in TIS-100 is pretty bare, and the reveal at the end didn't wow me so much as make me smile and say, "uh-huh, that's what I expected" before going to back to try one of the puzzles I'd skipped earlier. But I do love how the puzzles shape the narrative itself - not just the stated goals (detecting signal peaks, amplifying or multiplying, etc), but how that narrative hangs on the implied purpose of them, the implications that puzzles like these can exist.

Tthe game itself is obtuse, unwelcoming, and gives you the barest documentation and the suggestion that there's more than meets the eye to this computer but no kind of tutorial. The manual is written as a brief introduction for a user familiar with assembly code and only needing to be familiarized with this variant - and references another document, "Tesselated Intelligence System Best Practice - Patterns of Node Communication" as the best resource for more detailed examples and techniques, a document that, mockingly, was not included and does not exist in the real world (unless some enterprising fans wrote one, which wouldn't surprise me). But, again, this is the experience that your uncle, a tinkerer but not an expert, had. His initial fascination and confusion about the machine are because it's so strange, so obtuse. One of the hand-written notes on the manual is his to-do list, including "look for book of micro-optimization tips". As he becomes more obsessed with understanding the TIS-100, its purpose and its origin, he first asks other experts (who suggest it's some kind of government project) but the more he works on it the closer he feels to those who made it, to understanding them.

You also get peaks into his life, as there are gaps between the dates on the notes that imply he's set the machine aside for long periods and then picked it up again. The glimpses don't look good, either - the implication in some cases is that his obsession is driving people away, that the esoteric purpose of the machine is pulling him in and away from the world, but in one case it seem more like he was doing okay until something disrupted his life - he lost his job, and turned back to working on the TIS-100 to keep busy while he searched for a new one. It's only after this that the notes seem more supernaturally driven, when he starts speculating it came from another world, that it makes more sense if it was designed for intelligences not entirely like our own. The note I find the most interesting comes shortly after this turn.

Forget all about life that pains me & drags me down. I want to be a Tesselated Intelligence: Take inputs, process... take inputs, process... take inputs, process.

Perceive. Understand

The machine doesn't exist simply for the sake of existing. It was created by a being to do one thing, and that purpose is expressed through its design. I don't think it's that your Uncle Randy is being possessed by some otherworldy entity - at least, not just that. It's that understanding what a thing is simply through what it is capable of is so compelling. Wouldn't it be nice to know your purpose with such certainty? Wouldn't it be compelling if your purpose was simply to perceive, to understand your own purpose?

Would I recommend TIS-100? Well, frankly, if you don't already find this kind of restrictive programming game compelling, no. I enjoyed it a lot, but it's harder to accomplish pretty much anything than other, similar games I've played, and I already had a fair amount of experience with this style of game from Shenzhen I/O and Exapunks. If you're also familiar with them... I'm still not sure. It's pretty bare, and I definitely enjoyed the later games more, but this has its own charm and I think it's worth playing in contrast those. To see what makes it different as well as the ways Zachtronics has softened their onboarding, focused more on presentation, and also what ideas have stuck around (the pdf manuals to print remain a fun gimmick).

But, is it the kind of game it wants to be? I certainly think so. Obviously, Zachtronics also wanted the game to find success, to keep the company afloat and to entertain people. But it also wants to be obscure, an oddly compelling curiosity that draws in exactly the kind of player that sees unadorned boxes of code and wants to know what they do. Not to push you forward, but to draw you in and confound you.

That purpose is clear from the design.