Headline summary
Design and implement a shared src/ui/Renderer API (moderate scope) and migrate Main Street + The Mind to use it; include a moderate API (container/HUD/card rendering helpers + SVG adapter wiring), adapters, tests, and migration docs.
Problem statement
Multiple game scenes implement ad-hoc rendering helpers (container creation, HUD refresh, SVG card wiring), leading to duplication and "god-class" scene files. We need a shared renderer module that exposes a stable, moderate API and per-game adapters to simplify scene code and enable consistent rendering patterns across games.
Users
- Engine maintainers: easier maintenance and single place to fix rendering bugs.
- Game authors (Main Street, The Mind): smaller scene files, consistent helpers, and easier onboarding to engine patterns.
- QA: reliable integration tests and fewer rendering regressions across games.
Example user stories
- As an engine maintainer, I want a shared renderer API so fixes and improvements benefit multiple example games.
- As a Main Street dev, I want to replace duplicated HUD/container helpers with shared functions and keep scene behaviour identical.
- As a QA engineer, I want integration tests that verify Main Street and The Mind render equivalently after migration.
Success criteria
- API design: src/ui/Renderer exports a moderate API including container creation, HUD helpers, refresh patterns, and card rendering adapter hooks; public function signatures documented.
- Migration: Main Street and The Mind use the shared renderer via per-game adapters; scene tests for those games remain green.
- Tests: Unit tests for shared helpers added and passing; browser-level integration smoke tests for Main Street and The Mind demonstrate equivalent rendering (no missing elements, no test regressions).
- Docs: Migration guide in docs/ (usage examples, adapter pattern, and list of moved helpers) added.
- Build & tests: Full project test suite passes locally and CI (npm test; npm run build).
Constraints
- Moderate scope: implement a focused API (not a full facade). Avoid introducing multiple runtime strategies (DOM vs Canvas) in this first PR; prefer a single SVG/texture adapter using existing SvgHelpers.
- Keep migration changes minimal per-scene: replace 1–3 helpers per scene and provide adapters that re-export old names where feasible to reduce caller churn.
- Maintain browser and headless test compatibility.
- Do not change game mechanics or visual assets; this is a refactor/migration only.
Existing state
- Scenes contain duplicated rendering helpers; several work items note "god class" scenes (e.g., Decompose TheMindScene, Decompose MainStreetScene).
- There are prior migration/renderer items: CG-0MP12WBH70045LNE (Shared Renderer blocked), CG-0MOZMT7G80090Y6S (Extract SVG & card rendering), and other decomposition items.
- SvgHelpers exist at src/core-engine/SvgHelpers.ts and will be used for SVG rasterisation where needed.
Desired change
- Design a moderate src/ui/Renderer API that includes:
- container creation helpers (createHudContainer, createZone)
- HUD refresh helpers (refreshHudText, bindTooltip)
- card rendering adapter hooks (rasteriseCardSvg(scene, key, svgPath) wrapper that calls SvgHelpers.getOrCreateTexture)
- Implement per-game adapters for Main Street and The Mind that re-export or adapt existing helper names used by those scenes.
- Move 1–3 helper functions from each target scene into src/ui/Renderer and update callers to use adapters.
- Add unit tests for moved helpers and browser integration smoke tests for Main Street and The Mind.
- Add docs/DEVELOPER.md migration note with examples and adapter pattern guidance.
Related work
Potentially related docs (file paths)
- example-games/main-street/scenes/MainStreetScene.ts and MainStreetRenderer helpers
- example-games/the-mind/MindRenderer.ts and current MindCardRenderer
- src/core-engine/SvgHelpers.ts — raster helpers
- docs/DEVELOPER.md — update with migration note
Potentially related work items
- CG-0MP12WBH70045LNE — Shared Renderer (blocked)
- CG-0MP12VWO1003YL55 — this item (Shared Renderer)
- CG-0MOZMT7G80090Y6S — Extract SVG & card rendering into shared helpers and migrate Sushi Go
- CG-0MM1OP07Q16TUTHI — God class: Scene files exceed 1400-1850 lines
Appendix: Clarifying questions & answers
- Q1: "Scope/type — should this be: A) task (small), or B) epic (design stable API and migrate multiple games)?" — Answer: "B" (user). Source: interactive reply. Final: epic.
- Q2: "Initial game targets — for the first PR, should we adapt: A) Main Street only, B) Main Street + The Mind, or C) Main Street + The Mind + Sushi Go?" — Answer: "B" (user). Source: interactive reply. Final: Main Street + The Mind.
- Q3: "API surface — prefer: A) Minimal helpers, B) Moderate (container/HUD/card rendering + SVG adapter), C) Broad/full facade?" — Answer: "B" (user). Source: interactive reply. Final: Moderate API.
Idempotence note
This draft updates existing work item CG-0MP12VWO1003YL55. Re-running intake will update the same work item and will not duplicate Appendix entries.
Headline summary
Design and implement a shared src/ui/Renderer API (moderate scope) and migrate Main Street + The Mind to use it; include a moderate API (container/HUD/card rendering helpers + SVG adapter wiring), adapters, tests, and migration docs.
Problem statement
Multiple game scenes implement ad-hoc rendering helpers (container creation, HUD refresh, SVG card wiring), leading to duplication and "god-class" scene files. We need a shared renderer module that exposes a stable, moderate API and per-game adapters to simplify scene code and enable consistent rendering patterns across games.
Users
Example user stories
Success criteria
Constraints
Existing state
Desired change
Related work
Potentially related docs (file paths)
Potentially related work items
Appendix: Clarifying questions & answers
Idempotence note
This draft updates existing work item CG-0MP12VWO1003YL55. Re-running intake will update the same work item and will not duplicate Appendix entries.