jpmschweitzer/settled-reach
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(docs): assign teams to v0.2 story tickets (#614-#626)

Browse Source 
Resolve Q-WTF-039 (tile-scale heavy zoom, not portrait — D-146) and
Q-WTF-040 (aesthetic taste trait as shared root — D-147). Split #617
into server generator + client rendering, split #620 into server
culture resolution + client location picker. Sprint 28 candidate list
with 7 unblocked tickets.

Ticket: #676

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
jpmschweitzer
2026-03-17 08:10:29 +01:00
co-authored by Claude Opus 4.6
parent 2fddf8b6ca
commit 0d18c76dfa
5 changed files with 210 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
decisions/scope.md
+14 -1
View File
@@ -287,4 +287,17 @@ What we're building: game concept, design pillars, prototype definition, map spe
---
*25 decisions (16 active, 9 superseded). Last updated: 2026-03-15 (D-145 added)*
### D-146: Character creation preview — tile-scale sprite with heavy zoom
- **Date:** 2026-03-17
- **Decision:** The character creation screen shows the player character's game sprite at heavy zoom — the same top-down tile-scale rendering used in gameplay, rendered at high resolution so it holds up when zoomed in. No separate portrait rendering system. Cosmetic choices (hair, clothing, colors) update the zoomed sprite in real time. Rimworld uses this exact approach: the character customization screen shows the same pawn sprite rendered larger, with clothing/equipment layers visible.
- **Rationale:** The tile-scale sprite IS the player's character for the entire game. Showing it zoomed in character creation: (1) sets accurate expectations for in-game appearance, (2) reuses the production sprite/animation pipeline — zero new rendering infrastructure, (3) validates that cosmetic customization (#619) reads correctly at game scale, (4) keeps #618 as a single client ticket with no visual-team split. A separate portrait system would be a one-off rendering context (different camera, lighting, asset pipeline) that serves no other game feature. "CK3-style" in the bookmark concept refers to the bookmark structure, not the portrait aesthetic. Portraits can be added later as an additive feature if needed.
- **Team implication:** Ticket #618 (CK3-style character creation screen) stays as a single `client` team ticket. No split required.
- **Source:** Sprint 27 planning pass — Q-WTF-039 resolution
- **Raised by:** Tyre (architecture), Paula (narrative), Gestalt (systems), confirmed by project lead
- **Dissent:** Ozzie argued for portrait render (emotional attachment). Overruled: tile-scale at heavy zoom provides sufficient character identity without a second rendering pipeline.
- **Cross-reference:** [D-115](#d-115-character-creation-scoped-to-skills--bookmark-for-v02) (creation scope), [D-134](content.md#d-134-full-character-customization) (full character customization), [D-136](architecture.md#d-136-first-settled-reach-moment-auto-generated-apartment--insert-activation) (first game moment), ticket #618 (CK3-style character creation screen)
- **Resolves:** Q-WTF-039
---
*26 decisions (17 active, 9 superseded). Last updated: 2026-03-17 (D-146 tile-scale heavy zoom)*