I’ve played 3 Zachtronics games (SpaceChem, Infinifactory, Opus Magnum) and was ultimately disappointed by all of them. (I didn’t 100% any but got pretty far in all 3.)
Am I missing something about these games that makes them great, or is the following just what it looks like if I’m one of the people who doesn’t find them fun?
The early levels made me think: This is too easy, but early levels are effectively a tutorial and most players have less programming skill than me, so that’s not very surprising. Later on there should be harder levels, and I bet hard versions of this would be fun.
But then the levels never got harder, they only got bigger. Maybe an early level has 6 steps to the solution, and a later level has 30 steps, but no individual step is hard and the overall direction is obvious, so it’s not that much different from playing 5 easy levels in a row (and takes as long).
And when the levels get big, the lack of real programming tools really starts to pinch. You can’t annotate your code with comments, you can’t write reusable subfunctions, you can’t output logs. Test runs take too long because break points are weak or non-existent (you can’t e.g. break on the 12th iteration of a loop or when a condition is met) and in some of the games the max sim speed is also frustratingly low.
If solving these puzzles were my actual job, I’d invest heavily in building a better IDE.
I made some machines involving (IIRC) hundreds of sequential instructions where I had to hold in my mind the state the molecule was going to be in so I could keep track of what to do next. But tracking that was the only hard part; if the game had given me a continuously-updating preview of what the machine’s state would be at the end of what I’d written so far, the process would have been trivial.
Some Zachtronics games are more genuinely programming like as they include literal programming languages, and at least space for comments (TIS-100, Shenzen I/O, Hexapunks). That said, there’s always an “artificial limitations of the system” factor, as they’re going for emulating a certain kind of old time experience of working with very low level programs (assembly or very limited microcontrollers). I like them though I must say I almost never finish them as after a whole work day coding, my general idea of fun doesn’t tend to coincide with “even more coding, but made more frustrating on purpose”.
Did you not find the leaderboards compelling? My experience with Zachtronics games was that I’d solve a few levels, then try to optimize earlier levels based on new things I’d learned. Rinse and repeat. Sometimes I’d find a better solution; at other times I’d fail and would then marvel “how could this level possibly be solved any faster?”. Just solving the levels was only half the fun, for me.
I finished most Zachtronics games, and the only game where I had a similar “this is just bigger” complaint, was the last chapter in Infinifactory, so I stopped playing there.
That said, if you program as a career or hobby, I can see how these games would offer more of the same, except with a worse work environment (IDE, editor, etc.), and so might be a somewhat poor fit.
Personally I liked how some of these games also yielded some pretty neat insights for me.
In particular, in Opus Magnum, I eventually realized that to achieve the fastest-possible solution to a level (except for a constant), you either need to fill the outputs as quickly as possible (IIRC every 2 cycles), or fetch from the inputs as quickly as possible (also every 2 cycles). But once you’ve done that, all other details of your actual design are almost irrelevant. Even the constant is just “how quickly can I produce the first output”.
Anyway, this input/output thing generalizes to systems of all kinds: e.g. a factory is maximally efficient, given fixed input or output bandwidths, if either bandwidth is fully utilized. Once your assembly line produces items 24⁄7 at its maximum speed, the factory is maximally efficient until you can further speed up the assembly line or add another. Or, as a looser analogy, in electro- and hydrodynamics, you can characterize a system either by its contents or by just its boundaries; that’s how in Maxwell’s equations, the integral vs. differential equations are related.
Programming is my career. I didn’t find the leaderboards very challenging; I especially noticed this in Opus Magnum, which I partially blame on them picking boring optimization targets. I typically picked one category to optimize on my first play of the level, and often tied the best score for that category on my first try.
Your realization that the fastest cycle time would be limited by the max input or output speed is something that I figured out immediately; once you’re aware of it, reaching that cap is basically just a matter of parallelization. Hitting the exact best possible “warm-up” time to produce the first output wasn’t completely trivial, but getting in the top bucket of the histogram was usually a breeze for me.
Optimizing cost is even simpler. You can put a lower bound on the cheapest possible cost by listing the obviously-necessary components (e.g. if the output has a bond that the inputs don’t then you need at least one bonder), then calculating the shortest possible track that will allow a single arm to use all of those, then checking whether it’s cheaper to replace the track with an extending arm instead. As far as I can recall, I didn’t find a single level where it was difficult to hit that lower bound once I’d calculated it; doing the entire level with only 1 arm is sometimes a bit tedious but it’s not actually complicated.
Doing the minimum-cost solution will usually get you very close to the minimum-size solution automatically, since you’ve already crammed everything around one arm. This is probably the hardest category if you want to be literally optimal, but I was often in the top bucket by accident.
I think they should have had players optimize for something like “rental cost” where you pay for (components + space) multiplied by running time, so that you have to compromise between the different goals instead of just doing one at a time.
Wow, that sounds like those games really were way too easy for you. That said, after reading your comment, I can’t help but think that you’re obviously not the target audience for these games. A popular programming-style game marketed at gamers was unlikely to challenge a career programmer, otherwise it would’ve never gotten popular in the first place. For people like you, maybe code competition websites are more suitable?
That’s definitely not Zachtronics, at least any of the games I’ve played. If that game exists it would be pretty awesome—although probably even more niche than Zachtronics games (which weren’t too niche to support the makers for a decade+, granted).
Fun is subjective. I enjoyed how there are many valid routes to a solution, it’s a constrained solution space but the levels that come with the game are all still solvable many different ways. (all 3 are the same game. There is also TIS-100, Shenzhen IO, Exapunks, and Molek-Syntez. Same game. )
What others say is that a Zachtronics game makes you feel smart. Because of the freedom you have to a solution, sometimes you get an “ah-ha” moment and pick a solution that may be different from the typical one. You can also sometimes break the rules, like letting garbage pile up that doesn’t quite fail your test cases.
I agree with you an IDE would make the game easier though not necessarily more fun. FPS games do not give you an aimbot even though in some of them it is perfectly consistent with the theme of the game world. Kerbal space program does not give you anything like the flight control avionics that Apollo 11 actually had, you have to land on the Mun the hard way.
That is a rather long article that appears to be written for an audience that is already familiar with their community. Could you summarize and/or explain why you think I should read it?
I read it, it’s a summary of a weekly challenge in Opus Magnum by the author of the challenge, detailing how people managed to beat the author’s cycles score and get reasonably close to the theoretical minimum cycles. As someone who only got about halfway through Opus Magnum, the puzzle and solutions there are wildly complex.
I’ve played 3 Zachtronics games (SpaceChem, Infinifactory, Opus Magnum) and was ultimately disappointed by all of them. (I didn’t 100% any but got pretty far in all 3.)
Am I missing something about these games that makes them great, or is the following just what it looks like if I’m one of the people who doesn’t find them fun?
The early levels made me think: This is too easy, but early levels are effectively a tutorial and most players have less programming skill than me, so that’s not very surprising. Later on there should be harder levels, and I bet hard versions of this would be fun.
But then the levels never got harder, they only got bigger. Maybe an early level has 6 steps to the solution, and a later level has 30 steps, but no individual step is hard and the overall direction is obvious, so it’s not that much different from playing 5 easy levels in a row (and takes as long).
And when the levels get big, the lack of real programming tools really starts to pinch. You can’t annotate your code with comments, you can’t write reusable subfunctions, you can’t output logs. Test runs take too long because break points are weak or non-existent (you can’t e.g. break on the 12th iteration of a loop or when a condition is met) and in some of the games the max sim speed is also frustratingly low.
If solving these puzzles were my actual job, I’d invest heavily in building a better IDE.
I made some machines involving (IIRC) hundreds of sequential instructions where I had to hold in my mind the state the molecule was going to be in so I could keep track of what to do next. But tracking that was the only hard part; if the game had given me a continuously-updating preview of what the machine’s state would be at the end of what I’d written so far, the process would have been trivial.
Some Zachtronics games are more genuinely programming like as they include literal programming languages, and at least space for comments (TIS-100, Shenzen I/O, Hexapunks). That said, there’s always an “artificial limitations of the system” factor, as they’re going for emulating a certain kind of old time experience of working with very low level programs (assembly or very limited microcontrollers). I like them though I must say I almost never finish them as after a whole work day coding, my general idea of fun doesn’t tend to coincide with “even more coding, but made more frustrating on purpose”.
Did you not find the leaderboards compelling? My experience with Zachtronics games was that I’d solve a few levels, then try to optimize earlier levels based on new things I’d learned. Rinse and repeat. Sometimes I’d find a better solution; at other times I’d fail and would then marvel “how could this level possibly be solved any faster?”. Just solving the levels was only half the fun, for me.
I finished most Zachtronics games, and the only game where I had a similar “this is just bigger” complaint, was the last chapter in Infinifactory, so I stopped playing there.
That said, if you program as a career or hobby, I can see how these games would offer more of the same, except with a worse work environment (IDE, editor, etc.), and so might be a somewhat poor fit.
Personally I liked how some of these games also yielded some pretty neat insights for me.
In particular, in Opus Magnum, I eventually realized that to achieve the fastest-possible solution to a level (except for a constant), you either need to fill the outputs as quickly as possible (IIRC every 2 cycles), or fetch from the inputs as quickly as possible (also every 2 cycles). But once you’ve done that, all other details of your actual design are almost irrelevant. Even the constant is just “how quickly can I produce the first output”.
Anyway, this input/output thing generalizes to systems of all kinds: e.g. a factory is maximally efficient, given fixed input or output bandwidths, if either bandwidth is fully utilized. Once your assembly line produces items 24⁄7 at its maximum speed, the factory is maximally efficient until you can further speed up the assembly line or add another. Or, as a looser analogy, in electro- and hydrodynamics, you can characterize a system either by its contents or by just its boundaries; that’s how in Maxwell’s equations, the integral vs. differential equations are related.
Programming is my career. I didn’t find the leaderboards very challenging; I especially noticed this in Opus Magnum, which I partially blame on them picking boring optimization targets. I typically picked one category to optimize on my first play of the level, and often tied the best score for that category on my first try.
Your realization that the fastest cycle time would be limited by the max input or output speed is something that I figured out immediately; once you’re aware of it, reaching that cap is basically just a matter of parallelization. Hitting the exact best possible “warm-up” time to produce the first output wasn’t completely trivial, but getting in the top bucket of the histogram was usually a breeze for me.
Optimizing cost is even simpler. You can put a lower bound on the cheapest possible cost by listing the obviously-necessary components (e.g. if the output has a bond that the inputs don’t then you need at least one bonder), then calculating the shortest possible track that will allow a single arm to use all of those, then checking whether it’s cheaper to replace the track with an extending arm instead. As far as I can recall, I didn’t find a single level where it was difficult to hit that lower bound once I’d calculated it; doing the entire level with only 1 arm is sometimes a bit tedious but it’s not actually complicated.
Doing the minimum-cost solution will usually get you very close to the minimum-size solution automatically, since you’ve already crammed everything around one arm. This is probably the hardest category if you want to be literally optimal, but I was often in the top bucket by accident.
I think they should have had players optimize for something like “rental cost” where you pay for (components + space) multiplied by running time, so that you have to compromise between the different goals instead of just doing one at a time.
Wow, that sounds like those games really were way too easy for you. That said, after reading your comment, I can’t help but think that you’re obviously not the target audience for these games. A popular programming-style game marketed at gamers was unlikely to challenge a career programmer, otherwise it would’ve never gotten popular in the first place. For people like you, maybe code competition websites are more suitable?
I suppose I was hoping for a programming-based puzzle game, with some new clever insight required to solve each level, rather than pure programming.
That’s definitely not Zachtronics, at least any of the games I’ve played. If that game exists it would be pretty awesome—although probably even more niche than Zachtronics games (which weren’t too niche to support the makers for a decade+, granted).
Fun is subjective. I enjoyed how there are many valid routes to a solution, it’s a constrained solution space but the levels that come with the game are all still solvable many different ways. (all 3 are the same game. There is also TIS-100, Shenzhen IO, Exapunks, and Molek-Syntez. Same game. )
What others say is that a Zachtronics game makes you feel smart. Because of the freedom you have to a solution, sometimes you get an “ah-ha” moment and pick a solution that may be different from the typical one. You can also sometimes break the rules, like letting garbage pile up that doesn’t quite fail your test cases.
I agree with you an IDE would make the game easier though not necessarily more fun. FPS games do not give you an aimbot even though in some of them it is perfectly consistent with the theme of the game world. Kerbal space program does not give you anything like the flight control avionics that Apollo 11 actually had, you have to land on the Mun the hard way.
Would this have been trivial?
That is a rather long article that appears to be written for an audience that is already familiar with their community. Could you summarize and/or explain why you think I should read it?
I read it, it’s a summary of a weekly challenge in Opus Magnum by the author of the challenge, detailing how people managed to beat the author’s cycles score and get reasonably close to the theoretical minimum cycles. As someone who only got about halfway through Opus Magnum, the puzzle and solutions there are wildly complex.