Visual Basic 2010 (Console) Guide
Pocket Cube - Other Puzzles
The concepts and the method used here can be used for other puzzles too. There is some guidance below based on puzzles for which I have written solving programs.
Whichever puzzle you choose to work with, always check your program's calculations with those on Jaap's Puzzle Page. If you can't produce the same numbers, something is wrong with your program. You will almost certainly need to look at the various algorithms he has in the Computer Puzzling section as well as read the sections of his site on the specific puzzles.
The Rubik's 3x3x3 Cube and some of the other more complex puzzles can't be cracked with this method alone - the tables would be way too large. Jaap describes the main approaches to this task. It's something to work up to.
The puzzle doesn't have a lot of positions. Programs for this run in the blink of an eye. You will need to track the permutations (but not orientations of the corner pieces) as well as the orientation (but not permutation) of the edges. Not all expected positions are reachable on this puzzle but the small number of positions means that you don't need to worry about having indexes twice the size needed. You wil need to modify the orientation index functions to remove the twist constraint.
A pyramorphinx is a shape-modification of a pocket cube. The result is that you have 4 pieces which have no visible orientation. You would need to adapt the pocket cube solver so that it always kept the orientations of these 4 pieces as 0.
There are a lot of positions on this puzzle but they are all permutations, 11! to be precise - you keep piece number 12 still. The pieces do turn upside down but are always correctly oriented when in their home position.
For the slim tower, there are no orientations to track, pieces are oriented if in their home positions. The top and bottom layer pieces can be tracked as one group of 8. I then track the 3 pieces of the middle layer unaffected by moves F, R, U & D and allow only those moves.
There are a lot of positions here. The corners and edges need are two groups of pieces - no orientations to be concerned with. To fix the puzzle in space, you have to use moves that don't change the position of one of the pieces. Otherwise your tables are many times the size. Following Jaap's advice, I go with an index for the permutation of the corners, one for the permutation of the edges and another 0 or 1 index to keep track of whether the centres are swapped. To keep the back bottom corner piece still use F, R & U moves. You will also need Rw (right and middle layers together) as well as Fw. Single turns are only allowed on the upper face. It's not too tricky to write a program to convert sequences with these funny moves into 'normal' ones.
The original Rubik's Cheese is a pretty simple puzzle, but nigh on impossible to find. There is a 2-layer version and the solution to that can be found using a similar approach to the puck puzzle and defining clearly what you mean by solved.
There's a fair bit going on with a pyraminx. You can ignore the tips of the puzzle completely. You then have 4 vertex pieces which can have one of 3 orientations with all orientations possible (ie no twist constraint). After that there are 6 edge pieces. These can only be in even permutations (Jaap's site for the pseudocode). These pieces have 2 orientations and the total twist is 0 mod 2. Working out how the turns twist the edges might be easier for you than me. Thanks to Jaap for his help in understanding this.
Bicube Bandaged Cube
The bandaged cube is quite a challenge to solve, let along program. It's also another case where advice from experts really helps. I am indebted to Jaap for pointing out that you need only keep track of the position and orientation of the corner-edge pieces - the orientation of the centre-edge pieces doesn't need to be tracked. The orientation of the corner-edge pieces in the face you want to turn let you know whether the turn is possible. For this puzzle, I store permutations as normal. Each corner has 3 directions in which a corner-edge piece can be pointing. I map the usual 0, 1 & 2 onto these. You need an extra function to determine whether a move is possible (from orientation).
If you stick to the 180° turns then you have a chance with this puzzle. Using partial solvers can give you everything you need to calculate a reasonable method for the puzzle. Here are screenshots of mine,
This program deals only with the top layer. There are 4 corners for which permutation and orientation are tracked - the same way as with a pocket cube. The centres on this puzzle are in fixed orbits. In the top layer, there are 4 groups of centres. If you calculate an index for the permutation of each group and write those numbers in order, what you have is the equivalent of 4 pieces, each with 6 possible orientations. You can index that orientation without any twist constraints to make a more manageable program.
The screenshot also shows the visuals. This is what you get if you folded up the stickers on the sides of the cube to make the whole thing flat. Doing this can be a real help to test that pieces are going to the right places when you make a move.
This program was adapted from the first with some time wasted on making a still-life 3D representation.
For this program, there are only 3 possible moves - allowing 3 adjacent moves around the corner gave much better algorithms.