How do I constrain a puzzle and keep a singular solution?

Question

I am tinkering with a puzzle framework that has the following rules:

In a 6x6 grid of squares, arrange 8 strips of connected squares such that there exists exactly one strip of every length (i.e. a strip of 1 square, 2 squares, etc up to 8). Strips cannot double back/form 2x2 blocks.

I intend for the clues to be endpoints of said strips, without indication of length. The idea being that the solver is trying to pin down path and length together. Giving all endpoints though is over-constrained and makes for fairly easy puzzles. I'm trying to (systematically/programmatically) shave off information to make the puzzle interesting but still have a single solution. Here are some example solutions and their unsolved over-constrained "prompts":

Any guidance, reading, or other direction would be greatly appreciated.

P.S. Don't hold back on the math, I'm here because of a mathematical curiosity.

Answer 1

I thought about this overnight and came up with a seemingly interesting variant:

• You are given two kinds of markers, say A and B.
• Eight A's and seven B's are given in total. One of the A's form a length-1 strip by its own. All the other strips (of lengths 2 to 8) start from one of the remaining A's and end at one of the B's.

Here is a sample puzzle

A A A B . A
A B . . B A
. . B . . .
. B . . . .
. B . A . .
. . . A B .

with a unique solution

1 2 8 3 3 3
4 2 8 8 5 6
4 4 4 8 5 6
7 7 8 8 5 6
7 8 8 5 5 6
7 7 7 7 6 6

It looks pretty challenging to programmatically generate this kind of puzzle while keeping it interesting. A "dumb" way would be to fill the grid first and randomly assign A/B to the endpoints until one with a unique solution is found (which can be done by bruteforcing 40320 possible pairings maybe? Giving up fast will reduce search space a lot I believe).

Answer 2

(No maths or formal rigour here I'm afraid, just some insights from someone who gets a great deal of enjoyment from grid-deduction puzzles.)

The key point for me when designing a grid-deduction puzzle is that I tend to start from the other end.

I have a known solution that I want to reach, and I start with a minimal set of clues that (almost) certainly won't be enough to constrain me to the intended solution. I then try to solve the puzzle and see how far I can get. When I reach an ambiguity, I know where extra clues are required, and can be fairly precise in adding only enough to resolve that sticking point.
It's then a cycle of rinse and repeat, until I have a completely solved puzzle.

For the particular puzzle that you are trying to clue, just pinning the ends of the strips may not give you enough flexibility to clue puzzles that are solvable, but at the same time not too trivial.

You may need to consider some other clue types, and fortunately for this puzzle layout you have several options (the following are just the first few that occurred to me) :

• A number in a square indicating the length of the strip passing through it.
• A known edge between strips.
• Column/row clues outside the grid, giving:
  • The number of distinct segments in that row/column.
  • The sum of the lengths of the strips passing through that row/column.

I tend to do all this by hand, as I find it enjoyable/relaxing; it also gives me a better insight into how hard a puzzle really is, and whether the puzzle will actually be enjoyable or just tedious to solve.
But it would certainly be possible to automate this process of progressive (re)solving, with the gradual addition of extra clues targeted at areas where the grid still has multiple possible solutions.