# Unique 1983 Megaminx Method



## efattah (Jul 23, 2016)

Hi Guys,

With recent surge in excellent Megaminx times posted around the world I thought I would share an unusual Megaminx method from 1983. I got my first Megaminx in '83, and there were no books on how to solve it (nor internet), I came up with a method that finishes differently than the current one, and might be worth investigating for speed solving.

The current (modern) Megaminx method involves just doing F2L style pairs until you reach the last layer; at which point you solve the last layer with a number of looks/algorithms generally based on orienting/permuting the edges, permuting/orienting corners. The problem with this method is that with a last layer comprised of 5 corners and 4 edges, there are horrible number of possible combinations. Even with 4LLL, there are lots of pieces to observe.

The method I developed in '83 starts the same way with F2L style pairs. However, you get to the last layer and you leave one F2L slot unsolved. So at this point you have the last layer unsolved, plus one F2L slot unsolved (at the front of the cube). Now, by intuitive solving using the 'freedom' of the empty F2L slot, you solve the far corner on the last layer along with the edge piece on either side of it. This is generally done by solving that far pair in the front F2L slot and then raising it into the last layer next to its appropriate edge.

At this point, you have a three arm 'cross' that is still unsolved. The cross consists of four corners and three edges. This presents radically fewer combinations than the normal last layer method. In fact, four corners and three edges is less than a 3x3 last layer. So in effect you are now solving the equivalent of a simpler 3x3 last layer.

Furthermore the algorithms are favorable as you turn three slices and easily alter their overlapping area which is the cross.

Now, you can solve the last 'layer' with 3x3 style methods; you can do COLL (42 algs) then ELL (9 algs), or you can do classic OLL/PLL, or orient the edges then do reduced ZBLL. For more ambitious solvers, when solving the far corner on the last layer, you could do some edge control at the same time to guarantee oriented edges, at which point you could finish with a single ZBLL algorithm and no edge orientation.

Anyway I thought it might be of interest as it allows direct solving of the last pieces with far fewer algorithms than the modern method. Unfortunately as we didn't have computer generated algorithms back in '83, the algs I manually created were not very short, but if someone generated them by computer it would be really slick.

Eric Fattah
BC, Canada


----------



## Dene (Jul 23, 2016)

What you have described doesn't make sense. Can you please revise it?


----------



## stoic (Jul 23, 2016)

I can't follow your reasoning for the last 'layer' as you describe, but it's definitely a viable method and interesting in its own right.
It's similar in approach to how I solve most of the Dayan Bermuda cubes, by leaving a three way axis with a corner at the centre, attached to three corner-edge pairs. Then solve by rotating around that axis and using variations of (R' F R F')3 and (R' U R U' z x')6 and a couple of other tricks. I've never got round to converting it for megaminx, although I did consider it recently when solving Bermudaminxes.


----------



## DGCubes (Jul 23, 2016)

Dene said:


> What you have described doesn't make sense. Can you please revise it?



It makes sense to me, I think. I'm pretty sure he left out a step in which you also solve another corner-edge pair of the top layer, after doing the first corner and two edges. That way, you end up with something like this:



Spoiler: Image












The way I see it, from here you could do any amount of sledges and other forms of edge manipulation to solve the edges, and then condense the CO and CP into one alg. He also suggested some other ways to do that. Correct me if I'm wrong with my interpretation.


----------



## stoic (Jul 23, 2016)

^^
Yes, that's what I'm getting. 
Solve two corners and three edges of the LL intuitively as a block, while leaving the last "slot" open.


----------



## wir3sandfir3s (Jul 23, 2016)

Seems like a cool method. Anyone wanna make Algs for the very last step?


----------



## stoic (Jul 23, 2016)

How many cases are there?

Algs will all be 3-gen, so there's a chance of them being decent for speed.

(Not volunteering btw, I don't have the software.)


----------



## DGCubes (Jul 23, 2016)

I can possibly generate some algs, but I'd need to know the exact number of cases and whatnot. I'm quite a noob at generating algs, so I'm currently using CubeExplorer with 3x3 cases instead of Megaminx ones, but the algs appear to work fine. If anybody knows of any Megaminx algorithm generators, that could help.


----------



## sqAree (Jul 23, 2016)

Wouldn't this method actually be viable for 3x3 in general?


----------



## shadowslice e (Jul 23, 2016)

It's tripod and is perfectly viable though I think the minitripod thing I experimented with may be better though this is still a cool method.


----------



## efattah (Jul 23, 2016)

Yes, sorry, I forgot to mention you actually solve two corners and three edges on the back of the top layer, thanks for correcting me.

There are some non-obvious constraints for those who have never tried this method, if you compare it to a 3x3 last layer that has a similar number of pieces:

1. As the last 'layer' is not a slice, you cannot AUF. This means that what used to be an AUF is now a cube rotation, in terms of applying algorithms onto symmetrical cases. For example if you need to exchange two corners, in a normal last layer method you hold the cube, do an AUF until the two corners are in the correct spot, then execute the algorithm. With the megaminx-cross method, you must rotate the cube until the corners to be exchanged are in the correct spot.

2. Using the OLL/PLL (or oriented cross/permute cross) offers little or no advantage. Normally OLL/PLL beats COLL/ELL on 3x3 because of far easier recognition. However with the cross, determining if a piece is oriented is not obvious because you are not looking for a single color pattern anymore (instead you must compare vs. the centers of the faces). This is why when I developed algs way back, I used the COLL/ELL style method. As far as I recall there are 42 COLL algs and either 8 or 9 ELL ones, so 50-51 algorithms and you can solve the whole cross in 2 steps.

3. A huge advantage of this method is occasional skipped steps. Any type of skip on the modern megaminx last layer is pretty rare. However with the cross method, I would routinely get to the cross and have all the corners and edges already solved with just 2 edges needing to be flipped which was a pretty fast algorithm even without a computer to generate it. This seemed to be so common that all my (ancient) PB's were with this skip at the end. The other common skip was all corners and edges solved, and two corners requiring rotation on the spot.

4. All the cases were solvable with 2-gen algorithms except the cases where you need to 'circulate' 3 corners. This had to be 3-gen as I'm quite sure there is no 2-gen solution. Anyway, with most of the algorithms 2-gen, they are ultra-fast. When I recently learned the modern megaminx last layer method, I was very frustrated with the 'slow' 3-gen algorithms in comparison to what I had learned before.

5. If you use the ZBLL approach, the number of cases is way less than 494 since there are only 3 edges instead of 4. If the edges are already oriented, then there are only three cases of permutations (1. solved, 2. roll clockwise, roll counter-clockwise). So my best guess is 42 corners cases each with 3 edge permutes = 126 algorithms for megaminx-cross ZBLL.

6. With the cross method, unlike the 3x3 you now have the option of a 1-look solution. The number of cases at first seems to be 42 x 8 = 336. However I think it is double (672). i.e. for 3x3 you have 42 x 29 = 1218, but the actual number of 3x3 last layers I think is 2536. While 672 algorithms seems excessive, if you consider how many people now know both ZBLL and OLLCP, the combination of those is essentially the same as a 672 algorithm 1-look megaminx cross.


Eric Fattah
BC, Canada


----------



## stoic (Jul 24, 2016)

Very cool, and thanks for the explanation. 
672 is manageable-ish, in a way, but obviously out of reach to all but the most dedicated and elite minxers. 
51 algs for a 2-look finish, however has to be in the conversation as a legitimate mainstream method - right? Especially if the algs can be OK; how is recognition?


----------



## efattah (Jul 24, 2016)

Megaminx LL recognition (in general) is harder than 3x3 LL recognition. The megaminx-cross finishing method has I would say slightly harder recognition than the modern methods, but nothing that some extra practice wouldn't make up for. However, it is extremely important that you always leave the same F2L slot open at the bottom of the cross. In other words, you need to orient the final cross at the exact same point on the cube every solve, to ensure color recognition is exactly the same every time. Recognition is way harder if you have random colors. Just like with 3x3 ZBLL, most ZBLL users can only recognize with 1 or 2 colors as the top face.

Eric Fattah
BC, Canada


----------



## supercavitation (Jul 24, 2016)

DGCubes said:


> I can possibly generate some algs, but I'd need to know the exact number of cases and whatnot. I'm quite a noob at generating algs, so I'm currently using CubeExplorer with 3x3 cases instead of Megaminx ones, but the algs appear to work fine. If anybody knows of any Megaminx algorithm generators, that could help.


You can use ksolve.


----------



## efattah (Jul 24, 2016)

The megaminx-cross maps directly onto a 3x3. I'm quite certain it is possible to generate the algorithms using Cube Explorer (3x3), constraining the search to F, R, and U turns. 
Once I had generated the old megaminx-cross algs way back, I was doing some 3x3 and found I could use the same algorithms on the 3x3, although they had limited usefulness (depending on the method you are using for 3x3). For example the megaminx algorithm to flip the orientation of two edge pieces worked just fine on the 3x3.

Eric Fattah
BC, Canada


----------



## stoic (Jul 24, 2016)

efattah said:


> Megaminx LL recognition (in general) is harder than 3x3 LL recognition. The megaminx-cross finishing method has I would say slightly harder recognition than the modern methods, but nothing that some extra practice wouldn't make up for. However, it is extremely important that you always leave the same F2L slot open at the bottom of the cross. In other words, you need to orient the final cross at the exact same point on the cube every solve, to ensure color recognition is exactly the same every time. Recognition is way harder if you have random colors. Just like with 3x3 ZBLL, most ZBLL users can only recognize with 1 or 2 colors as the top face.
> 
> Eric Fattah
> BC, Canada


Yes, I'd agree with that. Although I think I'm right in saying that most minxers solve in the same colour order anyway so it shouldn't really be a problem?


efattah said:


> The megaminx-cross maps directly onto a 3x3. I'm quite certain it is possible to generate the algorithms using Cube Explorer (3x3), constraining the search to F, R, and U turns.
> Once I had generated the old megaminx-cross algs way back, I was doing some 3x3 and found I could use the same algorithms on the 3x3, although they had limited usefulness (depending on the method you are using for 3x3). For example the megaminx algorithm to flip the orientation of two edge pieces worked just fine on the 3x3.
> 
> Eric Fattah
> BC, Canada


Any chance you have your original algs in a postable format?
I'd also note for anyone generating algs that <F,R,U> algs which are F-heavy can sometimes be more ergonomic for speed when mapped onto <L,F,U> with a rotation.
Also, a suggestion: I think we need to avoid terms involving "LL" or "cross" when talking about this method, as they're both pretty widely associated with something else.


----------



## Dene (Jul 24, 2016)

btw you also said the last layer has 5 corners and 4 edges.


----------



## irontwig (Jul 24, 2016)

Dene said:


> btw you also said the last layer has 5 corners and 4 edges.



Yes, there's at most 4 bad edges, so AUF one edge and you got at most 5C4E left.


----------



## efattah (Jul 24, 2016)

Okay, so I found *one* page of my ancient megaminx 'tripod' algorithm list and it is attached here.
Please understand the weird notation as modern notation had not been invented yet.
In this case there are four basic patterns, A+, A-, B+, B-, which are all variants of the 4 move 2-gen sledgehammer (R' F R F') except the cube is held so the F is the U face.
A+ = U R' U' R
A- = inverse of A+
B+ and B- are inverses
Honestly I'm not even exactly sure which one is which sledgehammer anymore.

So each A+/A-/B+/B- represents four turns, and most algs are either four of these (=16 moves), six of them (=24 moves) or eight of them (=32 moves). The exception is the roll three corners which is 3-gen and has an even stranger notation that I can't really recall the meaning of (I think Raway = F' and Rnear = F).

There were several sheets, I had all the algorithms memorized at one point, and I didn't do a strict COLL/ELL pattern; I would look at the tripod and identify first the permutation of the corners and edges and usually try to simultaneously permute them all into the correct spot, then orient the corners then orient the edges (sort of reverse 3x3, PLL/OLL). Sometimes I could solve the tripod in 2 algs, sometimes it was three, in rare cases 4 algs, this was because I hadn't quite generated/memorized the full set of 51 algorithms. As I said computer generated versions would be WAY shorter.
 


Eric Fattah
BC, Canada


----------



## stoic (Jul 24, 2016)

That's great, thanks for sharing.


----------



## DTCuber (Jul 25, 2016)

This is really interesting.


----------



## wir3sandfir3s (Jul 25, 2016)

I guess I'll also generate some new Algs, maybe they'll be better. Recog doesn't seem too bad.


----------



## xyzzy (Aug 1, 2016)

lol algs



Spoiler: flip two edges



(R' F R F') (R' F R F') (F' U F U') (F' U F U') (F R' F' R) (U' R U R') (U F' U' F)
(R' F R F') (U F' U' F) (U F' U' F) (F R' F' R) (F R' F' R) (F' U F U') (R U' R' U)
(F R' F' R) (F R' F' R) (R U' R' U) (R U' R' U) (R' F R F') (U F' U' F) (U' R U R')
(F R' F' R) (U' R U R') (U' R U R') (R' F R F') (R' F R F') (R U' R' U) (F' U F U')
(U' R U R') (R' F R F') (R' F R F') (R U' R' U) (F' U F U') (F R' F' R) (U' R U R')
(U' R U R') (U' R U R') (U F' U' F) (R' F R F') (R U' R' U) (F' U F U') (F' U F U')
(U' R U R') (U F' U' F) (R' F R F') (R' F R F') (F' U F U') (F' U F U') (F R' F' R)
(R U' R' U) (R' F R F') (U F' U' F) (U' R U R') (F R' F' R) (F R' F' R) (R U' R' U)
(R U' R' U) (F' U F U') (F R' F' R) (U' R U R') (U' R U R') (R' F R F') (R' F R F')
(F' U F U') (F R' F' R) (U' R U R') (U F' U' F) (R' F R F') (R' F R F') (F' U F U')
(F' U F U') (R U' R' U) (R' F R F') (U F' U' F) (U F' U' F) (F R' F' R) (F R' F' R)
(U F' U' F) (F R' F' R) (F R' F' R) (F' U F U') (R U' R' U) (R' F R F') (U F' U' F)
(U F' U' F) (U' R U R') (F R' F' R) (F R' F' R) (R U' R' U) (R U' R' U) (R' F R F')
(U F' U' F) (U F' U' F) (U' R U R') (F R' F' R) (F' U F U') (R U' R' U) (R U' R' U)

I think the alg in efattah's alg list is nicer despite using one more sledgehammer than optimal. Also, this is the only case that needs seven sledges at the minimum; every other case that doesn't have a 3-cycle of corners can be done with six or fewer.





Spoiler: twist two far corners



(R' F R F') (R U' R' U) (F' U F U') (F R' F' R) (F' U F U') (R U' R' U)
(R' F R F') (U F' U' F) (U' R U R') (F R' F' R) (U' R U R') (U F' U' F)
(F R' F' R) (U' R U R') (U F' U' F) (R' F R F') (U F' U' F) (U' R U R')
(F R' F' R) (F' U F U') (R U' R' U) (R' F R F') (R U' R' U) (F' U F U')
(U' R U R') (R' F R F') (U F' U' F) (U F' U' F) (F R' F' R) (U' R U R')
(U F' U' F) (F R' F' R) (U' R U R') (U' R U R') (R' F R F') (U F' U' F)





Spoiler: twist two adjacent corners



(R' F R F') (R' F R F') (F' U F U') (R U' R' U) (R U' R' U) (U F' U' F)
(R' F R F') (U F' U' F) (R' F R F') (R U' R' U) (F' U F U') (R U' R' U)
(F R' F' R) (F' U F U') (F R' F' R) (U' R U R') (U F' U' F) (U' R U R')
(U' R U R') (U' R U R') (U F' U' F) (F R' F' R) (F R' F' R) (F' U F U')
(F' U F U') (R U' R' U) (R U' R' U) (U F' U' F) (R' F R F') (R' F R F')
(U F' U' F) (F R' F' R) (F R' F' R) (F' U F U') (U' R U R') (U' R U R')





Spoiler: twist three corners in U



(R' F R F') (F' U F U') (F' U F U') (U' R U R') (U' R U R') (R' F R F')
(U' R U R') (R' F R F') (F' U F U') (U' R U R') (R' F R F') (F' U F U')
(F' U F U') (F R' F' R) (U' R U R') (U F' U' F) (R' F R F') (R U' R' U)
(U F' U' F) (R' F R F') (R U' R' U) (F' U F U') (F R' F' R) (U' R U R')





Spoiler: twist three corners not all in one layer



(R' F R F') (R' F R F') (F' U F U') (F' U F U') (U' R U R') (U' R U R')
(U' R U R') (U' R U R') (R' F R F') (R' F R F') (F' U F U') (F' U F U')
(F' U F U') (F' U F U') (U' R U R') (U' R U R') (R' F R F') (R' F R F')





Spoiler: twist all corners



(F' U F U') (R U' R' U) (F' U F U') (R U' R' U)
(U F' U' F) (U' R U R') (U F' U' F) (U' R U R')



All of these also work on the 3×3×3 as they never break up the blocks surrounding the tripod. I think this might be too strong of a restriction to impose, because then we can use only sledgehammers (which cannot solve a corner 3-cycle) and most of these algs look bad. It'd be interesting to see if "proper" <U,R,F> algs are nicer than these.


----------

