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.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@6158 cda61777-01e9-0310-a592-d414129be87e

diff --git a/devel.but b/devel.but
index 6435cc2..a717fc2 100644 (file)
--- a/devel.but
+++ b/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.
 
 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
 
 (Unfortunately, Solo is complicated by the need to provide puzzles
 at varying difficulty levels. It's easy enough to generate a puzzle