Files
puzzle-design-kb/src/puzzles/cognitive-transfer-overview.md
Bryce 9e11c74065 Complete: Remaining restructure tasks - design notes, cross-reference index, worksheet, FAQ
- Add Design Process Notes to 5 puzzle taxonomy overviews
- Create cross-reference-index.md mapping 28 games to puzzle types
- Create quick-start-worksheet.md with design checklist and templates
- Create comprehensive FAQ with 10 common design questions answered
2026-03-19 15:38:49 -07:00

3.9 KiB

Cognitive Transfer Puzzles

Cognitive transfer puzzles operate on a Learn → Apply structure rather than Gather → Synthesize. Players encounter a system, rule set, or behavioral pattern in one context, then transfer that knowledge to solve problems elsewhere. The core challenge isn't collecting pieces—it's recognizing that information learned in situation A applies mechanistically to situation B.

These puzzles test whether players observe systems deeply enough to extract reusable rules. The "aha" moment comes not from finding new information, but from realizing old information has new applications.

Core Characteristics

Trait Description
Learning Phase Player observes or experiments to discover rules/patterns
Transfer Distance How different the application context appears from the learning context
Abstraction Level Whether rules are concrete (this button = that light) or abstract (patterns mirror relationships)

Cognitive Transfer Taxonomy

Cognitive transfer divides into five distinct mechanisms based on what transfers and how:

Direct Pattern Types

Abstract Reasoning Types

Observation-Based Types

Design Distinctions

Cognitive transfer puzzles differ from other categories by their emphasis:

Vs. Other Types Key Difference
Multi-Faceted Plan MFP synthesizes disparate requirements; cognitive transfer applies unified rules across contexts
Meta-Construction Meta-construction chains outputs sequentially; cognitive transfer uses parallel application of learned system
Brokerage Brokerage trades items along networks; cognitive transfer trades knowledge across domains

Common Design Failures

Observation vs. Replay: Teaching players to memorize a specific sequence rather than understand underlying rules creates observation replay, which feels like rote memorization instead of genuine learning.

Insufficient Transfer Distance: If the application context looks identical to the learning context, players don't experience cognitive transfer—they recognize surface similarity rather than rule abstraction.

Hidden Learning Opportunities: Players must have clear opportunities to learn the system before being asked to apply it. No tutorial means no fair transfer.

Design Process Notes

Failure Modes to Avoid:

  • Creating "aha moments" that depend on pixel hunting rather than reasoning about learned rules
  • Making the learning phase too short or too long relative to the transfer challenge
  • Allowing players to brute-force the transfer through trial-and-error instead of applying the rule

Playtesting Focus:

  • Do players articulate what rule they learned, or just stumble into the solution?
  • Is the transfer distance calibrated—visible enough to be fair, hidden enough to feel earned?
  • Do players recognize the learned system applies before or after encountering the transfer context?

Connection to Design Process:

  • See working-backwards.md for designing cognitive transfer puzzles from the solution backward
  • See failure-modes.md for the dependency chart anti-pattern where transfer feels arbitrary