Opus Magnum Transmute-All

Hey, Unicycle, can you friend me up on Steam? RobearGWJ. I can't find you to friend you...

MightyMooquack wrote:

At this point I'm on the top of my friends list (tied or not) for everything from the prologue through the end of chapter 2.

Nicely done; that's what I'm aiming for, too. Being able to save different solutions to the same puzzle is such an awesome improvement over SpaceChem and makes shooting for the stars way more convenient.

You mean save solutions via GIFs, right Ted? Or is there some other save function I'm missing?

Sorry for not being clearer. I'm referring to the new / rename / copy / delete functions on the histogram screen. So nice!

This is so good. Maybe the best one yet.

I had no idea you could do a "new" save and start a second solution or more. Brilliant!

This is Zach's best yet, combining the best points of his previous molecular games. (I suspect he has a similar upgrade in the works for an electronics game, so I'll leave out TIS-100 for now). A perfect puzzle game.

Ted wrote:

Sorry for not being clearer. I'm referring to the new / rename / copy / delete functions on the histogram screen. So nice!

The last few games have all had that - I don't think it's new.

I added you Ted.

I need more people on my histograms!
http://steamcommunity.com/profiles/7...

My steam profile is in my signature, more than happy to friend you all. So shoot me a request!

dibs wrote:

This is so good. Maybe the best one yet.

I think you're right about that. The unlimited play area means that it's never really that hard to merely solve a puzzle, but the challenge of optimizing solutions is as great as it ever was.

The visual nature of the game makes it less arcane than TIS-100 or Shenzhen I/O were, but the clearly laid out instruction lists make it far less fiddly than SpaceChem could be. They managed an incredible trick here of making a game that is at once far more accessible than the assembly language games, while not really sacrificing the complexity of the gameplay.

DudleySmith wrote:
Ted wrote:

Sorry for not being clearer. I'm referring to the new / rename / copy / delete functions on the histogram screen. So nice!

The last few games have all had that - I don't think it's new.

This is good to know. I haven't played a Zachtronics game since SpaceChem, although TIS-100 and Shenzhen I/O are on my list.

dibs wrote:

I added you Ted.

Cheers dibs!

I have to agree that it's probably the best game, mechanically.

While I'm only approaching the end of chapter 2, I think I preferred Spacechem's plot. I also really enjoy the Spacechem soundtrack, while this one has left me feeling a bit so-so.

Maybe it's nostalgia.

You have no sig for me, Unicycle, that's why I asked...

Edit - Oh, wait, your sig is one tiny, itsy-bitsy icon on the far right? I see...

Haha sorry, I would have sent over a friend request myself, but was at work with no Steam!

MightyMooquack wrote:

What can I say? I have some very competitive people on my friends list, and I get the most fun out of these games from beating or at least tying their scores.

Regarding Prologue - Stabilized Water, would you care to divulge the cost and area metrics of your 15-cycle solution(s)?

Here are mine:

330g - 21a
270g - 25a

I'm curious whether I can deduce your approach(es).

I'm having a lot of fun doing puzzles by (smallest) area. Here's mine for Airship Fuel:

Spoiler:

IMAGE(https://i.imgur.com/33x6K9l.gif)

Ted wrote:

Regarding Prologue - Stabilized Water, would you care to divulge the cost and area metrics of your 15-cycle solution(s)?

Here are mine:

330g - 21a
270g - 25a

I'm curious whether I can deduce your approach(es).

My only saved 15-cycle solution is 220g/15c/28a.

Hmm. I managed a 25 cycle version that involves spinners and looks (I thought anyway) cool. Ah, well. I was curious about the 15 cycle thing, and looked one up.

...

...

Well, Henry Ford would have been proud. LOL.

My best on that so far is 80g/22c/16a. That last 7 is *killing* me...

I just discovered the numbers on the command tracks can be drag-n-dropped up and down. The mechanisms will be renumbered. Nice!

Ted wrote:
MightyMooquack wrote:
Ted wrote:

Regarding Prologue - Stabilized Water, would you care to divulge the cost and area metrics of your 15-cycle solution(s)?

Here are mine:

330g - 21a
270g - 25a

I'm curious whether I can deduce your approach(es).

My only saved 15-cycle solution is 220g/15c/28a.

Hmm, okay. My guess is you...

Spoiler:

used two track loops.

ChipRMonk wrote:

I was curious about the 15 cycle thing, and looked one up.

...

...

Well, Henry Ford would have been proud. LOL.

Indeed! My first approach aligns with what I bet you saw. My second approach...

Spoiler:

replaces each loop with a set of three parallel tracks, with each track servicing a single extender. Each extender is a different length, resulting in three grab-ends occupying the same line.

goes like this:
IMAGE(https://i.imgur.com/z2gpMlr.gif)

I'd post a pic but I recently bailed out of Photobucket so I don't have an image host at the moment. I should get that figured out soon. Figured out.

I've been trying to order my thoughts on how I optimize for cycles, and I ended up writing a whole essay. Oops. Have some of my notes:

There is a hard lower bound on how fast a solution can be. This is usually how quickly you can pull a reagent off its source (once every two cycles), though in at least one puzzle it's limited by how quickly you can put the products on their destinations (once per cycle). Beyond that, the total cycle count is a function of your solution's total time between repeats, and its per-repeat reagent-to-product time. Improving the former gives a significant multiplier on the final score, and it's differences in the latter which account for the tiny little one-cycle differences you often see at the top of the leaderboard. Eliminating that one last cycle can be tricky.

A lot of this has to do with managing the movement of pieces properly.

It is very common for one arm to hand a piece off to another. For instance, arm 1 is set to grab an item, rotate once, drop it, then rotate back. Arm 2 is set to grab the item in the instant arm 1 drops it, then rotate, drop the item, and rotate back. We might represent it like this:

_ 1 2 3 4 5 6 1 grab right drop left 2 grab right drop left

Say the goal is to move the item twice, then drop it. In the example above, that final drop occurs on cycle number 5. On the other hand, say you just have the one arm rotate twice:

_ 1 2 3 4 5 6 1 grab right right drop left left

There are two important differences: (1) The drop occurs on cycle number 4. (2) The total length of the instruction chain is 6.

Recall what I said above: There are two components of your overall cycle count. Let's call them the repeat time and the end-to-end time. The repeat time is how often, in cycles, the machine will loop. This usually (but not necessarily!) corresponds with its time between grabbing reagents, and beginning the process of assembling a new product. A good solution will pipeline its reagents, beginning a new product before it has completely finished one or more previous ones. A short repeat time will improve its ability to pipeline products, which acts as a multiplier on your final score.

The end-to-end time is how long it takes a given set of reagents to be assembled into a product and dropped on the output. A good end-to-end time has a direct, but not multiplicative, effect on your score.

For example, say your solution has a repeat time of 4 cycles (as in the example above). Then say it has to pass through a number of steps from reagent to product, giving an end-to-end time of 7 cycles. This means that the first product will be output on cycle number 7. However, because this hypothetical solution is well-pipelined, it will output the second product 4 cycles later. The time to output all six products required by the puzzle is therefore:

7 + 4 * 5 = 27 cycles

Look back at the examples above: The first has an end-to-end time of five cycles, and a repeat time of four. The second, an end-to-end time of four cycles, and a repeat time of six. So even though the second example gets to where it's going more quickly, it does not pipeline as well, and the overall solution may be slower.

A good question might be: Where did that extra cycle go? Exactly why does the first example have an end-to-end time that is one greater than the second? And the answer is simple: The handoff in cycle 3. An entire cycle is spent just exchanging the piece from one arm to the other. More on this in a moment.

Each approach has its place. Sometimes you don't have enough reagent sources to sustain an overall repeat time of four cycles. Four example, if the end product requires three atoms, but you only have one reagent source, it will take you a minimum of six cycles to obtain enough atoms to make the solution. With six cycles to work with, this opens up a whole realm of making two movements with a single arm.

This also opens up the possibility of making effective use out of those double or triple arms. Consider what the instruction set for a triple arm looks like, in order to move an item twice:

_ 1 2 3 4 1 grab right right drop

Because the arm has three grabbers, we don't need to reset its position! On paper, this is the best of both worlds: The repeat time and the end-to-end time are both four cycles. However, there is a very important caveat: If your overall repeat time is four cycles, it will immediately grab the item again on the next cycle. It becomes impossible to hand the item off to another arm in the conventional manner.

Roughly speaking, there are three situations where this is useful:

  1. Dropping products on the output. No handoff is necessary: The item vanishes as soon as it is dropped. This can also apply to glyphs which consume an item.
  2. Your machine's repeat time is longer than four cycles. This adds a delay between the drop and the grab, allowing other arms to grab and then move the item.
  3. You are dropping the item on a tile of a glyph of bonding, and another arm is already grabbing an item it is being bonded to. The other arm is then free to move away before the tri-arm tries to re-grab the item.

All of this applies equally to making three rotations with a double arm, save with a repeat time of five cycles instead of four.

That third point is particularly notable. If you have one operation that takes two movements (say, pulling an element off a source, moving it over a glyph of calcification to get salt, and then moving it onto a glyph of bonding), and one operation that takes one movement (moving an element directly onto the same glyph of bonding), that means the latter operation could get there ahead of time, and be ready to move one cycle ahead of the incoming salt atom. If the salt is being created with a triple arm doing grab-rotate-rotate-drop, this gives you the opening required to yank the salt out of the way before the arm immediately grabs it again.

You can see an example of this in this 27-cycle solution for Face Powder:

Spoiler:

IMAGE(https://i.imgur.com/UT8K434.gif)

However, there's a 26-cycle solution to be found, as well. Can you spot the extra cycle?

Nothing to see here (quote is not edit).

Ted wrote:

Hmm, okay. My guess is you...

Spoiler:

used two track loops.

Close:

Spoiler:

Four straight parallel tracks.

MightyMooquack wrote:

Close:

Spoiler:

Four straight parallel tracks.

Hmm,

Spoiler:

four straights, huh? I used six. I'll have to ponder how four would work.

Wow, nice essay. Thanks for taking the time to putting it together. Eliminating that one itty bitty extra cycle has definitely been a fun challenge thus far.

I'm developing an irrational dislike of MightyMooquack. All I see is his numbers on my leaderboard.

This is what I regard as the best balance between cost, area, and cycles. Can anyone beat 80g/22c/16a without going above on one of the 3? I'm going for overall efficiency here, not optimizing any one element.

Spoiler:

IMAGE(https://i.imgur.com/uHx0a5Y.gif)

It strikes me that we could angle for all sorts of efficiencies beyond just optimizing one of the three characteristics:

Cost/Cycles/Space aggregate - Overall Efficiency
Cost/Space - Overhead Cost
Cost/Cycles - Fixed Cost (of manufacturing unit)
Cycles/Space - Device Efficiency

Cost/Unit is not really needed if all output counts are 6. That can be optimized just by optimizing cost.

This would give us a sort of shorthand for describing combo optimizations.

Robear wrote:

This is what I regard as the best balance between cost, area, and cycles. Can anyone beat 80g/22c/16a without going above on one of the 3? I'm going for overall efficiency here, not optimizing any one element.

Spoiler:

IMAGE(https://i.imgur.com/uHx0a5Y.gif)

Not to mention an elegantly simple instruction set. It's poetry in motion.

I took a crack at it and can't seem to get under it. The closest I got was 70g/28c/14a.

*tips hat*

It took me a few hours of incremental improvements and unwrapping the loop to get to that point. I learned a *lot* in the process.

Now someone will get to 21c and drive me crazy, most likely.