# Generic Solving Method

#### Lyle

##### Member
Hi everyone. I am sure I am not the first person to do this, but I have developed a method for solving any twisty puzzle without having to rely on external resources (ie. googling algorithms).

The steps are as follows:

1. Develop a notation which can be used to write down algorithms for your puzzle. You will need a character representation for every twistable part of the puzzle and a character representation for every direction a part can be twisted.
2. Decide what order you want to solve the pieces of the puzzle. Some orders may be easier than others.
3. Solve the puzzle as far as you can until you get stuck. Take note (ie. draw/take a picture) of the current state of the puzzle.
4. While using the notation developed in step 1 to keep track of every twist, perform the following steps: a. unsolve the last part of the puzzle you solved. b. mix up the unsolved pieces of the puzzle. (Usually just a couple twists is sufficient. Anything that changes the state of the puzzle to something new) c. solve the puzzle back up to the same level of progress achieved in step 3.
5. Take note of the current state of the puzzle and compare to step 3. Most likely, you are at the same stage in the solving process, but the unsolved pieces are in a different order. Take note of how they have changed. Categorize the pieces into different categories (ie. edge, corner). How did the algorithm developed in step 4 affect each of those categories? Can that algorithm be used to solve the puzzle further than what we achieved in step 3? If not, go back to step 4. If yes, go back to step 3.

Using this method, I have developed algorithms for solving a variety of different twisty puzzles. I have also used this method to help me understand certain algorithms I was already using for the 3x3x3 rubik's cube (namely the T-perm and Y-perm I have been using). I will note though, that shape changing puzzles like the square-1 may need to be in the correct shape before this method can be applied to rearrange the pieces. Most of the time, algorithms developed in this manner will not be the fastest and will not be suitable for any kind of speed cubing. However, I find it easy to wrap my head around and it saves me from needing to rely on guides. I also don't usually need to actually write down the algorithms, but it can help if things get complicated.

I have considered creating a tutorial on how to solve a rubik's cube using this method to better show how this works in action. If anyone would be interested in such a thing, let me know.