claude-code-arcane 1.0.0

package/templates/gamedev/concept-doc-from-prototype.md

@@ -0,0 +1,304 @@
+# [Prototype Name] — Concept Document
+
+---
+**Status**: Reverse-Documented from Prototype
+**Prototype Path**: `prototypes/[name]/`
+**Date**: [YYYY-MM-DD]
+**Creator**: [User name]
+**Outcome**: [Success | Partial Success | Failed | Needs More Testing]
+---
+
+> **⚠️ Reverse-Documentation Notice**
+>
+> This concept document was created **after** the prototype was built. It captures
+> the core mechanic, learnings, and design insights discovered through prototyping.
+> This is a formalization of experimental work, not a pre-planned design.
+
+---
+
+## 1. Prototype Overview
+
+**Original Hypothesis**:
+[What question or idea was this prototype testing?]
+
+**Approach**:
+[How was the prototype built? Quick and dirty? Focused on one mechanic?]
+
+**Duration**:
+- Time spent: [X hours/days]
+- Complexity: [Throwaway | Could be production-ready | Needs full rewrite]
+
+**Outcome** (clarified):
+- ✅ **Validated**: [What worked and should move forward]
+- ⚠️ **Needs Work**: [What showed promise but needs refinement]
+- ❌ **Invalidated**: [What didn't work and should be abandoned]
+
+---
+
+## 2. Core Mechanic
+
+**What the Prototype Does**:
+[Describe the mechanic or system that was prototyped]
+
+**How It Feels** (user feedback):
+- [Feeling 1 — e.g., "Satisfying", "Clunky", "Too complex"]
+- [Feeling 2 — e.g., "Intuitive", "Confusing", "Needs tutorial"]
+- [Feeling 3 — e.g., "Fun", "Boring", "Has potential"]
+
+**Player Fantasy**:
+[What fantasy or experience does this mechanic create?]
+
+**Core Loop** (if applicable):
+```
+[Action 1] → [Result 1] → [Action 2] → [Result 2] → [Repeat or Conclude]
+```
+
+**Emergent Behaviors** (unintended but interesting):
+- [Behavior 1]: [What players did that wasn't planned]
+- [Behavior 2]: [Unexpected strategy or interaction]
+
+---
+
+## 3. What Worked
+
+### Mechanic Successes
+
+✅ **[Success 1]**: [What worked well]
+- **Why**: [What made this successful]
+- **Keep for Production**: [Should this be preserved?]
+
+✅ **[Success 2]**: [What worked well]
+- **Why**: [What made this successful]
+- **Keep for Production**: [Should this be preserved?]
+
+### Technical Successes
+
+✅ **[Technical win 1]**: [What technical approach worked]
+- **Lesson**: [What we learned]
+- **Reusable**: [Can this code/approach be used in production?]
+
+✅ **[Technical win 2]**: [What worked]
+- **Lesson**: [What we learned]
+
+---
+
+## 4. What Didn't Work
+
+### Mechanic Failures
+
+❌ **[Failure 1]**: [What didn't work]
+- **Why**: [Root cause]
+- **Could It Be Fixed**: [Is it salvageable or fundamentally flawed?]
+
+❌ **[Failure 2]**: [What didn't work]
+- **Why**: [Root cause]
+- **Could It Be Fixed**: [Yes/No + how]
+
+### Technical Failures
+
+❌ **[Technical issue 1]**: [What caused problems]
+- **Lesson**: [What to avoid in production]
+
+❌ **[Technical issue 2]**: [What caused problems]
+- **Lesson**: [What to avoid]
+
+---
+
+## 5. What Needs Refinement
+
+⚠️ **[Element 1]**: [What showed promise but needs work]
+- **Issue**: [What's wrong with it currently]
+- **Path Forward**: [How to improve it]
+- **Effort**: [Small | Medium | Large refactor]
+
+⚠️ **[Element 2]**: [What needs refinement]
+- **Issue**: [Current problem]
+- **Path Forward**: [Improvement approach]
+- **Effort**: [Estimate]
+
+---
+
+## 6. Key Learnings
+
+### Design Insights
+
+💡 **[Insight 1]**: [What we learned about game design]
+- **Implication**: [How this affects future work]
+
+💡 **[Insight 2]**: [Design learning]
+- **Implication**: [Impact on GDD or other systems]
+
+### Technical Insights
+
+💡 **[Insight 3]**: [Technical learning]
+- **Implication**: [Architecture or implementation guidance]
+
+💡 **[Insight 4]**: [Technical learning]
+- **Implication**: [Future technical decisions]
+
+### Player Psychology Insights
+
+💡 **[Insight 5]**: [What we learned about player behavior]
+- **Implication**: [How this affects design philosophy]
+
+---
+
+## 7. Production Readiness Assessment
+
+**Should This Become a Full Feature?**: [Yes | No | Needs More Testing | Pivot to Different Approach]
+
+**If Yes — Production Requirements**:
+- [ ] [Requirement 1 — e.g., "Rewrite for performance"]
+- [ ] [Requirement 2 — e.g., "Add proper UI"]
+- [ ] [Requirement 3 — e.g., "Design 10 more variations"]
+- [ ] [Requirement 4 — e.g., "Integrate with progression system"]
+
+**Estimated Production Effort**: [Small | Medium | Large]
+- Prototype reusability: [X%] of code can be kept
+- From-scratch effort: [X hours/days to production-ready]
+
+**If No — Why Not?**:
+- [Reason 1 — e.g., "Fun but doesn't fit game pillars"]
+- [Reason 2 — e.g., "Too complex for target audience"]
+- [Reason 3 — e.g., "Technically infeasible at scale"]
+
+**If Pivot — Suggested Direction**:
+- [Alternative approach 1]
+- [Alternative approach 2]
+
+---
+
+## 8. Design Pillars Alignment
+
+**How This Relates to Game Pillars** (if game pillars are defined):
+
+| Pillar | Alignment | Notes |
+|--------|-----------|-------|
+| [Pillar 1] | ✅ Strong / ⚠️ Weak / ❌ Conflicts | [Explanation] |
+| [Pillar 2] | ✅ Strong / ⚠️ Weak / ❌ Conflicts | [Explanation] |
+| [Pillar 3] | ✅ Strong / ⚠️ Weak / ❌ Conflicts | [Explanation] |
+
+**Overall Pillar Fit**: [Does this belong in the game?]
+
+---
+
+## 9. Next Steps
+
+### Immediate (If Moving Forward)
+1. **[Task 1]**: [e.g., "Create full design doc for this system"]
+2. **[Task 2]**: [e.g., "Write ADR for technical approach"]
+3. **[Task 3]**: [e.g., "Add to backlog for Sprint X"]
+
+### Before Production (If Needs More Work)
+1. **[Task 1]**: [e.g., "Build second prototype testing X variation"]
+2. **[Task 2]**: [e.g., "Playtest with 5+ people"]
+3. **[Task 3]**: [e.g., "Investigate technical feasibility of Y"]
+
+### If Abandoning
+1. **[Task 1]**: [e.g., "Archive prototype with this document"]
+2. **[Task 2]**: [e.g., "Extract reusable code/learnings"]
+3. **[Task 3]**: [e.g., "Update game pillars if this changed thinking"]
+
+---
+
+## 10. Technical Notes
+
+**Prototype Implementation**:
+- Language/Engine: [What was used]
+- Architecture: [How it was structured]
+- Shortcuts taken: [What was hacky or throwaway]
+
+**Reusable Code** (if any):
+- `[file/path 1]`: [What it does, reusability]
+- `[file/path 2]`: [What it does, reusability]
+
+**Technical Debt** (if moving to production):
+- [Debt 1]: [What needs rewriting]
+- [Debt 2]: [What needs proper implementation]
+
+---
+
+## 11. Playtest Feedback
+
+*(If prototype was playtested)*
+
+**Testers**: [N people, [internal/external]]
+
+**Positive Feedback**:
+- "[Quote 1]" — [Tester name/role]
+- "[Quote 2]" — [Tester name/role]
+
+**Negative Feedback**:
+- "[Quote 1]" — [Tester name/role]
+- "[Quote 2]" — [Tester name/role]
+
+**Suggestions**:
+- "[Suggestion 1]" — [Tester name]
+- "[Suggestion 2]" — [Tester name]
+
+**Themes**:
+- [Theme 1]: [What multiple testers agreed on]
+- [Theme 2]: [Common feedback]
+
+---
+
+## 12. Related Work
+
+**Inspired By** (games/mechanics this was influenced by):
+- [Game 1]: [What mechanic or feeling]
+- [Game 2]: [What was borrowed or adapted]
+
+**Differs From** (how this is unique or different):
+- [Difference 1]
+- [Difference 2]
+
+**Integrates With** (existing game systems):
+- [System 1]: [How they would connect]
+- [System 2]: [How they would connect]
+
+---
+
+## 13. Open Questions
+
+**Design Questions**:
+1. **[Question 1]**: [What's still undecided about the design?]
+2. **[Question 2]**: [What needs playtesting or iteration?]
+
+**Technical Questions**:
+3. **[Question 3]**: [What technical unknowns remain?]
+4. **[Question 4]**: [What needs feasibility testing?]
+
+---
+
+## 14. Appendix: Prototype Assets
+
+**Code**:
+- Location: `prototypes/[name]/src/`
+- Status: [Archival | Partial reuse | Full reuse]
+
+**Art/Audio** (if any):
+- Location: `prototypes/[name]/assets/`
+- Status: [Placeholder | Production-ready | Needs replacement]
+
+**Documentation**:
+- README: [Exists | Missing]
+- Build instructions: [Exists | Missing]
+
+---
+
+## Version History
+
+| Date | Author | Changes |
+|------|--------|---------|
+| [Date] | Claude (reverse-doc) | Initial concept doc from prototype analysis |
+| [Date] | [User] | Clarified outcomes, added playtest feedback |
+
+---
+
+**Final Recommendation**: [GO | NO-GO | PIVOT]
+
+**Rationale**: [1-2 sentence summary of why]
+
+---
+
+*This concept document was generated by `/reverse-document concept prototypes/[name]`*

package/templates/gamedev/difficulty-curve.md

@@ -0,0 +1,330 @@
+# Difficulty Curve: [Game Title]
+
+> **Status**: Draft | In Review | Approved
+> **Author**: [game-designer / systems-designer]
+> **Last Updated**: [Date]
+> **Links To**: `design/gdd/game-concept.md`
+> **Relevant GDDs**: [e.g., `design/gdd/combat.md`, `design/gdd/progression.md`]
+
+---
+
+## Difficulty Philosophy
+
+[One paragraph establishing this game's relationship with difficulty. This is
+not a mechanical description — it is a design value statement that all tuning
+decisions must serve.
+
+The four common difficulty philosophies are:
+
+1. **Masochistic challenge as the core fantasy**: Difficulty is the product.
+   Overcoming it is the emotional reward. Reducing difficulty removes the
+   point. (Dark Souls, Celeste at max assist off)
+2. **Accessible entry, optional depth**: The base experience is completable by
+   most players; depth and challenge are opt-in for those who want them.
+   (Hades, Hollow Knight with accessibility modes)
+3. **Difficulty serves narrative pacing**: Challenge rises and falls to match
+   story beats. The player must feel capable during story resolution and
+   threatened during story crisis. (The Last of Us, God of War)
+4. **Relaxed engagement**: Challenge is present but never the focus. Failure
+   is gentle and infrequent. The experience prioritizes comfort and expression
+   over obstacle. (Stardew Valley, Animal Crossing)
+
+State the philosophy explicitly, then add one sentence on what the player is
+permitted to feel: are they allowed to feel frustrated? For how long before the
+design must intervene? What is the acceptable cost of failure?]
+
+---
+
+## Difficulty Axes
+
+> **Guidance**: Most games have multiple independent dimensions of challenge.
+> Identifying them explicitly prevents the mistake of tuning only one axis
+> (usually execution difficulty) while leaving others unexamined. A game can
+> feel "easy" on execution but overwhelming on decision complexity — players
+> experience this as confusing, not engaging.
+>
+> For each axis, answer: can the player control or reduce this axis through
+> choices, builds, or settings? If not, it is a forced challenge dimension —
+> be very intentional about how it is used.
+
+| Axis | Description | Primary Systems | Player Control? |
+|------|-------------|----------------|-----------------|
+| **Execution difficulty** | [The precision and timing demands of core actions. e.g., "Dodging enemy attacks requires correct timing within a 200ms window."] | [e.g., Combat, movement] | [Yes — practice reduces this / No — fixed mechanical threshold] |
+| **Knowledge difficulty** | [The cost of not knowing information. e.g., "Enemy weaknesses are not telegraphed; players who have not discovered them take significantly more damage."] | [e.g., Enemy design, UI, lore] | [Yes — through in-game discovery / No — requires external knowledge] |
+| **Resource pressure** | [How scarce are the resources needed to progress? e.g., "Health consumables are limited; efficient play is required to sustain long dungeon runs."] | [e.g., Economy, loot, crafting] | [Yes — through build optimization / Partially] |
+| **Time pressure** | [Does the player have time to think, or does the game demand rapid decisions? e.g., "Enemy spawn timers and attack windows require real-time response."] | [e.g., Combat pacing, timers] | [Yes — through difficulty settings / No — core to genre] |
+| **Decision complexity** | [How many meaningful choices must the player evaluate simultaneously? e.g., "Build decisions interact across 4 systems; suboptimal combinations create compounding disadvantage."] | [e.g., Progression, inventory, skills] | [Yes — through UI and tutorialization / No — inherent to strategy depth] |
+| **[Add axis]** | [Description] | [Systems] | [Player control] |
+
+---
+
+## Difficulty Curve Overview
+
+> **Guidance**: This table describes the intended challenge arc across the whole
+> game. Difficulty levels use a 1-10 scale where 1 = no meaningful challenge,
+> 10 = maximum challenge the game can produce. The scale is relative to THIS game's
+> design intent — a 6/10 in a soulslike is not the same as a 6/10 in a cozy sim.
+>
+> "Primary challenge type" refers to the difficulty axis (from the table above)
+> that is doing the most work in this phase. New systems introduced should list
+> only systems introduced for the FIRST TIME — the cognitive load of learning
+> a new system is itself a form of difficulty.
+>
+> "Target player state" is the emotional state the designer intends. If the actual
+> playtested state diverges from the intended state, this column is what needs
+> to be achieved.
+
+| Phase | Duration | Difficulty Level (1-10) | Primary Challenge Type | New Systems Introduced | Target Player State |
+|-------|----------|------------------------|----------------------|----------------------|---------------------|
+| [Prologue / Tutorial] | [e.g., 0-15 min] | [2/10] | [Knowledge] | [Core movement, basic interaction] | [Safe, curious, building confidence] |
+| [Early game] | [e.g., 15 min - 2 hrs] | [3-5/10] | [Execution] | [Combat, inventory, first upgrade path] | [Learning, occasional failure, clear cause-effect] |
+| [Mid game - opening] | [e.g., 2-6 hrs] | [5-7/10] | [Decision complexity] | [Build choices, advanced enemies, crafting] | [Engaged, strategizing, feeling growth] |
+| [Mid game - depth] | [e.g., 6-15 hrs] | [6-8/10] | [Resource pressure] | [Elite enemies, optional hard content, endgame previews] | [Challenged, invested, approaching mastery] |
+| [Late game] | [e.g., 15-25 hrs] | [7-9/10] | [Execution + knowledge] | [Endgame systems, NG+ or equivalent] | [Mastery, confident in build identity, seeking peak challenge] |
+| [Optional / Endgame] | [e.g., 25+ hrs] | [8-10/10] | [All axes combined] | [Mastery challenges, achievement targets] | [Expert play, self-imposed goals, community comparison] |
+
+---
+
+## Onboarding Ramp
+
+> **Guidance**: The first hour deserves its own detailed breakdown because it
+> does the most difficult design work: it must teach every foundational skill
+> without feeling like a lesson, and it must create enough investment that the
+> player commits to the journey ahead. Research on player retention shows that
+> most players who leave a game do so in the first 30 minutes — not because
+> the game is bad, but because onboarding failed to connect them.
+>
+> The scaffolding principle (Vygotsky's Zone of Proximal Development, adapted
+> for game design): introduce each mechanic in isolation before combining it
+> with others. A player cannot learn two skills simultaneously under pressure.
+
+### What the Player Knows at Each Stage
+
+| Time | What the Player Knows | What They Do Not Know Yet |
+|------|-----------------------|--------------------------|
+| [0 min] | [Literally nothing — treat this row as your most important UX audit. What can a player infer from the title screen alone?] | [Everything] |
+| [5 min] | [Core movement verb, basic world reading] | [All progression systems, all secondary mechanics] |
+| [15 min] | [Core interaction loop, first goal] | [Build depth, advanced mechanics, danger severity] |
+| [30 min] | [Has made at least one strategic choice] | [Whether that choice was optimal] |
+| [60 min] | [Has a working model of the core loop] | [Late-game depth, optional systems] |
+
+### Mechanic Introduction Sequence
+
+> The order mechanics are introduced is a design decision with real consequences.
+> Introduce the most essential verb first. Introduce mechanics that modify other
+> mechanics AFTER the base mechanic is internalized. Never introduce two new
+> mechanics in the same encounter.
+
+| Mechanic | Introduced At | Introduction Method | Stakes at Introduction |
+|----------|--------------|--------------------|-----------------------|
+| [Core movement / primary verb] | [e.g., First 30 seconds] | [Tutorial prompt / environmental design / NPC instruction] | [None — safe space to experiment] |
+| [Primary interaction / action] | [e.g., First 2 minutes] | [Method] | [Low — reversible, forgiving window] |
+| [First resource mechanic] | [e.g., 5 min] | [Method] | [Low — abundant at introduction] |
+| [First strategic choice] | [e.g., 15 min] | [Method] | [Low — choice can be changed or revisited] |
+| [First real failure risk] | [e.g., 20-30 min] | [Method] | [Moderate — player should feel genuine threat but have fair tools to respond] |
+| [Add mechanic] | [Timing] | [Method] | [Stakes] |
+
+### The First Failure
+
+[Describe the intended design of the first moment the player can meaningfully
+fail. This is one of the most important beats in the game.
+
+A well-designed first failure teaches rather than punishes. The player should
+be able to immediately identify what they did wrong and what they would do
+differently. If the cause of failure is ambiguous, the player blames the game.
+
+Answer: What causes the first failure? What does the player learn from it?
+How quickly can they retry? What is the cost? Does the game provide any
+feedback that bridges cause and effect?]
+
+### When the Player First Feels Competent
+
+[Identify the specific moment — not a vague window, but a specific beat —
+where the player should shift from "learning" to "doing." This is the moment
+of first competence: the first time their prediction about the game comes true,
+or the first time they execute a plan and it works.
+
+This moment must happen within the first hour. If it does not, the player
+will not reach Phase 3 of the journey (First Mastery). Design this moment
+deliberately — do not leave it to chance.
+
+What is the moment? What systems create it? What does the player do to
+trigger it? How does the game communicate that they have succeeded?]
+
+---
+
+## Difficulty Spikes and Valleys
+
+> **Guidance**: A healthy difficulty curve follows a sawtooth pattern
+> (Csikszentmihalyi's flow model applied to macro-structure): tension builds
+> through a sequence, then releases at a milestone, then re-engages at a
+> slightly higher baseline. Flat difficulty creates boredom; uninterrupted
+> escalation creates fatigue.
+>
+> Spikes are intentional peaks that test accumulated skills. Valleys are
+> intentional troughs that give the player space to breathe, experiment, and
+> feel powerful before the next escalation. Both are designed, not emergent.
+>
+> "Recovery design" is critical: what happens immediately after a spike? The
+> player should exit a hard moment feeling accomplished, not depleted. Give
+> them a valley, a reward, or a narrative payoff.
+
+| Name | Location in Game | Type | Purpose | Recovery Design |
+|------|-----------------|------|---------|-----------------|
+| [e.g., "The First Boss"] | [e.g., End of Area 1, ~1 hr] | [Spike] | [Tests all skills introduced in Area 1. Acts as a gate confirming the player is ready for increased complexity.] | [Post-boss: safe area, upgrade opportunity, story beat that provides emotional relief before Area 2 escalation begins.] |
+| [e.g., "The Safe Zone"] | [e.g., Hub area between Areas 1 and 2, ~1.5 hrs] | [Valley] | [Player feels powerful from boss win. Space to experiment with build options before stakes rise.] | [N/A — this IS the recovery from the preceding spike.] |
+| [e.g., "The Knowledge Wall"] | [e.g., Area 3 first encounter, ~4 hrs] | [Spike — knowledge type] | [Forces players to engage with a mechanic they may have been avoiding. Survival requires understanding it.] | [Clear feedback on what killed them. Tutorial hint surfaces on third failure. Mechanic becomes standard after this point.] |
+| [e.g., "Pre-Climax Valley"] | [e.g., Just before final act, ~20 hrs] | [Valley] | [Emotional breathing room before the final escalation. Player reflects on how far they have come.] | [N/A — designed as relief before the finale's spike.] |
+| [Add spike/valley] | [Location] | [Type] | [Purpose] | [Recovery] |
+
+---
+
+## Balancing Levers
+
+> **Guidance**: Balancing levers are the specific values and parameters that
+> tune difficulty at each phase. Centralizing them here makes it possible to
+> tune the whole-game difficulty curve without hunting through individual GDDs.
+> For each lever, the GDD that owns it should be cross-referenced.
+>
+> "Current setting" is the design intent at the time of writing — implementation
+> values live in `assets/data/`. The tuning range is the safe operating range:
+> values outside this range reliably break the intended experience.
+
+| Lever | Phase(s) | Effect | Current Setting | Tuning Range | Notes |
+|-------|----------|--------|----------------|-------------|-------|
+| [Enemy health multiplier] | [All] | [Higher = longer fights = more resource pressure and execution time] | [1.0x] | [0.7x - 1.5x] | [Below 0.7x, fights end before player can read enemy patterns. Above 1.5x, attrition replaces skill.] |
+| [Enemy aggression timer] | [Mid game onward] | [Time between enemy attacks; lower = less time to react] | [e.g., 2.0s] | [1.2s - 3.0s] | [Below 1.2s, reaction window is sub-human. Above 3.0s, encounters feel passive.] |
+| [Resource drop rate] | [Early game] | [Lower = more resource pressure = punishes inefficiency harder] | [e.g., 1.5x baseline] | [0.8x - 2.0x] | [Onboarding generosity; reduces in mid-game as player skill assumed.] |
+| [New mechanic introduction density] | [First hour] | [How many new concepts per minute of play; too high = cognitive overload] | [e.g., 1 new mechanic per 8 min] | [1 per 5 min (max) to 1 per 15 min (slow)] | [Above 1 per 5 min in early game causes retention drop. Below 1 per 15 min causes boredom.] |
+| [Failure cost] | [All] | [Time lost on failure; higher = more punishing = more tension] | [e.g., 2 min setback] | [30s - 8 min] | [Must scale with encounter frequency. Frequent failures need fast recovery.] |
+| [Add lever] | [Phase] | [Effect] | [Setting] | [Range] | [Notes] |
+
+---
+
+## Player Skill Assumptions
+
+> **Guidance**: Every game implicitly assumes players develop a set of skills
+> over the course of play. Making these assumptions explicit allows the team to
+> verify that each skill is actually taught before it is tested, and that the
+> gap between "introduced" and "tested hard" is long enough for internalization.
+>
+> A skill introduced and tested in the same encounter is a surprise difficulty
+> spike. A skill assumed but never formally introduced is an undocumented knowledge
+> wall. Both are fixable — but only if they are documented.
+>
+> "Taught by" refers to the mechanism: tutorial prompt, environmental design,
+> safe practice opportunity, NPC instruction, or organic discovery.
+>
+> "Tested by" refers to the first encounter that REQUIRES this skill to survive
+> without taking significant damage or cost.
+
+| Skill | Introduced In | Expected Mastered By | Taught By | First Hard Test |
+|-------|--------------|---------------------|-----------|-----------------|
+| [Core movement / dodging] | [Tutorial area, 0-5 min] | [End of Area 1, ~1 hr] | [Safe practice zone with visible hazards] | [First Elite enemy, ~45 min] |
+| [Resource management] | [First shop encounter, ~10 min] | [Mid game, ~4 hrs] | [Resource scarcity in Area 2 forces planning] | [Boss that requires consumables to survive efficiently] |
+| [Build decision-making] | [First upgrade choice, ~20 min] | [End of mid game, ~10 hrs] | [Multiple playthroughs / community discussion / in-game build advisor] | [Endgame encounters that punish build incoherence] |
+| [Enemy pattern reading] | [Area 1 basic enemies] | [Area 3, ~4 hrs] | [Enemy telegraphs visible and consistent from introduction] | [Elite enemy with 3+ distinct attack patterns] |
+| [Add skill] | [When introduced] | [When mastered] | [Taught by] | [First hard test] |
+
+---
+
+## Accessibility Considerations
+
+> **Guidance**: Accessibility in difficulty design is not about making the game
+> easier — it is about ensuring players with different needs and skill profiles
+> can reach the intended emotional experience. Be explicit about what CAN be
+> adjusted and what CANNOT, and justify both.
+>
+> The principle from Self-Determination Theory: players need to feel competent.
+> Accessibility options that help players feel competent without removing the
+> feeling of agency are always worth including. Options that make competence
+> meaningless undermine the core experience.
+
+### What Can Be Adjusted
+
+| Adjustment | Method | Effect on Experience | Tradeoff |
+|-----------|--------|---------------------|----------|
+| [e.g., Enemy speed reduction] | [Difficulty setting / accessibility menu] | [Lowers execution difficulty without changing knowledge or decision requirements] | [Reduces the tension of combat timing; acceptable for narrative players] |
+| [e.g., Extended input windows] | [Accessibility menu] | [Allows players with motor impairments to achieve the same skill outcomes with more time] | [Minimal — skill expression preserved, threshold relaxed] |
+| [e.g., Hint frequency] | [Settings toggle] | [Surfaces contextual guidance more or less aggressively based on player preference] | [Higher hints reduce knowledge difficulty; players who want to discover organically may feel over-guided] |
+| [Add option] | [Method] | [Effect] | [Tradeoff] |
+
+### What Cannot Be Adjusted (and Why)
+
+| Fixed Element | Why It Cannot Change | Design Reasoning |
+|--------------|---------------------|-----------------|
+| [e.g., Permadeath in roguelike run] | [Removing it eliminates the resource pressure axis that all encounter balance is built around] | [The weight of each decision comes from permanence; without it, the core loop loses meaning] |
+| [e.g., Core narrative pacing] | [Difficulty valleys are timed to story beats; adjustable pacing would decouple challenge from narrative intention] | [Story and difficulty are designed as one arc, not two independent tracks] |
+| [Add fixed element] | [Why] | [Reasoning] |
+
+---
+
+## Cross-System Difficulty Interactions
+
+> **Guidance**: When two systems operate simultaneously, their combined
+> difficulty is often greater than the sum of their parts — or sometimes
+> less. These interactions are frequently unintended and only surface during
+> playtesting. Documenting anticipated interactions here creates a checklist
+> for QA and playtest sessions.
+>
+> "Is this intended?" Yes means the interaction is a designed feature.
+> No means it should be mitigated. Partial means the interaction is
+> acceptable in small doses but problematic if it becomes the dominant
+> experience.
+
+| System A | System B | Combined Effect | Intended? |
+|----------|----------|----------------|-----------|
+| [Combat difficulty] | [Resource scarcity] | [Resource-poor players face combat encounters with fewer options, compounding difficulty for players already struggling. Can create a death spiral where failing creates worse conditions.] | [Partial — intended as stakes, not as a trap. Pity mechanics required to prevent unrecoverable states.] |
+| [Build complexity] | [Time pressure] | [Players who are still learning their build take longer to make decisions under time pressure, increasing cognitive load beyond the intended challenge of either system alone.] | [No — reduce decision complexity demand in high time-pressure encounters.] |
+| [New mechanic introduction] | [Resource pressure] | [Introducing a new system while the player is already under resource pressure forces them to learn and optimize simultaneously.] | [No — new mechanics should be introduced in low-resource-pressure environments.] |
+| [Enemy density] | [Execution difficulty] | [High enemy counts with individually demanding enemies produce difficulty that scales exponentially, not linearly.] | [Partial — intended for optional challenge content only; not acceptable on the critical path.] |
+| [Add System A] | [Add System B] | [Combined effect description] | [Yes / No / Partial] |
+
+---
+
+## Validation Checklist
+
+> **Guidance**: These checkpoints structure playtesting sessions to verify
+> the difficulty curve is achieving its intent. Each item should be checked
+> with at least 3 playtester sessions before being marked complete. Note the
+> playtester profile that revealed issues — difficulty problems are almost
+> always player-profile-specific.
+
+### Onboarding (0-30 min)
+- [ ] Players with no prior genre experience complete the tutorial area without external help
+- [ ] Zero players cite confusion about what they are supposed to be doing in the first 5 minutes
+- [ ] At least one playtester spontaneously says "I want to see what's next" within 15 minutes
+- [ ] First failure moment produces a visible learning response (player verbalizes what went wrong)
+
+### Early Game (30 min - 2 hrs)
+- [ ] Average player reaches the first competence moment within 60 minutes
+- [ ] First major encounter (boss or equivalent) is passed within 3-5 attempts on average
+- [ ] No player cites a mechanic introduced "too suddenly without warning"
+- [ ] Players can describe their current goal without prompting
+
+### Mid Game (2-10 hrs)
+- [ ] Players discover at least one depth mechanic through organic play (without guide)
+- [ ] Playtest sessions report "I want to try a different build / strategy next run"
+- [ ] No single difficulty axis dominates player complaints — frustration is distributed
+- [ ] Players who fail a mid-game encounter correctly identify the cause without being told
+
+### Late Game (10+ hrs)
+- [ ] Players report the final challenge feels like a culmination of everything they have learned
+- [ ] Failure at late-game content does not feel unfair (even if it is hard)
+- [ ] Players who complete the main content express a reason to continue playing
+
+### Accessibility
+- [ ] All listed accessibility options function without breaking encounter intent
+- [ ] Players using accessibility settings report feeling competent, not patronized
+- [ ] Fixed difficulty elements are encountered and accepted without negative reception from accessibility playtesters
+
+---
+
+## Open Questions
+
+| Question | Owner | Deadline | Resolution |
+|----------|-------|----------|-----------|
+| [Is the onboarding ramp correctly calibrated for players without prior genre experience?] | [game-designer] | [Date] | [Unresolved — schedule genre-naive playtester sessions] |
+| [Does the first boss represent the correct difficulty spike or is it a wall?] | [game-designer, systems-designer] | [Date] | [Unresolved — requires 5+ playtester sessions to establish average attempt count] |
+| [Do any cross-system interactions produce unrecoverable states?] | [systems-designer] | [Date] | [Unresolved — requires targeted playtest with resource-constrained starting conditions] |
+| [Add question] | [Owner] | [Date] | [Resolution] |