Anyway Opus Magnum is IMO well-named and truly Zachtronics' magnum opus and if you haven't played the base game, you have to check it out!
Now excuse me while I try the DLC
@rygorous I split the Zachtronics oeuvre into "games about machines and games about programs" and Opus Magnum is the best of their games about machines and the best overall.
I give the nod to EXAPUNKS for the games about programs. It's the only one with a solid enough programming model to not feel like a dumb stunt but a weird enough one to not feel like I'm doing work.
@mcmartin Don't care about this story in TIS at all. But it has by far the most interesting (and interestingly abusable) programming model of his games. (Mostly due to a single instruction that I won't get into.) It also has the most interesting puzzles.
Exapunks OTOH is pretty much a one trick pony, and I don't find it a very interesting trick.
@TomF @rygorous For me, the issue with both TIS and Shenzhen was eternally being one instruction slot short somewhere and repeatedly having to redesign the entire solution at that point, a thing that got tedious and which never happens in EXA or Opus.
I also kind of liked the bizarre networking model, though I feel like I got up to less mischief with it than I'd have hoped.
If hard limits on micro-optimizations is the *goal*, yeah, the calculus gets reversed.
@mcmartin @TomF That's definitely the prime issue with both but with Exa I _still_ kept running out of instruction slots for optimized solutions because the answer to cycle-optimized solutions is _always_ unrolling as much as you possibly can.
So at that point you end up with something that still has the exact same type of tedious frustrating limits but makes you type a lot more code to get there.
@mcmartin @TomF and the thing that really turned me off Exa was that you fairly quickly realize that due to this emphasis on bulk processing via unrolled loops, if you want low cycle count scores, you end up forced into this pattern where you have one Exa running an unrolled infinite loop and another Exa that kills the first Exa at just the right time to process the number of items you needed.
It's fun to figure out the first time you do it,
@mcmartin @TomF This adds a lot of boilerplate and makes it extra-annoying to edit solutions after because ~every change requires redoing the "number of cycles to wait until I kill the other Exa" calc.
The main reason TIS-100 is my favorite is purely because it is the _one_ Zachtronics programming game where you can do jump table/switch statement/computed goto that is actually decent. (Via JRO.)
@mcmartin @TomF both TIS-100 and Shenzhen I/O also have the thing where you have the implicit free looping that biases you away from jumps and forces you into weird spaghetti.
It's kind of annoying that in all three (TIS, Shenzhen, Exa) the key source of challenge in cycle(/power)-optimized solutions is just that your flow control sucks.
I think I would've enjoyed Exa a lot more if I just had a fricking M68k "dbra" (dec counter and branch if it wasn't 0) equivalent.
@mcmartin @TomF That said, I definitely agree that the thing in especially Shenzhen and TIS where a key challenge is just getting any solution that fits _at all_ is also frustrating.
It's annoying how rigid the game is about this. In both I would've had a much better experience if it let me exceed instruction limits during dev with the caveat that "solution will not score" or similar.
Not even having space for sensible labels, comments or empty lines is just obnoxious.
@mcmartin @TomF The worst is when you design a solution that it turns out can't possibly work because it's reliant on some timing thing that you thought was true for all inputs (based on the first verification test you can see) but then fails later on.
Needing to fit inside the insn limits at all times means you do all the work to cram it into the limits only to _then_ learn that your approach was doomed from the start.