mcpField
P
puzzle

puzzle

github.com/gamedev-skillsDevelopment5.4k6.7k installsUpdated 1d ago
Repository

About puzzle

A compositional skill for grid and board puzzle games, helping developers model board state, resolve rules, and structure progression. It emphasizes deterministic resolution and complete undo to avoid logic errors.

Key features

  1. 01Separate board state from visuals
  2. 02Validate and apply player moves
  3. 03Resolve matches, pushes, and other rules
  4. 04Handle cascades, objectives, and scoring
  5. 05Implement full undo and progression

Use cases

  1. 01Design match-three or sliding puzzles
  2. 02Implement Sokoban and rule-based boards
  3. 03Add cascade resolution and undo
  4. 04Build solvable levels with progression

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/gamedev-skills/awesome-gamedev-agent-skills --skill puzzle

After installing, type/puzzlein Claude Code to confirm it loaded.

Bundled filesreferences/board-and-resolution.md

Details

From the project README

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

KnobEffectNotes
Grid size / shapecomplexitySquare is standard; hex/irregular change feel.
Match/push rulegenre identity3-in-a-row, shapes, push-into-goal, etc.
Cascade scoringreward depthBigger chains = exponential payoff.
Move / time limitpressureMove-limited = puzzly; time = arcade.
Difficulty curvelearningIntroduce one mechanic at a time.
Undo depthforgivenessSingle-step vs. full history.
Solvability guaranteefairnessGenerated boards must be solvable.
Deadlock handlingno dead endsDetect no-moves; shuffle or end (refs).

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).
def make_move(move):
    history.append(snapshot(board, score, moves_left))   # push BEFORE applying
    apply(move); resolve(board); moves_left -= 1

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

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.
  • 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).
  • 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.

Comments

Markdown supported