Playing Opus Magnum by different rules
I’m far from the first person to write about Opus Magnum. It’s a genius game from 2017, made by the studio Zachtronics, in which you program machines to perform alchemy. However, I can just about guarantee that I am the first person to have played it in the following way. So it’s time to talk about how my latest crazy creation works.
Opus Magnum
First, the basics. What is Opus Magnum?
As shown above, the game is structured into a story, and progressing the story involves solving puzzles. In classic Zachtronics fashion, every solution made is scored in a few different ways, and the tradeoffs between cost, cycles, and area, reward going back and solving the same puzzle again for a different goal. Many players try to chase the best possible scores, and there are histograms and leaderboards with your steam friends, to motivate that sort of competition.
So what does solving a puzzle look like? Well, in the process of solving, it looks sort of like this:
You place as many parts as you want on the hexagonal grid, and place instructions on the arms to get them to perform actions. Here, both arms have a simple instruction tape: grab the part, swing twice, drop, and swing back. They swing in different directions, and arm 2 starts one cycle after arm 1. The silver glyph converts water (blue) into salt (white), and the two-tile glyph bonds things together. Top center is the output, and making the output 6 times brings up the “you win” screen and gives you your scores.
Pretty basic, as this is the tutorial puzzle. But the most rewarding part of solving a puzzle, is watching it run after it works. And the game has a built-in gif creator to enable that.
Optimization and its alternatives
The solution above isn’t particularly optimal in any score. You can be cheaper, or faster, or smaller, with a different design. Players will pick whatever they want to focus on. Sometimes the goal is to be pretty-good at everything at the same time, instead of making the best possible score in one. Sometimes the goal is purely aesthetic. Every single goal you can define, including the cost, cycles, or area provided by the game, is just a guideline. To me, the real ideas given by the game are the hexagonal grid, a few movement rules, and the means to turn inputs into outputs.
Years ago, one player was fed up with the definition of “cycles” used by the game. Scores are assigned at the “you win” screen, which typically comes when your machine drops its 6th output. This means you can get a good cycles score with a machine that crashes immediately after completion. If the goal is for some alchemical wizardry to be performed on atoms, or atomic proxies, wouldn’t it be a complete failure to only create six and then fail? You need trillions of trillions of atoms to be able to solve the problems the puzzles purport to solve, like making fuel or clean water.
So, he proposed an alternative metric: throughput. Throughput shares a lot of features with cycles – you want to be making outputs as quickly as possible. However, there is the additional requirement that a solution is able to run forever. When the instruction tape loops, the machine must keep going. And, importantly, players need not worry about latency. Rather than rushing the 6th product out as quickly as possible, a throughput-optimized solution can take its time and keep the perfect balance between input rate and output rate. All of the solutions below have the same throughput (one output on average every 2 cycles, ad infinitum), despite scoring differently on cycles.
There is a clear problem though. Throughput can’t be quickly checked by the game, in the same way as cost or cycles or area. Opus Magnum is Turing Complete, and people have built computers in the game (I will make a post on that one some other time). When you require a solution to run forever, you end up with examples reminiscent of the Halting Problem. By replacing 6 with infinity, we moved toward scoring systems which require mathematical proof. Fortunately, many solutions are simple cases where the machine settles into a steady state. If there are identical board contents before and after the instruction tape has looped, the proof is trivial.
Within what follows, I will stick to puzzles where there is no Halting Problem trickery. I will assume that throughput, when it can be calculated trivially from the programming, is the one true metric to optimize.
Finding the limits
I play the game trying to find the limits. Cheesy as it is, I want to be the very best. Throughput being a mathematical property, it is natural to try to prove not only that it takes some specific value, but that this value is optimal. In nearly every case, the limit to throughput comes from the inputs. Your solution is optimal only if it is obtaining (and using) inputs at the maximum possible rate.
There are occasionally some clever insights or errata hiding behind that remark, but that’s the bulk of it. Pull inputs off of the sources every 2 cycles (one to grab, one to move). Use them to build outputs. Drop the outputs.
You can design puzzles where this is easier said than done, such as providing a 47 atom input and 31 atom output. Every 2 cycles you would generate 47 more atoms to handle, and it would take a lot of effort to get the proper 31 atom structures out of wherever those atoms go. Especially when you need to waste nothing. But thanks to bonding, I am confident it would still be possible. Bonders allow you to connect things and move them as a group, or as I like to call it sometimes, a brick. A brick rotated around its corner can move fast, cover ground, and transform in parallel. These biggie-bricks are the savior of throughput.
Besides inputs, the other limit to throughput is the outputs themselves. You can drop an output on the output glyph once per cycle. So if instead of 47 and 31 above, I had picked 47 and 3, the limit would be one output per cycle, and you could slow the input rate down quite a bit and still meet that.
So for a while, that is how I played the game. Inputs every 2 cycles, or outputs every cycle, and the design problem in the middle addressed with bricks. It’s still definitely within the spirit of the game, and it got me cycles leaderboard spots.
What came next, is much less in the spirit of the game. But that is where it gets really interesting.
Overlap
Misbehaving
Opus magnum saves the solutions you build, in .solution files in your Documents folder. Such a file can be opened, examined, and edited. It isn’t pretty, the file is raw bytes.
But I have a stomach for such things (I have a stomach for a lot, apparently). I was able to determine that the checks being performed in the solution editor, aren’t performed when you load a solution from a file. In other words, the message “there is already another part here”, could be bypassed.
By building a solution file through means other than the in-game editor, I could stack up whatever I pleased. Luckily, the game is completely happy to load, run, and score a solution that uses overlapping components. So here is the true best solution to stabilized water.
You don’t need to place any arms at all, for this puzzle. The inputs spawn into place, transform using glyphs underneath them, and fill the output glyph instantly. The whole thing completes in 3 cycles.
I would consider the number 3 here, to be a very unexpected result.
It was through overlap, that a collection of players began to reverse engineer the game. Make a solution, try to predict what that stack of components will do, and update your understanding of the process based on the result. Repeat until satisfied. Two major players in that early reverse engineering were Grimmy and myself. Grimmy has a writeup on the “sub-cycle ordering” here: https://github.com/grimy/om_overlap. And indeed, the theory predicts that this should complete in exactly 3 cycles. This happens because the inputs will try to spawn both before and after movement. Because the output glyph is taking them away, both spawns succeed and so two outputs are formed every cycle.
It is safe to say that this was never a design intention of the game. The fact that components act at two separate points in the cycle, can be motivated for other reasons. It looks nicer if you are stepping through a solution, for the inputs to be there after you move, but before the next cycle starts. It makes more sense. And it really shouldn’t matter. But with overlap, we made it matter. And I started to go through the game, one puzzle at a time, and beat cycles records using this new exploit.
Reception
Obviously they were not considered leaderboard-eligible solutions by the community. This was cheating. And to a lot of people, I was doing a bad thing, by designing these solutions. But this alternate universe of Opus Magnum solutions was exciting, and still had its rules. And the limits were far murkier. When a solution wasn’t capable of auto-solving like stabilized water, the best approach seemed to be to stick a bonder underneath the input, and pull atoms out like a chain of beads, one per cycle. It was far better than needing to waste the cycle grabbing every time.
Word made it to Zach of Zachtronics himself. Some crazy player had discovered a game within his game, enabled by stacking parts on top of each other. This was early 2019, and he was giving a talk at the Game Developers Conference. In the Q&A, he was asked “what is the craziest solution you have seen, that surprised you, to any of your puzzles”. His response is below.
I don’t think I’ve ever been surprised by anything – no I take that back. Somebody hacked our save files so they could overlap, like, a bunch of glyphs. And they make these incredible solutions where it’s just like they are pulling stuff out and it’s instantly being bonded. It’s like a magician, this molecule just appears out of nowhere, and you’re like “how did that happen?”. That was cool, and that surprised me. And then I had to go in and, like, delete all of his leaderboard entries because he had leaderboards turned on and his friends were complaining.
-Zach Barth of Zachtronics, 2019
As a personal note, I was thrilled to have been noticed, recognized, and called out for this. I also missed the opportunity of a lifetime to be in the room for it. I was in the city at the time and my company had a shared pass to GDC, but I didn’t look at the schedule and assumed that I would be happier giving my spot to someone else. If only..
Next steps
Convenience measures
Because of this discovery being announced so publicly, many people were concerned that the game would be patched. But instead, Zach took an approach I appreciate – adding a new option to the game so that solutions do not submit to steam. Overlap was here to stay, but you could solve puzzles without poisoning your leaderboards.
Another player also found a way to achieve overlap within the editor, using a series of invalid placement, drag-delete, and multiselect. It’s a little song and dance but it is way more convenient than trying to build a solution from bytes or code.
New achievements
Grimmy went through all the puzzles and effectively one-upped me in every way they could manage. Using their theoretical knowledge, they built contraptions that started to take more advantage of the fact that inputs spawn twice in a cycle, leading to faster solutions that displaced me from the (overlap-specific) record boards.
These solutions become impenetrably complex very quickly. I will try to explain some of the features of this solution.
First is the setup process. You will notice that as part of the loop, there is a point where arms at top and bottom grab the input salts directly and spin them into these big wheels. This is done to set aside enough extra salts for the next 6 outputs.
Next is the work loop. Every 7 cycles after setup, the arms do a little dance which creates an output. The output glyph itself is the sprawling chemistry looking thing made of 6 black atoms and an attached bit of color. The little arms on the right are holding a red and a green “wand”. These atoms aren’t needed in the actual product, but the fact that they exist allows one to take an input in a single cycle, by bonding to it instead of grabbing it. It is called a wand due to the notion that you hold the thing that moves the thing, instead of holding the thing you move. They help produce the colorful part of the output.
The black ring, which this puzzle is notorious for, is made of mors. Mors is an atom created by passing two salts into the glyph of animismus. Also produced is vitae, (the life counterpart to mors’ death), but due to the requirements of this puzzle, vitae only really goes into the trash (which are the big yellow disposal glyphs).
It is during the creation of mors, that this solution manages to use two salt in the same cycle. Every time that the output is created, the final salts to finish it off spawn into place from the inputs, and are instantly whisked away by the output. Before the next movement phase, salt spawns again. And by placing a second salt from storage on top of the animismus glyph, Grimmy provides a means to use it.
Now, animismus is only able to consume salt during the specific half-cycle being employed here. The output itself, is able to consume on either half cycle. So this specific marriage of output-after-movement, animismus-before-movement, is the usable tech.
Lastly, is the cleanup. Either as part of building the 6th output or immediately after, all wands are dropped off, arms return to their starting positions, and there is some real downtime, before the next 6 products are created. This is well-behaved by cycles solution standards. Nothing stops a player from just letting the machine crash, but those who enjoy looping gifs tend to prefer a result that loops, even if there is downtime.
To summarize: this machine has a 52 cycle loop. In those 52 cycles, it creates 108 atoms (6 outputs) worth of material, all by cycle 50. The downtime afterward is to get back into its initial state. Comparing the efficiency to a couple of standards:
- vs fair play: 2 salt sources can generate a total of 52 salt
- vs pulling out a chain of atoms: 2 salt sources can generate a total of 102 salt (one salt grabbed, the rest follow)
- vs the potential displayed by stabilized water: 2 salt sources attempt to create 208 salt
Clearly this solution is better than fair play, and marginally better than what I was doing, but there’s still a lot of material that we just can’t use. Murky limits.
Other metrics
As evident in the Stabilized Water overlap solution, cycles is not the only metric to benefit from overlap. Area and cost also are brought below their fair-play counterparts. As acceptance within the community of this alternate game-within-a-game grew, we expanded our leaderboards to accept overlap solutions for all metrics. This brings us naturally to a very intimidating conclusion.
Overlap Throughput
A first look
On November 1, 2021, I proposed a fun challenge to the discord community. I built a simple custom puzzle, and asked people to submit an overlap solution with perfect throughput. It wasn’t trivial like Stabilized Water, you still needed to program some arms and to use your brain. I had calculated perfect throughput to be an output every 2 cycles. No downtime allowed, your approach needed to run in a fully functioning loop.
This isn’t the first time overlap throughput had been discussed. In the 2021 tournament earlier the same year, one of the puzzles provided overlapping glyphs with one of the inputs, and one of the scores awarded was for throughput. But that puzzle never let people overlap things with the output glyph, which meant we were free from output-after-movement, something-else-before-movement tricks, which my custom puzzle had.
In total, this custom puzzle got the attention of maybe a dozen people, and 4 submitters. The best solution is shown below.
This solution gives some insights into what separates overlap cycles, from overlap throughput. You need to find ways for the same programming to achieve both the setup and the work loop. This is related to the ways of building a computer in the game. The same programming manifests differently depending on context.
For example, there is what appears to be a useless track at the top. The arm on that track never goes to the minus end. But actually, the arm starts on the minus end, and its programming is:
- Grab
- Pivot clockwise
- Attempt to move in the + direction on the track
- Pivot clockwise
- Repeat
The grab is a useless instruction if the arm is already grabbing. And the advance-on-track is a useless instruction if the arm is at the end of its track. But those two extra instructions allow it to begin by grabbing the input and moving into position. Those instructions allow it to do its own setup, without disrupting the possibility of spending the rest of ever in a work loop.
Similarly the arm at the bottom appears to be grabbing nothing. That is another case where programming manifests differently depending on context. The first time that arm is acting, the atoms there are grabbable. But all future times, the atom that would be there has already been consumed into the output, and so the grab fails.
All that said, here is the same gif, but starting from cycle 0. It will be much more jarring, but it is the exact same solution.
Absolute Insanity
But we were only just beginning. By most measurements, “Reactive Shenanigans” was a very simple, pedagogical puzzle. Some true horrors of overlap throughput lie within the campaign of the game. I began to study, experiment, and expand the wealth of techniques Grimmy had recorded from their efforts. My goal was to make some unbelievable overlap throughput solutions.
My early efforts on Litharge Separation and Health Tonic were well loved by the reddit community. Both solutions had some wonderful aesthetics and weren’t too mired in complex ratios or abstruse setup loops. You can read more about them in the threads below.
However, not every puzzle was so kind. Meet the antagonist of this blog post, Invisible Ink.
Invisible Ink
Often admired for its symmetric outputs with a yin/yang feel to them, this puzzle seemed like another candidate for an aesthetically pleasing overlap throughput solve. That impression turns out to be very wrong.
The math
This puzzle is just some water and salt attached to vitae and mors, both of which are created in a pair from animismus. But as Grimmy showed in the cycles solution above, animismus provides some sneaky opportunities with overlap. If salt belonging to an output is generated in-place, then you can also use that same input to fill animismus on the same cycle. But if both inputs have salt glyphs beneath them, then the puzzle cannot be solved. You need there to be some water. And so, the symmetry breaks immediately, by putting salt under one input and not the other.
There’s a second method available to extract an input during the half cycle after an output. This method is compatible with any input, but it this case it is only possible immediately after animismus acts. This wasn’t used at all in Grimmy’s solution above because it wasn’t necessary – every cycle an output was made, the inputs were used twice already. But in Invisible Ink, you make two outputs while using animismus only once. So it’s a perfect opportunity to make full use of this tech.
- First output is formed, salt fills animismus
- Second output is formed, animismus output is used to extract both inputs
- …repeat?
Not exactly. Even ignoring downtime, that process simply uses more material than it creates. In this demonstration puzzle, I have the invisible ink inputs and outputs (overlapped with each other) in the middle of the board. Then I added on the right, a 5 atom input that gets reduced to a single atom by following the outlined process. On the left, I added a 2 atom input that gets converted to a 5 atom output.
Counting atoms only, it looks like we are a single atom short of sustaining this, 5+2 in and 5+1 out. That missing atom is water, which checks out – we don’t get water when filling animismus, only the cycle after. But we can get salt both times.
If we modify the process a tiny bit, to grab one more input pair on the way out, then we prevent creating an output on that cycle (now limiting us to 1 of each output per 3 cycles, instead of 2 cycles), but we come out with more material than we need. One extra atom of salt.
So assuming that salt atom can be put to use somehow, the ideal throughput is somewhere between outputs-every-3, and outputs-every-2. Now it’s time for the kicker. Salt alone doesn’t let you make a complete output. But the act of using animismus next to the output, lets you obtain water, which does make a complete output. Take the stoichiometry above, and couple it with the fact that salt + salt = vitae + mors + water, (in this perverse context only), and try to find the new balance.
The answer turns out to be 3 pairs of outputs every 8 cycles. It also creates more vitae and mors than it can use (because it lacks the water to use it, and the only way to get more is to make even more vitae and mors). So we have a result that forces us to make waste!
The brick
Armed with this result (which took a couple hours of scratchwork, and a discussion with Grimmy where we both spent a lot of time second guessing ourselves), I set off to make a custom puzzle that actually proceeded at this rate, similar to the ones above but without the downtime. The result is below.
Holy hell is that a brick.
Shown here is an 8 cycle loop, producing 3 of each invisible ink output (remember, the point is still the “outputs” being smashed together in the middle!), and matching its excess to its requirements, plus the predicted waste at the top. Between the two auxiliary inputs, there are:
- 4 vitae
- 5 mors
- 5 salt
- 6 water
And this is perfectly matched by the output being dropped off to the left. Just, in a horrifically unrelated shape. So the next step would be to make a pipeline that turned the created formation of those atoms, into the desired formation.
Sounds like rearranging a biggie-brick to me. I was game.
The loop
With a bit of effort and understanding of degrees of freedom in the process, I was able to complete the loop, over the course of a few days.
Now I no longer needed the custom output, and the cycles statistic looks deceptively nice. This is because it is only counting the invisible ink outputs now, and those are fed at high speed by the custom input. Which, incidentally, is the reason my work here was far from over..
The setup
How does one migrate all of this progress over to the actual puzzle, Invisible Ink? What has been made so far appears pretty self-referential. It is only able to sustain a loop, because of the existence of custom inputs inside of the loop to serve as fodder until they can be replaced.
What we need now, is a way to set all of this up, without access to the custom input. Once the whole process is bootstrapped, the loop will be identical to the one above. But we need to get to that point using only the water atoms embedded in the output. Here is where the setup tech from the pedagogical puzzle, comes into play.
Every arm is perfectly happy to wait before it begins executing instructions. There isn’t a “loop from here” in the game, but there is an initial stall that can be dragged on for as long as is needed. So if every arm were to take, say, 112 instructions for its loop, but most of them didn’t begin until cycle 100, that is still ok. Every arm will eventually get into a repeating pattern, and sustain perfect throughput. Forever. As alchemy wizards intended.
The solution
Fortunately since readers here only have to be patient enough for my verbose rambling, not patient enough to design a setup loop for enormous bricks, I can just cut to the point. I did it! Here is the setup process that begins from cycle 0, for Invisible Ink.
Every arm essential to the setup, ends up away from the action. Either by running away on a track like the long track cutting through the middle, or being so far away from the loop like the arms on the right as to pose no issue once atoms aren’t being tossed that way.
For a more pleasant gif, one that loops forever and looks nice, see below.
Reflections
How can I be sure that this is optimal throughput? Based on the current understanding of when you can actually obtain inputs in an overlap solution, it has to be. But that understanding could certainly be wrong. Anything short of output-every-cycle, is theoretically falling short of how often inputs try to spawn.
Do I think that this solution is worth the few thousand words spent on it in this post? Yeah, I think it is. And separately, I think that the story here, of picking your own challenge and chasing it to perfection, is worth those words as well.
Would I recommend this game to others? In a heartbeat. One of the best puzzle games ever made.
Would I recommend they try to build solutions using overlap? Not really, at least not at first. It takes a deep understanding of the rules of fair play, to make much headway understanding overlap solutions as anything other than a cheat. There are hundreds of hours of optimization, and a great community, ahead of you before you need to tackle the game-within-a-game. But if you do, feel free to reach out to me and share your creations!
Should I consider throughput to be the one true metric? Nah. I kind of misrepresented old-me in this post anyway, I did really care about cycles the most, and throughput only when cycles was too hard. And even that, I consider an opinion and personal preference. Every possible reason to play this game is valid. That includes meme solutions, which a certain Steven can generate like none other.
Special thanks to the entire Opus Magnum community on discord, https://discord.gg/98QNzdJ. Particularly Grimmy, who never runs out of capacity to at least hear me out on the most niche and complicated explorations within the game.