Kevin d40bc09867 Phase 1: reducer, SQLite, rooms & invite links
Turns the Phase 0 deployment shell into a playable async multiplayer game:

- shared/game.js + shared/board.js: pure reducer (reduce(state, action) ->
  newState) over a small branching board subset mirroring the sketched
  design (Career/Education fork, Relationship/Investment fork, High-Risk/Safe
  fork, race to Finish). Dice randomness is generated server-side and shipped
  inside the ROLL action payload, so the reducer itself stays fully pure and
  is identically importable by both server and browser.
- server/db.js: SQLite (better-sqlite3) schema for games/players/tokens,
  config and state stored as JSON. tokens covers both room invite links and
  per-player reconnect secrets.
- server/rooms.js: in-memory room registry that is the only place the shared
  reducer is invoked server-side — validates intents, applies actions,
  persists, and broadcasts to every socket in the room.
- server/index.js: REST endpoints to create/join/inspect a game, and a
  room-aware /ws that authenticates via a first {type:'AUTH'} message rather
  than a URL query param (keeps session tokens out of access/proxy logs).
- public/client.js + public/index.html: NetworkTransport wrapping the
  WebSocket, localStorage-backed session persistence so a reload resumes as
  the same player, and a lobby/waiting-room/game-view UI.
- Dockerfile: adds python3/make/g++ so better-sqlite3's node-gyp fallback
  builds on Alpine when a prebuilt binary isn't available for the exact
  Node/musl combo.

Verified: shared/game.test.js (node --test) covers the full rules engine;
a scripted two-client run over real HTTP+WS confirms both clients converge
on identical state through create/join/start/play-to-finish; a server
restart mid-game preserves state and reconnect resumes the same player
without creating a duplicate.
2026-07-21 17:10:56 -07:00
2026-07-21 16:17:12 -07:00
2026-07-21 20:48:28 +00:00
2026-07-21 14:16:59 -07:00
2026-07-21 16:17:12 -07:00

Life Journey — Phase 1

An async multiplayer, Game-of-Life-style board game. Phase 0 proved the deployment path (Docker → Nginx Proxy Manager → HTTPS → WebSocket). Phase 1 adds the actual game: a pure shared reducer, SQLite persistence, and rooms with shareable invite links, so a few people can play together across devices and tab closes.

The server is the sole authority over game state. It generates the only source of randomness (the dice roll) and applies it through the exact same reducer (shared/game.js) the browser imports — client and server can never disagree about the rules.

What's here

lifegame/
├── docker-compose.yml
├── Dockerfile
├── package.json / package-lock.json
├── shared/
│   ├── board.js          # the Phase 1 board graph + movement helper
│   ├── game.js            # pure reducer: reduce(state, action) -> newState
│   └── game.test.js        # node --test coverage of the whole rules engine
├── server/
│   ├── index.js           # REST + WebSocket, static hosting
│   ├── rooms.js            # in-memory room registry, applies/broadcasts actions
│   ├── db.js               # SQLite schema + data access (games/players/tokens)
│   └── ids.js               # id/token/join-code generation
└── public/
    ├── index.html          # lobby / waiting room / game UI
    └── client.js            # REST wrappers + NetworkTransport (WebSocket)

Running locally

npm install
npm test          # reducer unit tests — no server needed
npm run dev        # starts on :3000, creates data/lifegame.db on first game

Open two browser tabs at http://localhost:3000. Create a game in one tab, copy the invite link, open it in the other tab, join, and start the game once both players are in the lobby.

The board (Phase 1 subset)

The full hand-drawn board (assets/game_board.png) has ~150 spaces across two thematic passes (Career, Education, Gap Year, Relationship/Family, Investment, High Risk). Phase 1 encodes a small subset with the same shape — a Career-vs-Education fork, a Relationship-vs-Investment fork, a High-Risk-vs-Safe fork, converging to Finish — enough to prove the reducer, persistence, and rooms all work end to end. More spaces can be inserted into any branch later without touching the reducer or database schema.

Deploying on the homelab

Same as Phase 0 — see homelab-config.md for the full infrastructure reference. Set PUBLIC_URL in .env (or the compose environment) to your public domain so invite links generated by the server are shareable rather than pointing at an internal address:

cd ~/homelab/lifegame
docker compose up -d --build
docker compose logs -f      # expect: "Life Journey (Phase 1) listening on :3000"

Data & backups

The lifegame-data volume (mounted at /app/data) holds lifegame.db — every game, player, and token. Back it up like your other self-hosted data; losing it loses every in-progress and finished game.

What's next

  • Expand shared/board.js toward the full sketched board
  • Richer board rendering (the current UI is a functional list view, not the illustrated board)
  • Tighter reconnection/presence handling (who's online right now, not just who's joined)
  • Admin page (ADMIN_PASSWORD, already stubbed in .env.example)
S
Description
Mairins Version of The game of life
Readme 22 MiB
Languages
JavaScript 92%
HTML 7.7%
Dockerfile 0.3%