print all possible paths to a value. The latter has a lot of
de-duplication left to be done, due to multiple evaluation orders.
[originally from svn r8061]
(require both main diagonals to have one of every digit in addition
to all the usual constraints) and Jigsaw Sudoku (replace the array
of rectangular sub-blocks with the sub-blocks being random
polyominoes). To implement the latter, I've moved my `divvy.c'
library routine out of the `unfinished' subdirectory.
Jigsaw mode is currently an undocumented feature: you enable it by
setting the rows parameter to 1 (and the columns parameter to your
desired grid size, which unlike normal Sudoku can be anything you
like including a prime number). The reason it's undocumented is
because generation times are not yet reliably short: sometimes
generating a jigsaw-type puzzle can hang for hours and still get
nowhere. (The algorithm should terminate in principle, but not in
any time you're prepared to wait.) I _think_ I know how to solve
this, but have yet to try it. Until then, jigsaw mode will remain a
hidden feature.
Printing of X-type puzzles is also substandard at present, because
the current print-colour API replaces the desired light shading of
the X-cells with heavy diagonal hatching. I plan to adjust the API
imminently to address this.
[originally from svn r7974]
connected polyominoes actually causes a loss of generality for
sufficiently large k. I hadn't previously noticed, because you need
k to be (I think) at least 23 and none of my potential applications
require anything nearly that large. Add some discussion of this.
[originally from svn r7701]
works, but it's slow, and the puzzles are currently at a relatively
low level of difficulty. Also this is a generator only: no UI yet
(because I'm waiting to see if I can make the generator practical
before bothering to write the rest).
[originally from svn r7700]
arbitrary unclaimed square. This cures the most common cause of
generation failures (covering a large area in dominoes was the most
difficult case, and would fail even if the large area was 1xn!); the
failure rate is now sufficiently low under all circumstances I've
found that I'm willing to just loop until I get a success.
[originally from svn r7693]
rectangle into equally sized ominoes. I have a couple of potential
applications for this, but none I've actually implemented yet, so
for the moment it's living in `unfinished'.
[originally from svn r7690]
several different systems in strange directories. So I'm creating an
`unfinished' directory within source control, and centralising all
my half-finished, half-baked or otherwise half-arsed puzzle
implementations into it. Herewith Sokoban (playable but rubbish
generation), Pearl (Masyu - rubbish generation and nothing else),
Path (Number Link - rubbish generation and nothing else) and NumGame
(the Countdown numbers game - currently just a solver and not even a
generator yet).
[originally from svn r6883]
