mirror of
git://git.tartarus.org/simon/puzzles.git
synced 2025-04-21 08:01:30 -07:00
Slant uses the same generation strategy as Solo, despite not having
the property which devel.but claimed to be the reason why that strategy works. A bit of thought revealed what the _real_ reason is why this strategy works in some puzzles and not others, so I've rewritten the paragraph to be more accurate. [originally from svn r6158]
This commit is contained in:
29
devel.but
29
devel.but
@ -3293,19 +3293,22 @@ is next to a three}, which can depend on the values of up to 32 of
|
||||
the 56 squares in the default setting!), so this tweaking strategy
|
||||
would be rather less likely to work well.
|
||||
|
||||
A more specialised strategy is that used in Solo. Solo has the
|
||||
unusual property that the clues (information provided at the
|
||||
beginning of the puzzle) and the solution (information the user is
|
||||
required to fill in) are inherently interchangeable; therefore a
|
||||
simple generation technique is to leave the decision of which
|
||||
numbers are clues until the last minute. Solo works by first
|
||||
generating a random \e{filled} grid, and then gradually removing
|
||||
numbers for as long as the solver reports that it's still soluble.
|
||||
Unlike the methods described above, this technique \e{cannot} fail
|
||||
\dash once you've got a filled grid, nothing can stop you from being
|
||||
able to convert it into a viable puzzle. However, it wouldn't even
|
||||
be meaningful to apply this technique to (say) Pattern, in which the
|
||||
clues and the solution occupy completely different spaces.
|
||||
A more specialised strategy is that used in Solo and Slant. These
|
||||
puzzles have the property that they derive their difficulty from not
|
||||
presenting all the available clues. (In Solo's case, if all the
|
||||
possible clues were provided then the puzzle would already be
|
||||
solved; in Slant it would still require user action to fill in the
|
||||
lines, but it would present no challenge at all). Therefore, a
|
||||
simple generation technique is to leave the decision of which clues
|
||||
to provide until the last minute. In other words, first generate a
|
||||
random \e{filled} grid with all possible clues present, and then
|
||||
gradually remove clues for as long as the solver reports that it's
|
||||
still soluble. Unlike the methods described above, this technique
|
||||
\e{cannot} fail \dash once you've got a filled grid, nothing can
|
||||
stop you from being able to convert it into a viable puzzle.
|
||||
However, it wouldn't even be meaningful to apply this technique to
|
||||
(say) Pattern, in which clues can never be left out, so the only way
|
||||
to affect the set of clues is by altering the solution.
|
||||
|
||||
(Unfortunately, Solo is complicated by the need to provide puzzles
|
||||
at varying difficulty levels. It's easy enough to generate a puzzle
|
||||
|
Reference in New Issue
Block a user