The need to attempt solutions and revert to a previous state to solve a puzzle.
Backtracking is required in puzzles that do not have enough information to solve in advance. A player is required to attempt a solution, discover it doesn't work, then undo part of their solution to try another.
The clearest example of backtracking is finding a path through a labyrinth. Without any information on which direction to go at each branch, a player is forced to try one at random, then go back to it if they reach a dead-end.
Examples: - Crate Treasure - This labyrinth puzzle limits the information it provides to require the player to try multiple paths.
Backtracking can be an intentional part of puzzle design. The designer creates a puzzle with a series of possibilities, but does not provide enough information on which one to choose.
It's important when using backtracking as a design element that it's easy for the player to verify their solution. This is the final phase of puzzle solving, where a player checks if they have the right answer. This can apply to a partial solution along the way, so the player doesn't have to find a complete solution. For example, if a player may not cross an obstacle in a maze, encountering that obstacle is enough to rule out a path — there is no need to find the exit from that point.
Though usually a form of work, backtracking can also be used as rule deduction. The player can test their intrepretations of the rules by applying them. Whenever they find an inconsistency they can alter their solution by altering one of the rules. In this sense, the player is backtracking in the rule space, as opposed to the solution space.
Players with incomplete information about a puzzle may also use backtracking to solve the puzzle. This can be used to reduce a brute force approach to a much more manageable number of possibilities.
Backtracking specifically refers to partially unwinding a solution, avoiding the need to start from the beginning each time. If the player has to, or chooses to, redo all of their work, it's no long backracking, but merely a straight forward iterative process. A player subjected to repeated work can quickly become frustrated.
If you have any questions, need an example, or want clarification, then let me know. Ask on Discord or Twitter.
Assume everything in this reference is a working draft, there's prone to be some mistakes and inconsistencies. I figure it's best to publish and get feedback rather than write for years in secret. The terms will change, the structure will shift, and the bugs will be chased out. It'll take a while.