Kevin
220f70d342
shared/tile-inventory.json + shared/roll-tables.json + shared/GAME-REVIEW.md
+ shared/BRANCHING-TEMPLATE.md were parsed from the design doc in a separate
session and were already sitting untracked in this repo. This is the real,
authoritative game content — 211 tiles across 12 segments, 5 player stats
(cash/love/education/wealth/age), 48 placeholder roll tables — far more
complete than the hand-sketch-inspired board built earlier.
Adds shared/tileInventory.js and shared/rollTables.js: mechanical
`export default {...}` wrappers around the same JSON (kept as-is alongside
them as the raw source reference), so the content is importable both by the
server and by the browser fetching shared/*.js with zero bundler — the same
pattern every other file in shared/ already uses. Avoids relying on JSON
module import-attribute syntax, whose support is uncertain on node:20-alpine
(the Dockerfile's base image).
Also includes assets/colors.json and assets/tile_types.json (an apparently
separate, incomplete transcription of the hand sketch) — not wired into
anything yet, just brought into version control.
Appends integration-gap TODOs to GAME-REVIEW.md: 85 inline_table tiles have
a die size but no table content anywhere in the parsed files; payday/
cash_bonus amounts are undefined everywhere; multi-table roll_table_ref
tiles (2-3 tables at once, 22 of them) have no documented combination rule.
3.1 KiB
Life Journey — Branching / Adjacency Template
The design doc lists tiles in order within each segment, but it does not say how the twelve segments connect, or where the forks and merges are. That wiring is what turns a pile of tile-lists into a playable board graph. Fill this in and I'll turn it into a connection map the game can walk.
The twelve segments (as parsed, in doc order)
| # | Segment id | Tiles | First tile → Last tile |
|---|---|---|---|
| 1 | starting_strip |
7 | Graduation party → STOP |
| 2 | career |
22 | Pay Day → STOP |
| 3 | investment |
20 | Pay Day → Dice Space |
| 4 | investment_bottom |
23 | Pay Day → Dice Space |
| 5 | high_risk |
11 | Dice Space → Dice Space |
| 6 | gap_year |
17 | Pay Day → STOP |
| 7 | education |
12 | Pay Day → Graduation Gift |
| 8 | relationship_top |
20 | Pay Day → Aging Parents |
| 9 | relationship_bottom |
26 | Pay Day → … |
| 10 | retirement_top |
11 | Pay Day → Hobby |
| 11 | retirement_middle |
22 | ½ Life Crisis → … |
| 12 | retirement_bottom |
20 | Pay Day → … |
The (top)/(bottom)/(middle) names strongly suggest parallel lanes on the
physical board — that's exactly the geometry only your layout knows.
What I need — two things
1. The STOP forks
There are 3 STOP tiles (end of starting_strip, career, gap_year). Each
says "roll D8 to age, then pick your new path." Tell me the choices at each:
STOP after starting_strip → player may choose: [ career | education | gap_year ] ← confirm/edit
STOP after career → player may choose: [ ? | ? | ? ]
STOP after gap_year → player may choose: [ ? | ? | ? ]
(Do investment / high_risk / relationship / retirement also branch off a STOP, or are they entered some other way? Note it.)
2. Segment connections (the graph)
For each segment, tell me what its entry connects from and what its exit connects to. Easiest format — just fill the arrows, referencing segment ids and tile numbers (0-indexed within the segment):
career: enters from STOP#1 → exits to STOP#2
investment: enters from ?? → exits to ??
investment_bottom: enters from ?? → exits to ??
high_risk: enters from ?? → exits to ??
...
If a segment has a mid-path fork or merge (e.g. tile 8 of career splits to
investment tile 0 AND continues to tile 9), write it like:
career tile 8 → forks to: career tile 9 OR investment tile 0
relationship_top tile 19 → merges into retirement_top tile 0
Don't worry about being formal — bullet points in plain English are fine. Photos or a rough hand-drawn arrow diagram of the board work too; I'll translate.
What happens after you send this
I convert it into a board-graph.json — every tile gets a next (or list of
next for forks) so the game can move tokens along real paths. Only then do
coordinates get authored (against the real artwork), because a token's screen
position and its graph position are two different things and both need the final
layout to exist first.