Opus Magnum represents an interesting maturation in the Zachtronics catalogue. The most visually evident aspect of this maturation is that of aesthetic. Gone is the cold pragmatism of most former (and future) Zachlikes, and in its place is an inviting opulence. The green honeycomb background, the shiny metallic parts, and the revitalized alchemical imagery bring forth an evocative veneer that almost succeeds in hiding the fact that you are actually coding in disguise. The GIF maker is an ingenious rework from Infinifactory, resulting in easily sharable clips of people proud of their creations. And it’s hard not to be slightly proud of your contraptions, as they chug and rotate around following a mesmerizing periodic pattern.
This shift to a strongly appealing aesthetic fits inside a bigger push towards more accessibility. Zachtronics’ veterans will almost immediately note the sharp decline in the actual puzzle-solving challenge here. Compared to the multistaged grandeur of late-game Infinifactory or the spartan ruthlessness of TIS-100, Opus Magnum is fairly easy throughout its runtime. Part of this is a direct consequence of flirting with the infinite (or more like machine precision, which is practically infinite). The player has an astonishing amount of solving power at their disposal, unhindered by any form of space or instruction constraints. It becomes more a matter of when, rather than if, one can solve a puzzle. I was certainly disappointed by this realization. One of the core appeals of these games for me is being thrown into the wilderness and being asked to come out alive with the tools provided. This disappointment has subsided over the years for two reasons. The first is acknowledging the benefits of such openness with puzzle design and tool power. Seeing folks who have never played a Zachtronics game before brimming with satisfaction at their solution. Seeing them sharing their design in a beautiful and convenient manner. All this pokes directly at the heart of what makes the act of problem-solving so damn fun! There are four other games before this where I can baptize myself with fire if I so desire…
Regardless, the second reason is a bit more selfish. One that is another consequence of infinite solving power - incredible optimization depth. Now, here’s a confession. I have over 500 hours in this game. I will spend a thousand more over the coming years. I have performed relatively well in high-level tournaments and have a couple of optimization world records. Still, I would only consider myself somewhat competent at this game. So as a warning, this part is gonna get a bit technical and poke at some of the deeper design decisions and dilemmas that one faces as one falls down this rabbit hole.
Much like other Zachtronics games, the gameplay loop essentially boils down to taking provided inputs in the form of atoms, moving them using mechanical arms and tracks, transforming them using glyphs, and finally dropping them as output. The solution goal here is consistency. Your contraption should, ideally, be able to loop infinitely often. After solving the puzzle, the follow-up question is minimizing one of the three provided metrics. Here’s where all that depth in the design process shows up. In Opus Magnum’s case, there’s the cost of the parts (Cost), the speed of the solution (Cycles), and the amount of space a solution takes (Area). Minimizing one of these metrics usually impacts the other two noticeably, but each offers a substantially different way of solving the puzzle. There’s another tier of optimization that exists beyond this primary level, where you try reducing a second metric at your lowest primary metric score.
Primary Cost minimization requires solving the puzzle with the bare minimum number of arms and glyphs. After some experience with the game, the actual process of recognizing the absolutely required glyphs becomes noticeably easy and the number of arms required is almost always one. Some glyphs have bizarre shapes, thus mandating the use of longer arms or tracks, but ultimately it does become “trivial” to realize what minimum cost is. There does exist a silver lining though. Some puzzle inputs and outputs occupy a lot of space, giving enough flexibility to maybe not require extra tracks or glyphs. This realm of “dubious cost”, as the community calls it, is rich with theory and provides some of the hardest optimization challenges in the game. In terms of secondary optimization, you can pick one of Cycles or Area to minimize. Cycles minimization at low cost mostly boils down to smart programming choices, while Area minimization at low cost amounts to smarter rotations and glyph placement.
Primary Area minimization is closely related to Primary Cost minimization since both try to solve the puzzle with as few pieces as possible. Area just requires better packing of the inputs, outputs, glyphs, and arms. Here the solution process boils down to two major steps. The first is figuring out a good packing of everything you need. The second is programming the arms and ensuring you don’t swing the product you are making too much. More nuanced concepts of the game emerge here, such as input suppression (placing an atom on a partially moved input prevents the next input from spawning). Secondary optimization as Cost or Cycles doesn’t radically change the types of solutions one explores for this metric. This two-step process and a consistent level of challenge across all puzzles make me like this metric more than Cost.
Primary Cycles minimization is intense. You construct massive beasts of machines to reduce two important numbers - Latency (the amount of time it takes to make the first output), and Throughput (the average amount of time between two outputs). Surprisingly enough, tricks to minimize Throughput are different from those that minimize Latency, and sometimes they contradict each other. This results in the richest variety of solutions of any metric, by a substantial amount. Secondary optimization in Cost or Area also heavily influence the design process, and some of the harder Cycles records in the game are massive collaborations across numerous top players.
There’s also a fourth primary metric, Instructions. This only shows up in a special class of puzzles called Production puzzles, where you have to solve the puzzle in a constrained space. Production puzzles are a somewhat controversial addition to the game, as they end up as a response to the game’s lack of difficulty. Unfortunately, the space constraints mean that the actual potential for design is noticeably limited. A swing too hard in the opposite direction, in a way.
These primary metrics are among the better-balanced ones in the Zachtronics’ catalogue, but there’s still some criticism to be had. Area and Cost, for instance, mirror each other a little too much. They both turn the game into a fascinating challenge in constraints, but the constraints are somewhat similar. Cycles minimization can often result in massively exploiting the game’s output system. On the one hand, Opus Magnum (usually) asks for 6 outputs to ensure completion of a puzzle. This surprisingly low requirement means that one can essentially “hack” their way into solving the puzzle before the machine crashes one moment later. On the other hand, the actual detection of the output is janky for an entire class of levels (infinite polymers), resulting in wonderfully bizarre solutions there. I’m certainly a fan of these eccentricities, but they do end up going against the spirit of infinitely running engines. Finally, Instructions is relatively uninteresting as a metric. The sheer power of Opus’ tools has resulted in every single campaign level being solved in at most 4 instructions, and Production puzzles are too few and far between to meaningfully challenge this metric.
Now moving back to infinite space and power. One of the other consequences is that of custom metrics, a surprisingly new phenomenon in Zachlikes. The Opus Magnum community is a desperate hungry lot, and we craft numerous rich metrics to explore on our own. The first example is the SUM metric, which is just the sum of the Cost, Cycles, and Area score of a solution. This bizarre metric forces some surprising compromises at a design level, and coincidentally results in some of the most aesthetically-pleasing solutions. Other custom metrics are Height and Width, which look at how much space a solution occupies vertically and horizontally, respectively. The secondary goal in these metrics is that of Cycles optimization. One of the most bizarre custom metrics is that of Overlap. Turns out there’s a glitch in the game that allows multiple glyphs to be placed on top of each other. This allows for astonishingly fast solutions, and optimization here splits the very notion of a single cycle into fragments (i.e. subcycles) that can be influenced. As I said, we’re a desperate hungry lot.
If there’s one major criticism I’d throw at the game, it would be that of the UI. There are four options for screen resolution, resulting in weird compromises in how the game looks on the screen. None of these choices is particularly ideal, and I’ve had to shift between resolutions based on the puzzle itself. Another issue with the UI is the actual programming part. Unlike previous Zachtronics games, which intertwine the process of design and programming, Opus asks you to place objects on a grid and separately code their instructions on a large tape. You have to drag-and-drop instructions onto this tape, which can be sped up using fixed keyboard shortcuts for the instructions. This is bizarrely limiting, as drag-and-drops are slow for how big the tapes for even simple solutions can get, and fixed keyboard shortcuts can be inconvenient to get used to. The worst part is arguably when you want to insert an instruction in the middle of a full tape - you have to drag-or-drop exactly in the middle. There’s no keyboard shortcut for that! This means fixing parts of your solution becomes taxing over time, especially in the case of Cost or Area solutions, which have incredibly long instruction tapes. Cycles solutions don’t escape from this as well. It’s cumbersome to copy large chunks of instructions to reuse, requiring you to drag your mouse over multiple screens while holding the Shift key. Finally, the actual speed of running the solutions is surprisingly slow. Even the Alt-click speedup isn’t sufficient at points. Granted, one can use speedhacks to alleviate this, but this makes Cost and Area solutions painful to deal with overtime. I think a better checkpoint system for instruction locations across a tape would have made navigation and code reuse much more efficient. Ironic really, that a game all about efficiency does have some notable inefficiencies when it comes to actually playing the game. This only really grates on folks who spend far too much time on this game, so maybe it’s on us?
Regardless, Opus Magnum is a pretty cool game. It’s probably the most accessible and aesthetically-pleasing Zachtronics game. Getting into higher-level play has been one of the most satisfying parts of my gaming life in the past three years. Go play it y’all!
This shift to a strongly appealing aesthetic fits inside a bigger push towards more accessibility. Zachtronics’ veterans will almost immediately note the sharp decline in the actual puzzle-solving challenge here. Compared to the multistaged grandeur of late-game Infinifactory or the spartan ruthlessness of TIS-100, Opus Magnum is fairly easy throughout its runtime. Part of this is a direct consequence of flirting with the infinite (or more like machine precision, which is practically infinite). The player has an astonishing amount of solving power at their disposal, unhindered by any form of space or instruction constraints. It becomes more a matter of when, rather than if, one can solve a puzzle. I was certainly disappointed by this realization. One of the core appeals of these games for me is being thrown into the wilderness and being asked to come out alive with the tools provided. This disappointment has subsided over the years for two reasons. The first is acknowledging the benefits of such openness with puzzle design and tool power. Seeing folks who have never played a Zachtronics game before brimming with satisfaction at their solution. Seeing them sharing their design in a beautiful and convenient manner. All this pokes directly at the heart of what makes the act of problem-solving so damn fun! There are four other games before this where I can baptize myself with fire if I so desire…
Regardless, the second reason is a bit more selfish. One that is another consequence of infinite solving power - incredible optimization depth. Now, here’s a confession. I have over 500 hours in this game. I will spend a thousand more over the coming years. I have performed relatively well in high-level tournaments and have a couple of optimization world records. Still, I would only consider myself somewhat competent at this game. So as a warning, this part is gonna get a bit technical and poke at some of the deeper design decisions and dilemmas that one faces as one falls down this rabbit hole.
Much like other Zachtronics games, the gameplay loop essentially boils down to taking provided inputs in the form of atoms, moving them using mechanical arms and tracks, transforming them using glyphs, and finally dropping them as output. The solution goal here is consistency. Your contraption should, ideally, be able to loop infinitely often. After solving the puzzle, the follow-up question is minimizing one of the three provided metrics. Here’s where all that depth in the design process shows up. In Opus Magnum’s case, there’s the cost of the parts (Cost), the speed of the solution (Cycles), and the amount of space a solution takes (Area). Minimizing one of these metrics usually impacts the other two noticeably, but each offers a substantially different way of solving the puzzle. There’s another tier of optimization that exists beyond this primary level, where you try reducing a second metric at your lowest primary metric score.
Primary Cost minimization requires solving the puzzle with the bare minimum number of arms and glyphs. After some experience with the game, the actual process of recognizing the absolutely required glyphs becomes noticeably easy and the number of arms required is almost always one. Some glyphs have bizarre shapes, thus mandating the use of longer arms or tracks, but ultimately it does become “trivial” to realize what minimum cost is. There does exist a silver lining though. Some puzzle inputs and outputs occupy a lot of space, giving enough flexibility to maybe not require extra tracks or glyphs. This realm of “dubious cost”, as the community calls it, is rich with theory and provides some of the hardest optimization challenges in the game. In terms of secondary optimization, you can pick one of Cycles or Area to minimize. Cycles minimization at low cost mostly boils down to smart programming choices, while Area minimization at low cost amounts to smarter rotations and glyph placement.
Primary Area minimization is closely related to Primary Cost minimization since both try to solve the puzzle with as few pieces as possible. Area just requires better packing of the inputs, outputs, glyphs, and arms. Here the solution process boils down to two major steps. The first is figuring out a good packing of everything you need. The second is programming the arms and ensuring you don’t swing the product you are making too much. More nuanced concepts of the game emerge here, such as input suppression (placing an atom on a partially moved input prevents the next input from spawning). Secondary optimization as Cost or Cycles doesn’t radically change the types of solutions one explores for this metric. This two-step process and a consistent level of challenge across all puzzles make me like this metric more than Cost.
Primary Cycles minimization is intense. You construct massive beasts of machines to reduce two important numbers - Latency (the amount of time it takes to make the first output), and Throughput (the average amount of time between two outputs). Surprisingly enough, tricks to minimize Throughput are different from those that minimize Latency, and sometimes they contradict each other. This results in the richest variety of solutions of any metric, by a substantial amount. Secondary optimization in Cost or Area also heavily influence the design process, and some of the harder Cycles records in the game are massive collaborations across numerous top players.
There’s also a fourth primary metric, Instructions. This only shows up in a special class of puzzles called Production puzzles, where you have to solve the puzzle in a constrained space. Production puzzles are a somewhat controversial addition to the game, as they end up as a response to the game’s lack of difficulty. Unfortunately, the space constraints mean that the actual potential for design is noticeably limited. A swing too hard in the opposite direction, in a way.
These primary metrics are among the better-balanced ones in the Zachtronics’ catalogue, but there’s still some criticism to be had. Area and Cost, for instance, mirror each other a little too much. They both turn the game into a fascinating challenge in constraints, but the constraints are somewhat similar. Cycles minimization can often result in massively exploiting the game’s output system. On the one hand, Opus Magnum (usually) asks for 6 outputs to ensure completion of a puzzle. This surprisingly low requirement means that one can essentially “hack” their way into solving the puzzle before the machine crashes one moment later. On the other hand, the actual detection of the output is janky for an entire class of levels (infinite polymers), resulting in wonderfully bizarre solutions there. I’m certainly a fan of these eccentricities, but they do end up going against the spirit of infinitely running engines. Finally, Instructions is relatively uninteresting as a metric. The sheer power of Opus’ tools has resulted in every single campaign level being solved in at most 4 instructions, and Production puzzles are too few and far between to meaningfully challenge this metric.
Now moving back to infinite space and power. One of the other consequences is that of custom metrics, a surprisingly new phenomenon in Zachlikes. The Opus Magnum community is a desperate hungry lot, and we craft numerous rich metrics to explore on our own. The first example is the SUM metric, which is just the sum of the Cost, Cycles, and Area score of a solution. This bizarre metric forces some surprising compromises at a design level, and coincidentally results in some of the most aesthetically-pleasing solutions. Other custom metrics are Height and Width, which look at how much space a solution occupies vertically and horizontally, respectively. The secondary goal in these metrics is that of Cycles optimization. One of the most bizarre custom metrics is that of Overlap. Turns out there’s a glitch in the game that allows multiple glyphs to be placed on top of each other. This allows for astonishingly fast solutions, and optimization here splits the very notion of a single cycle into fragments (i.e. subcycles) that can be influenced. As I said, we’re a desperate hungry lot.
If there’s one major criticism I’d throw at the game, it would be that of the UI. There are four options for screen resolution, resulting in weird compromises in how the game looks on the screen. None of these choices is particularly ideal, and I’ve had to shift between resolutions based on the puzzle itself. Another issue with the UI is the actual programming part. Unlike previous Zachtronics games, which intertwine the process of design and programming, Opus asks you to place objects on a grid and separately code their instructions on a large tape. You have to drag-and-drop instructions onto this tape, which can be sped up using fixed keyboard shortcuts for the instructions. This is bizarrely limiting, as drag-and-drops are slow for how big the tapes for even simple solutions can get, and fixed keyboard shortcuts can be inconvenient to get used to. The worst part is arguably when you want to insert an instruction in the middle of a full tape - you have to drag-or-drop exactly in the middle. There’s no keyboard shortcut for that! This means fixing parts of your solution becomes taxing over time, especially in the case of Cost or Area solutions, which have incredibly long instruction tapes. Cycles solutions don’t escape from this as well. It’s cumbersome to copy large chunks of instructions to reuse, requiring you to drag your mouse over multiple screens while holding the Shift key. Finally, the actual speed of running the solutions is surprisingly slow. Even the Alt-click speedup isn’t sufficient at points. Granted, one can use speedhacks to alleviate this, but this makes Cost and Area solutions painful to deal with overtime. I think a better checkpoint system for instruction locations across a tape would have made navigation and code reuse much more efficient. Ironic really, that a game all about efficiency does have some notable inefficiencies when it comes to actually playing the game. This only really grates on folks who spend far too much time on this game, so maybe it’s on us?
Regardless, Opus Magnum is a pretty cool game. It’s probably the most accessible and aesthetically-pleasing Zachtronics game. Getting into higher-level play has been one of the most satisfying parts of my gaming life in the past three years. Go play it y’all!