cubing / kpuzzle.js Goto Github PK

Put move family smarts in ksolve; bridging alg to kpuzzle.

On 5x5, just for U-D we need:

U 1U 2U 3U 4U 5U
D 1D 2D 3D 4D 5D
u 1u 2u 3u 4u 5u
d 1d 2d 3d 4d 5d
1-1u 1-2u 1-3u 1-4u 1-5u 2-2u 2-3u 2-4u 2-5u 3-3u 3-4u 3-5u 4-4u 4-5u 5-5u
1-1d 1-2d 1-3d 1-4d 1-5d 2-2d 2-3d 2-4d 2-5d 3-3d 3-4d 3-5d 4-4d 4-5d 5-5d
1-1Uw 1-2Uw 1-3Uw 1-4Uw 1-5Uw 2-2Uw 2-3Uw 2-4Uw 2-5Uw 3-3Uw 3-4Uw 3-5Uw 4-4Uw 4-5Uw 5-5Uw
1-1Dw 1-2Dw 1-3Dw 1-4Dw 1-5Dw 2-2Dw 2-3Dw 2-4Dw 2-5Dw 3-3Dw 3-4Dw 3-5Dw 4-4Dw 4-5Dw 5-5Dw

That's 252 total "moves" for the 5x5, and increasing quadratically for
larger nxn puzzles.

Proposal: describe grips and slice moves and let kpuzzle manage combining
slices into these combinations of moves. So at the ksolve level we would
give (for example):

U 2U 3U 2D D

as the only moves for U/D (so a total of 15 moves for the 5x5x5), but also
(using a new API call) tell kpuzzle:

kpuzzle.addGrip("U", "D", 5)

saying there's a grip axis that goes from U to D and has 5 layers. This is
sufficient information for kpuzzle to parse the full collection of moves
above, because it can discover the five independent slice moves from the
ksolve definition, and with the information that the grip goes from U to D
and there are five layers, it can build all the requisite composite moves
on demand as needed. It can synthesize u/Uw block moves, and also do
things like generate a 4U move from a 2D' move.

This does mean that things are not any longer quite as simple as just
passing an svg and ksolve def, except that still works and this is just
extending the functionality to make it "smarter".

And of course I'm willing to write the requisite code.

On puzzles such as the helicopter, move notation is (for instance) FR (for the edge where the front and right face come together). This is equivalent to RF. It would be nice if algorithms can specify either, equivalently.

To support this, the code that resolves the previous issue should be extended to also support implicit families that have the face orders different. As long as the face names are prefix-free, we can add an option that says "setFaceNames(string[])" that sets the face names, and then the code can permit moves to be either RF or FR, for instance.

For vertex-turning puzzles, where three or more faces come together into a vertex, I propose we accept moves with face names only in clockwise order (so on a vertex-turning cube we would support URF and RFU and FUR but not FRU or UFR or RUF.)