Visual C# Guide
Floppy Cube Project - Extending The Program
- Output the sequences in groups depending on number of turns, number of flipped edges etc.
- Don't output the sequences after calculating God's algorithm. Instead have a menu system and allow the user to input a cube state. Return the sequence needed to solve, not generate this position.
- Look up how to do regular expressions in C# to see if a string matches a given pattern. Use this to allow you to find ways to generate given patterns (eg all edges flipped, all corners misplaced etc.).
- Generate bitmap output files showing the positions graphically, alongside their solutions. Group them logically into a series of bitmaps.
- Use the program to work out a method for solving the puzzle from any position requiring the least number of sequences to be memorised.
Not all puzzles have such a small number of solutions. Different puzzles have different sets of possible moves and different numbers of unique positions. Some require more processing power and time than your desktop computer can offer. Some are a little easier though.
As you calculate more positions, the execution time of your program can take a dip. You will notice a significant speed difference between debug mode and a compiled executable. It's a good idea to build your solutions before running them - using debug mode when you know you have a problem. It's also worth only calculating to a depth of 3 or 4 and then checking a reliable source to see if you are getting the numbers correct.
The slim tower 2x2x3 puzzle is one such puzzle. If you imagine one of the centre pieces beig fixed and turn only 3 faces (through 90°cw, &90deg;ccw and 180° each face), you can uncover all of the positions. There are a few hundred thousand of them. On the slim tower, the orientation of pieces is determined by their position. There are no parity constraints either.
The Pocket Cube 2x2x2, is a little more complicated. Again, assuming a fixed piece (back left, bottom layer) and turning only 3 faces, you end up with 3.67 million combinations. On this puzzle, the pieces can be twisted in place. Each corner can have one of 3 different orientations and you need to keep track of that. Probably best not to search for the sequences first time - just record the depth.
A pyraminx is a simple puzzle. The tips of the triangles don't really matter to the solution and could be ignored in a search - leaving just under a million positions to uncover.
The bandaged cube is quite complicated but comes down to just over a million positions. There are effectively 8 moving pieces, each piece having 4 of 6 different possible orientations. Not all turns are possible from each position so you need some complicated transition tables and procedures to check whether turns are possible.
The skewb has about 3 million positions and a diameter of 11. It is a classic puzzle and would be an interesting puzzle to solve using only computer searches to guide the way.
Don't Bother With
Exciting as the prospect of completely solving a complicated puzzle can be, there are some puzzles that are just too complicated for a computer to solve in reasonable time. The 3x3x3 rubik's cube is an example of this. It has 43,252,003,274,489,856,000 positions. If you start thinking about the information you would need to store about each position and work out the memory and storage requirements, you'll see the problem. The number of combinations increases, the more pieces there are per face. The 4x4x4 and larger cubes are also some way out of reach.
You could however, look at a smaller range of positions for one of these puzzles.
Make a floppy cube simulator. A lovely GUI for playing around with the puzzle and a button to press to find the quickest solution from a point. You can do this in the console if you look up how to display colour although the algorithm is quick enough that a forms-based program wouldn't be hurt by it.