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).
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).