Sadly I've played sgt-puzzles too much so that my favourite puzzles
doesn't feel difficult enough at lower levels/sizes, so I've used
custom settings on those to scale them up. Sadly I've noticed that it
seems to freeze more often on startup the bigger puzzle you've make; For
example `galaxies 25x15du` freezes ⅔ or starts for me, and for `galaxies
25x15du` it freezes ⅘ times for me.

Usually though `loopy 40x20t2` works; `bridges 65x25m2` works all the
time, but `bridges 35x25m4` seldom works (also notice you can't set hard
there from cmd line, but that's an other bug).

This is odd.  I will forward this to the author.

For 'bridges', difficulty must be specified as a number, not a letter.
(I have no idea why this is not consistent across puzzles.)

Ben.

Simon,

It does seem like the time taken to generate puzzles for some of the
given settings is at least very variable.  Is it possible that certain
seed values could result in infinite loops?  I can't think why that
would happen.

Ben.

Ben Hutchings <ben@decadent.org.uk> wrote:

There shouldn't be any cause for a literally _infinite_ loop, no; if
anybody can prove otherwise, I'll certainly treat it as a bug
needing to be fixed.

Of course many of the puzzle generators, if you dial them up to big
enough grids, will take time which is theoretically finite but in
practice too long to wait for. But more subtly than that, yes, it is
perfectly possible that generation time for some sizes of some
puzzles can be very variable.

The typical process of generation is to invent part of a puzzle at
random, run a solver (perhaps repeatedly) to check its solubility
while refining the clue set and/or solution to converge on a
uniquely soluble puzzle of the right difficulty, and then encode it.
Sometimes the randomly invented puzzle at the start of that process
happens to be such that the next phase has to spend a lot of time
tweaking and may not get anywhere, but sometimes it comes out right
first time.

My general editorial criterion is that the _preset_ puzzle settings
should generally give reasonable generation times; if you ask for
settings significantly outside that range, they'll still make their
best effort to return games for you, but I don't attempt to
guarantee anything about their efficiency.

It is possible that some of the generators might be improved by
being a little less persistent. 5x5 Solo, for example, used to be
very hit-and-miss: sometimes it was able to generate a puzzle
immediately, but sometimes it would sit there and think (for
practical purposes) indefinitely, depending on whether the initial
recursive function that constructs a filled valid Sudoku grid
happened to recurse into a large dead end or luckily went straight
to a plausible arrangement. This problem was even worse when I
introduced jigsaw mode, so I came up with r7978 - the filled-grid
generator has limited time to come up with an answer, and otherwise
is guillotined and told to start again. This turned out to work much
better, since the length of time taken to negotiate a dead end was
much larger than the time needed to keep restarting the generator
until it didn't get into one in the first place; so now 5x5 Solo
grids are generated much more reliably. So it's possible that other
puzzles would benefit from similar work, but a comprehensive review
of that nature is a long way from the top of my list. Competent
assistance welcome!

Cheers,
Simon

I rediscovered this bug while waiting for a 150x150 'galaxies' board, which
has had a CPU  maxed out for the last hour.  (Still going... didn't want to
play it so much as see what it'd look like.)

It would be better to progressively warn the user if the generation process
was expected to take longer than than 10 seconds, 1 minute, 10 minutes, an
hour, days...  assuming it's possible to know that.

Some kind of progress meter would be helpful, to tell the user the
program hasn't hung, perhaps with a time prediction, if feasible.

HTH...

The generators produce candidate configurations at random and then check
that they are solvable and have the correct difficulty (difficulty
affects which deduction rules have to be used).  In some cases, they
will refine unsolvable candidates in order to make them solvable; in
other cases they will generate new configurations.

It's just not possible to tell how far this has progressed or how long
it will take.

Ben.

Based on that description, it sounds like it might be feasible to show
how it's getting along.  It wouldn't be prediction, but it would allow users
to see what they're waiting on.  A window would pop up, and display:

	Generating random candidate of X*Y squares at normal difficulty.  1st try...

Done.  Now:

	Is it solvable at normal difficulty?  Testing...

...suppose it fails:

	Too difficult.  Try again.

...then:

	Generating random candidate of X*Y squares at normal difficulty.  2nd try...

...suppose that fails:

	Unsolvable.  Try again.

Etc.  Other messages might go by, "Unsovable, trying to refine it to solvable...", et al.
At the end, it might beep and show:

	Done.  After N minutes and 3 tries, a X*Y square normal difficulty puzzle found.
	Press OK, or wait 30 seconds.

It would help to log this to some hidden local file.  Later the log
might be optionally uploaded and averaged with other user logs.

After a certain length of time, or number of tries, the prompt might
offer to give up.

Once there's data on how long things take, a "give up" prompt could be
offered immediately:

	Are you sure you want to generate a 300x300 grid game?  Doing so can
	take several weeks.

HTH...

Dear Maintainer,
also note that pearl 5x5 tricky with allow unsoluble unchecked also goes out to
lunch.