How we prove a board is fair before you see it

The failure nobody can see

A puzzle generator that produces an impossible board has failed in the worst available way, because nothing about the board announces it. The player works, gets stuck, and concludes the fault is theirs. They cannot tell the difference between a puzzle that is hard and a puzzle that is broken, and neither can we by looking.

Two puzzles here are especially easy to get wrong. Randomising sliding tiles produces an unsolvable board half the time. Randomising Lights Out cells produces an unsolvable board for most arrangements on a five by five grid. In both cases the naive generator is one line of code and looks perfectly reasonable.

Sudoku: count the solutions, then remove

The dealer works backwards. It fills a complete valid grid first, using a randomised search that backtracks whenever it paints itself into a corner. A finished grid is easy to produce and, importantly, is certainly consistent.

Then it removes digits one at a time. Before each removal is accepted, it runs a solver that counts solutions and stops as soon as it finds a second one. If a second solution exists, the digit goes back and the dealer tries a different cell.

This is why difficulty settings here are described as roughly a number of givens rather than exactly one. The dealer removes as much as it can while the uniqueness proof holds, and where it stops depends on the grid. A promise of exactly twenty-five givens would require abandoning the proof, and the proof is the more valuable of the two.

Sliding tiles and Lights Out: build it backwards

For these two the generator does not check the board at all. It builds boards that cannot be broken, by constructing them out of the moves the player will use.

The sliding puzzle begins solved and makes a long sequence of legal slides. The proof is immediate: reverse the sequence and the board is solved again. There is no parity test to implement and therefore no parity test to get wrong.

Lights Out begins with every light off and presses a random selection of cells. Since a press is its own inverse — pressing twice returns things exactly as they were — pressing that same selection again clears the board.

This approach has a second benefit: the number of moves used becomes an honest difficulty control. A twelve-press Lights Out board is genuinely harder than a four-press one, in a way that cannot accidentally tip over into impossible.

Sokoban: solve it by machine first

Crate levels cannot be generated backwards, because pushes are not reversible — you can pull a crate in reverse but the player's position makes the reversal invalid in general. And they cannot practically be generated at random, because almost every random arrangement is dead on arrival.

So our twelve levels are drawn by hand and then verified by a separate program. It performs a breadth-first search over crate arrangements, discarding any position where a crate has become permanently stuck, and reports whether the marks can all be filled and the fewest pushes required. All twelve pass, and their minimum push counts are known.

Word Search is checked similarly but far more cheaply: the placer refuses any word that would conflict with letters already on the grid, and a word that cannot be placed after a number of attempts causes the whole grid to be discarded and redrawn. That is why the list you get always matches the grid you get.

Nonograms need no check at all, because of the order of work: the picture is drawn first and the clues are computed from it. A clue set derived from an actual image always describes at least that image. Our pictures are also designed so the intended drawing is the only one the clues allow.

The randomness itself has to be right

Two smaller details, both easy to get wrong and both invisible in the output.

The source. We use the browser's cryptographic random generator rather than the ordinary one. Not for security — there is nothing here to attack — but because it has no visible structure. Simpler generators can produce faint patterns, and a puzzle site is exactly the kind of place where a player would eventually notice.

The range reduction. Turning a random number into “a number from one to nine” with a remainder operation introduces a small bias, because the range rarely divides evenly. Low values come up marginally more often. Our helper discards draws that fall in the uneven tail and asks for another instead of folding them back in. The bias would be tiny and it would also be real, and discarding is a few characters of code.

The same helper does the shuffling, using a standard algorithm that gives every ordering equal probability. The obvious wrong version of a shuffle — swapping each item with any random position — does not, and produces detectably uneven results.

What we do not claim

Two limits are worth stating plainly, because a page about proofs should be clear about where the proofs stop.

Minesweeper can force you to guess. No generator fixes this; it is inherent to the game. Some implementations reshuffle the board when a guess would be needed, which changes the puzzle into a different one. We do not, and we wrote a guide on guessing well instead. The first click is always safe, which is the one guarantee available.

Solvable is not the same as fair. We can prove a Sokoban level has an answer. We cannot prove a person will enjoy finding it. Every difficulty label and completion time on this site is an estimate from our own play, and is labelled as one wherever it appears.

All of the above happens on your own device, in the fraction of a second between asking for a puzzle and getting one. Nothing is fetched from a server and nothing was prepared in advance, so every guarantee described here is being made fresh for the board in front of you.