More on FLTK glpuzzle logic

There is a complete structure of nodes and the way that the solution is found is by using a back pointer. Once the solution is identified, it takes its back pointer and marks it as a solution pointer. All possible moves up to that point are mapped, but for any set of moves from a specific game position, only one will lead to a solution.

The second part of this is how the list of nodes is generated and that could be depth first and so would identify many dead ends and loops as they happened.

I used the debian diagram editor to demonstrate the relationships. Here the moves 1,2,4 are all different moves from the same puzzle condition. Move 3 is from puzzle condition 2 and was not a solution and thus the back pointer is unused. The move numbers indicate in which order they are checked and have nothing to do with their dependency.

Strangely, once I discovered how the game worked it is exactly as I imagined that I would program it without looking at the code. There is a list of puzzles that are generated and each is walked until a solution is found. In this case there are 80 free paths that result in potential solutions and I assume if I keep running it, that it will generate all paths and I can go back and find the valid multiple solutions from the back pointers.

So that does work and tomorrow I can add the graph with colors for dead ends and loops and cross-links and solve paths. Which brings up an interesting thought. Of course I could map any point to any other point as it is based on valid moves. I suppose a stat that I could generate is the farthest path between 2 nodes and the range of distances to solutions.

solvePuzzle number of elements is 24780 and poss= 152

That is horrible. I thought there were a couple more ways to solve and there are 152 different ways. The picture is #152. That is just so bad. I still haven't answered why I would assume that the tree was vastly smaller. I guess it is just the same as everybody, assumptions and ignorance. Now I need to see where these are located and the length of the paths. I guess I ignored the positions that didn't make a lot of difference and so there are only really a dozen truly different solutions. That makes me feel a bit better. I guess there really aren't that many unique solutions. There are many states where it is solved and the other pieces are moved about, but they are not states that move from unsolved to solved. That is the next analysis.

115 moves to path number 2 at 23943 !
115 moves to path number 3 at 23982 !
115 moves to path number 6 at 24075 !
117 moves to path number 8 at 24112 !
46 moves to path number 69 at 24674 !
46 moves to path number 71 at 24682 !
22 moves to path number 77 at 24695 !
22 moves to path number 80 at 24701 !
solvePuzzle number of elements is 24780 and poss= 152

So there are really only 8 truly unique solution paths and the others are puzzles that are already solved and have pieces moved about without affecting the solution. So I feel even better about what I thought. I did miss one major branch, and its mirror image, but that does tell me something. In looking at the problem I failed to wander back far enough to see a branch as it seemed to be less and less likely. I suppose that is that hidden valley issue of stable states.

I now have the procedures to display the data, but I am considering a cave like structure or maybe a strange mountain range with tunnels and colors.

115 from 0 - path 1 at 23903 length 115 intersect 0 116
114 from 3 - path 2 at 23943 length 117 intersect 1 116
115 from 4 - path 6 at 24075 length 119 intersect 1 118
117 from 0 - path 8 at 24112 length 117 intersect 0 118
46 from 90 - path 69 at 24674 length 136 intersect 1 135
46 from 90 - path 71 at 24682 length 136 intersect 2 135
22 from 116 - path 77 at 24695 length 138 intersect 69 137
22 from 116 - path 80 at 24701 length 138 intersect 71 137
solvePuzzle number of elements is 24780 and poss= 152

This is quite odd and there seems to be a path that is 47. This does have something to solution for Rubik's cube also and so I may extend it for that. Presently I have a good layout for the data and will implement moves of a specific piece type as a dimension. This is more realistic and so there are really 8 solutions in two categories and perhaps I was right about seeing the entire tree in my head. Its always iffy with the mind.