puzzle

Puzzle

A playbook for grid/board puzzle games — the board model, move input, rule resolution (matching, pushing, logic), scoring, undo, and level progression. This is a compositional skill: it models board state and rules and presents them through a tilemap/UI. It does not re-teach tilemaps; it defines the resolution loop and the correctness rules (clean state, deterministic resolution, undo) that keep a puzzle fair and bug-free.

When to use

• Use when the game is a discrete board the player changes with moves, and the board resolves by rules: match-3/tile-matching, sokoban/block-pusher, sliding puzzle, logic grid.
• Use when designing match/cascade resolution, undo, level progression, or solvability.

When not to use: real-time grid action with permadeath → roguelike. Card zones/turns → card-game. Physics-based "puzzle platformer" → platformer + physics-tuning. For the tile rendering, use godot-tilemap / unity-tilemap-2d.

Core loop

Read the board → plan a move → make the move → the board resolves by its rules (match, push, fall, fill, cascade) → see progress toward the objective → repeat until solved/failed. The fun is the planning; the engine's job is to resolve each move deterministically and present it clearly.

Must-have systems

1. Board model — a grid of cells holding pieces; the single source of truth (logic, not visuals).
2. Move input — swap, push, drag, rotate, or place; validate legality before applying.
3. Rule resolution — detect and apply the genre's rule (matches, pushes, logic) until stable.
4. Cascades/chains — when resolution changes the board, re-resolve until no more changes.
5. Objectives + scoring — win/lose conditions (score, clear all, reach goal); move/time limits.
6. Undo — revert the last move (and its resolution) exactly; essential for thinky puzzles.
7. Level progression + (often) generation — hand-authored or generated solvable boards.
8. Feedback ("juice") — clear, satisfying animation/sound for matches, falls, and chains.

Design knobs

Patterns

1. Board model + match detection (logic separate from visuals)

# Pseudocode. The board is the truth; rendering reads from it. (0,0) top-left, y grows down.
board = [[piece_or_empty for _ in range(W)] for _ in range(H)]

def find_matches(board):
    matched = set()
    for y in range(H):                       # horizontal runs of >= 3 equal pieces
        run = 1
        for x in range(1, W):
            if board[y][x] and board[y][x] == board[y][x-1]: run += 1
            else:
                if run >= 3: matched |= {(y, k) for k in range(x-run, x)}
                run = 1
        if run >= 3: matched |= {(y, k) for k in range(W-run, W)}
    # ... repeat the same scan vertically (columns) ...
    return matched

2. Resolve → collapse → refill → cascade (repeat to stability)

# Pseudocode. One player move can trigger a chain; loop until the board stops changing.
def resolve(board):
    chain = 0
    while True:
        matches = find_matches(board)
        if not matches: break                 # stable: resolution complete
        chain += 1
        score += score_for(matches, chain)    # later chain steps score more (see refs)
        clear(board, matches)                  # remove matched pieces
        apply_gravity(board)                   # pieces fall into the gaps
        refill(board, rng)                      # spawn new pieces at the top (seeded RNG)
    return chain

3. Undo via state snapshot or command

# Pseudocode. Snapshot before each move; undo restores it exactly (board + score + counters + RNG).
def make_move(move):
    history.append(snapshot(board, score, moves_left, rng.state))   # push BEFORE applying
    apply(move); resolve(board); moves_left -= 1

def undo():
    if history:
        board, score, moves_left, rng.state = history.pop()   # exact revert, including refills

For large boards prefer the command pattern (store the move + enough to invert it) over full snapshots to save memory; snapshots are simplest and fine for small boards.

Pitfalls / failure modes

• Mixing logic and visuals → animations desync from state and cause bugs. The board model is the single source of truth; the view only renders it.
• Resolving only once → cascades/chains are missed. Loop resolution until the board is stable (Pattern 2).
• Undo that doesn't restore everything → score/move-count/random-state drift. Snapshot all state, or make the move fully invertible. If undo skips the RNG state, redoing the same move refills different pieces and players learn to "reroll" by undoing.
• Unseeded refill RNG → can't reproduce a level / no deterministic undo or daily puzzle. Seed it.
• Generated boards that aren't solvable → unfair dead ends. Generate-and-verify, or generate from a known solution backward (refs). A sliding-tile puzzle filled by a random shuffle is unsolvable half the time; check the parity rule in refs §7.
• No deadlock detection (match-3) → board with no valid moves softlocks. Detect "no moves" and shuffle or end the level (refs).
• Difficulty spikes → too many mechanics at once. Teach one mechanic per level before combining.
• Resolution mid-animation accepts input → double-moves/corruption. Lock input until the board is stable.

Composition (build it from these skills)

• Board rendering: godot-tilemap / unity-tilemap-2d for the grid; godot-ui-control for HUD, score, and menus.
• Levels: level-design for hand-authored puzzles and difficulty pacing; procedural-gen for solvable generated boards.
• Persistence: save-systems for level progress, high scores, and seeded daily puzzles.
• Juice: game-feel for match/cascade pop, screen shake, and chain feedback; the engine animation/Tween skill for swaps/falls/clears; audio-design for match and chain cues.
• Scripting: godot-gdscript / unity-csharp-scripting for the resolution loop and rules.

References

• For match-3 detection/gravity/refill/cascade detail, deadlock detection and reshuffles, sokoban/rule-based puzzles, undo strategies, solvable generation, and scoring, read references/board-and-resolution.md.