Roadmap #

Current baseline #

Single-player Timed and Free Play support icosahedron and octahedron boards at subdivisions 1–10. Scenarios, checkpoints, recovery, and finished runs retain explicit board metadata.

Public scenario search, player pages, a leaderboard directory with populated starting levels, direct play links, and score submission from Game over are implemented. Published and guest results remain unverified summaries. Music selection and sound effects have independent controls.

Multiplayer foundation #

The existing GameSession owns ordered commands, deterministic RNG and timing, a read-only game view, and validated snapshots and restore. It has no DOM or Three.js dependency. Preserve this boundary rather than replacing the engine. See the session contract.

The score-race design keeps each player's simulation local. A separate match coordinator owns membership, readiness, scheduled start and finish, disconnect policy, and reported results. It relays read-only observations rather than simulating opponent boards. Scores and timing are client-trusted; the coordinator does not verify that a player earned their reported result.

The shared scenario, board, seed, starting level, and rules stay fixed for each race. Individual pause and restart are unavailable. Live match transport stays separate from AT Protocol publication and AppView indexing.

Opponent boards need a display without gameplay input or an opponent simulation. Their cameras belong to the observer; their logical focus and placement preview come from remote observations. Profile the four-player layout before optimizing it; remote displays do not need placement indexes.

Implemented multiplayer slice #

The first slice provides an invite-only, fixed-duration score race for 2–4 players:

1. Create and join a room with the same scenario, starting level, and seed; hosts can fill open seats with basic bots for solo playtesting.
2. Start local sessions after a synchronized countdown, without individual pause or restart. Compare reported scores at the match deadline.
3. Show live opponent boards, including moving previews and logical focus; allow independently rotating and enlarging them while play continues.
4. Keep connection status separate from elimination/forfeit, and share ranks for tied scores. Finish early once the sole active player has a strict lead over every finished opponent.
5. Recover current match state and observations on reconnect; resuming active play requires the player's local checkpoint. Missing recovery means forfeit.

Tests cover room access, bounded messages, stale-observation rejection, match timing, disconnect/reconnect, and disposal of local and opponent displays. Browser checks exercise both supported polyhedra and four-player rendering. Matchmaking and rankings can follow.

Deferred work #

• More capable bot controllers; the initial bot deliberately uses a simple, replaceable move policy.
• Attack mechanics and other battle rules, following the score-race foundation.
• Public matchmaking, multiplayer rankings, and spectator-only guests.
• Replay recording and verification for separately verified results.
• Survival races and stronger server authority if the competition needs them.
• Eligibility controls and moderation for public content and submissions.
• Tetrahedron boards and other polyhedra.
• Account-synced resumable checkpoints; current named saves remain local.

These features are separate from the score race. Public replay verification is distinct from a live server enforcing a match's rules.