If you're a programmer, you owe it to yourself to check out Zach's games. They very much focus on the same skills: if you like one, you'll like the other.
They are all at amazingly different levels of abstraction too. This game is probably my next buy. I have to admit I saw it yesterday and dismissed it as "some amateur is making Yet Another Programming Game that's going to be unbalanced and unfun" until I saw it was Zachtronics.
>Because let's face it, masochism is what programming is about.
True, but Zach is good at pulling out a simple representative subset for each game. There's no arcane syntax for using registers vs IO in TIS-100 for example. It's just another dest/source that works with MOV. Then he adds something outlandish and gamey like adjacent core communication. I've played some other attempts at the programming masochism genre and they struck me as fiddly attempts to cram complexity into the instructions vs the problem.
This is why I like ZT games more than other excercises in masochism like BrainFuck. They're ultimately more about using a simple, well-understood set of tools to solve difficult problems than they are about using a deliberately obstructive set of tools. The fact that the tools are so easy to understand is what draws me to it over real asm programming: nothing's worse than trying to solve a puzzle when you have the sneaking suspicion that there's a few pieces you're missing that would make your job easier if you were to only learn them.
Let the complexity emerge naturally. Because it will.
By the way, if you like ZT games, and haven't checked out the work of Eric Wastl (The Synacor Challenge, and The Advent of Code) you should do so immediately. It's not as fun now that everyone else has done it, but it's still a blast.
> This is why I like ZT games more than other excercises in masochism like BrainFuck. They're ultimately more about using a simple, well-understood set of tools to solve difficult problems than they are about using a deliberately obstructive set of tools.
I tend to feel the opposite way -- the games are written to be deliberately obstructive; that's why we call them "games". It gets frustrating pretty quickly.
Spacechem is a series of exercises in writing Befunge. I don't see how that could be characterized any other way than as "obstructive for the sake of obstructive".
But they don't feel obstructive: allow me to put it like this:
With many games of this sort, or with INTERCAL and Befunge, you are asked to build a device with broken, strange tools that don't work properly, and are designed to be as annoying as possible.
The TIS instruction set, OTOH, is perfectly well designed and clear in how it works, it's just very primitive. This is akin to BF, but BF is so low level that it's far more irritating.
Spacechem is a ZT game just like TIS-100 is. All of your problems come from the fact that each thread's cursor has to physically travel to the next instruction in a very cramped area while avoiding other instructions that may have been laid out in between. (Also, if full cursors crash into each other, your program crashes.) With real tools, Spacechem programs would all be trivial.
Feel does come into it, I guess, because I loved Manufactoria (also Befunge). Manufactoria is a lot more computational than Spacechem; your goal there is to manipulate a bitstring, not to traverse the environment for its own sake.
I guess what I'm saying is that it doesn't give you a toolkit with a bunch of weird tools and impractical designs and bizzare edge cases (looking at you, INTERCAL), it's purely, "right, here's your tools, you knoe how they work, let's see you pull this off."
Sure, it's less obviously linked to programming, but think about it: that sort of issue comes up all the time.
And just because the goal is more overtly computational in nature doesn't mean it's actually a more computational game: I wouldn't know, because it's 9 o'clock here on USEast, and I'm typing this on my phone, so I can't play the game ATM.
If you're scheduling cargo shipments, it strikes me as both easier and more "primitive" to have one tool that can load, move, and unload cargo in response to commands, and an entirely different programmable tool that issues the commands.
In Manufactoria, your bitstring exists in an abstract space. Your program is still written in Befunge, and so the execution cursor must physically travel around a 2D grid, but instructions affecting the bitstring just happen -- there are no requirements for you to have positioned the various bits within the grid.
So yes, the Befunge cursor in MFT is the command-issuing tool, and you could view the bitstring as being acted on by a separate color-blob-manipulating tool.
In Spacechem, the command "pick up object" will only work if the logic cursor, which doubles as the robot, is currently over an object. In MFT, the command "rotate right" acts on your ineffable bitstring no matter where the logic cursor happens to be.
That's probably a result of Spacechem's history: The Codex of Alchemical Engineering, the game which would become Spacechem, and to an extent Spacechem itself, focus on programming things to move physical objects.
On a related note, thank you, Zach, for only having two mechanisms, using more visual programming, and adding a sync instruction. Until you play CAE, you cannot possibly know how good you've got it.
