Axe'n'Stax Build Roadmap

Priority shift 2026-04-17 (ADR-003): PWA Alpha is now the active phase. Remaining Phase 1 multiplayer work is paused until alpha testers are in and giving feedback. See docs/architecture/ADR-003-pwa-first-for-alpha.md.

Phase 0 — Foundation (DONE)

~11K lines of Rust, ~20K lines of specs

• Custom wgpu renderer with chunk meshing, day/night, water
• Movement, physics, collision, flight
• Block placement/destruction, inventory, crafting (2x2 + 3x3)
• Combat, mobs, mob AI, spawning, biomes
• egui UI: splash, world management menu, HUD, crafting screen, pause menu
• World save/load with metadata
• Procedural 16x16 textures
• Multiplayer scaffolding (GameServer, PlayerSlot, Transport abstraction)
• 8 spec documents covering the full platform vision
• World Integrity Ledger (one-way flags: pure_survival, ever_creative, cheats_used)
• Basic creative mode (invulnerability, flight, instant break)
• Difficulty selector (peaceful/easy/normal/hard) with integrity logging
• Game mode selection at world creation (survival/creative)
• Autosave (5-minute intervals, crash recovery)

Phase 1α — PWA Alpha (NOW)

The gate: alpha testers play in a browser and give feedback

Execution doc: docs/superpowers/plans/2026-04-15-pwa-alpha.md Design doc: docs/superpowers/specs/2026-04-15-pwa-alpha-design.md Rationale: docs/architecture/ADR-003-pwa-first-for-alpha.md

• WASM build green — engine compiles to wasm32-unknown-unknown, runs in Chromium with WebGPU
• Touch input — virtual joystick + buttons for tablet/phone
• Signet login — two paths:
• QR (cross-device relay mode) — phone scans QR, signs, Signet app publishes the NIP-17 gift-wrapped response to wss://relay.trotters.cc; the browser-side signet-verify.waitForAuthResponse SDK subscribes, unwraps, and verifies. No backend poll.
• Same-device button (redirect mode) — links to mysignet.app, approves, redirects back via HMAC-signed fragment handoff. Accepts the ~5–10s page reload cost.
• Persistent local session — pubkey cached in localStorage after first auth; subsequent visits skip the auth flow entirely before first paint. "Switch user" clears and re-auths. Home-device play feels like any other PWA.
• Local-first world storage — worlds saved to IndexedDB only (no cloud for alpha). Clearing browser data loses worlds; acceptable trade for alpha simplicity.
• Cloud save — SHIPPED — encrypted cloud save (the Stash primitive) landed during alpha as the user-visible "Save to cloud" / Sync Stash feature; worlds are no longer IndexedDB-only.
• Single-player only — multiplayer over WebRTC is post-alpha
• Open access — anyone with a Signet identity can sign in. No per-pubkey gate; the friction is owning a Signet identity, not approval.
• Live server — HTTPS, domain, TLS cert, production host.
• Chromium-only scope — Chrome / Edge / Chromium Android. Firefox/Safari deferred.
• Daily build-test workflow (docs/workflow/daily-build-test.md) driven by PWA-hosted builds

Why first: The native gameplay loop works. The blocker is distribution — testers can't practically run the binary (especially on Chromebooks). PWA removes that friction and unlocks the feedback loop that Phase 1/2/3 priorities depend on. See ADR-003.

Delivered during the alpha (2026-05 → 06)

Shipped on top of the alpha gate, beyond the original Phase 1α plan:

• Encrypted cloud save — the Stash primitive; "Save to cloud" / Sync Stash, plus the lobby Stash Column (browse an npub's open Stash to adopt skins and play their Experiences, distributed over Beacon).
• The Workshop — reskin and reshape blocks and mobs in-game (blow-up-and-sculpt: Bellows cage, paint/carve, symmetry, pin-across-instances, per-block wardrobe).
• Experiences — two arcade scenarios, Hash Dash and Satori Rush, built for BTC Prague, on a reusable scenario seam.
• Native installers — a cross-platform packaging pipeline (Windows / macOS / Linux) feeding an OS-aware /download.
• Lobby feedback mailbox — serverless NIP-17 player↔dev feedback.
• Player onboarding — the twelve-step Learn journey + the player Wiki reference.
• Logistics — flat layer (shipped 2026-07-02) — auto-connecting rail bends (straights + corners, live-computed from neighbours) + flat floor cables (redstone-style, lie on the ground). Next: the elevation layer — 45°-locked ascending rails (cart vertical pathing + tilted ramp mesh; 45° is the natural voxel fit and MC-parity) and surface-mount cables that run up and along walls (90° surface turns, no ramp — beats redstone's floor-only limit). Future / exploration (parked, possible differentiator): shallower multi-block rail ramps (~26°, 2-across-1-up) and the associated non-45° cart physics — recorded so it isn't lost, not scheduled. Spec: docs/superpowers/specs/2026-07-02-rail-auto-connect-design.md.

Web tier: local-sandbox pivot (2026-06-27)

For UK compliance (hosting a service brings OSA/GDPR duties), the web build is now a login-free local sandbox — a taster. Web login, cloud Stash and multiplayer were retired on web and gated off; identity, cloud saves and multiplayer live in the free native download, and the in-game lobby nudges players there. (This supersedes the "Signet login — two paths" and "Cloud save — SHIPPED" items above for web — both remain on native.) Engineering spec + what shipped: docs/superpowers/specs/2026-06-27-web-local-sandbox-design.md.

Planned — "Take your worlds to native": web saves are local-only (IndexedDB), so give players a one-click way to carry their whole local profile to the desktop app. Separate, unbuilt spec — flagged here so it's on the map.

• Export everything — a single bundle of all local worlds plus trial progress (today's Export is one .axeworld per world; this is the whole-profile version).
• Native first-run import — on first launch the native app offers "Import your web worlds?" and ingests the bundle.
• Conflict / merge — the open design question: what happens when a player has already started on native (last-writer-wins by save version, keep-both, or prompt). Needs its own design; the append-only WorldSave invariant + the identity-tag / monotonic-version seams from docs/foundations/2026-06-10-offline-first-login-and-stash-sequencing.md make it tractable.

Phase 1 — Multiplayer Core (PAUSED — resume post-alpha)

The gate: two players in the same world

• PlayerIntent input abstraction — game loop reads intents, not raw keys (DONE)
• Gamepad support — Xbox/PS controllers via gilrs, stick/button mapping, menu nav (DONE)
• Controller-only play — auto-named worlds, D-pad menu navigation, disconnect auto-pause (DONE)
• Split-screen rendering — two viewports, two cameras, one window (DONE — Screen abstraction, render_world_viewport, side-by-side split)
• Split-screen gameplay — two PlayerIntents, two players, shared world (DONE — per-player tick/frame/HUD, multi-player save/load, Player 2 join flow)
• LAN co-op — QUIC transport (quinn crate), client-server over local network. Foundation built: protocol.rs (packet types, serialization, LZ4 chunk compression), network.rs (QUIC transport via quinn+tokio, bridged to sync game loop), discovery.rs (UDP broadcast LAN discovery), hosted_server.rs (server thread with QUIC accept loop + LAN broadcast), menu UI (Host Game / Join Game / direct connect dialog). See docs/research/2026-04-01-lan-co-op-research.md. Remaining: input serialization over network (Phase D), state sync (Phase D), remote client chunk streaming (Phase C).
• Server authority — server owns world state, clients predict + reconcile
• Player sync — position, actions, block changes replicated
• Shared world persistence — save/load works with multiple players
• Binary distribution — website serves release binary for download + Linux prerequisites. HTTPS with self-signed cert for Games Master mic access on LAN devices.

Why first: Everything downstream (hosting, payments, scaling) requires multiplayer. Controller support is a prerequisite for split-screen — two players can't share a keyboard.

Phase 2 — Hosted Worlds

The gate: someone else can run a server

• Dedicated server binary — headless mode, no renderer
• Server browser / direct connect — join by IP or discovery
• Plug-and-play NAT traversal — UPnP auto-mapping, STUN discovery, UDP hole punching, DERP-like relay fallback. See docs/research/2026-04-01-nat-traversal-multiplayer.md
• Nostr signaling — replace WebSocket signaling server with Nostr relay-based connection exchange (NIP-RTC)
• World configuration — game mode, spawn rules, permissions
• Basic anti-cheat — server-authoritative validation (no fly hacks, no speed hacks)
• Voice chat — WebRTC to Decented voice server, tied to game server (no Discord needed). Audio only, no DMs/links/files.
• Dominion (basic) — parent-controlled permissions: voice on/off, friends-only, join approval
• Chat system — in-game text communication

Why second: Self-hostable servers are the foundation of the platform model. NAT traversal must "just work" — no port forwarding, no tech knowledge. Voice chat replaces Discord with something parents can trust. See docs/research/2026-04-01-voice-chat-parental-controls.md.

Phase 3 — Gameplay Depth

The gate: Axolittle says "this feels like a real game"

• Tool progression — wood > stone > iron > diamond (mining speeds, durability)
• Expanded crafting — more recipes, smelting, tool repair
• Combat polish — knockback, attack cooldowns, mob drops, XP
• More mobs — skeletons, spiders, passive animals
• Audio — footsteps, block sounds, ambient, per-player audio routing
• World gen v2 — caves, ores, structures, trees variety
• Death & respawn — inventory drop, bed spawn points
• Companion screen MVP — RG35XX handheld (~£40) as controller + 3.5" second screen over WiFi. Four tabs: inventory (L1), map (R1), crafting browser (L2), ore scanner (R2). Physical buttons only, no touch. See docs/research/2026-04-01-companion-screen-rg35xx.md and docs/superpowers/specs/2026-04-01-companion-screen-design.md.
• Companion connection — WiFi primary (TCP, application-level, no OS trust), USB-C for charging only. Game host can run WiFi hotspot for car/LAN scenarios. Companion never touches keys — Heartwood is process-isolated.

Why here: Gameplay depth needs multiplayer context to test properly (balance, fairness, PvP). The companion screen needs inventory and crafting to be deep enough to warrant a second screen. And it's what keeps Axolittle engaged for testing.

Phase 4 — Web Client (WASM)

The gate: play in a browser

• WASM build — compile engine to WebAssembly + WebGPU
• Asset streaming — textures and chunks over HTTP
• WebRTC transport — browser-compatible networking
• PWA wrapper — installable, offline-capable shell
• Touch controls — mobile-friendly input (stretch goal)
• Console hardware targets — Pi 5 (£80 entry), N100 mini PC (£130 budget), AMD Ryzen 5 6600H / Beelink EQR6 (~£250, RDNA 2 GPU sweet spot), N305 (~£200 CPU-only sweet spot). Native builds, controller-only, HDMI to TV. See docs/research/2026-04-01-console-hardware-research.md.
• Chromebook support — WASM/WebGPU build plays in Chrome browser with no install. Chrome already supports WebGPU.
• Dual-screen support — two monitors on one box (dual HDMI), each player gets full screen. Or player + sidecar (companion/tutorial/stream on screen 2). Uses multi-window wgpu via Screen abstraction.
• Car mode — N100 box under seat, dual HDMI to headrest screens, WiFi hotspot for companion handhelds, USB-C charging. Fully offline local play.
• GPU tier auto-detect — render distance slider, auto-pick settings based on hardware capability

Why here: Web access massively expands reach. The Pi 5 console is a statement piece — open source hardware running open source software earning real Bitcoin. Both are distribution plays that need the game to be worth distributing first.

Phase 5 — Bitcoin Integration

The gate: mine a block, earn sats

• Hash-on-mine mechanic — SHA256 on every pickaxe strike, reward on difficulty match
• Noncustodial wallet — derived from Nostr 12-word seed, built into client. Companion screen shows wallet balance and mining stats.
• LNbits integration — payment hub for Lightning micropayments
• Revenue splits — server operator / platform / player splits via keysend
• Signet age verification — Bitcoin testnet for under-18 accounts
• Creator kit — server monetisation tools, tournament payouts

Why here: Bitcoin is the business model, but it requires stable gameplay, multiplayer, and hosting infrastructure underneath it. Premature integration would distract from the game.

Phase 6 — Platform Services & Paid Hosting

The gate: launch as a platform, not just a game

• Nostr identity — player accounts, parent/child accounts (nsec-tree derivation). Heartwood on console holds family key tree — keys never leave the device, signing is process-isolated (Tor-only). Console security model: dedicated Linux box running Rust binaries, no browser, no random apps — safer than any alternative a normie family uses today.
• Matchmaking — Open Match or custom session directory
• Kubernetes + Agones — fleet management, autoscaling, region routing
• World lifecycle — sleep/wake, snapshots, migration between hosts
• Paid hosting launch — Starter (£3-8/mo), Community (£15-30/mo), Creator (£50-150/mo)
• Auto-sleep billing — worlds shut down when empty, cost only when active
• Admin dashboard — player count, performance, ban management, world backups
• Moderation tools — reporting, bans, content filtering
• Resource packs — community textures, server-specific assets
• WASM plugin system — server-side mods in sandboxed WASM

Hosting model: Free relay for everyone (£50/year to run). Self-hosted always first-class. Paid tiers for managed servers. Revenue from hosting fees + Bitcoin mining splits. See docs/research/2026-04-01-hosting-business-model.md.

Phase 7 — Scale & Events

The gate: 500+ concurrent players in one world

• Distributed region simulation — world split across workers
• Spectator tiers — full interactive / limited / view-only
• Celebrity worlds — 10K+ viewers with tiered presence
• Event tier hosting — tournaments, charity streams, game launches (custom pricing)
• BitLaunch billing — infrastructure costs paid from transaction flow
• CDN for assets — global texture/chunk distribution
• Portal system — cross-world travel
• Broadcast feed — server-side stream for Twitch/YouTube integration
• Creator referral system — join links with Nostr pubkey tagging, referral % of mining rewards
• Live earnings OBS overlay — real-time sats-mined widget for streamers
• Tournament mode — brackets, Bitcoin prize pools, leaderboards
• Highlight / clip system — capture key moments for content

The flywheel: YouTubers earn from hosting + mining splits + referrals. Players earn from mining. Servers pay for themselves. See docs/research/2026-04-01-youtuber-flywheel.md.

Progress

Phase 1α is the active critical path — alpha testers drive Phase 1+ prioritisation. Phase 1 multiplayer work resumes once alpha feedback is flowing. Phase 4 retains console hardware, Firefox/Safari support, and dual-screen work; the Chromium-PWA scope moves to Phase 1α. Phase 5 can start once Phase 2 is stable.