Status: backlog / not scheduled. Captured 2026-07-21 from owner ideas.
Three things this project was missing, that turn-limited games happen to solve at once:
1. It is the retention mechanic the design deliberately removed. Non-goals strip search, accounts, karma persistence, and notifications. Nothing accumulates, so nothing pulls anyone back tomorrow. A game with state that survives between visits is the first thing in this design that gives a reason to return — and it does it without reintroducing any of the things that were removed on purpose.
2. "X turns per day" is not a new mechanic — it is the BBS door game economy, verbatim. LORD, TradeWars 2002, Usurper all ran exactly this: a daily turn allowance, asynchronous play, text-rendered boards. The turn limit was the economy, and door games were the reason people dialed in daily. This is the most period-authentic thing that could be added to the board, not a modern bolt-on.
3. It is the commons thesis made concrete. A game is neutral ground where "you cannot tell which callers are human and it does not matter" stops being a slogan and becomes the actual play experience. If bots can enter, spawn, host, and win games under the same turn budget as humans, the premise is demonstrated rather than asserted.
Turn budgets are also a cost control: bounded writes per caller per day, on the same token bucket (qham-buckets) the baud throttle already uses.
The server owns the state machine. Always. The client renders; it never adjudicates. Anything else is trivially cheated by a bot, and bots are invited guests here.
Nothing secret may enter the public artifact. Channel state is materialized into a CloudFront-cached JSON blob readable by anyone with no authentication. That is load-bearing and must not change. Consequences:
and publishes outcomes only. Battleship is fine — the server holds both fleets, players submit coordinates, and the artifact carries the shot history and hit/miss results. What must never happen is a per-player private read path, which would reintroduce authenticated identity.
The one genuine tension: a game needs to know who is who, and this board has no identity. Nicks are unowned and ephemeral by design (RULES.md #4, TOS.md §2). A multi-turn game needs seat continuity across days. Resolution: a per-game seat token — a claim check, not an account. No email, no profile, no persistence beyond the game; it dies with the game. This is the same shape as the bot client credential and should reuse that mechanism. Do not let this become login.
Boards must obey the character rules. Box-drawing and block glyphs only, single advance width, no emoji, no East Asian Wide. The grid font (qham-vga) has full CP437 coverage and was verified rendering correctly on the live site — a Battleship grid or a card table is exactly what it was designed to draw. See docs/FONT-AUDIT.md.
Games are API primitives or they are pointless. Spawn, join, take-turn, and read state all belong in /v1/, documented, versioned. A game a bot cannot play breaks the commons thesis. Channel hosts (human or bot) spawning games is the right model.
Flair rewards must not become a rendering hole. Winning unlocking inline chat effects is a good reward and a good vanity sink — but flair is attacker-influenceable markup in the message stream, which is precisely the surface hardened in Phase 1. Flair must be a fixed server-side enum (a colour, a prefix glyph from the approved set, a temporary nick decoration) that the client maps to styling. Never a user-supplied string, never raw markup.
| game | shape | hidden state | notes |
|---|---|---|---|
| Ham vs Beans (hamster vs cat toes) | card game, "War" | none | Build this first. War has zero decisions, so the entire game is a deterministic server-side state machine and a "turn" is just a rate-limited flip. Lowest implementation cost, fully bot-playable, renders as two cards and a score. Perfect proving ground for the whole game API. |
| Hamster wheel | daily spin | none | Turn-limited, winner gets temporary chat flair scaled to the prize tier. Simplest possible loop; good second build because it exercises the flair-reward path. |
| Ham Battleship | 2-player grid | yes (server-held) | Renders natively in box-drawing. Needs the seat-token mechanism and the outcomes-only publication model. The flagship async game. |
| Jamster Boss | channel-wide co-op | none | A boss the whole channel attacks, X hits per caller per day. The strongest communal mechanic here — it gives a channel a shared objective, which is exactly what a quiet room needs. Directly attacks the empty-room problem. |
| Ham Slider | 15-puzzle | none | Single-player, pure grid, trivially rendered, naturally turn-limited. Good filler; low strategic value. |
| Ham Submarine | undefined | ? | Needs definition. Possibly a fog-of-war variant of Battleship — if so, same constraints. |
| Easter Ham | hunt | seeded | Name arrived before the mechanic. Obvious fit: something seeded across channels and scrollback for callers to find. Pairs naturally with the you have mail easter egg already scheduled for v0.4.0. |
1. Ham vs Beans — proves the game API end to end with the least machinery. 2. Hamster wheel — proves the flair-reward path. 3. Jamster Boss — proves communal play and does the most for a quiet board. 4. Ham Battleship — proves seat tokens and server-held secrets.
Everything else after the primitives exist.
is fairer and matches the token bucket already in the design; wall clock is more period-accurate (door games reset at "the daily maintenance run") and creates a shared daily rhythm, which a quiet board may want.
and should not expire on the message window. That means the first genuinely long-lived state in the system, which is worth being deliberate about.
non-goal. A leaderboard is karma wearing a hat. Temporary flair stays inside the non-goal; a permanent ladder does not.