Opus Magnum

Introduction

Opus magnum is a open-ended sandbox puzzle game developed by Zachtronics. In any given puzzle, the player is given an infinite hexagonal grid in which they convert input molecules—with a solution built and programmed with arms, glyphs, and tracks—into output molecules. Every solution is given a score in three metrics: gold (cost), cycles (speed), and size (area). The primary goal of the game is not just to solve the puzzles, but to create solutions optimized exclusively for individual metrics.

Cost Optimization

The in-universe currency is actually called Guilder, but the community generally refers to it as gold for convenience (which is what I will refer to it as from now on). Every part placed on the solution board costs gold. Because instructions programmed into arms do not cost gold, records look to minimize the number of arms used, as well as eliminate glyphs unnecessary to the completion of the product. To do so, they often fill one arm up with hundreds of instructions, as well as use glyphs in unintentional ways, sometimes only accessing one or no hexes of a multi-hex glyph.

Cycles Optimization

Cycles refers to the number of time steps the solution takes before outputting six of each output molecule. Cycles is primarily dependent on throughput (how often inputs can be pulled) and latency (how long it take from pulling the last input used to outputting the final molecule). Latency is usually the harder of the two to improve, as minimizing the number of actions performed on the final input pull requires a clear pathway to the outputand having the rest of the product near-complete already. As puzzles with more complex outputs start to show up, the complexity and size of solutions increases dramatically.

Area Optimization

Although area solves often look similar to gold solves, there are a lot of exclusive strategies used to minimize area. Optimizing area focuses more on finding compact layouts, where the required area from the glyphs needed to solve the puzzle are placed as easily accessible hexes. Large swings of arms are kept to a minimum, and solves are usually conceptualized backwardsfrom the final step to the initial stepin order to make sure intermediate products are able to move around the solution without exceeding the expected area.

Instruction Optimization

I know I said earlier that there were only three metrics, but that's not entirely true.

There's a second kind of puzzle in the game that limits the space you can work with. In these puzzles, area is no longer meaningful, so solutions are instead graded on total instructions used. An arm will loop through its given instructions indefinitely until the puzzle is completed. Optimizing for instructions is tricky: it often requires you to find symmetry in the product so that the same set of instructions can be looped through to create everything. Arms are often conditional, doing different things based on whether an atom is grabbed or not.

Community Leaderboards

As the game doesn't provide very comprehensive leaderboards (only showing somewhat vague histograms in each metric), the community has created their own, independently hosted record repository at https://zlbb.faendir.com. Records do not have name attribution, which intends to prevent record hoarding ("what if I spend hours on a solution and someone else finds a minor improvement in seconds") as well as encourage community collaboration on theoretically optimal solutions.

What do I do?

Record Improvement

Although the leaderboards don't have attribution, I've helped improve many of the records posted (most of which remain on there to this day). In particular, I helped develop tech to reduce instructions in many of the production puzzles, cutting down most of them by about 30%. A few of them are shown below.

Previous record (48 instructions)

My improvement (36 instructions)

Previous record (29 instructions)

My improvement (20 instructions)

Previous record (45 instructions)

My improvement (29 instructions)

Speedrunning

Opus Magnum doesn't seem like a game designed for playing fast, but it turns out that trying to beat the game as fast as possible is an interesting challenge in itself. A solution designed for speedrunning not only needs to solve fast, but it needs to be able to be built fast as well. This combines key ideas in each of the 4 metrics mentioned above:

  1. Cost solutions have few parts, which means less time spent dragging parts from the tray to the board.

  2. Cycles solutions run fast, which means less time spent waiting for the machine to complete the level.

  3. Area solutions are small, which means less time spent scrolling the board to place parts.

  4. Instructions solutions are quick to program, which means less time spent coding the solution.

With that said, I am proud to be the holder of the current any% speedrun world record, as well as the world record holder of every individual level played in isolation. The any% WR video and the individual levels playlist are shown below. The records can also be found at https://www.speedrun.com/opus_magnum.