What Works And Why: Optimising in Opus Magnum

What Works And Why is a new monthly column where Gunpoint and Heat Signature designer Tom Francis digs into the design of a game and analyses what makes it good.

Opus Magnum is a puzzle game about designing machines that arrange and combine shiny little atoms to turn lead to gold, and other fanciful alchemy. It's by Zachtronics, whose games follow such a recognised pattern that they've become a genre: the Zachlike. SpaceChem, Infinifactory, Shenzhen IO, and now Opus Magnum all involve designing an automated system to process some given input, and produce some desired output. But it's a particular quirk of this format I want to dive into, and it's one Opus Magnum does especially well: optimisation.

An early puzzle requires you to produce 'Stabilised water' from water atoms. It's olden times. All you have to do is take two water atoms, turn one of them into salt, then join them together. That is one 'stabilised water', and you've got to design a machine that will keep producing these on a loop.

The two bright green orbs are where the water atoms come in, so I grab one of each. The one on the left passes through that rune thingy to turn it to salt, then they both lie in those connector slots, which joins them, and are pushed into the outpot slot. Repeat!

And that, above, is reason 1 that optimisation is so satisfying in Opus Magnum. Everything you make can be exported to a GIF, and there was never a more perfect game for GIFs. It's literally your job to make a short, pleasing sequence that repeats, and having it as a perfect infinite loop to show to people makes you all the more proud of your little machine baby.

As a new player, this solution looked very neat to me. Everything you make in Opus is tremendously satisfying to watch, so even if you're only muddling through the game you get to feel smart. But there's also enormous scope for improvement, in three different directions.

It could be cheaper. That piston arm that extends to shove the product into the output slot is 10g more expensive than a regular non-extending arm, so if I could find a way to not need that, I'd save money. This solution involves 70g worth of gear. The cheapest one I've designed since only costs 40g.

It could be smaller. Not by much, this is the metric I scored best on. This solution takes up 9 tiles and my best takes 7. The cool thing about optimising for space is that Opus doesn't just count tiles you built things on, but any space your machine needs to move. So if you have a long arm swinging out from your machine, all the space it sweeps through counts against you here. It encourages you to build satisfyingly compact contraptions, whose parts move over each other instead of jutting out.

And my solution could be faster. It could be a lot faster. My first solution took 63 cycles, then my friend Alex beat me with 53, so I made that one which only takes 45. I was pretty pleased with myself. Until the leaderboards told me my friend Jeep had done it in 24. Twenty-four?! You can do this almost twice as fast as my fast solution? Opus Magnum lets you see your friends scores but doesn't show you their solutions, and I'm actually glad. I wanted to figure this out for myself.

That's reason 2: you get to choose what to optimise for. If optimising for space feels fiddly, try optimising for time. If that's too hard, try cost. You can usually find success somewhere.

On this early, simple puzzle, my best solution for both cost and space happens to be the same machine:

I find it delightful. Just one moving part, surrounded by everything it needs, quietly solving the problem at its own plodding pace, not getting in anyone's way. Small, cheap and neat. So that's reason 3: an optimal solution is even more satisfying to watch.

By contrast, you're about to see how monstrous they can get when you don't give a shit about any of those things.

Optimising for Time

Discovering I've been hopelessly inefficient in a Zachlike is not a new experience. I blundered through a few levels of SpaceChem with solutions I knew were clumsy, but that game's more abstract presentation made it feel like programming, and if I'm gonna be programming I'd rather work on my own game and have something to show for it.

I clicked better with Infinifactory because it lets you build physical machines, in a Minecraft-ish blocky 3D world. That made it feel more like advanced Lego than programming. But when I struggled with it, it also made it overwhelming. It's harder to visualise new solutions in 3D, and harder to see all of your current solution at once. I handled this adversity with all the grace I could muster.

Opus Magnum has neither of these problems. Its gleaming mechanical look and satisfyingly physical interactions mean it doesn't feel like work the way SpaceChem did for me. And you can see your whole solution and visualise new ones easily, in a way I struggled to in Infinifactory.

All of which means: when I know my solution could be more efficient, I actually try to fix it. And that process has been a revelation.

Optimisation is boring when it's a matter of examining a complex system and finding one tiny replacement, or fiddly rearrangement, that will shave off one cycle. This has not been that. I've radically reinvented my solution from scratch at least six times, introducing whole new concepts and inventing new subsystems to open up different avenues.

So that's reason 4: optimising in Opus Magnum is more than just tweaks, it's reinvention.

My first thought: in the solution above, a lot of time is wasted moving the arms back to their starting positions. What if we used a spinning wheel that could just keep moving in the same direction?

It's worse! It's so much worse! This one takes 53 cycles instead of 45. Still, I've never been one to let disastrous results put me off an idea that sounded good in my head, can we make a better wheel?

38, now we're getting somewhere! Still not 24. What if the wheel was... bigger?

30! The real invention here is to use the joiner device as a way of picking up the extra atom from the helper arm at the side: it can just latch on as the arm swings by, which saves it stopping to pick it up. But we're still only doing one product at a time, and putting everything on one big wheel makes it hard to do more at once. Would a production line be faster?

No! Not this one, anyway. To much grabbing and dropping. But what if... more wheels?

27! Hurray for wheels! But there's still a lot of grabbing and dropping going on. I hate to say it, but would it be faster with... fewer wheels?

25! Yes! My God, I'm so close to Jeep's 24.

It's around this time my friend Kevin chimes in with this:

Reason 5: friendly competition.

FIFTEEN?! This is absurd. But I'm actually kind of glad - if I know I can lose 9 cycles, I know it's a big new concept I'm looking for.

My time with the game is now divided in two: I'm continuing on with the campaign, completing each puzzle to a basic standard, and not really stopping to optimise. Then the other half of my time is just repeatedly re-solving the Stabilised Water puzzle in new and more efficient ways.

And that's reason 6: you don't have to optimise. If I had to do this to progress, I probably would have quit in frustration. Instead I get to dip in and out of this and the campaign, which is both more fun and often gives me new ideas.

When I reached a puzzle in the campaign that only gives you one atom source, I discovered you can use two three-armed wheels to grab from it at twice the rate. Returning to Stabilised Water, I found a way to fit this in, getting twice the output rate:

18! This is clearly mad, but it has an interesting property. Watch the output slot. It's spending all of its time receiving completed products. That's the absolute maximum rate you can achieve - even if you could make them faster you couldn't fit them all through. So what could possibly be left to improve?

Well, your cycles score is how long it took your machine to make 6 products from a cold start. So it's the time it takes to make and deliver the first one, plus 5x whatever your rate is. Our rate is optimal, so our time to make the first product must be slow. What if we went back to the production line approach, but had at least 2 arms operating on every space along the line, to keep it moving fast?

17! One cycle faster! Still need to lose two more. All that's left is the picking up and dropping. Every time an atom changes hands, that takes a cycle. Could an atom... never change hands? I had an idea.

The six rails method! This is much, much faster to deliver its first product, so its overall score is... exactly the goddamn same.

I couldn't quite do what I wanted here: there are four steps in the process and I wanted an arm for each. But arms can only extend 3 hexes, so adding more rails on the outside of this leaves the new arms unable to reach. So now there's a gap in our transit system, one cycle each loop where nothing gets delivered. It just needs a liiittle nudge.

Six rails plus nudgers! 15 cycles! I've done it!

These nudgers can't reach far enough to push the atoms all the way to their destination, but my realisation was they don't need to: if we move the joiner to before the salter, we only need one arm to take the atoms forward from that point: it'll bring the joined atom with it. It took some fiddling with the instructions these arms are running to make use of that, but I got there in the end.

I was tweeting these solutions as I came up with them, and Matthew Smith on Twitter actually spotted a much cooler tweak I could have made at this point if I'd known you could do it: looping rails!

Reason 7: even once you've optimised, there's always a cooler design to be discovered.

Just to get perspective, every one of these GIFs is a solution to the same problem. Every one of them does exactly the same thing. They're not even all the ones I tried, I have 5 more. And this problem is in the tutorial. There are 5 whole acts after that, all of which increase in complexity. If there's that much depth and scope for ingenuity in the ultra-simple tutorial puzzle, I can only imagine how much there is in the complex ones later on. That level of depth, I assume, is not new to Zachlikes. But Opus Magnum's beautiful presentation, excellent tutorial and inherent shareability have let me dig into it for the first time, and it's a wonderful thing.

Tom Francis is the designer of Gunpoint and Heat Signature and a former games journalist. You can find more of his thoughts on making games on his blog.