How Puzzle Designers Prove a Level Is Solvable Before You Play

The Short Answer

Puzzle designers prove a level is solvable by finding at least one complete, rule-following path from its starting state to its goal. That path may be created by hand, discovered by an automated solver, guaranteed through reverse construction, or confirmed with mathematical constraints. Afterward, playtesting determines whether the solution is understandable, fair, and enjoyable.

What “Solvable” Really Means

A puzzle is solvable when at least one legal sequence of actions reaches its intended goal. In a maze, that may mean walking from the entrance to the exit. In Sudoku, it means filling every cell without breaking a rule. In a block-pushing game, it could mean placing every crate on a target.

The important word is legal. A level is not proven solvable if the designer reaches the exit using a developer shortcut, ignores a locked door, or moves an object in a way players cannot. The successful route must obey exactly the same rules that apply during normal play.

In mathematical language, finding one valid route is a constructive proof: the solution itself demonstrates that the level can be completed. However, this only proves that a solution exists under the tested version of the rules. Designers must also check that the game’s actual code behaves like the model used to test it.

Building the Puzzle Around an Answer

One of the safest design methods is to create the solution first and build the puzzle around it. A designer might begin with a planned chain of events:

1. Move the red block away from the wall.
2. Use it to hold down a pressure plate.
3. Walk through the newly opened door.
4. Push the blue block onto its target.
5. Return and reposition the red block.
6. Reach the exit.

The designer then arranges the room so that these actions are possible while hiding the sequence behind obstacles, choices, and visual misdirection. Because the intended route was part of the construction process, the designer already possesses evidence that the level is solvable.

The challenge is making that route discoverable without making it obvious. This connects to the idea of an invisible tutorial that teaches through level design. Objects, walls, colors, and safe experiments can quietly teach the player how the puzzle works.

Designing around an answer does not guarantee a perfect level. Adding one decorative wall or changing when a door closes can accidentally break the planned solution. Designers therefore retest the puzzle whenever its layout or rules change.

Working Backward from the Solved State

Some puzzles can be generated in reverse. The designer or computer begins with everything correctly placed, then performs legal backward steps to produce the starting position.

Imagine a tile puzzle in which every move can be reversed. Starting with the completed picture, the game makes hundreds of valid random moves. The resulting board may look thoroughly scrambled, but it remains solvable: reversing those moves will restore the completed picture.

This method works especially well when every scrambling action has a reliable inverse. It is less straightforward in games with one-way doors, consumable keys, collapsing floors, or crates that can be pushed but not pulled. In those systems, a backward action may not represent something the player can legally undo.

Reverse construction also proves existence, not quality. A board might technically be solvable but require thousands of dull moves. It might even return to the solution through a much shorter route than the one used to scramble it. Designers still need additional tests for difficulty and interest.

Letting a Computer Search Every Possibility

For many digital puzzles, the game state can be described precisely: where the player stands, where objects are located, which doors are open, and which resources remain. Each legal move creates a new state.

Together, these states form a network—often called a state graph:

• Each state is a point in the network.
• Each legal action creates a connection to another state.
• The starting position is the first point.
• Any completed position is a goal point.

An automated solver explores this network until it finds a goal. Breadth-first search can examine states by distance from the start, which makes it useful for finding a solution with the fewest moves when every move has the same cost. Other techniques, including depth-first search and A*, may be more suitable depending on the puzzle’s structure.

If the solver produces a sequence such as “up, left, push, down, right,” the designer can replay it inside the game. That recorded sequence is a direct solvability certificate.

For a finite puzzle, a correct exhaustive solver can also show that no solution exists by exploring every reachable state without finding a goal. The difficult part is efficiency: a puzzle with only a few choices per turn may still produce millions of possible states after a long sequence of moves.

Using Constraints Instead of Simulating Moves

Not every puzzle needs to be tested as a journey through physical states. Logic puzzles are often represented as collections of variables and constraints.

In Sudoku, for example, each empty cell is a variable whose possible values are the numbers 1 through 9. The rules become constraints: values cannot repeat within a row, column, or box. A constraint solver removes impossible values, follows logical consequences, and searches remaining possibilities.

Google’s introduction to solving constraint-programming problems demonstrates the basic pattern: define variables, state the restrictions, and ask a solver to find an assignment satisfying them.

Constraint tools can answer several valuable questions:

• Does at least one solution exist?
• Does more than one solution exist?
• Which clues are essential?
• Can the puzzle be completed within a move limit?
• Is a particular answer forced by the rules?

Uniqueness is especially important in number and deduction puzzles. If two different completed grids satisfy every clue, the puzzle may be solvable but still ambiguous. Researchers have used constraint satisfaction to generate logic puzzles with unique solutions, selected difficulty levels, and solutions based on inference rather than unsupported guessing.

Generate, Test, Reject, Repeat

Procedurally generated games may create enormous numbers of levels automatically. A common approach is generate and test:

1. Create a candidate level.
2. Give it to an automated solver.
3. Keep it if the solver finds a valid solution.
4. Reject or modify it if no solution is found.
5. Measure other qualities, such as length, difficulty, or variety.

Researchers have demonstrated this idea in Sokoban-style block-pushing puzzles using simulated gameplay and search. One published system used Monte Carlo Tree Search to generate puzzles while guaranteeing that its accepted levels were solvable. It also evaluated features associated with how difficult players found those puzzles.

Another technique is to generate a solution path first and then construct the level around it. This can avoid wasting time on large numbers of impossible boards. Hybrid systems may combine both methods, creating a guaranteed route before using a solver to look for errors and alternative solutions.

Solvable Does Not Mean Fair

A computer can confirm that a solution exists without proving that ordinary players have a reasonable chance of discovering it.

A puzzle might be technically solvable but require:

• Clicking an object that appears decorative.
• Remembering a tiny clue shown hours earlier.
• Performing a long sequence with no visible feedback.
• Guessing between identical-looking choices.
• Avoiding a permanent dead end that is not clearly communicated.
• Using an unintended physics trick.

This is why automated proof is followed by human playtesting. Designers observe what players notice, which strategies they attempt, where they hesitate, and whether they understand why an action succeeds or fails. Completion times, resets, abandoned attempts, and repeated mistakes can help identify confusing moments, but these measurements require interpretation.

The Puzzles Arcade guide to how playtesting makes puzzle games feel fair explores how designers use observation and player behavior to distinguish satisfying difficulty from unclear communication.

Checking for Dead Ends and Unintended Solutions

Designers do not stop after finding the intended answer. They also try to break the level.

A deadlock or softlock is a state from which the goal can no longer be reached, even though play may continue. Pushing a crate into a useless corner is a classic example. Designers may prevent such moves, warn the player, provide an undo system, or make restarting quick and painless.

An undo button gives players safe second chances while preserving the reasoning required to discover the solution. It is particularly helpful when one legal move can quietly make a puzzle unwinnable.

The opposite problem is an unintended shortcut. A player might bypass the main idea by stacking objects, slipping around a barrier, exploiting enemy behavior, or solving clues in an unexpected order. Some alternative solutions are delightful and worth keeping. Others erase the lesson or challenge the level was designed to provide.

Automated solvers can help by finding shortest solutions or listing multiple routes. Human testers remain essential because they are skilled at interpreting visual hints, misunderstanding instructions, experimenting creatively, and doing things the designer never expected.

The Proof Behind the “Aha!” Moment

Before a puzzle reaches you, it may have been solved thousands of times—by its creator, testing tools, automated agents, quality-assurance teams, and playtesters. Each method answers a different question.

A planned route proves that an intended solution exists. Search algorithms verify reachable paths. Constraint solvers check logical consistency and uniqueness. Reverse generation preserves a route to the goal. Playtesting reveals whether real people can understand and enjoy the challenge.

That invisible preparation creates one of the best feelings in puzzle solving: the moment an impossible-looking level suddenly makes sense. The solution was there all along, carefully proven before you ever made your first move.