Wrap-up: The Making Of Mirror Donimoes
This is not a solution to the puzzle, but provides notes from its poser. This type of answer has been approved by the community.
Caution: This post may contain spoilers.
Inspiration
I was one of the many people blown away by boboquack's Magic Maze Puzzle, and
I'm always looking for puzzle ideas to add to my Donimoes collection, so I
tried to come up with a simplified version of his puzzle that could be played
with dominoes and pawns. I thought it might be more approachable, because it
didn't require the solver to print out and assemble the pieces. See the evolution
section below for all the ideas that didn't work before I got to this one, but I
always kept the core idea of four pawns walking around on top of the dominoes,
along with the goal of forming them into one connected group. What changed were
the restrictions on movement.
Creative steps
One challenge with this puzzle was adding diagrams that showed where the pawns
were on top of the dominoes. These diagrams highlighted what I think is a big
weakness of this puzzle: the pawns hide the domino numbers underneath them.
I experimented with a few ideas, but I ended up drawing a mini version of the
pips inside the pawn's circle, like this:
I'm still annoyed that the domino movement arrow sometimes interferes with a
pawn label, but it's not a huge problem.
When I work on these diagrams, I use the live turtle graphics feature of my
Live Coding in Python tool, and I find that really helpful for designing
graphics with Python code. It makes my Python code as responsive as a drawing
program like InkScape would be.
Logistical steps
As with most of my domino puzzles, I designed the rules, and then I wrote a
program to solve a problem given the starting layout. Then I used evolutionary
search to randomly shuffle the dominoes and find the most interesting layouts.
Because this puzzle uses pawns and has more flexible moves than most of my other
puzzles, I noticed two things:
- The larger layouts had too many moves for my program to solve. It would just
run out of memory.
- The moves were clear enough that I could actually design layouts by hand.
As a result, I just designed all the largest layouts by hand, and wrote a
separate program to check the solutions instead of solving them automatically.
I was surprised when I found a problem that took almost 400 moves to solve. I
included it as the final problem in the Donimoes collection, and I hope it's
not too frustrating to solve. As I said, I think the moves are clear enough that
you can see the long-term strategy, and it just takes a lot of moves to get
there.
Resources
I already had most of the code for modeling domino layouts, evolutionary search,
and drawing the diagrams from previous domino puzzles, but I had to add features
for moving pawns around on top of the dominoes. When searching for solutions, I
switched from Dijkstra's algorithm to A* search.
Evolution
I started out very close to the inspiration of boboquack's Magic Maze puzzle,
with its cycle of move types. I called it Ladder Donimoes, and the pawns had
to move onto a 1, then a 2, then a 3, and so on. I wrote up the software, and
generated some puzzles, but the moves were just too hard to see. Also, if you
made the wrong move, it was hard to back out. I prefer to design puzzles with
reversible moves, so you can safely explore them. Ladder Donimoes felt close,
but not fun yet. Before I abandoned it, though, I added the rules for moving a
domino only when it has a pawn on it. That brought domino movement into play,
but restricted it enough to keep it interesting. It also made it feel like one
pawn is helping another out of a tight spot.
After Ladder Donimoes, I tried to come up with a reversible set of movement
rules. Partner Donimoes used the number at the other end of the domino as a
pawn's "partner", and the pawn could move to another domino only if it kept the
same partner. I chose the number at the other end of the domino, so the pawn
wouldn't hide anything important underneath itself. However, that meant that it
was hard to see where the possible moves were. You could see where each pawn
could move right now, but looking ahead to future moves was really hard. Again,
it felt close, but it wasn't fun.
Finally, I came up with the idea of just matching the number the pawn was
standing on. That was much easier to see, even though you had to lift the pawn
to see what number was under it.
png_diagram.pyscript in my repository to generate diagrams. $\endgroup$