Advertisement

2d and 3d puzzle solvers

Started by November 10, 2007 06:21 AM
27 comments, last by kirkd 17 years, 3 months ago
Thanks everyone, It's going to be a bit of work for me to understand everything here. I'll take my time to try to figure it all out.

I decided to go with Rockoon1's suggestion and go with 6 arrays for the cube.

My test bed is in command line c++. It took me a while to write out all the transformations, but I think I figured it all out.

Here is what I got so far.
cube_test_01 2d test, with my cube display. Most of my transformations use a 2d rotation somewhere.
cube_test_02 Rotate face.
cube_test_03 Rotate top row.
cube_test_05 Rotate right column up with different display.
cube_test_06 Same as the last one, normal display.
cube_test_07 Grid, from rotating the middle slice on each axis.

I got the rotations currently in 3 functions.
rotateFaceClockwise(int slice)rotateTopRowLeft(int slice)rotateRightColUp(int slice)
I just tell it which of the 3 slices I want when I turn. Currently these rotations only work in one direction, so If I want to rotate right instead of left, I gotta use the turn left three times method. XD For now it gets the job done.

Now I just got the hard part of telling it how to solve.
Now that you have them all working clockwise, it would be very simple to make them all work counter-clockwise. Either way you're next major step is a solver. I look forward to hearing about your results.

-Kirk

Advertisement
Quote:
Original post by Rockoon1

Or more simply:

bd - 1
------ = n
b - 1


How is that more simple than bd?
You can do better than manhattan distance for sliding tile puzzles under some circumstances.

The most obvious optimization is detecting when two tiles are next to each other and need to be swapped to end up in the right place. In that case the manhattan distance will be 1 for each tile where you really need to move them much further to complete it. Unfortunately I'm not sure of the biggest value you can give them while leaving the heuristic as admissible, but it's obviously at least 2. It shouldn't be too hard to work it out though.
I'm a little stumped right now, I'm having troubles figuring out how to locate a piece on the cube. Since I'm storing everything as a bunch of 2d arrays, They don't have any real relation to what pieces are connected.

Cube

So I need a lookup function, a way to identify a piece I'm looking for. Say I want to find the Red and White side cubie, I need a function to spit out faces 41 and 10 and have it tell me where they are located in my data array.

//How my cube is storedint data[3][3][6];for (z=0;z<6;z++) for (y=0;y<3;y++) for (x=0;x<3;x++)  data[x][y][z] = i++;//How my colors are formedint color = int(value/9);//How the Z dimensions are laid out.//_ 4//0 1 2 3//_ 5

Once I can locate these cubies I can begin to move these little guys around to where they belong. Anyway, I'll keep trying. I think I might start by numbering all the cubies.
Quote:
Original post by Timkin
Quote:
Original post by Rockoon1

Or more simply:

bd - 1
------ = n
b - 1


How is that more simple than bd?


bd doesnt give the answer desired..

..you gave the summation formula Σi=0d-1bi which does give the answer desired...

..my formula replaces the summation with a direct calculation .. much simpler, yes?

Advertisement
Except that I used the symbol n to mean the number of leaf nodes, not the number of nodes in the tree... hence my questioning why you felt it was simpler than bd. If you had meant that n was to now represent the number of nodes in the tree, you should have said so to avoid the confusion. ;)

Regards,

Timkin
Quote:
Original post by Timkin
Except that I used the symbol n to mean the number of leaf nodes, not the number of nodes in the tree... hence my questioning why you felt it was simpler than bd. If you had meant that n was to now represent the number of nodes in the tree, you should have said so to avoid the confusion. ;)

Regards,

Timkin


I felt that it was self-evident since bd is a term in the expression

Yes, representation of the cube and individual cubies is a bit tricky. The first time I did this I used six arrays like you've done. This does fine for the simple manipulations and displaying the details, but it can become difficult to do things such as determine the orientation of a particular cubie.

I switched to a different representation in which I have two vectors, one for the edge cubies (two faces) and one for the corner cubies. Each element of the vector represents a particular cubie and holds it position in the cube (numbered like you've done) and its orientation. Corner can be oriented neutrally, rotated clockwise, or rotated counter-clockwise, and edges can be neutral or flipped. This get tricky also in that you have to define what is "neutral." For the corners I defined neutral as having the top/down face oriented either top or down and then rotations from there.

Too much detail, I'm sure. Regardless, getting the right representation is probably more a matter of finding one that works for you. All representations will have their idiosyncrasies.

-Kirk

This topic is closed to new replies.

Advertisement