Every 15-puzzle implementation eventually hits the same quiet question: given a starting arrangement, can the player ever reach the goal? The answer is not obvious. Random shuffles fail roughly half the time, and a permissive build that lets the player play an unsolvable board wastes the user's evening. A strict gate that blocks too many starts kills engagement. Engineers building or integrating a sliding-tile game need a clear, testable rule, plus a way to debug it when their version disagrees with a reference solver.
This piece walks through the parity math behind the classic sliding puzzle, the edge cases that bite production code, and a short checklist you can drop into a code review. It is written for engineers, not for casual players — if you want the gameplay walkthrough, rules, and winning tips, the 15 puzzle rules and winning tips guide covers that side of the topic.
The Two-State Rule Most Codebases Get Wrong
The puzzle's state space splits cleanly into two connected components. From any reachable configuration, the parity of the permutation combined with the row of the blank tile determines which component the configuration lives in. The standard formulation:
Count the number of inversions — pairs (i, j) with i < j and value[i] > value[j], treating the blank as value 16 and ignoring it when it occupies a tile position.
