# Rules for writing a 13x13x13 Move Generator



## unsolved (Feb 14, 2016)

I finished my 5x5x5 program (finally) and now I have a 13x13x13 cube. It's a Tony Fisher original, the 13x13x13 sphere is a cube. Pretty cool looking!

So, of course, I'm making a solving program for it.



There must be a fair number of ways to reduce unnecessary moves in the move generator routine. For example:

*7 moves made on the same rotation axis with 7 moves in the same direction.*

Since there is 1 more than half of the cube slices, the same position can be achieved by moving the other 6 then physically rotating the cube.

Is there a telescoping set of conditions like this for large cubes?

Like 6 moves on the same axis with 5 moves in the same direction; 5 moves on the same axis with 4 in the same direction, etc.

I'm struggling with this for now.


----------



## Lucas Garron (Feb 16, 2016)

I wouldn't overthink this.

At each point, just select a random valid move. If you want to avoid redundant moves on the same axis, either backtrack when necessary or generate moves per axis with weights. Backtracking is easier.


----------



## adimare (Feb 16, 2016)

unsolved said:


> I finished my 5x5x5 program



Neat. Does that mean it can now solve any random position?


----------



## unsolved (Feb 17, 2016)

Lucas Garron said:


> I wouldn't overthink this.
> 
> At each point, just select a random valid move. If you want to avoid redundant moves on the same axis, either backtrack when necessary or generate moves per axis with weights. Backtracking is easier.



Well the problem is, there's 117 moves possible on the 13x13x13 cube. If you are building a move sequences such as:

*3R2 7R2 [more moves...]* you don't want to later generate something like 
*7R2 3R2 [more moves...] *

They'd produce the same cube arrangement at the end.

So, there are some "rules" that are needed when generating moves. Without a complete set of these, the game tree grows fast at a ridiculous rate.


----------

