I'm dating a girl who likes to play on
Neopets (what can I say, I like'em young!), where you can get neopoints (in-game currency) by succeeding in various games. One such game is
Shapeshifter. It looks like this:
The object of the game is to place the various shapes, in order, on the board, so that all the symbols are the goal symbol, as indicated in the diagram with the big red arrows. Each symbol that's under a shape placed on the board gets turned into the next symbol according to, again, the big red arrow diagram.
I think it's fairly self explanatory.
My question is how can one solve this puzzle, efficiently?
It started out as a simple software project that I did for the fun of it, since the puzzle seemed so interesting to me and it's rated as "extremely difficult" by Neopets. My first implementation simply recursed through all possible board positions to find a solution. This worked for a while but, as you solved one puzzle after the other, they gradually become much harder and, subsequently, the program had to run much longer. Eventually, I added a progress bar and a prediction as to when the program will solve the puzzle, since no one likes to wait around without knowing how much longer you'll things will take. In actuality, the program can't really
know how long it will take but it could calculate an upper bound for the time needed and that's what it reported.
Much to my chagrin, it didn't take long before the upper bound time to solution was measured in
years! So, not one to easily give up, I was forced to actually
think about the problem. What will follow is a description of the evolution of my current implementation for solving Shapeshifter. If you'd rather not be told of any of the properties of the puzzle so that you can solve it "entirely by yourself," then don't look into the spoiler tags.
Spoiler:
I brought it up with some friends and one of them, Yakk actually (and why to links penetrate the spoiler tag?), pointed out that the corners could only be reached in one way, and sometimes not even at all! While it was not immediately obvious how this fact can be used to my advantage, it was clearly a restriction of the solution space and, thus, (theoretically) something that can shorten my search time.
After mulling over the problem for a while, other properties of the puzzle occured to me. The order that the shapes are applied is irrelevant. The special properties of the corners can be generalized to all the points on the board. Not every shape can reach every piece. Each board point has certain shapes that can reach it and in a varying number of ways. Finally, each piece needs a specific number number of pieces to solve it. In the case of two symbols (such as the puzzle image used here) a board point that's already the target symbol needs an even number of shapes on it, while another point that's not the target symbol needs an odd number of them.
After these considerations, I concieved of a different algorithm. Inspect the puzzle one board point at a time. Sort them in order of available shape positions on them. For each board point to inspect, iterate over all possible combinations of necessary numbers of shapes that will solve that board point and recurse. Surprisingly, this drastically reduces the number of board positions being evaluated and cuts tree searches off earlier. This reduces time to solutions to within a day, rather than years! Now
that's an optimisation!
Still, a day is a rather long time to wait for a solution. Can't we do better? With a few refinements and some micro-optimisations, I've been able to reduce time to solution to (experimentally, since execution times with algorithms this complex are too hard to calculate accurately) within two or so hours. Not bad but still...
Can we still do better?
So, here I am. I'm almost at my end. There's one last property of the puzzle that I was able discern recently and, thus, one last optimisation I can make but it won't recduce hours to seconds. Spoiler:
If you look at the sheer number of shapes (it gets worse later on), you can see that there are a fair number of shapes on each square. Counting shape squares and dividing by the number of board points, you will see that the number of shapes over each square can average between 2.4 to 3.7 shapes! Seems a little weird to start guessing number of shapes over a (two symbol) square at zero or one, right? Now, the situation is a little more complicated than that because, since the corners and edges are less accessible, the average number of shapes over a board point varies even within the same puzzle board! Luckily, this just makes the situation more advantagous, not less. The corners average about none, while the center squares can have as many as eight shapes over them! That makes it totally ridiculous to start guessing at zero... while at the corners, you'd want to guess the exact number of shapes needed.
But that's it. That's where I am and I'm all out of ideas. If anyone else can think of more that can be done, or if there's a totally foreign appraoch that might do better, please mention it!
Thank you...