Revealing hidden information by combining constraints
Constraint logic puzzles are a staple across all mediums. With a limited set of information, including textual and visual clues, a player must piece together a complete state.
For example, a player needs to order the heights of some children and has been given this information:
From these "constraints" we can work out the answer. From tallest to shortest the children are: Sally, Jose, Greg, Anka.
The answer is the "state"; it's the information we're after. This can take many forms, from the simple ordering of a list, to the arrangement of food and guests at a dinner table, or the positions of checkers on a game board.
The bits are information are called constraints because they constrain the set of possible states. That is, each clue limits what the answer can be. When given enough constraints the player can piece together the complete solution.
Most constraint logic puzzles aim to be unambiguous: there is only one possible state that matches the constraints.
If we modify our example we can create an ambiguous state:
The state could be either: Sally, Jose, Mia, Anka, or Jose, Sally, Mia, Anka. There's a missing constraint. We can't tell whether Sally or Jose is taller than the other.
Any state which matches all the constraints is a valid answer. If multiple answers are possible, but a game accepts only one, then it's a game design error.
There is no fundamental reason why a constraint logic puzzle should have only one answer. However, when given strict constraints, players will tend to assume this is the case, getting frustrated if they are unable to determine a "correct" answer.
Solving a constraint logic puzzle invovles reconstruction of a state to which all the constraints apply. A player solves these puzzles by working backwards from the constraints and working forward from state assumptions.
For each state the player creates, they test it against the constraints provided. They check each rule if it is true. If any rule is false, then the solution is not valid. This can be done even without a complete solution, as most rules can be interpreted on a partial state.
In many constraint logic puzzles, the state can be built step-by-step from the constraints. Here we can find at least one constraint that fixes at least one part of the state. For example, "Anka is the shortest". From this kernel of knowledge it might be possible to apply each additional constraint in turn to arrive at a solution.
Alternately, some constraints may not reveal enough information on their own to determine the state. In our example, "Sally is taller than Mia" and "Jose is taller than Mia" on their own don't identify an unambiguous state. However, taken together we know for sure that "Mia" is the third shortest, but still not whether Sally or Jose is taller. Adding in the final detail "Jose is taller than Mia but not the tallest" removes that last bit of uncertainty.
How much unresolved state a player has to juggle lends significantly to the difficulty of the puzzle. In the easiest puzzles, a player can repeatedly go through the constraints and each iteration resolve at least one part of the state. In a complex puzzle, a player may have numerous potential states hinged on a variety of constraints.
It is often easier, sometimes required, for a player to test solutions, instead of only deriving the next state from the rules. With their current partial state, the player choose to add another bit of detail, then they check if the system is still consistent with the rules. If yes, they continue. If no, then they undo that detail and try again. This approach is called backtracking.
Deductive logic is based on constraint logic, but works with imperfect information and assumptions. In pure constraint logic, the constraints provided in the game are taken at face value without implied knowledge. Whereas in a deductive logic game, you make assumptions or leaps of faith. In a true detective style game you may even be left with ambiguous outcomes: where more than one "state" is correct.
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.