To encourage people not to type comments, and to make recons easier to understand at a glance, I've designed dynamic icons that come before each line of text.
The icons should make sense enough, so I'm not going to talk about them. But they do come in handy with the new Screenshot feature.
Solves are visual. To efficiently communicate the information, recons should be too. Most people just post the text when they share recons. You could make a video or post to a recon website, but that makes everything take longer.
Introducing Screenshots. They're not actually screenshots. But they are pretty!
The last major feature in this release is autocomplete. Using it is simple. Type in a solution to cross, press enter, and suggestions will start to generate. Currently, there's algorithm suggestions for F2L, OLL, and PLL.
Simple to use, very difficult for me to write the code for. If you're interested, I want to talk about some of what went into writing it. Then, I'll talk about how it works.
The first half of v0.4 development mostly consisted of the following:
...point being that perseverance is important sometimes. Eventually I made a key observation.
These are the same cubes.
They're solved the same. A human who knows the CFOP method immediately knows how to solve both cases, even though the colors are different. It's about the pattern of the colors, not the colors themselves.
If we could convert the colors into standard pattern format, we'd be in business. We could compare the pattern of the current state of the cube against the pattern that an algorithm solves.
I chose to represent the pattern as 26 letters, one letter for each piece of the cube. For example, here's a pattern:
"abcdefghijklehkbnqtwabcdef"
It's not gibberish. If we programmatically check all the pieces and get this pattern, it means the cube is solved!
How do we know what's an "a" and what's a "q"? It's complicated. I don't expect this to make sense right away, but I think it's good to outline first what we need to do:
Now for an example. Let's take a look at those cubes again.
We'll say for simplicity that the cube on the left is at rotation 0. This means the cube on the right is at rotation y (90 degrees clockwise about the vertical axis).
To normalize the colors on the right cube, we essentially need to "rotate" the colors as well. Yellow stays yellow--the top center color didn't change despite the rotation. The front center color is green, but it needs to be red. Orange needs to be green, blue needs to be orange, and so on.
Now the cubes actually look the same to the computer:
We look at each piece one by one, starting with a predetermined piece of certain actual colors. Let's pretend the first piece we always look at is the yellow-green piece. Using our color mapping, we look for the yellow-red piece instead:
It's between the Up and Front centers! That was easy, it didn't move.
It also didn't change orientation. If it did, we'd say it's between the Front and Up centers, in that order. We predetermine one sticker to be "primary" to make that work.
In the code, there's simply a table where we can look up the value of the Up-Front (UF) location.
private readonly edgePieceDirections: { [key: string]: number} = {
'UF': 0, 'UR': 1, 'UB': 2, 'UL': 3,
'DF': 4, 'DR': 5, 'DB': 6, 'DL': 7,
'FR': 8, 'FL': 9, 'BR': 10, 'BL': 11,
'FU': 12, 'RU': 13, 'BU': 14, 'LU': 15,
'FD': 16, 'RD': 17, 'BD': 18, 'LD': 19,
'RF': 20, 'LF': 21, 'RB': 22, 'LB': 23
};So the value associated with 'UF' is 0. The 0th letter of the programmer alphabet is "a", so that's the first letter of our pattern.
currentCubePattern = "a..."
We follow this procedure for every piece. The corners are a bit different, but let's move on. Draw the rest of the owl, as they say.
currentCubePattern = "acidefghbjklmkgbfqtwabcdef"
Now we have a pattern of the current cube. Computed in advance, we also have the patterns for all of our cubing algorithms. These were made by applying the inverse of the algorithm to a solved cube, then calculating the pattern like normal. In our case, the algorithm we need to solve the cube is "U R U' R'". We applied the inverse, "R U R' U'", to a solved cube and calculated this pattern:
inverseAlgPattern = "acidefghbjklmkgbfqtwabcdef"
It's the same pattern as currentCubePattern. Since the patterns match, we know that the algorithm solves the cube! Job done, right? Owl drawn! Not quite.
Most times, the patterns won't match exactly. Only letters at certain positions will. The trick is just checking that the correct letters match. We need a list of letters that must be in certain positions for an algorithm to be a valid choice.
To exemplify this better, let's look at a more complex cube state, but one that would benefit from having the same algorithm applied:
The pattern for this cube is:
complexCubePattern = "mclvefghbpkuuhmkfpbwabcdef"
We still want the alg "U R U' R'" here to solve the white-orange-green corner and orange-green edge.
This cube also has a couple pieces solved in the back. Let's look at those quick:
So the algorithm must:
this gives us the pieces that must be in a certain location for the algorithm to be valid for our case. these indices are easy to get a hold of. for example, if cross is on the bottom face, the cross indices are always 4, 5, 6, and 7. let's also get the current location of the pieces using the complexCubePattern from a minute ago. The indices tell us directly which letters to grab. If we look at the 4th indice, we grab the 4th letter, counting from zero.
| Piece Index | 4 | 5 | 6 | 7 | 8 | 10 | 16 | 19 |
|---|---|---|---|---|---|---|---|---|
| Current location: | e | f | g | h | b | k | f | w |
Let's highlight those indices in our algorithm pattern:
inverseAlgPattern = "acidefghbjklmkgbfqtwabcdef"
Then compare the letters of complexCubePattern and inverseAlgPattern at those indices:
| Piece Index | 4 | 5 | 6 | 7 | 8 | 10 | 16 | 19 |
|---|---|---|---|---|---|---|---|---|
| Current location: | e | f | g | h | b | k | f | w |
| Alg Location: | e | f | g | h | b | k | f | w |
They all match! We're good to suggest the algorithm this pattern is associated with, "U R U' R'". We go on to search over the other F2L inverse alg patterns in the same way and build out a list of suggestions.
Again, we're drawing the rest of the owl. We check other F2L pairs for algs. Or OLL or PLL, depending on how much of the cube is solved. It's complicated!
The logic for OLL and PLL alg suggestions is actually very different. With OLL and PLL, we no longer solve pieces to a precise location, so the pattern needs to be more flexible. If you're curious, feel free to look at the source code on Github. Link is at the bottom of the page.
While you're down there, go join the Discord. At time of writing, the site has 2751 algs for the autocomplete, but it needs more! Please submit some.
Thanks for reading! Say hello to my friend's cat, Sharknado.
