Build Plan — Game Loop on Our Engine

Status: living doc. Owner: Oleg + Mariana. Audience: public — we publish our launch thinking in the open.

The Game-First Loop Reference doc picks the loop (cozy-frontier build). This doc grounds it in what we have actually shipped, names the one architectural decision that gates everything, and gives a specific, prioritized build order mapped to real files. The source of truth for "what ships" is public/world/src/main.mjs (Spike 48), not the architecture docs and not the blog hero.

Where we actually are (code-grounded)

Cinevva World today is a persistent, multiplayer, browser WebGPU sandbox: a world owner sculpts a fixed ~1 km island, places props from a curated Quaternius / medieval / downtown kit, can drive those same edits through an OpenAI tool-calling AI Builder, and shares it with visitors who see each other's avatars and edits in near-real-time. It is a sandbox, not yet a game.

Capability	State	Where (real files)
Persistent multiplayer world (presence + shared editing)	Shipped	public/world/src/main.mjs + transport.mjs + worker/src/world-chunk-do.ts
Terrain sculpt + procgen island presets	Shipped	terrain.mjs, brushes.mjs, procgen-terrain.mjs
Prop placement + scatter recipes (curated kits)	Shipped	scatter/library.mjs, props/store.mjs, scatter/recipes.mjs
AI Builder (chat to ~20 tools, executes + persists + syncs)	Shipped	worker/src/world-designer.ts, shared/world-designer-tools.ts, hud/ai-assistant.mjs
Spatial voice, ambient audio, water/weather, grass/wind, animal NPCs	Shipped	voice/, ambient/, water/, grass.mjs, npc/
Worlds CRUD, publish, visits, reactions, cover, insights	Shipped	worker/src/worlds/
Game loop: quests, objectives, score, progression	Missing entirely	none in world code
Plot claiming in a shared overworld	Schema only, unused	world_plots (migration 0021), perms.ts canClaim; no API, UI, or write path
Creator economy (tips, marketplace)	Stubbed off	hud/render.mjs TIP_ENABLED=false (needs Stripe Connect)
User GenAI assets placed in-world	Not wired	genai/ pipelines exist (hunyuan3d, sam3d, flux, elevenlabs) but no world_inventory and no "place in world" path
LLM NPC dialogue, in-world text chat	Missing / mocked	roadmap only; the SPA chat feed is static HTML

The headline: Bet 1 (game first) is 100% unbuilt in code. Everything shipped is scaffolding around a sandbox. The highest-value move is to add the smallest real loop on top of what already works, not to build more sandbox.

The gating decision (resolved): one shared world with claimable territory

We are committing to one shared world where people claim territory, not a grid of separate per-creator worlds. This is what the public essay always implied (the three-layer world: shared ground, your claimed deposit, your personalized path), and the evidence for territory-claiming as a retention engine is strong — provided claims sit on top of a loop and are earned, not sold. The three layers map cleanly:

• Shared ground = the one world everyone spawns into, curated to a high bar. The meeting place. Buildable and seedable today with shipped tools.
• Claimed territory = your earned plot, which you build, decorate, and defend. This is the endowment-effect retention engine and the "unique deposit" the essay wants. Neighbors co-build adjacent claims, so co-building is how a district fills in, not a replacement for ownership.
• Personalized path = quests routing you across the shared world toward landmarks and other people's territory.

Why it's feasible, and the successful cases. Territory claiming on a shared, persistent world is one of the most durable retention mechanics in multiplayer, when it rides a game:

• Minecraft Towny and Factions are the closest analog and have been among the most-played server modes for over a decade. You claim land chunk-by-chunk on top of a shared survival/PvP world; Towny adds towns, nations, taxes, and protected resident builds, Factions adds raidable territorial conquest. Retention comes from social investment, economic progression, and the security of owned, protected assets. The design key (straight from the Towny docs) is that you "can't run rampant claiming massive amounts of land without working for it" — claims are earned and must be adjacent, which keeps the world dense instead of sprawling.
• Reddit r/place shows the viral ceiling of shared-canvas territory claiming: ~1M users in 2017, ~6M users and 72M pixels in 2022, with communities self-organizing to claim, defend, and contest space. It worked because it was free, equal, social, and about the process and community, not ownership-as-investment.
• The psychology underneath is well-established: psychological ownership plus the endowment effect (owners value what's theirs roughly twice as much; losing it triggers loss aversion) plus the IKEA effect (you value what you built). The actionable rule from that literature is exactly our alpha plan: deposit ownership in the user's hands within the first session, and make it feel earned rather than gifted.

The two traps, and the rules that avoid them. Claiming fails in two specific, well-documented ways:

1. Land-as-speculation (Decentraland, The Sandbox): make land a scarce investable product and you get billion-dollar valuations sitting on dozens of daily users. The fix: territory is earned by playing/building, never sold as an investment, and value is utility (a place to do things with neighbors), not price.
2. Empty-plot sprawl (Horizon Worlds: ~9% of created worlds ever visited by 50+ people): if everyone gets an isolated private plot, you manufacture a graveyard of empty rooms. The fix is Towny's: claims must be adjacent to existing claims and to the shared ground, so the world grows as a connected, walkable place, and the shared meeting layer stays the default destination.

So the design rules are: earned, adjacency-gated, protected, utility-not-speculation, with a high-bar shared meeting place that is always the spawn.

Where our code already is. We are not starting from zero. The scaffolding exists: a world_plots table (migration 0021), a worlds.allow_plot_claims flag, and a canClaim permission hook in perms.ts. What's missing is the claim handler/API, the claim UI, and per-plot edit permissions — and the Durable Object already enforces per-object locks, which is the same capability applied to a region. So a minimal claim system is an extension of existing scaffolding, not a greenfield build. This reverses the earlier draft of this doc, which deferred plots for alpha; with this direction, a lean claim system is in scope.

Minimum viable loop, in build order

Ranked by leverage. Each item is tagged reuse / extend / new and names the system it touches. The throughline: the creative act is assembly, not generation. Most of what we need to make assembly fast already ships; AI is an optional accelerant, not the main path.

1. A goal and an objective tracker. (NEW, small, critical path.) This is the only missing core piece and the entire point of Bet 1. Build a lightweight milestone state for a short founder objective chain (arrive, claim your first territory, make your first build, reach the landmark, leave your mark). Implement as client objective state synced through the existing Durable Object (same path as edits and reactions); reuse visit logging (world_sessions) and the reactions endpoint for telemetry. Do not build a generic quest engine; hardcode the alpha chain.

2. A minimal territory-claim system. (EXTEND scaffolding, core to the loop.) Turn the existing world_plots / allow_plot_claims / canClaim scaffolding into a working claim: a claim handler/API, a simple claim UI ("claim this spot"), and per-plot edit permissions on top of the DO's existing per-object locks. Keep it lean and follow the rules above — earned (claiming is a step in the Founders' Quest, not a store), adjacency-gated (you claim next to the shared ground or an existing claim, so the world stays dense), and protected (only you and invited neighbors edit your plot). Ownership is the retention engine; deposit it in session one and make it feel earned.

3. The creator aha: assemble something recognizable in under 60 seconds with the tools we already have. (MOSTLY SHIPPED — package it.) The aha is not "wait for an AI to generate a model." It is "I claimed a spot, sculpted a hill, dropped a cabin from the medieval kit, scattered a pine grove around it, and it's mine." Terrain sculpt, click-to-place modular kits (2m snap, 90-degree rotate), scatter recipes, and region painting all ship today. The work is packaging them into a guided first build plus the quick-build helpers below, so a newcomer makes a recognizable thing fast and reliably, with no minutes-long wait and no quality lottery. This is the highest-leverage, lowest-cost move because the engine already does it.

4. Make assembly fast and delightful with new building tools. (NEW / EXTEND — see The assembly toolkit.) Snap-kit polish, one-click auto-build, blueprints/stamps with a starter library, duplicate/array/mirror, and a decorate mode. These turn "place objects one at a time" into "assemble a scene in a minute," which is what actually clears the 60-second creator aha and brings builders back.

5. An idle / return hook. (NEW, minimal.) Grow a Garden's habit engine needs a progression substrate we do not have. Do not build an economy. Build the minimum that gives a reason to return tomorrow: one shared landmark that visibly progresses as founders contribute (a co-built monument), or a daily founder objective. Reuse DO persistence for the state.

6. Onboarding: time-to-fun under 60 seconds. (EXTEND.) Editing currently requires sign-in plus world membership. For the alpha hero world, let an invitee make their first build immediately and defer the hard account gate, per the 2026 cold-start consensus (Game-First Loop Reference, Trend 6). Route concurrent founders into the same area (the engine already renders remote avatars and edits) instead of building matchmaking.

7. AI as an optional accelerant, never a blocking step. (REUSE, demote.) The AI Builder already drives the same manual tools (place_props, scatter_paint, sculpt_terrain), so keep it as an assistant for the tedious parts ("scatter a pine forest on the north ridge," "line this path with lamps") and as an idea starter, not the primary creation path. On-demand model/texture/audio generation (hunyuan3d, sam3d, flux, elevenlabs) stays async and in the background: generation takes minutes and the quality is inconsistent, which disqualifies it as the 60-second aha. The right use is to pre-generate and curate a large, vetted, ready-to-place library so users assemble from a deep catalog instantly. Wiring a user's own completed generations into a placeable inventory is still worth doing as a variety source and a "deposit your unique creation" mechanic, but it is one input to assembly, not the aha itself.

The assembly toolkit (what we have, what to build)

Shipped today. Terrain authoring (sculpt brushes raise/lower/smooth/flatten on heightmap, build/carve/round on marching-cubes; procgen island presets; region/topology painting). Prop placement (click-to-place from curated kits — Quaternius nature, medieval village, downtown city — transform gizmo, select, group delete, 2m-grid snap with 90-degree rotation, per-object lock). Scatter (recipe-driven painting — forest, meadow, beach — gated by slope/altitude/topology, footprint-aware spacing). Environment (weather/water tuning, grass, ambient audio). This is already a serious assembly kit; most users will never need more than this plus the additions below.

Worth building, researched against the games that nailed assembly:

1. One-click auto-build (Townscaper-style). Townscaper's whole magic is "driven Wave Function Collapse" over a marching-cubes tileset: you click to mark a cell solid and the system auto-assembles the walls, roofs, arches, stairs, and backyards that fit the shape — no skill, instant, beautiful. We already run the marching-cubes lineage Townscaper itself is built on, so this is the most on-brand fast-assembly tool we could add and the strongest single candidate for the 60-second aha.
2. Blueprints / stamps plus a starter prefab library. Every assembly-first platform lets you save a build and re-place it: Fortnite Scene Graph prefabs, UEFN named JSON "stamps," LEGO prefabs/galleries, The Sims gallery rooms. Add: save any selection as a named, editable, re-placeable blueprint, and ship ~15-30 team-built starter prefabs (cabin, campfire, market stall, dock, garden) so a newcomer assembles a whole scene in seconds. The DO already persists arbitrary object records and group-select exists, so the substrate is there.
3. Duplicate / array / mirror. LEGO's Ctrl-drag duplicate is a staple; add line/array-along-a-path and mirror-across-an-axis. One fence becomes a perimeter, one column becomes a colonnade. Cheap to build, large jump in perceived power.
4. Snap UX polish. Ghost preview with green/red validity, snap-point cycling, and a hold-to-free-place override are the conventions in Valheim, Fortnite, and Brickadia. Our 2m kit snap already exists; this makes it feel professional and removes the main cause of build frustration (misaligned pieces).
5. Decorate mode (snap-to-surface). Placement onto walls, shelves, and ceilings, the way The Sims build/buy and Animal Crossing decorating work. Turns dressing an interior from fiddly to fast and leans into the cozy audience.
6. Co-build, surfaced as a feature. We already sync shared editing, and collaborative building is the 2026 cozy trend (Animal Crossing 3.0 added 12-player collaborative island decorating; Hometopia and The Creator: Live Together are built entirely around real-time co-design). Founders co-building one island is both the social hook and the supply engine.
7. More themed kit palettes / galleries. Fortnite-style galleries of curated, themed assets to pick from. Variety the user gets instantly, with no wait on generation.

What to reuse as-is (do not rebuild)

Multiplayer presence and shared editing (main.mjs + WorldChunkDO), DO persistence (props, terrain blobs, topology, weather), procgen island presets for the ~30% AI seed, spatial voice, ambient audio, water/weather/grass, reactions and visit logging for telemetry, worlds CRUD/publish/Discover. These are shipped and load-bearing; the loop sits on top of them.

What NOT to build for alpha

• A land market or any tradable/sellable territory. Claims are earned by playing, never bought or speculated on — that is the Decentraland trap. A claim economy, if ever, is a Phase 3 question.
• Faction warfare / raiding / contested territory. Alpha ships Towny-style protected claims (they fit the founding-citizen tone); contested territory is a deliberate future expansion, not an alpha feature. See Future expansions.
• Tipping and marketplace (correctly stubbed; tips round to zero at 50 users anyway, per Metrics).
• LLM NPC dialogue, in-world text chat, mobile auto-tier, Yjs/CRDT, bitECS. Roadmap, not alpha.
• Any "world model" framing. We are the persistent-shared-world opposite of Genie (Game-First Loop Reference, Trend 3).

Honest risks specific to our build

1. There is no loop at all yet. Bet 1 is entirely unbuilt; the objective tracker, the claim system, and the idle hook (items 1, 2, and 5) are net-new and on the critical path to even testing the thesis.
2. Assembly has to feel fast and good, or there is no aha. The bet now rests on the building tools, not on generation. If snapping is fiddly or the first build takes more than a minute, the creator funnel stalls. One-click auto-build and the snap polish in the toolkit are there to de-risk this; prove the 60-second build on a fresh account early.
3. On-demand generation is too slow and too inconsistent to sit on the critical path. Minutes of latency and a quality lottery mean it cannot be a step in the first session. This is a known constraint, not a risk to discover: keep generation async and curated, and lead with hand assembly.
4. Claiming can fragment the world if we get the rules wrong. The two failure modes (empty-plot sprawl, land-as-speculation) are specific and avoidable: enforce adjacency so claims grow a connected place, keep claiming earned-not-sold, and keep a high-bar shared meeting ground as the default spawn. Watch the seeded-vs-claimed visit ratio (per Metrics) for early signs of sprawl.
5. The shipped SPA still leans per-creator-worlds. The code, the essay, and the SPA copy were not aligned; this doc resolves it toward the shared world with claims. Align the SPA copy and Discover so we are not building a claim loop the front end fights.

The alpha, concretely

Operate one shared Founders' Island. Seed ~30% of the shared ground with procgen presets, the AI Builder, and team showcase builds (all shipped). Invite the ~50 (top 3D-asset generators first, per Alpha Playbook); each claims a territory adjacent to the shared ground and assembles something they own in their first session. Ship items 1 through 7. Measure the one number that matters: does a cohort return in week 2 unprompted (Metrics north-star), and do claimed plots get visited and built on rather than abandoned. Everything here is falsifiable against that curve. If we cannot stand up a real loop on this engine, that is itself the most important finding, and we want it fast and cheap.

Future expansions (post-PMF)

These are deliberately out of scope for alpha and only worth building once protected claims show the retention curve flattening. They amplify a working loop; they do not fix a missing one.

Contested territory. The most promising expansion of the claim system, and the evidence is encouraging: Minecraft Factions has sustained shared-world territorial conquest for over a decade, and r/place showed the viral ceiling of contesting space on a shared canvas. Design it so it deepens the loop without breaking the founding-citizen tone:

• Opt-in contested zones, not a global rule change. Keep the core shared ground and home territories protected (the Towny model). Designate separate frontier/wilds zones where claims can be contested, captured, or co-occupied, so players choose the stakes. The protected world stays the default; conquest is a place you go to.
• Soft conflict before hard conflict. Start with non-destructive contests — influence, flag-capture, build-offs, community voting — rather than base-raiding and griefing, which carry real moderation and trust costs and clash with the cozy tone. r/place-style claim-and-defend is a softer template than Factions-style raiding.
• Earned, never speculative. Same rule as the base system: territory is won by playing, never bought, and a player's invested home plot is never raidable. Conflict happens only in zones designed for it.
• Gate it on the data. Build this only after protected claims prove out on the Metrics north-star (cohort returns, claimed plots visited and built on, not abandoned). Contested territory is an amplifier, not a remedy.