chore(meta): plan Sprint 28: Character Visuals
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude Opus 4.6
@@ -0,0 +1,103 @@
|
||||
---
|
||||
title: "Sprint 28 — Planning Briefing"
|
||||
description: "Character visuals planning workshop and character creation screen wireframe"
|
||||
type: sprint
|
||||
status: planning
|
||||
sprint: 28
|
||||
team: "planning"
|
||||
---
|
||||
|
||||
# Sprint 28: Character Visuals — Planning Tasks
|
||||
|
||||
**Goal:** Move beyond placeholder art to final product candidate character visuals, from design specs through asset production and compositor implementation.
|
||||
|
||||
**Branch:** `planning`
|
||||
**Agents:** Araminta (art direction — proposer), Gestalt (systems — proposer), Tyre (technical — proposer), Ozzie (player experience — proposer), Qatux (documenter — records decisions, updates domain files), SI (project manager — creates follow-up tickets, updates sprint assignments)
|
||||
|
||||
## New Tickets
|
||||
|
||||
| # | Title | Blocked by |
|
||||
|---|-------|------------|
|
||||
| #684 | Character visuals planning workshop | — |
|
||||
| #685 | Character creation screen wireframe | #684 |
|
||||
|
||||
Use `tooling/db/ticket show <id>` for full details.
|
||||
|
||||
## Key Decisions
|
||||
|
||||
- `decisions/architecture.md` — D-134 (full character customisation: hair, clothing, colors at tile scale), D-146 (character creation preview: tile-scale sprite with heavy zoom — NO separate portrait system)
|
||||
- `decisions/scope.md` — D-115 (character creation scope: superseded by Sprint 28 workshop), D-146 (tile-scale preview as the production approach)
|
||||
- `decisions/content.md` — D-147 (aesthetic taste as character personality trait — shared root for cosmetic + apartment expression)
|
||||
|
||||
## Notes
|
||||
|
||||
### #684 — Character visuals planning workshop
|
||||
|
||||
This ticket gates all downstream work in the sprint. Nothing else starts until this workshop outputs its spec documents.
|
||||
|
||||
**Discussion structure — three rounds:**
|
||||
|
||||
**Round 1 — Inventory and constraints**
|
||||
Each domain agent assesses their area:
|
||||
- Araminta: What does tile-scale readable character art require? What layer order is needed? Color mesh regions — how are they defined per sprite type?
|
||||
- Gestalt: What data model does the compositor (#693) need? How do layer stacks, color overrides, and 8-direction rotation map to a clean API?
|
||||
- Tyre: What does the Godot client need from the compositor? How does it plug into the existing `EntityRenderer` (`client/scripts/rendering/entity_renderer.gd`) which currently uses a single `Sprite2D` per entity?
|
||||
- Ozzie: What does the player need from the character creation screen? What are the emotional beats — first impression, customisation flow, confirmation?
|
||||
|
||||
**Round 2 — Specification proposals**
|
||||
Agents propose specs per deliverable. Each proposal must be concrete enough for Araminta to start drawing:
|
||||
- Body type spec: shapes, proportions, 8-direction rotation consistency rules, color mesh region definitions
|
||||
- Face type spec: feature range, skin tone mesh regions, expression state requirements
|
||||
- Hair style spec: silhouette guidelines, color mesh regions
|
||||
- Expression state list: named states, how expressions layer over base face
|
||||
- Scar/tattoo overlay spec: placement grid, additive blending rules
|
||||
- Injury overlay spec: damage state progression (states TBD — min viable: undamaged / light / heavy)
|
||||
- Clothing/apparel spec: layer ordering, occlusion rules, color mesh regions
|
||||
- Compositor API spec: layer enum, color override struct, direction enum, Godot node architecture
|
||||
|
||||
**Round 3 — Convergence and sign-off**
|
||||
Review proposals for consistency conflicts. Lock specs. Qatux records all decisions. SI creates any follow-up tickets identified during the workshop.
|
||||
|
||||
**Output specification — what this workshop must produce:**
|
||||
|
||||
1. `docs/design/character-visuals-spec.md` — complete spec document covering all layer types, color mesh regions, 8-direction rotation rules, layer ordering, and occlusion rules
|
||||
2. `docs/design/compositor-api-spec.md` — Godot-side compositor data model and node architecture
|
||||
3. Any new D-records filed to `decisions/` for architectural decisions made during the workshop (claim IDs before writing: `tooling/db/decision claim D <domain> "title"`)
|
||||
4. Workshop outcomes captured in `docs/workshops/character-visuals/workshop-outcomes.md`
|
||||
|
||||
**Important — D-146 is locked:** The character creation screen uses tile-scale sprite at heavy zoom. No portrait render. Do not reopen this question. Ozzie's dissent is on record.
|
||||
|
||||
**Important — D-147 is locked:** The `aesthetic_taste` trait is the shared root for cosmetic choices and apartment expression. The compositor does not pipeline choices into the apartment generator. Do not reopen this question.
|
||||
|
||||
### #685 — Character creation screen wireframe
|
||||
|
||||
Produces the UI layout artifact that drives client implementation (#694).
|
||||
|
||||
**Scope:** Collaborative design between the planning team and Jeroen (project lead) using Frame0 (or equivalent wireframing tool). This is a design document, not a code deliverable.
|
||||
|
||||
**Coverage:**
|
||||
- Layout of all layer selection controls (body, face, hair, clothing, accessories, scars, tattoos)
|
||||
- Preview pane position and scale (tile-scale sprite at heavy zoom — D-146)
|
||||
- Color picker / palette selector UX
|
||||
- Randomise button placement
|
||||
- Navigation: how player confirms, goes back, returns to main menu
|
||||
- Keyboard navigation flow (must support controller/keyboard-only — existing character_select.gd is keyboard-friendly)
|
||||
|
||||
**Output:** `docs/design/character-creation-screen-wireframe.md` — annotated wireframe (or image file at `docs/design/character-creation-wireframe.png` if drawn). This is the acceptance input for #694 (Character creation screen, client team).
|
||||
|
||||
**Dependency note:** #685 must complete before #694 starts. The wireframe IS the spec for the client implementation.
|
||||
|
||||
## Dependency Chain
|
||||
|
||||
```
|
||||
#684 (workshop) → #685 (wireframe) → unblocks #694 (client: creation screen)
|
||||
#684 (workshop) → unblocks ALL visual team tickets (#686–#692)
|
||||
#684 (workshop) → unblocks #693 (client: compositor) via #686 (body type sprites)
|
||||
```
|
||||
|
||||
## PR Workflow
|
||||
|
||||
When ready to submit planning artifacts, create a PR with `tea` CLI. **All flags are required** to avoid TTY prompts (see `CLAUDE.md` "Gitea access" section):
|
||||
```bash
|
||||
tea pr create --repo jpmschweitzer/settled-reach --login schweitz --title "chore(meta): character visuals planning workshop outputs" --description "body" --base main --head planning
|
||||
```
|
||||
Reference in New Issue
Block a user