ertyumpx / hashiwokakero Goto Github PK

There is something wrong with the implementation in PR#6 , needs to be revised.

As it was said in the puzzle rules, there may be more than 1 solutions and puzzle could be still solvable. When the current solver with essential rules applied encounters such a situation, it remains as is.

We can create a second algorithm, that takes the output from current solver, and makes a random move and passes back to the current solver. If the output is not valid, brute force algorithm goes back and makes another move.

This gives room for the solver algorithms to find all possible outcomes as well.

To check if the output is invalid, two information is required:

• if there is any island that has max_out < needed
• if the islands create a non-continues connections

First one is quite easy to check. For the second one, we need to create a function which takes a grid and checks if everything is continues. This function would require a fully solved grid, meaning there is no island that has needed != 0

The first thing comes to mind is always the solver algorithm step count for deciding general difficulty of a puzzle.

From years of personal experience with Hashi, there are other options for determining the difficulty of the puzzle before creating it.

Which are:

1. Having the island count (1-8) lower as possible: Higher island counts create ease for user since 8 has directly gives itself away, 7 cannot have any other bridge be on its way etc.
2. Having the bridge lengths as short as possible: Longer bridges cut of the way of other islands and give them shorter direction options. Therefore lower bridges help the user way less and makes the puzzle more difficult.

To apply these, We need to create a scale for difficulty, add it as an input to the generator.

While creating random island counts and bridge lengths, according to the difficulty, longer bridges will have higher or lower percentage to be selected.

For island counts, as the difficulty is higher, generator algorithm will tend to create newer islands instead of extending the current ones.

While enhancing and advancing the main algorithms, it is essential to make sure that everything works on the track.

We need to create unit tests for both generator, making sure every need is fulfilled, and for solver, to be sure solved and generated solution are the same.

Create a cross-platform window, where the user can solve the puzzle, check if the solution is correct or if there is any wrong bridges.

One thing is, we cannot directly force 1 solution to be true, since there might be more than 1 solutions. We should check give the current grid to the solver and see if it can be solved from there.

For the solver, general rules are applied and working. I'm not exactly sure if it's necessary, but there could be one more rule added to increase the speed and accuracy.

Also it's important that the solver works as much human as possible, so that the iteration count can show the similar difficulty for humans.

Here is the suggested rule:

And island that has count of 2, cannot send double bridge to another island that has count of 2.
And island that has count of 1, cannot send any bridge to another island that has count of 1.

The project must immediately be rewritten in C++ ASAP!

We need to make a script for creating thousands of puzzles and categorise them according to the cycle count of the solver algorithm.

This script could get input of:

• grid width
• grid height
• puzzle count - t
• difficulty

Task parallelisation might help here, collecting "Generate - Solve - Categorise" steps into one function and use multiprocessing on them t times.

Currently we are mapping min & max step count with puzzle grid geometry, with width and height.

We might want to map the step count with island amount instead of geometry; since a grid with 50x50 geometry may at least have 4 islands and step count even be 1 in this case. Using island amount might help us more here.