mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 01:37:05 +00:00
Release 1.1.2 — the default path works end to end
Fix release for 1.1.1: the minimal path end to end, engine commands that run on Godot, Unity and Unreal, hook warnings you can see, and verdicts that say when they could not check. Details in CHANGELOG.md; upgrade steps in UPGRADING.md (v1.1.1 → v1.1.2). Fixes #67 Fixes #131 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WuJn2FdynEybfL5KC697nJ
This commit is contained in:
Donchitos
co-authored by
Claude Opus 5.5
Claude Opus 5.5
parent
7ed2c3e9c4
commit
b21fa0f7f2
@@ -40,9 +40,9 @@ pointers in the templates name the exact section to read.
|
||||
|
||||
**`docs.density`** — it controls per-section *depth*, where `workflow`
|
||||
controls which screens are specced. `modes.rigor` sets both together; set
|
||||
`docs.density` explicitly to vary depth alone: `terse` = wireframe descriptions +
|
||||
`docs.density` explicitly to vary depth alone: `terse` (the default, via `rigor: minimal`) = wireframe descriptions +
|
||||
interaction bullets; `balanced` = wireframes + paragraph descriptions of flows
|
||||
(default); `thorough` = full prose including user-research summaries and
|
||||
(`rigor: standard`); `thorough` = full prose including user-research summaries and
|
||||
alternative flow considerations. Apply it to every section you author.
|
||||
|
||||
## 1. Parse Arguments & Determine Mode
|
||||
@@ -81,7 +81,8 @@ comes from arriving informed.
|
||||
|
||||
### 2a: Required Reads
|
||||
|
||||
- **Game concept**: Read `design/gdd/game-concept.md` — if missing, warn:
|
||||
- **Game concept**: Read `design/gdd/game-concept.md` — or `design/game-brief.md`,
|
||||
the one-page brief that replaces it at `rigor: minimal` — if neither exists, warn:
|
||||
> "No game concept found. Run `/brainstorm` first to establish the game's
|
||||
> foundation before designing UX."
|
||||
> Continue anyway if the user asks.
|
||||
@@ -123,7 +124,11 @@ Grep pattern="^#+ .*UI Requirements" glob="design/gdd/*.md" output_mode="content
|
||||
```
|
||||
|
||||
Establish the denominator first (glob `design/gdd/*.md`, count **N**) and check
|
||||
the match count against it. **A GDD with no UI Requirements section is not a GDD
|
||||
the match count against it. Count system GDDs only: `game-concept.md`,
|
||||
`systems-index.md`, `game-pillars.md`, `gameplay-tags.md`, `entity-registry.md`,
|
||||
`fixture-swap-ledger.md`, `sound-bible.md` and any `gdd-cross-review-*.md` live
|
||||
there too, but they are not systems and have no UI to aggregate.
|
||||
**A GDD with no UI Requirements section is not a GDD
|
||||
with no UI needs** — it may predate the section. List the unmatched ones and
|
||||
confirm with the user that they are genuinely headless before excluding them
|
||||
from the HUD's requirement set; a HUD that silently omits a system's readout is
|
||||
@@ -200,7 +205,8 @@ Then ask: "Anything else I should read before we start, or shall we proceed?"
|
||||
|
||||
Before creating a skeleton, check if the target output file already exists.
|
||||
|
||||
Glob `design/ux/[filename].md` (where `[filename]` is the resolved output path from Phase 1).
|
||||
Glob the resolved output path from Phase 1 — `design/ux/[filename].md`, or
|
||||
`design/accessibility-requirements.md` in `accessibility` mode.
|
||||
|
||||
**If the file exists — retrofit mode:**
|
||||
- Read the file in full
|
||||
@@ -211,15 +217,25 @@ Glob `design/ux/[filename].md` (where `[filename]` is the resolved output path f
|
||||
>
|
||||
> | Section | Status |
|
||||
> |---------|--------|
|
||||
> | Overview & Context | [Complete / Empty / Placeholder] |
|
||||
> | Player Journey Integration | ... |
|
||||
> | Screen Layout & Information Architecture | ... |
|
||||
> | Interaction Model | ... |
|
||||
> | Feedback & State Communication | ... |
|
||||
> | Purpose & Player Need | [Complete / Empty / Placeholder] |
|
||||
> | Player Context on Arrival | ... |
|
||||
> | Navigation Position | ... |
|
||||
> | Entry & Exit Points | ... |
|
||||
> | Layout Specification | ... |
|
||||
> | States & Variants | ... |
|
||||
> | Interaction Map | ... |
|
||||
> | Data Requirements | ... |
|
||||
> | Events Fired | ... |
|
||||
> | Transitions & Animations | ... |
|
||||
> | Input Method Completeness Checklist | ... |
|
||||
> | Accessibility | ... |
|
||||
> | Edge Cases & Error States | ... |
|
||||
> | Localization Considerations | ... |
|
||||
> | Acceptance Criteria | ... |
|
||||
> | Open Questions | ... |
|
||||
>
|
||||
> (Rows are the skeleton's own `##` headings for the active mode — the list above is
|
||||
> UX spec mode; HUD and accessibility modes list their skeleton's headings.)
|
||||
>
|
||||
> I'll work on the [N] incomplete sections only — existing content will not be overwritten."
|
||||
|
||||
- Skip Section 3 (skeleton creation) — the file already exists
|
||||
@@ -251,6 +267,7 @@ Ask: "May I create the skeleton file at `design/ux/[filename].md`?" — except i
|
||||
> **Author**: [user + ux-designer]
|
||||
> **Last Updated**: [today's date]
|
||||
> **Journey Phase(s)**: [from context]
|
||||
> **Platform Target**: [target platforms and input methods from 2h]
|
||||
> **Template**: UX Spec
|
||||
|
||||
---
|
||||
@@ -281,7 +298,7 @@ Ask: "May I create the skeleton file at `design/ux/[filename].md`?" — except i
|
||||
|
||||
## Layout Specification
|
||||
|
||||
### Information Hierarchy
|
||||
### ASCII Wireframe
|
||||
|
||||
[To be designed]
|
||||
|
||||
@@ -293,7 +310,7 @@ Ask: "May I create the skeleton file at `design/ux/[filename].md`?" — except i
|
||||
|
||||
[To be designed]
|
||||
|
||||
### ASCII Wireframe
|
||||
### Information Hierarchy
|
||||
|
||||
[To be designed]
|
||||
|
||||
@@ -311,6 +328,12 @@ Ask: "May I create the skeleton file at `design/ux/[filename].md`?" — except i
|
||||
|
||||
---
|
||||
|
||||
## Data Requirements
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Events Fired
|
||||
|
||||
[To be designed]
|
||||
@@ -323,7 +346,7 @@ Ask: "May I create the skeleton file at `design/ux/[filename].md`?" — except i
|
||||
|
||||
---
|
||||
|
||||
## Data Requirements
|
||||
## Input Method Completeness Checklist
|
||||
|
||||
[To be designed]
|
||||
|
||||
@@ -362,6 +385,7 @@ Ask: "May I create the skeleton file at `design/ux/[filename].md`?" — except i
|
||||
> **Status**: In Design
|
||||
> **Author**: [user + ux-designer]
|
||||
> **Last Updated**: [today's date]
|
||||
> **Platform Targets**: [target platforms and input methods from 2h]
|
||||
> **Template**: HUD Design
|
||||
|
||||
---
|
||||
@@ -390,19 +414,37 @@ Ask: "May I create the skeleton file at `design/ux/[filename].md`?" — except i
|
||||
|
||||
---
|
||||
|
||||
## HUD Elements
|
||||
## HUD Element Specifications
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Dynamic Behaviors
|
||||
## HUD States by Gameplay Context
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Platform & Input Variants
|
||||
## Information Hierarchy
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Visual Budget
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Feedback & Notification Systems
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Platform Adaptation
|
||||
|
||||
[To be designed]
|
||||
|
||||
@@ -414,6 +456,18 @@ Ask: "May I create the skeleton file at `design/ux/[filename].md`?" — except i
|
||||
|
||||
---
|
||||
|
||||
## Tuning Knobs
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Open Questions
|
||||
|
||||
[To be designed]
|
||||
@@ -667,8 +721,9 @@ Update `production/session-state/active.md` with:
|
||||
Before presenting options, state clearly:
|
||||
|
||||
> "This spec should be validated with `/ux-review` before it enters the
|
||||
> implementation pipeline. The Pre-Production gate requires all key screen specs
|
||||
> to have a review verdict."
|
||||
> implementation pipeline. The Production gate (`/gate-check production`)
|
||||
> requires all key screen specs to have passed `/ux-review` at `workflow: full`
|
||||
> (recommended at `standard`)."
|
||||
|
||||
Then use `AskUserQuestion`:
|
||||
- "Run `/ux-review [filename]` now, or do something else first?"
|
||||
@@ -679,7 +734,7 @@ Then use `AskUserQuestion`:
|
||||
- "Stop here for this session"
|
||||
|
||||
If the user picks "Design another screen first", add a note: "Reminder: run
|
||||
`/ux-review` on all completed specs before running `/gate-check pre-production`."
|
||||
`/ux-review` on all completed specs before running `/gate-check production`."
|
||||
|
||||
### 6c: Cross-Link Related Specs
|
||||
|
||||
@@ -714,7 +769,7 @@ specific sub-topics, additional context or coordination may be needed:
|
||||
| Implementation feasibility (engine constraints) | `ui-programmer` — before finalizing component inventory |
|
||||
| Gameplay data requirements | `game-designer` — when data ownership is unclear |
|
||||
| Narrative/lore visible in the UI | `narrative-director` — for flavor text, item names, lore panels |
|
||||
| Accessibility tier decisions | Handled by this session — owned by ux-designer |
|
||||
| Accessibility tier decisions | Recorded by this session (`/ux-design accessibility`; the user picks the tier) against the criteria `accessibility-specialist` defines and audits — consult it when a requirement's criterion is unclear |
|
||||
|
||||
When delegating to another agent via the `Agent` tool:
|
||||
- Provide: screen name, game concept summary, the specific question needing expert input
|
||||
@@ -764,4 +819,4 @@ Verdict: **COMPLETE** — UX spec written and approved section by section.
|
||||
|
||||
- Run `/ux-review [filename]` to validate this spec before it enters the implementation pipeline
|
||||
- Run `/ux-design [next-screen]` to continue designing remaining screens or flows
|
||||
- Run `/gate-check pre-production` once all key screens have approved UX specs
|
||||
- Run `/gate-check production` once all key screens have approved UX specs
|
||||
|
||||
@@ -68,7 +68,7 @@ categorization from Section B.
|
||||
|
||||
---
|
||||
|
||||
#### Section D: HUD Elements
|
||||
#### Section D: HUD Element Specifications
|
||||
|
||||
For each element in the layout, specify:
|
||||
- Element name and category (Must Show / Contextual / On Demand)
|
||||
@@ -83,14 +83,16 @@ exist for status displays, resource bars, or cooldown indicators.
|
||||
|
||||
---
|
||||
|
||||
#### Sections E, F, G: Dynamic Behaviors, Platform Variants, Accessibility
|
||||
#### Sections E–L: HUD States, Information Hierarchy, Visual Budget, Feedback & Notification, Platform Adaptation, Accessibility, Tuning Knobs, Acceptance Criteria
|
||||
|
||||
These parallel the UX spec's States, Interaction, and Accessibility sections.
|
||||
The guidance you need is below — **do not load `sections-ux-spec.md`; one mode
|
||||
file applies per invocation.** For the HUD, apply it as follows.
|
||||
|
||||
**Dynamic Behaviors (states over time).** Beyond the happy path, capture what
|
||||
changes the HUD mid-gameplay and present it as a table for approval:
|
||||
**HUD States by Gameplay Context (states over time).** Cover at least
|
||||
exploration, combat, dialogue/cutscene and paused — `/ux-review` checks for all
|
||||
four. Beyond the happy path, capture what changes the HUD mid-gameplay and present
|
||||
it as a table for approval:
|
||||
|
||||
| State / Variant | Trigger | What Changes |
|
||||
|-----------------|---------|--------------|
|
||||
@@ -102,7 +104,22 @@ changes the HUD mid-gameplay and present it as a table for approval:
|
||||
Ask specifically: what causes the HUD to change density mid-gameplay
|
||||
(combat vs. exploration), and what fades, pulses, or slams in on each transition?
|
||||
|
||||
**Platform Variants.** Does mobile/console require different element sizes or
|
||||
**Information Hierarchy.** Give every element in HUD Element Specifications a
|
||||
priority tier — MUST KEEP, SHOULD KEEP, CAN HIDE or ALWAYS HIDE — with the reason,
|
||||
and what carries its information when it is hidden (a sound, a diegetic cue, or
|
||||
nothing). This is the order the Visual Budget below drops elements in.
|
||||
|
||||
**Visual Budget.** State the maximum number of simultaneous HUD elements and
|
||||
the maximum share of the screen the HUD may cover, and which elements are dropped
|
||||
first when a state would exceed it.
|
||||
|
||||
**Feedback & Notification Systems.** One row per transient notification type
|
||||
(pickup, XP gain, objective update, achievement) — trigger system, screen position,
|
||||
duration, max simultaneous, priority and **queue behavior**: what happens when two
|
||||
arrive at once, which are held during combat, and which are never queued.
|
||||
`/ux-review` checks that every notification has queue/priority behavior defined.
|
||||
|
||||
**Platform Adaptation.** Does mobile/console require different element sizes or
|
||||
positions? Note per-platform overrides — touch targets, safe-area insets, and
|
||||
whether any element moves or is dropped on a given platform.
|
||||
|
||||
@@ -118,3 +135,14 @@ exists, then walk this checklist for the HUD:
|
||||
If no accessibility tier has been defined for this project, note the gap in the
|
||||
HUD design's Open Questions section (WCAG-AA is a reasonable baseline) and
|
||||
continue without stopping.
|
||||
|
||||
**Tuning Knobs.** List every player-adjustable HUD setting — overall scale,
|
||||
opacity, per-element show/hide, subtitle size — with its range and default.
|
||||
|
||||
**Acceptance Criteria.** At least 5 checkbox criteria a QA tester can verify
|
||||
without reading another document — `/story-done` closes HUD stories against
|
||||
them. Cover at least: safe-zone margins on every target platform, the correct
|
||||
elements in each gameplay context above, the visual budget (screen share in
|
||||
exploration and in combat), one accessibility criterion for the committed tier,
|
||||
and notification queueing. Section 12 of `.claude/docs/templates/hud-design.md`
|
||||
has worked examples.
|
||||
|
||||
@@ -199,6 +199,19 @@ Present the data requirements as a table:
|
||||
|
||||
---
|
||||
|
||||
#### Section F2: Input Method Completeness Checklist
|
||||
|
||||
One checklist block per input method in the spec's **Platform Target** line —
|
||||
keyboard, gamepad, mouse, touch; drop the blocks for methods this game does not
|
||||
support and say so. Take the items from section 11 of
|
||||
`.claude/docs/templates/ux-spec.md` (reachability, tab/d-pad order, visible
|
||||
focus, focus trap for modals, Esc/back behavior, hit-target sizes, controller
|
||||
disconnect). Tick an item only when the Interaction Map above already specifies
|
||||
it; an unticked item is an open implementation question — list it under Open
|
||||
Questions rather than ticking it.
|
||||
|
||||
---
|
||||
|
||||
#### Section G: Accessibility
|
||||
|
||||
Cross-reference `design/accessibility-requirements.md` if it exists.
|
||||
|
||||
Reference in New Issue
Block a user