But there are at most two possible versions of a level, so you can't invalidate your solution like it is possible for modulo.
There is also one level, where only one version can be solved (the other one is already solved, but there are no possible moves and submitting an empty string as solution is not accepted).
Great puzzle!
Seems I have reached difficulty to be almost out of rich of my code. I have no problems to solve the levels manually in few minutes, but the code tooks several hours on them. (I am on 964 now).
I have already implemented generation of pictures of "checkpoints". May be next step would be to make interactive solver ... to let the code search (for example initial task to make worms looped) and allow human interaction ... to make some moves from computed position ... and to let the comp continue from the human reached position ...
Of course I still know about some bugs in the "code in development"... the free space economy still not implemented. Probably even ... arrange worms near to final positions ... before starting final placement ... could help.
Now I have debugged several bugs, may be it helps ... the most important was I decided to use common zobrist codding for the level, but I forgot to remove optimisation reducing number of colors in initialisation
. So several worms were prohibited from moving ... (in a lot of tries).
I have added a pseudomove allowing to change colorshape(either per color component or per color component split) during the search when it improves heuristic distance. That move put me to very deep heuristic hole even on level 123. Without it ... the level 123 was solved so quickly that I have not mentioned it is worth thinking. ... new arguments to implement some kind of free space economy.
I have added "debug print" generating partially solved html where one could continue in manual solving ... I wish there would be challenges solved to see fully working code for these serial puzzles. Now I have to implement interface to continue computing after a manual help.
Finally I was forced to solve knapsack by sizesOfColorWorms instead by worms as huge number of worms of size 6 kicked memory consumption to gigantic size.
Furthermore, I got some solutions rejected by exceeding 10000 moves limit.
I have already implemented generation of pictures of "checkpoints". May be next step would be to make interactive solver ... to let the code search (for example initial task to make worms looped) and allow human interaction ... to make some moves from computed position ... and to let the comp continue from the human reached position ...
Of course I still know about some bugs in the "code in development"... the free space economy still not implemented. Probably even ... arrange worms near to final positions ... before starting final placement ... could help.
Now I have debugged several bugs, may be it helps ... the most important was I decided to use common zobrist codding for the level, but I forgot to remove optimisation reducing number of colors in initialisation
. So several worms were prohibited from moving ... (in a lot of tries).I have added a pseudomove allowing to change colorshape(either per color component or per color component split) during the search when it improves heuristic distance. That move put me to very deep heuristic hole even on level 123. Without it ... the level 123 was solved so quickly that I have not mentioned it is worth thinking. ... new arguments to implement some kind of free space economy.
I have added "debug print" generating partially solved html where one could continue in manual solving ... I wish there would be challenges solved to see fully working code for these serial puzzles. Now I have to implement interface to continue computing after a manual help.
Finally I was forced to solve knapsack by sizesOfColorWorms instead by worms as huge number of worms of size 6 kicked memory consumption to gigantic size.
Furthermore, I got some solutions rejected by exceeding 10000 moves limit.
So finally I am at the end ... there were no levels difficult for humans.
For my code levels with long worms were much easier than levels with a lot of worms.
My final experimental code is still with bugs. Now I would probably not used the algorithm switching strategy. Running two different algorithms in parallel (having enough memory) would probably do better.
(one with almost stupid heuristics interrupted only when the level is solved, the other doing component splits interrupted more often to prevent nonsolvable splits).
From the last two hundred of levels, I solved most by starting by algorithm and finishing by hand.
Only levels with very few worms were solved fast enough by comp. I am not too happy with this.
I have not seen levels where the move is not possible.
(OK there were probbaly levels without move requiring head or looped worm attached to free space).
May be I will debug the code later to be able to solve the series itself ...
.
BTW: I have implemented a bit of space economy just by adding number of free space components to heuristics.
For my code levels with long worms were much easier than levels with a lot of worms.
My final experimental code is still with bugs. Now I would probably not used the algorithm switching strategy. Running two different algorithms in parallel (having enough memory) would probably do better.
(one with almost stupid heuristics interrupted only when the level is solved, the other doing component splits interrupted more often to prevent nonsolvable splits).
From the last two hundred of levels, I solved most by starting by algorithm and finishing by hand.
Only levels with very few worms were solved fast enough by comp. I am not too happy with this.
I have not seen levels where the move is not possible.
(OK there were probbaly levels without move requiring head or looped worm attached to free space).
May be I will debug the code later to be able to solve the series itself ...
.BTW: I have implemented a bit of space economy just by adding number of free space components to heuristics.