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]

1 files changed, 16 insertions, 13 deletions

diff --git a/devel.but b/devel.but
index 6435cc2..a717fc2 100644
--- 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.
 
-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