Background

I’ve recently been playing with a series of puzzles called the Bermuda cubes. They look and behave a like a Rubik’s cube but some centers have been replaced by triangles and others have been rotated 45 degrees. Mechanically, these new centers don’t add anything new. The pieces around them can be interchanged with regular corners and edges. From a solving perspective, these centers add a few challenges.

1. The unusually shaped pieces and centers make it harder for me to visualize setups.
2. The notation for algorithms is cumbersome which makes it harder for me to memorize them.
3. The triangle centers block other faces depending on their position so it’s harder to come up with broadly reusable algorithms.

One nice feature of this collection of puzzles is that they have a suggested order. Each one is named after a planet and they (mostly) get harder as the planets get further from the sun.

Now that I’ve completed the series, I wanted to write a blog post to reflect on the solving experiences and to record my solving notes for others (and maybe for my future self).

First Approach

A pretty standard technique for designing a solution is to solve one kind of piece at a time. The idea is that you can solve the solve the first piece type with ignoring the rest of the puzzle. Then you can solve the second piece type while only paying attention to the first piece type and ignoring the rest, etc. This sort of solution doesn’t require very many algorithms but does require you to be good at visualizing setups so you can get the most out of your sequences.

For this whole series, it felt most natural to me to solve centers then edges, then corners. Moving centers after anything else is solved seemed like a pain so I knew I wanted to do those first. Isolating edges without slice turns seemed like it would be painful so I chose to do those before corners.

With a bit of planning, I was able to adapt well known 3x3x3 commutators to the first few puzzles in the Bermuda cubes series. The trick was identifying which center positions were workable and then finding ways to set up to those positions. But when I started working on Mars, I found it a lot harder to adapt ideas I already knew from 3x3x3 Rubik’s cubes. That puzzle has three triangle centers, two of which are opposite each other. That means the middle one is always blocking at least one of the other triangles and that made it much trickier to access certain pieces of the puzzle.

I decided to search for sequences that depended on as few faces as possible, that way the state of the puzzle would matter as little as possible when executing them. In particular, I looked for algorithms that only depended on neighboring triangle and square faces.

My big breakthrough centered on the fact that RUR’U’ repeated 3 times has no effect on edges and is a 2,2 swap of corners. I could execute that with a square face on top and a triangle face on the right in the correct orientation. From there, I could turn this into a useful algorithm by swapping some of the pieces of the U face with the unmodified corner/edge/corner on the hypotenuse of the R face. There were a few nice ways to do that interchange and all of the ones I tried resulted in useful 3-cycles!

• left: [(R U R’ U’)3, R^-1.5 U’ R^1.5]
• middle: [(R U R’ U’)3, R^-1.5 U R^1.5]
• right: [(R U R’ U’)3, R^-1.5 U2 R^1.5]

These cubes are tilted a bit to show the outcomes better. These should be executed with the orange face on U and the white face on R, starting with the white triangle orientated as shown.

I really like this trio of algorithms. The similarity made them easy to remember. The fact that the cube is in its normal shape most of the time meant I could use edges as clues if I ever lost my place in the middle. On top of that, they were able to easily move corners in and out of the tricky-to-reach spots on the hypotenuse of the triangular face.

For corner orientation, I also wanted to find a sequence that would work with only two turnable faces. Starting with a square face on U and a triangle face on R (orientated the same as my permutation algorithms), I realized I could execute a Sune. After a bit of fiddling, I found that three Sunes in a row had no effect on edges and swapped the corners of the square face with their diagonals. One pair’s orientation was unchanged while the other pair was twisted. That meant I could do a U2 and another triple-Sune to swap the corners back to their original positions but end up with one diagonal pair orientated differently.

• left: effect after 3 Sunes
• right: effect after [(R U R’ U R U2 R’)3 , U2]

You might notice that I only wrote about algorithms for corners, not ones for edges. That’s because I found the edges pretty intuitive. All these algorithms I’m writing about in this post are for using at the end of a solve when pieces are mostly where they need to be. Before that, I try to use intuition and blockbuilding as much as possible.

Oops All Triangles

At this point, I thought I’d cracked the whole series and all the was left was coming up with nice setup sequences. Then I started scrambling Saturn and realized my mistake. Even though that puzzle has two square-centered faces, neither of them is able to turn. Hilariously, the edge in between them is mechanically functional, it’s just impossible to unblock either face and actually move it. This meant all my nice ideas about triangle/square algorithms were not applicable.

I was pretty happy with my centers, edges, corners solve order and I liked the flexibility that I got from an algorithm that only needed two turnable faces; so I decided to try to find some new algorithms to use for adjacent triangular faces.

I came up with some kinda ugly ideas but I wasn’t looking forward to executing those long algorithms on an actual puzzle. Eventually I decided to give up and write a program to find some shorter sequences.

Writing a solver

In order to model the state of the puzzle, I needed to know orientation of each center. I used an enum where I named each state after the edge of the triangle that was shared with the other face:

enum Orientation : int {
  HYPOT = 0,
  LEFT_LEG = 1,
  RIGHT_LEG = 2,
};

From there, I modeled each state of the puzzle as a vector of edge locations and a vector of corner locations. This meant each move could be implemented as a permutation of those vectors.

struct Node {
  Node(const std::vector<int>& corners,
      const std::vector<int>& edges,
      const Orientation& left_center,
      const Orientation& right_center,
      const std::string& path) :
    corners_(corners),
    edges_(edges),
    left_center_(left_center),
    right_center_(right_center),
    path_(path) {}

  std::vector<int> corners_;
  std::vector<int> edges_;
  Orientation right_center_;
  Orientation left_center_;
  std::string path_;
};

One unintuitive detail is that the corners vector had one entry per sticker, not one entry per piece. That’s because I wanted to track the orientation of the corners. This wasn’t needed for edges since edges can’t change orientation with just two axes.

An example of a transformation function is as follows:

Node LhsClockwise(Node in) {
  if (in.left_center_ == Orientation::HYPOT) {
    PermuteVec(in.corners_, {
        {0,9,3,12,6},
        {1,10,4,13,7},
        {2,11,5,14,8},
      });
    in.left_center_ = Orientation::RIGHT_LEG;
  } else if (in.left_center_ == Orientation::LEFT_LEG) {
    PermuteVec(in.corners_, {
        {0,9,3,12,6},
        {1,10,4,13,7},
        {2,11,5,14,8},
      });
    in.left_center_ = Orientation::HYPOT;
  } else if (in.left_center_ == Orientation::RIGHT_LEG) {
    PermuteVec(in.corners_, {
        {0,12,9,6,3},
        {1,13,10,7,4},
        {2,14,11,8,5},
      });
    in.left_center_ = Orientation::LEFT_LEG;
  }
  PermuteVec(in.edges_, 0);
  in.path_ += "L";

  return in;
}

You might notice that I always add “L” to the path even though the number of degrees being turned isn’t always the same. To simplify notation, for triangle+triangle algorithms, I used L to mean “rotate the left triangle clockwise until the right is unblocked” and the same for “R” mutatis mutandis.

Finally, I wrote some code to breadth first search the graph, and print nodes which only modified a small number of corners. This approach worked well. By looking for states with 6 modified corner stickers, I could find pure orientation algorithms. By looking for states with 9 modified stickers, I could find permutation algorithms. I’ve included a table of about 400 algorithms that the solver found at the bottom of this post.

Aside: C++ and hashing vectors

One thing that was moderately annoying when I was writing my bfs was that I wanted to make a set of my Node struct so I could tell whether a node had been visited or not. Because it contains a vector, C++ didn’t know how to hash it so I had to write my own custom hash function. I found that a little annoying.

Second approach to writing a solver

The results from my first solver were decent but still felt awkward to me. The 2-axes approach generated algorithms that were highly reusable but were kinda long. I started to wonder if I could generate shorter ones by allowing the use of a third axis.

This meant I needed to make a few changes to how I was modeling states. First of all, I need to start modeling edges in a way that lets me see their orientation. This isn’t too bad - we can use the same trick as we did with corners and use one int for each sticker. Next, we need to model center orientation in a way that lets us see which faces are blocked. After some thought, I came up with a solution to this that felt really elegant.

We can treat each face like a regular pentagon (i.e. from a megaminx) but with some specific edges bandaged to those centers.

I updated my code to BFS using three triangular faces and this new model but the results were extremely disappointing. All the algorithms it found used just two out of three available faces! If I didn’t make any mistakes in my implementation, this means that adding a third triangular face doesn’t help at all.

Closing thoughts

If you enjoyed this and want to pick up some Bermuda cubes, you probably don’t need to get the whole set. Some, like Jupiter and Uranus feel pretty much the same with my method. I think my favorites were Mars and Neptune. Maybe start with Venus if you’re looking for something easier and maybe end with one of Jupiter/Saturn if you’re looking for something harder.

Numbering the pieces and figuring out the permutation that went with each turn was kinda tedious. I wonder if there’s a way to automate that. Also, I think there’s room for a nice library that takes the permutations of each move as input and has utilities for things like BFS written in a general way. There’s certainly some low hanging fruit when it comes to optimizing my current solver - it would be great to do that optimization on a shared library once and then benefit from it on future projects.

I think it would be fun to apply this same technique to mixes of 0 and 1 faces on the circle 3x3x3s. I think there would be lots of fun arrangements to analyze and I bet some really short algorithms would show up.

I know there is a series of Bermuda megaminxes that were also mass produced but are hard to find and expensive these days. Maybe I’ll solve a few of those in a simulator next time I’m looking for the Bermuda puzzle kind of experience.

Appendix

triangle-triangle Permutation algorithms:

(see data model above for starting position and label meanings)

Triangle triangle pure corner orientation algorithms

(see data model above for starting position and label meanings)