# The New Method / Substep / Concept Idea Thread

#### sqAree

##### Member
I FEEL LIKE A GENIUS TODAY AAAA!!! I have a new idea, and its similar to a method I posted in this thread a couple weeks ago, ZZ-Guimond-Woowy-whatever. Basically I found a method that's infinitely better than that.

I've done a bit of looking around, and this is similar in some way to Human Thistlewaite, SSC, Kociemba, and Orient First.

This is actually amazing. Idk what to call this maybe Isom's Guimond (so original I know right!!!) You can pick a name if you want. Here's the steps:
-------------------------
-Edge Orientation-
Just like ZZ EOline, except without the line. Very easy to plan during inspection, about 5 moves average.
The reason this step comes first is because if you solve CO -> EO, than the EO becomes much harder, but if you do EO -> CO, then Corner Orientation is barely affected.
-Corner Orientation-
Just like 2x2 Guimond, except EO must be preserved, so instead of moveset [R,L,U,D,F,B,] you will have [R,L,U,D,F2,B2]. Not much difference.
For 2x2, average optimal movecount for CO is 3.779 moves, so I will give a realistic number for this step, 5 moves average.
The reason you would want to do CO before E-slice placing is because CO gets actually terrible when the E-slice is solved.
Look at SSC or the method I propose a couple weeks ago on this thread. CO is bad. In this, CO is good.
Resource: Lucas Garron Sortega
-Chuck E-layer peices in E-layer-
R E2 R'. Enough said
-Seperate Corners-
Very intuitive and simple step. There's like only 6 distinct cases, so you will get used to them very quickly. This could be combined with the next step to make a more efficient solve, but its a bad idea as there would be 100s of cases and recognition would be poor so it wouldn't be any faster. "God's number" for this step is 5 moves.
I just did a quick ao12 and average time was 0.96 and average movecount was 3.75.
-Permute Corners-
Just like 2x2 Ortega PBL, except on 3x3. There are 5 algs minimum, 8 algorithms recommended (to prevent x2 rotations and stuff)
Diag Top- F R U' R' U' R U R' F' R U R' U' R' F R F' Diag Bottom- R D' R2 U2 R' U R U2 R U2 R D R'
Adj. Top- l' U R' D2 R U' R' D2 R2 Adj. Bottom- R' D R' F2 R D' R' F2 R2*
Double Adjacent- R2 U' B2 U2 R2 U' R2* Double Diagonal- R2 F2 R2*
Adj. Top / Diag Bottom- R U' R F2 R' U R'* Diag Top / Adj. Bottom- R' D R' F2 R D' R*
*same as 2x2 algs.

This is how move calculations are done, probabilty and preAUF's and all- (0*1/36)+(17*1/36)+(13*1/36)+((9+0.75)*4/36)+((9+0.75)*4/36)+((7+1.5**)*16/36)+(3*1/36)+((7+0.75)*4/36)+((7+0.75)*4/36) = 9.027
**
Both U and D have to be AUF'ed for double bars case. Also, solved and diag cases doesn't require preAUF.

The reason I permute in this way is because it is crystal clear that CP then EP is so much better than PLL then PLL. Everyone would agree. If you don't, then learn to think.
-UL/UR + DL/DR-
Basically L/R from Roux LSE, except its double. Pretty easy to see what you're doing, and you don't need to know any difficult concepts whatsoever. Most of the time I would solve DL/DR then UL/UR, but you can think of this step however you want.
If you've ever tried Roux, then this step is pretty straight foward.
By the way, you can use non-matching L/R trick to enhance efficiency. For example, you solve DL/DR red/orange, but UL/UR green/blue.
This might make 4c recog slightly worse, but this is usually worth it.

The reason that L/R -> 4c is better than Seperation -> EPLL is the same reason that vanilla Roux doesn't do Solve D edges -> EPLL.
Its simply less efficient with no ergonomic tradeoff, so L/R -> 4c is better.
- 4c + 4c -
The edges have been simplified so much that now M layer is just like Roux 4c and E layer is just like 4c. M and E are independent, besides the fact that you can have "parity", for example, the M layer couldn't be solved with just [M,U2] moveset. You can use R2 U2 R2 U2 R2 to fix this "parity". You tell me the movecount and ergonomics for this step
---------------------------

EXAMPLE SOLVE:
Scramble: U R2 D2 L2 F' D2 B D2 L2 R2 B2 F' D' F' D' L B' F' U' F2
y2 // inspection
R2 L2 B' // EO
R' U2 R U' R U2 R' // CO
U' R E2 R u2 U R E2 R' // E-layer placement. There's probably a more efficient way.
U' R2 U R2 // Corner Seperation
D' R' D R' F2 R D' R // Corner Permutation
M2 u2 M2 D' U2 M U2 M U // L/R
M U2 M R2 E2 R2 u2 // 4c
48 STM
Scramble: D L' F2 U F L D' F2 R2 B U2 D2 L2 F' D2 B D2 F' U2 R'
y z2 // inspection
U L D' F // EO
R D' R' U R' // CO
F2 D U L E2 L' // E-layer
D' R2 // Corner Seperation
y R2 U' B2 U2 R2 U' R2 // Corner Permutation
D' M' U2 M' U M U2 M' // L/R
z2 U' F' U2 M2 U2 F U2 // 4c
39 STM

Scramble: B2 R D2 B2 R2 B2 L2 D' U' L2 U' B' L' R' F2 D F2 U' R
B L2 U L B // EO
L' R' U R' U2 // CO
E2 R L2 B2 E' F E2 F // E-layer
U2 L2 // Corner Seperation
D R' D R' F2 R D' R' F2 R2 // Corner Permutation
y M2 U M' U2 M' u2 M2 D M2 U2 M2 // L/R
L2 D2 L2 D2 L2 U M U2 M' U // 4c
51 STM

Scramble: L D R2 B2 L2 F2 D R2 D' B2 D2 R U2 B D L B2 F' D2
y // inspection
R U L' F // EO
R U2 R U' R D2 L // CO
D2 U' R E2 R' // E-layer
U D R2 y' R2 D R2 D' R2 // CS+CP
U' S U2 S' U' M' U2 M' // L/R
U M2 U2 M' U2 M u' R2 D2 R2 D2 R2 D' // 4c
45 STM

Average movecount under 50. Nearly no algorithms to memorize, only 8 CP algs. It's just a lot of intuitive parts that has TONS of room for improvement because you will get more efficient and faster once you learn better algs to do certain cases and get used to these intuitive cases, especially CO and E-layer. This means you won’t be instantly fast with this method, so I guess you would say there is a learning curve to this?
I honestly think this is like the best thing ever. Okay, not best method, I know CFOP and Roux are the best, but this is the best method I have come up with. Everything makes sense and there isn't one step that is horribly inefficent. Everything is just so nice.

What suggestions do you have for this method to improve it?
Umm, co how it is done for ssc is pretty great, and as far as I can see you didn't come up with a solution to the steps after belt + co (which is the main disadvantage of ssc).

#### WoowyBaby

##### Member
Umm, co how it is done for ssc is pretty great, and as far as I can see you didn't come up with a solution to the steps after belt + co (which is the main disadvantage of ssc).
Yes, I did.
At no point in the solve is the belt ever solved, except at the very last move. (did you even look at he example solve?) This makes the corner steps significantly easier.
- In this, you could just do R2 to separate corners. In SSC, you would have to do U2 R2 U2 R2 for the same case.
- In this, most of the CP algorithms are identical to 2x2. SSC it’s not. Just tell me which is better- R2 F2 R2 or R2 (U D’) R2 (U’ D) R2.

Last edited:

#### sqAree

##### Member
Yes, I did.
At no point in the solve is the belt ever solved, except at the very last move. (did you even look at he example solve?) This makes the corner steps significantly easier.
- In this, you could just do R2 to separate corners. In SSC, you would have to do U2 R2 U2 R2 for the same case.
- In this, most of the CP algorithms are identical to 2x2. SSC it’s not. Just tell me which is better- R2 F2 R2 or R2 (U D’) R2 (U’ D) R2.
Sounds cool, I will have another look at it after the weekend.

#### Filipe Teixeira

##### Member

Belt minus one edge
Solve bottom layer using keyhole
Insert last edge while orienting all the last layer edges
Last layer

Example solve:

SCRAMBLE: R U2 R' U2 R2 U2 B2 R' B2 R U2 F' R2 D' L2 R' B D L F

SOLVE:
U D L U R2 // BELT MINUS 1
r U' r' // BOTTOM BLOCK 1
D M' U2 M R U R' // BOTTOM BLOCK 2
D U r U2 r' U' R U R' // BOTTOM BLOCK 3
D U M' U2 M F' L' U2 L F D // BOTTOM BLOCK 4
y U2 L' U L d R U' R' // LAST EDGE
U R' U' F' R U R' U' R' F R2 U' R' U' R U R' U R // PLL

(66h, 73q, 62s, 63e)

It need improvements but seems like a fun and unique method

Last edited:

##### Member
I'm just going to focus on the early steps since the last few are more or less the same as SSC and I have made quite a few posts on the issues I have with them.
As a preliminary note in your reply to @sqAree, you mention that this has a better last phase that SSC as the E-slice remains wholly unpermuted until the last step. There is actually a variant of SSC where I and a few others have played around with this idea called SSC-domino which I know I have mentioned in the wiki page though admittedly I can't remember if I described it. If I haven't then my bad; I'll have to add it in.

Although it is a more efficient, I personally discarded it for speedsolving as it can lead to uncomfortable move sequences involving thing like F2s or B2s etc (which I note you don't have in your example solves?) the way around this would be to be what you seem to be doing in those solves which is to separate the e-slice to R/L during CP (but this would add more algs as well as mean you would have to look at 3 layers to recog the case)

You would also have to deal with the parity you describe which can be folded into the last step but again recog is annoying

So overall, I'd conclude that only R2/r2/M2 off is really beneficial
-Edge Orientation-
Just like ZZ EOline, except without the line. Very easy to plan during inspection, about 5 moves average.
The reason this step comes first is because if you solve CO -> EO, than the EO becomes much harder, but if you do EO -> CO, then Corner Orientation is barely affected.
Cool, makes sense. My issue is that it seems to not be using inspection fully unless you can predict the next step (which is probably possible though would likely require a reasonable amount of investment similar to one-looking 2x2). Still not a bad step though.
-Corner Orientation-
Just like 2x2 Guimond, except EO must be preserved, so instead of moveset [R,L,U,D,F,B,] you will have [R,L,U,D,F2,B2]. Not much difference.
For 2x2, average optimal movecount for CO is 3.779 moves, so I will give a realistic number for this step, 5 moves average.
The reason you would want to do CO before E-slice placing is because CO gets actually terrible when the E-slice is solved.
Look at SSC or the method I propose a couple weeks ago on this thread
. CO is bad. In this, CO is good.
Resource: Lucas Garron Sortega
See my above comment: this is potentially good but recog wouldn't be fun so the only real way to make it viable would be prediction.

Re: italics; wait so are you saying here that SSC does CO after e-slice? That's just wrong; SSC does corners with belt rather than separately and that's arguably one of the best aspects of it.

-Chuck E-layer peices in E-layer-
R E2 R'. Enough said
This step reminds me of salvia. Like that method, I'm going to guess that this step is easy to lookahead but also has some horrible ergonomics and it not terribly efficient which negates the efficiency of the previous steps.

As I said above, the next few steps are the same as in SSC and so have the same issues I've complained about on numerous occasions
What suggestions do you have for this method to improve it?
The last few step need some improvement (just as they do with SSC) as well as putting the e-slice edges into the e-layer. It's a reasonable method overall though.

#### WoowyBaby

##### Member
I'm just going to focus on the early steps since the last few are more or less the same as SSC and I have made quite a few posts on the issues I have with them.
As a preliminary note in your reply to @sqAree, you mention that this has a better last phase that SSC as the E-slice remains wholly unpermuted until the last step. There is actually a variant of SSC where I and a few others have played around with this idea called SSC-domino which I know I have mentioned in the wiki page though admittedly I can't remember if I described it. If I haven't then my bad; I'll have to add it in.

Although it is a more efficient, I personally discarded it for speedsolving as it can lead to uncomfortable move sequences involving thing like F2s or B2s etc (which I note you don't have in your example solves?) the way around this would be to be what you seem to be doing in those solves which is to separate the e-slice to R/L during CP (but this would add more algs as well as mean you would have to look at 3 layers to recog the case)

You would also have to deal with the parity you describe which can be folded into the last step but again recog is annoying

So overall, I'd conclude that only R2/r2/M2 off is really beneficial
Cool, makes sense. My issue is that it seems to not be using inspection fully unless you can predict the next step (which is probably possible though would likely require a reasonable amount of investment similar to one-looking 2x2). Still not a bad step though.

See my above comment: this is potentially good but recog wouldn't be fun so the only real way to make it viable would be prediction.

Re: italics; wait so are you saying here that SSC does CO after e-slice? That's just wrong; SSC does corners with belt rather than separately and that's arguably one of the best aspects of it.

This step reminds me of salvia. Like that method, I'm going to guess that this step is easy to lookahead but also has some horrible ergonomics and it not terribly efficient which negates the efficiency of the previous steps.

As I said above, the next few steps are the same as in SSC and so have the same issues I've complained about on numerous occasions

The last few step need some improvement (just as they do with SSC) as well as putting the e-slice edges into the e-layer. It's a reasonable method overall though.
OK.
If I ever said SSC solves belt then CO, I am wrong. It solves 3/4 belt, then CO, which is a big difference.

—You mention that just doing EO is easy in inspection so you could do more, but entirety of CO may be too much. A better way to do it is EO + orient LD corners, then do CO completely 2-gen. This takes advantage of your inspection time, and makes lookahead much easier.
2-gen CO is also very quick to execute, and so much easier to figure out what to do vs. no corners oriented. There are 72 total cases, basically semi-intuitive, and its really easy to memorize all of them.
Lucas Garron’s Sortega page includes all cases.
Movecount would increase by like 1.5 moves but it is faster so who cares xd

EO+LD -> 2-gen CO > EO -> CO

—E-slice placement is a pretty bad step but I don’t think there’s much to do about it.
—You and sqAcree are telling me that the later steps of Isom’s Kociemba (bad name lol) and SSC needs improvement, and I don’t really have a solution to this, but a unique approach.
Build 2x2x2, Expand to F2L-1, then TTLL (zz-ct)
This would eliminate slice moves and inmprove ergonomics (R2 U’ F2 > M2 D M2), but might make movecount and lookahead worse because of blockbuilding. This is just an idea,
Scr: D R2 D R2 D2 R2 U F2 U2 R2 B2

U L2 U L2 // CS
U R2 U’ B2 U2 R2 U’ R2 // CP
M U2 M’ U M’ U2 M // L/R
U’ y M u2 M’ E M2 E // 4c
26 STM, current method

R2 U2 F2 L2 D2 // 2x2x2
F2 U’ F2 U’ R2 // Expand to F2L-1
D2 y z D2 U R U’ R’ D2 R U R’ U’ R r2 // TTLL
23 HTM, blockbuilding method. Pretty lucky (may not be 100% representive)
Scramble: U2 R’ B2 D2 F2 R’ D2 U2 R2 B2 D B2 R’ D2 U B U’ F’ L2 F’
x2 L D F D’ // EO LD
R’ U R2 U2 R’ U2 R // 2-gen CO
U’ R E2 R’ F2 L E2 L’ // E-layer
R2 D F2 L2 U’ L2 U L2 // 2x2x3
y R2 U R2 U’ R2 U’ R2 U’ R2 // F2L-1
u M2 U’ M U2 M’ U’ M2 U2 // TTLL (PLL)
45 STM

I will name a method with these steps Six-Step Kociemba: EO DL, 2-gen CO, E-layer placement, 2x2x2 or 2x2x3 block, expand to F2L-1, and TTLL.
First 3 steps = Kociemba Phase 1, Last 3 Steps = Kociemba Phase 2.

Ending like normal may still be better, which would be Isom’s Kociemba. EO->CO will be called Old Isom’s Kociemba.

Thanks for supporting this and telling me I’ve made a reasonable method

Last edited:

#### PapaSmurf

##### Member
Small correction: SSC does eoedge, then CO+belt, and that is done with OL5C, where you place a triplet at DL and a pair in UL. It means that orientation+belt is done in less than 20 moves on average. And while we're talking about orientation methods, what about eoedge, CO3/4Belt while making sure that the FR edge isn't a D layer edge, D layer minus corner, permute L10P. Can also be done in a ZZ approach, with ZZF2L-1, Orientate everything, pernute everything. So an extension to ZZ-CT.

#### American-Cuber

##### Member
Hey guys, I think I discovered a pretty good method. I like to call it SH2-WV. This stands for Speed Heise 2- Winter Variation. I'll explain the steps, but I think it's pretty self-explanatory.

1.Make a first block as you would in roux
2. Make a 2x2x2 block right next to it.
3. Either EO first or fill in the last edge first.
4. Winter Variation!
5. Permute top face edges
6. Use a commutator or alg for the corners.
I think this is a pretty cool method and ive gotten a couple sub 15 solves with it. You should try it out!

#### willtri4

##### Member
I feel like there are better ways to get to EOF2L-1 and better ways to go from EOF2L-1. The blockbuilding step is interesting, but seems kind of awkward, but then for LSLL, if you insist on using WV you should be doing PLL, but even then there are better options (insert+ZBLL).

#### American-Cuber

##### Member
I feel like there are better ways to get to EOF2L-1 and better ways to go from EOF2L-1. The blockbuilding step is interesting, but seems kind of awkward, but then for LSLL, if you insist on using WV you should be doing PLL, but even then there are better options (insert+ZBLL).
I like your ideas, I'll see what I can do. Because I don't even know full winter variation.

And about the block building stage, it's more about few moves and being efficient than ergonomics.

Last edited by a moderator:

#### Awesomesaucer

##### Member
I do cfop with vhls
Is this new or unoriginal
I have a Pb with this method of 9.286s

#### Sue Doenim

##### Member
The method just doesn't seem very viable at all. Making a 3/4 belt for the first step leaves step two, the brunt of the solve, with low visibility, not-so-good ergonomics, and unimpressive efficiency. The current algs for step three are not very good at all, although they might be improvable. Basically, it just doesn't seem like an idea that could really go anywhere.

#### WoowyBaby

##### Member
It's much better to solve the bottom block and then the E-layer, and, personally more fun. Hexagonal Francisco is one of my favorite methods to solve with, and I get times extremely similar to my CFOP times.
Doing Middle layer -> bottom layer instead is simply worse, it makes movecount spike and lookahead drop significantly, making this method slow.
(maybe that post was ignored for a reason)

#### dudefaceguy

##### Member
Intuitive 4x4 method and tutorial

I have updated the method here: https://www.speedsolving.com/forum/threads/intuitive-4x4-method-with-parity-avoidance.73049/

The old version is in the spoiler below.

I'm an intuitive solver, and I haven't been able to find any good resources for intuitive 4x4 solving, so I made this method and tutorial for others like myself. My hope is that it will be useful for folks who are looking for a completely intuitive 4x4 method that doesn't use any written or memorized algorithms. I think it should eventually be in the "How-tos and Guides" subforum, but I wanted to get your opinions on the method here first. It's based on the Sandwich method.

The most interesting parts are step 4, which is similar to parts of OBLBL, step 5, which I have not found anywhere else so far, and step 6, which I think employs a technique used by advanced Sandwich solvers, but which I haven't seen described anywhere in detail yet. I also like the fact that step 4 sets up good cases for very efficient 4-move center commutators in the last step.

I'm definitely not a speedcuber, so this method is not designed for speed - my major goals are elegance and efficiency. It's somewhat inspired by the Heise method, which I use to solve 3x3 cubes.

As far as move efficiency goes, I think this method has good potential. I have only been cubing for about a month, so I am not very good, but I can get to around 120 moves regularly. I think this will get lower once I get better and more familiar with the method. My personal best is 105 moves, and that includes many sub-optimal cases, so sub-100 is definitely possible. My worst solve full of horrible cases and poor decisions was 137 moves. The average of my last 9 solves is 122, and the average of my last 5 solves is 112 so I'm getting better. Even if this isn't amazingly efficient, at least it isn't terribly inefficient.

Here's the tutorial:

Solving the 4x4 and Avoiding Parity Problems Intuitively

This is the method that I use to solve the 4x4 intuitively without using any memorized algorithms, and to easily avoid parity problems. It is based on the Sandwich method.

I assume a good knowledge of blockbuilding and commutators. For a good video on commutators in general and 4x4 commutators in particular, I suggest this video:

I use these 7 steps:

1. Solve two opposite centers.​
2. Solve a 1x3x3 block and a 1x3x4 block (similar to Roux) on the opposite face.​
3a. Solve two more corners such that the last 3 corners are out of place, then solve the last 3 corners using a commutator.​
3b. Solve the last edge pair of the 1x3x3 block to extend it to a 1x3x4 block.​
4. Extend one of the 1x3x4 blocks into a 2x3x4 block by solving one middle slice excluding the top layer.​
5. Use the unsolved slice to solve exactly 7 of the remaining 10 edge pieces.​
6. Solve the remaining 3 edge pieces and some center pieces with a commutator.​
7. Solve the remaining center pieces with 2 or 3 commutators.​

Here is a photo album which includes a brief description of each step:
That's it! You should be able to do these steps intuitively without any more instruction (except maybe the parity explanation in step 3a). The remainder of the guide is just clarification and some tips for better efficiency.

My goals in making this method were the following:

1. Completely intuitive - no memorized or written algorithms.​
2. Ability to solve parity problems at their source, elegantly and intuitively.​
3. Move efficiency.​
4. Fun, which includes a varied set of problems and solving techniques during the course of the solve.​

Step 1: Opposite centers (~10 moves)

This is fairly straightforward. You can sometimes solve edges while solving centers if the edges are already attached to their matching center pieces. But, solving edges is very efficient in the next step so it doesn't make sense to spend more than 3 extra moves to solve an edge pair during this first step.

Step 2: Blockbuilding (~25-30 moves)

This step is also straightforward. The goal is to end up with one 1x3x4 block around one of your solved centers, and a 1x3x3 block around the other. I like to solve two 1x3x3 blocks first, then solve the last corner/edge pair to make a 1x3x4 block last. This gives me some more freedom compared to solving a 1x3x4 block first.

The two blocks don't actually have to have matching colors, but subsequent steps are a lot easier if they do. If you really want to save moves, try making unmatched blocks for an extra challenge.

Step 3: Corners (~12-17 moves)

First the short version: solve 2 of the 5 unsolved corners such that the last 3 unsolved corners are all incorrectly permuted (i.e. they are out of place, not just twisted in place), then solve these last 3 corners with a commutator. If only 2 corners are incorrectly permuted, they cannot be solved with a commutator because they have odd parity. In this situation, you can just make a quarter turn of the unsolved face to change the parity from odd to even, then solve with commutators.

Okay, now the long version.

This is where we have our first brush with parity problems. If you know the Heise method for the 3x3, you will know that it forces the last 3 corners to have even parity by solving all edges first. This makes it possible to solve the last 3 corners with a single commutator. With the 4x4, this technique does not work because corner parity and edge parity are independent. If we wait to solve the corners until the end of the solve, we can end up with odd corner parity, which is commonly known as a form of PLL parity. Fixing this at the end of the solve can be done intuitively, but it requires discarding and re-solving large portions of the puzzle. So, we are instead going to solve corners now when it is easy to fix parity problems.

First, since we are solving intuitively, we have to understand what parity is. In group theory, parity refers to the number of swaps that it takes to sort a particular permutation. If you can sort a permutation using an odd number of swaps, the permutation has odd parity, and if you can sort a permutation using an even number of swaps, the permutation has even parity. For some really interesting discussions of parity, I recommend the following resources:

Ryan Heise's parity explanation for the 3x3 https://www.ryanheise.com/cube/parity.html

The Parity of Permutations and the Futurama Theorem

A long parity essay about the 4x4
https://hlavolam.maweb.eu/parity-problem

Commutators are the secret weapon of the intuitive solver, but they cannot solve odd parity permutations, because they must always do an even number of swaps. So, we have to make sure that our last three corners have even parity before we can solve them with a commutator. Every quarter-turn of any face cycles corners between odd and even parity, so it is actually very easy to transition between odd and even parity.

The easy way to solve corners using commutators is to keep spamming commutators, and if you end up with 2 or 3 unsolved corners that can't be solved by commutators and conjugates, do a quarter turn of the unsolved face and then keep spamming commutators. However, this is neither elegant nor efficient. In order to be efficient, we need to know whether parity is odd or even before we start to solve the corners. We can do this by counting the number of swaps it will take to permute all of the corners. If you do blind solving, you already know how to do this. For our purposes here, we can use a simplified version. After a bit of practice, this can be done in a few seconds.

First, pick any incorrectly permuted corner (i.e. corners that are in the wrong place - corners twisted in place count as "solved" because we are only considering permutation, not orientation). Find its solved position; this is one swap. Now take note of the corner that is currently in this position and find its solved position; this is a second swap. Continue doing this until you come back to the original piece; this is one cycle. When counting swaps, don't count the starting piece itself, either at the beginning or the end of a cycle.

All of the corners may be in the same cycle, or they may be arranged in multiple separate cycles. Whatever the arrangement, the number of swaps it takes to solve a particular group of pieces will always equal the number of incorrectly permuted pieces minus the number of cycles. To express this as a formula, if p represents the number of pieces, c represents the number of cycles, and s represents the number of swaps needed to solve these pieces, then s=p-c. So in order to determine parity, we really only need to count the number of cycles, then subtract that number from the number of unsolved pieces. We can look at an easy example using four letters:

B C D A

Let's trace the swaps needed to put them in alphabetical order, starting with A. A belongs in B's spot, B belongs in C's spot, C belongs in D's spot, and D belongs in A's spot. All four letters are in the same cycle, and three swaps will sort all of the letters into their correct places. This arrangement has odd parity: 4 letters minus 1 cycle equals 3 swaps. Now look at this example:

C D A B

Here, the letters are arranged in two separate cycles, and we can sort them using only two swaps. This arrangement has even parity: 4 letters minus 2 cycles equals 2 swaps. Note that this example is the same as the previous example, except that the letters have all been rotated one spot to the left. This should help to illustrate how a quarter-turn switches pieces between odd and even parity.

We can apply exactly the same analysis to our corners quite easily. Count the number of corners that are out of place (don't count corners twisted in place), subtract the number of cycles it takes to permute them, and that number will tell you whether the corners have odd or even parity.

After we determine parity, our next goal is to solve two corners such that 3 corners remain unsolved with even parity. We can do this by solving 2 of our 5 unsolved corners using either an odd or an even number of quarter turns. 4-move commutators are very useful here. Remember that a 180 degree turn like U2 counts as two quarter turns. Once you have 3 corners unsolved and even parity, solve the last 3 corners with a single commutator, and this step is complete. (If you end up with all unsolved corners twisted in place, this is an even parity situation as well, it is just less efficient.)
Of course, if you already know a set of 2x2 or CLL algorithms you can just use those, but this method is designed for people who don't know any algorithms at all.

Personally I have found this step to be quite challenging but extremely fun and interesting. After practicing with my 2x2 I am starting to do fairly well. This step also works as a method for solving a 2x2 intuitively and reasonably efficiently.

Step 3b: Solve the remaining edge pair to extend the 1x3x3 block into a 1x3x4 block. (~6 moves)

This is self-explanatory. You want to end up with two 1x3x4 blocks solved on opposite sides, and all corners solved.

Step 4: Solve 3/4 of one middle slice, to extend one 1x3x4 block into a 2x3x4 block. (~14 moves)

This is more block building, but you have to use entirely new tactics that don't apply to 3x3. It took me some time to get the hang of this step, but I can now complete it in 12-15 moves. You can use several techniques to connect center pairs with edge pieces and insert them, but my favorite is to put the edge piece on the L or R side of the top layer, turn the M slices to pair centers with it, then rotate the top layer to insert the trio.

Step 5: Use the unsolved slice to solve 7 of the remaining 10 edge pieces. (~14 moves)

It took me a while to get the hang of this as well, but it ends up being more efficient than using commutators. Instead of pairing adjacent edges, you pair opposite edges on the unsolved slice, then insert them into the top face. The goal here is to arrive at a state in which three edge pieces are unsolved, which will mean that we have even edge parity, and we can solve these last three pieces with one commutator.

There are a lot of different ways to do this, but I like to solve all of the top-layer edges except for the two in the unsolved slice. In this case, all of the unsolved edge pieces will be in the same slice. It's not guaranteed to end up with only 3 pieces unsolved, but the odds are favorable here - for the even parity cases, you have a 2/3 chance for 3 unsolved pieces, a 1/6 chance for 4 unsolved pieces (which you can solve using 2 commutators), and a 1/6 chance for a skip in which all 4 pieces are solved. This is my preferred technique because of that sweet and satisfying skip. However, you can frequently save a lot of moves by just looking out for good cases and solving whatever edges are easiest.

It's usually not necessary to check for parity since you will correct it automatically by arriving at a state with 3 unsolved edge pieces, which is an even parity state. 2 unsolved edge pieces means odd parity, and 3 unsolved edge pieces means even parity. If you want to check parity earlier, or if you have more than 3 unsolved pieces, you can trace swaps and cycles just as we did when solving the corners. Note that individual edge pieces cannot be flipped in place, so a flipped edge piece must always be permuted to be solved.

If you have odd edge parity, simply turn the unsolved slice by 90 degrees to get to even parity. That's all it takes to avoid edge parity problems. Once you have even parity, you can check which of the two even-parity positions is most favorable for edges and centers - switch between them with a 180 degree turn of the unsolved slice.

Step 6: Use a commutator to solve the last 3 edge pieces and some center pieces. (~10 moves)

Since edges now have even parity, we can solve the last edge pieces with a commutator instead of learning a set of "last edges" algorithms.

It's possible to include either three or six center pieces along with the edge commutator, similarly to how we construct a pair 3-cycle on a 3x3 cube. This is easiest if the edges are not conjugated outside of the M slice layers. You can also include center pieces in your conjugates, of course. Sometimes it even makes sense to conjugate only the centers with a wide S2 or E2 move.

Using tricks like this, it's possible to move a lot of center pieces along with the edge commutators, without increasing the move count much or at all. Solving even one center piece during this step can end up being very helpful, since it could decrease the number of commutators needed to solve the centers in the next step.

Step 7: Center commutators (~20-25 moves)

In this last step, we have four types of commutators available:

1. 8-move commutators, moving 3 pieces
2. 8-move pair commutators, moving 6 pieces
3. 4-move commutators, moving 6 pieces
4. 4-move pair commutators, moving 12 pieces

Because center pieces have a 1/4 chance of being solved randomly, you will most often end up with 7 or 8 unsolved pieces, just by random chance, or less if you were able to solve some more center pieces along with your edge commutator. Centers will usually take 2 or 3 commutators to solve, the first of which can usually be a 4-move commutator that moves 6 pieces. Because of the way the previous steps set up the centers, you will often be able to easily conjugate a 4-move commutator with a wide slice move. Note that 4-move commutators can be extremely efficient, even with long conjugates. I frequently solve 5 pieces with a single 4-move commutator, which is very efficient even if it requires a 3-move conjugate for a total of 10 moves. It's worth studying and understanding how these 4-move commutators work.

Center commutators will usually require some kind of conjugate, and you can save moves by trying to conjugate the same face for every commutator. This means that you won't have to undo your conjugate at the end of each commutator - you can just rotate the face to a new conjugate for the next commutator instead.

Once you complete the centers, the cube is solved!

Wait, what about PLL and OLL parity?

Since we are solving pieces directly and ensuring even edge parity in step 5, we will never have to solve PLL or OLL edge parity problems as such. We avoid corner permutation parity problems in step 3.

The End

So, that is my method. If you have any suggestions for improvements I'd love to hear them! I feel like I should be able to do more work during the corner step, or do it more elegantly, but I haven't come up with any improvements yet.

Please also let me know if the explanation was too confusing, or if you have any interest in a video demonstration. Thanks for reading!

Last edited:

#### PapaSmurf

##### Member
That's quite interesting! Very infact. A video would be great.

#### dudefaceguy

##### Member
That's quite interesting! Very infact. A video would be great.
Alright, here is a video demonstration:

This is my first-ever YouTube video where I have a speaking role. Thanks for encouraging me to make this -- I had a lot of fun doing it!

I counted my moves, and came up with 135. I didn't count demonstration moves, immediately reversed mistakes, and pauses in the middle of turns, but I did count mistakes that I didn't reverse (notably in step 5, which cost me 7 extra moves). I think that's pretty good, considering that I was making no effort to be efficient.

I also noticed something interesting while re-watching the video. I think that the 6 unsolved center pieces in the last step were actually in a very bad configuration such that an 8-move 3-cycle would not be able to solve 3 pieces -- at least not without some very ugly conjugates -- since there were no unsolved center pieces located on opposite-color sides. So, the 4-move commutator that I used was actually able to save me a lot of moves, and possibly an entire commutator, even though it took a total of 8 moves including the conjugate.

#### PapaSmurf

##### Member
That's a very interesting method! If you were gonna optimise it for speedsolving, 42 corners would work well with it, or even straight L5C, but that's 614 algorithms, so not really alg free. And I can see how this could be optimised a lot in terms of movecount. When I can, I'll edit this post with some more thoughts on the method after playing about with it.

EDIT: So, I've done a few solves so far, and I think that this method has potential. There just needs to be some speed optimising of the L3E+centres steps. Making that algorithmic would help a lot, but that's not too hard as you can just use comms from bld. The best way to do corners is 42 style IMO, as it allows you to use only 42 algorithms that a lot of solvers attracted to this method will already know (roux), and it's applicable on 3x3 as well. I'm not sure how it compares to Yau, but if it's more efficient, it should stand a good chance, and as you don't get parity, that will also help.

Last edited:

#### dudefaceguy

##### Member
That's a very interesting method! If you were gonna optimise it for speedsolving, 42 corners would work well with it, or even straight L5C, but that's 614 algorithms, so not really alg free. And I can see how this could be optimised a lot in terms of movecount. When I can, I'll edit this post with some more thoughts on the method after playing about with it.
Thanks, I would love some more move optimization ideas!

I just tried this on a 5x5 and it actually worked (though I'm not sure how efficient it is). The middle edge pieces add a nice little bit of complexity, since they are in a separate orbit from the wing edges. But, they make the corner step easier since you can do it exactly like Heise. Just make sure to solve the two unsolved middle edge pieces in the D layer before starting step 3, then do step 3 exactly like Heise and you will end up with all corners and middle edge pieces solved. I suppose the D layer middle edges could be solved along with the blockbuilding step.

You can then solve 3/4 of the middle slice (which makes a cool-looking design) and 3/4 of one of the wing slices (or whatever they are called), and then use the remaining unsolved wing slice to solve 7 out of 10 wing edges, just like in the 4x4 method. The rest of the method is the same, with a single commutator for the last wing edges and a few center commutators.

For larger cubes, I think you would always have to leave 1/2 of the wing slices unsolved in order to be able to pair all of the wing edges, so it seems like the method would get much less efficient as cubes got larger and proportionally more of the pieces were centers. But of course I haven't tested it because my largest cube is a 5x5.

#### ImmolatedMarmoset

##### Member
Had a simple 3x3 method idea that’s kind of a ZZ-roux variant:

Start:

EoLine (But with inserting DL and DR instead of DF and DB)
FB (as in roux. You start with the DL edge and insert pairs around that w/o messing up EO)
SB (same style as FB except with DR)

Finish:

Then there are a few options for the finish. I’m not sure which one is better so I’m just putting them all out there:

Roux Finish:
CMLL (43 algs I think)
LSE (I don’t know if CMLL messes up EO. If it doesn’t you can skip EO during LSE)

ZZ- like finish:
Insert both edges into DF and DB w/o messing up EO
ZBLL (493 algs)

Lin Finish (Lin is a square one method I use):
CMLL+1: (Insert DB edge, then do CMLL and insert the other D edge with one alg) (These algs would preserve EO) (43 algs I think)
EPLL (4 algs)

I like the Lin finish the best because it fits with the first part the best and is the most unique.

This is my first serious method idea, so it probably has been thought of before and also probably sucks, so please correct me as much as you please.

I’ll attach an example solve with all 3 finishes later when I have time.

Thanks!

Last edited: