How we verified 2,000 sliding-block puzzle boards before release

A solver is only trustworthy if its idea of a move matches the game. In a sliding-block puzzle, a piece may glide until it reaches a wall, another piece or a gate that will not admit its colour. OutBrick adds stateful details too: keys can change gates, ice can take several slides to clear, and generators can introduce queued pieces. Reimplementing a simplified version of those rules for the verifier would leave a gap exactly where a bug could hide.

So the search asks the game’s own rules for legal moves and applies those moves through the same state-transition code used by play. The state key also includes the gate state, and includes a folded move count when cycling or timed gates make that count relevant. Two boards that look alike but have different live gate states must remain different search states.

The solver uses weighted A*. Its ExitTable heuristic asks how many slides each piece would need to reach a fitting exit if the other bricks were taken away. That relaxed board is cheaper to reason about than the real one and gives the search a useful estimate of what remains. Weighting the heuristic more heavily favours finding a clear quickly.

That choice has a limit: the route found is useful, but it is not guaranteed to be the shortest. A search can also stop at its node budget. When that happens the answer is unknown; the solver does not label the board impossible. Only a fully exhausted reachable state space can support a no-clear verdict. Keeping those outcomes distinct prevents a time limit or cancellation from becoming a false claim about the puzzle.

Finding a route is not the final check. For each authored board, we store a witness: the sequence of moves from its initial state to a clear. The replay starts from a fresh game state, checks that the initial state is valid, and applies the witness one move at a time through the real rules. An illegal move fails the replay immediately.

The checker also replays each move from the same before-state and compares the resulting state, events and outcome. This catches transitions that would behave differently when repeated. After each move it checks that every piece remains on a valid board cell and that no two pieces occupy the same cell. At the end, the board must actually be clear. A route that merely looks plausible, or stops with one brick still inside, does not count.

A legal witness proves that a route exists. It does not prove that a person will find it, that it feels fair, or that the board is difficult in the right way. Nor does the solver’s route establish an optimal move count. Those are separate design questions, which is why we treat a full-pack replay as a correctness gate and assess pacing and difficulty separately.

The move limit must also leave room for the board’s verified route. The player can think as long as they need: the limit counts moves, and OutBrick has no clock. That gives the puzzle pressure without turning the validation result into a timer.

The useful release result is not “the solver ran once”. It is that every board in the pack had a witness that replayed cleanly against the rules being shipped. When a rule or a board changes, the pack can be checked again, and the first failing move points to the part of the contract that broke: legality, determinism, board geometry or the final clear.

That is how we checked OutBrick’s 2,000 boards before release. You can try the same kind of sliding puzzle on the free browser board, or download OutBrick for iPhone and iPad.