I actually want to talk about a video game today: TIS-100. It’s not terribly new, but it’s new to me and I don’t remember seeing people talk about it very often.
I had never imagined programming puzzle game could be a genre, but now I want dozens of games like this because of how much fun it’s been.
It’s a great puzzle game because it’s programming assembly for a vaguely made up architecture of independent communicating nodes that are, for the sake of the puzzle, very limited in their features*. Each node can hold only a small number of instructions and has channels to communicate with its geometric neighbors, channels which block on empty reads or full writes. Each node has two “registers” that can hold an integer and there’s basic instructions for register manipulation and one of the registers is specially used for the control flow constructs and arithmetic instructions. It’s a very simple but very cute architecture.
I’m not done with the game, being almost halfway through with all the puzzles (unless more become available that don’t have a placeholder?), but it’s generally been a lot of fun. The puzzles are well-designed in that, at least so far, each one has had a particular programming concept that you’ve needed to internalize to finish it and the lessons have built on each other in a logical progression.
In fact, I’m enjoying this so much I’ve started a little project on github where I’m working on a simulation of similar kind of hardware. My goal is to eventually compile higher level languages down to a configuration of programmed nodes. The main difference is that I’ve removed the instruction limit because I feel like it was largely there for the puzzle factor. The intermmediate goal is to have a slightly-higher-level language that is basically an abstracted version of the assembly code for individual nodes where rather than geometry there’s just a general notion of naming entities in your file and letting them communicate, then with a little graph munging it can either be compiled down to a solution of connected nodes or throw an error that it would require a non-planar graph. That’s at least my current thought, we’ll see when I get around to actually trying it.
*Honestly, it reminds me a lot of how I’ve heard folks describe data flow in gpus for general programming, but I know so little about that topic that I don’t know if that’s an accurate assessment.