Multiple characters under one login

backlog priority 3 estimate L

server-architecture/022 · created 2026-08-31 · updated 2026-08-31

Kris, 2026-08-31: “at some point I’m thinking we might want to allow multiple characters under the one login — not now.” This file is the requested sketch of what the change looks like, written while 021’s single-identity model is fresh; it is a design note in backlog form, not scheduled work.

What changes — DB

New characters table: id, account_id FK → accounts, display_name, character_seed, entity_id (UNIQUE — the body id moves here from accounts), created_at, last_played_at.
accounts slims to auth-only: keep id, created_at, banned_at; its display_name / character_seed / entity_id columns migrate away.
Boot migration (idempotent, additive): for every existing account, mint one character row from the account’s current three fields — nobody loses their adventurer.
sessions gains active_character_id (nullable FK) — which character this device is playing.
account_collections: decide whether the element collection is per-account (shared knowledge across your characters — likely, per the trading design) or per-character. Per-account = no schema change.

What changes — director

signup_email / provider signup: same one transaction, now inserting account + identity + FIRST character together.
New messages: create_character {displayName, characterSeed}, select_character {characterId} (stamps the session); optional delete_character is a DECISION, not a given (the no-delete-anything rule from 019 may extend here).
whoami returns characters: [...] plus the session’s active one; join grants (join_home_area etc.) resolve entity_id / display_name from the ACTIVE CHARACTER, not the account.
Home Areas: today ensureHomeArea is per-account. The one real design fork: per-character homes (each adventurer their own front door — more Areas, portals need a “whose home” answer) vs one shared family home per account (cheapest, no portal changes). Decide before building.
Protocol version bump (whoami shape changes); old clients refused as usual.

What changes — client

account_session.gd: track active_character_id; signup_email unchanged in shape; new create_character / select_character calls.
account_flow.gd: the signed-in view’s character panel becomes the character list/picker (the 70%-sized preview per character, tap to select, a ”+ new adventurer” tile reusing the existing signup character step).
Remembered logins already store one seed per account — becomes “the last played character’s seed”; no format change needed.
e2e harness (game/test-device/): extend the driver’s loop with create-second-character → switch → verify the overhead name changes.

What does NOT change

One account ↔ one auth identity (021’s model) — characters multiply UNDER the login; the login stays singular.
Sessions/auth flow, the entry sheet, the sign-in screens.

View source in repository · also available as raw markdown.