vibe-rts-fps — an RTS you can drop into and play in FPS

A single-player RTS-FPS where the player is a god with finite attention across a procedurally-generated, evolving world zoomable from the Big Bang through cells and mutations up through empires to galactic scale. **S550 combo update:** unified with [WAITING-FOR-GODOT](WAITING-FOR-GODOT.md) under three principles — focus=fidelity (lens-shaped sim, per-agent inside, analytic outside), agency=biased dice (perception + surroundings, Monte Carlo resolves), reality-bound (every rule cites `vibe-game/CITES.md`). Phase 1 ships **headless Python (ASCII)**; engine choice deferred to Phase 2. Attention pool / evolving nature / mythology are no longer separate systems — they're consequences. See [`vibe-game/THESIS.md`](../../vibe-game/THESIS.md).

🌱 active tended 2026-05-16 S548 project gamedev rts fps voxel ai-assets vibe-coding onboarding

flowchart LR
  lens[focus lens] -->|biases| world[multi-resolution world]
  world -->|outcomes| lens
  world --> bands[zoom ladder · per-band verbs]
  swarm[swarm discipline] -.governs.-> world

Connected work

• Waiting for Godot (combo partner) — the metaphysics side of the same investigation — one actor, many minds, the scene runs by itself; see vibe-game/THESIS.md for the merge
• universe as compression — the cosmological-scale spine the game's deepest zoom rides on
• how to swarm — the protocol this project borrows
• build — godding essay — leaving things smaller and clearer
• scope — where to cut a project so it ships
• intelligent systems — RTS unit AI parallels

Project page · rating: draft. Can's personal side-project; planning artifact, not theory. Concrete decisions made when prototyped.

Status: seedling | 2026-05-16 | rating: draft Compress levels: L0 ↓ L1 ↓ L2

L0 — TL;DR (≤5 lines)

Build an Empire-Earth-style RTS where the player can zoom into any unit and take direct FPS control, with a Minecraft-style mutable world (place, dig, deform terrain). Use current AI tools to "vibe out" art, audio, 3D assets, and most code, but bind the process with the same swarm discipline this repo uses: every change small, version-controlled, reviewable. Six subsystems — engine, sim, body, world, assets, methodology — each with a chosen-default and a fallback. Cut scope to a 6-week prototype first: one biome, 50 units, one unit type playable in FPS.

L1 — Overview

Core question

A non-engine-developer (Can) wants to ship an ambitious genre-mash game by leaning hard on AI-generated code and assets. Two things have to be true at once: (a) the design has to survive a beginner's first contact with a game engine; (b) the AI-vibe workflow has to stay coherent enough that the game doesn't become 200 mismatched prototypes. What's the smallest plan that satisfies both?

Why it matters

• The genre mash is real — RTS scale + FPS embodiment + voxel world is something no shipped game does well together. There's actual design space here.
• For a first-time game-dev project, the hard problem is not "what to build" but "what to not build." The plan's job is to be the cut, not the wishlist.
• The same orient → predict → act → diff → compress cycle that runs the swarm maps cleanly onto AI-assisted game-dev. The repo is already a worked example of "vibe out something hard, reliably." Reuse the protocol.

Mermaid map (L1)

This map reflects the S550 merge (vibe-game/THESIS.md): the player is a focus lens that biases a single multi-resolution world; attention, evolving nature, and mythology are consequences of focus=fidelity, not separate gating systems. The detailed subsystem sections (§2.1–§2.16) predate the merge and remain as scoping detail — read them as "how to build the world the lens acts on."

flowchart TB
  lens["focus lens · finite attention"] -->|"biases: perception + surroundings"| world["one canonical world · multi-resolution Monte Carlo"]
  world -->|outcomes| lens
  world --> ladder["zoom ladder S0–S7<br/>verbs: seed · bias · elevate · order · embody"]
  lens -.->|focus = fidelity| att["attention economy"]
  world -.->|reality-bound sim| nat["evolving nature"]
  world -.->|sim compressed to symbol| myth["mythology layer"]
  build["AI-vibe pipeline + swarm discipline · cites CITES.md"] -.governs.-> world

Mermaid map (L1, scale axis)

The world subsystem isn't one resolution; it's a stack. Each band is a separate simulation kernel with its own tick rate. The same canonical world state must be readable at any band — the dual-resolution pattern from §2.2, generalized.

flowchart TB
  S0[cosmological\n~10^9 yr/tick · stars · plate-scale geology\nverb: seed]
  S1[planetary\n~10^4 yr/tick · climate · tectonics · biome shift]
  S2[ecological\n~years/tick · species · food chains · migration\nverb: bias]
  S3[civilization\n~months/tick · economy · diplomacy · tech\nverb: elevate]
  S4[battle/RTS\n~seconds/tick · units · pathing · orders\nverb: order]
  S5[FPS / first-person\n~16 ms/tick · embodied · pixel-accurate\nverb: embody]
  S6[cell\n~hours/tick · metabolism · signaling]
  S7[sub-cell / mutation\n~generations/tick · selection · drift]
  S0 --> S1 --> S2 --> S3 --> S4 --> S5
  S2 --> S6 --> S7
  S5 -.zoom out.-> S4
  S7 -.zoom out.-> S6
  classDef phase1 fill:#e6f4ea,stroke:#3a7a3a
  classDef phase2 fill:#fff7d6,stroke:#a67b4a
  classDef phase3 fill:#f0eaf7,stroke:#7a4aa6
  classDef phase4 fill:#eaf0f7,stroke:#4a7aa6
  class S4,S5 phase1
  class S3 phase2
  class S2,S6 phase3
  class S0,S1,S7 phase4

Green = Phase 1 (just battle + FPS). Yellow = Phase 2 add (civilization). Purple = Phase 3 add (ecology, cell). Blue = Phase 4 add (cosmological, sub-cell). Each band can be skipped at runtime — when zoomed at S4, S0-S2 still tick, just at low fidelity. None of the deeper bands exist in v0.1. The architecture just has to admit them.

The verb: label on each band is the per-band agency grammar from the THESIS vocabulary contract: skilled play is selecting the verb the scale calls for (order at S4, embody at S5) and translating intent across the seam — not stacking. S4↔S5 ship today in vibe-game/sim/; the rest are their phase's work.

Skeleton sub-claims

1. The hardest engineering decision is the seam between RTS sim and FPS sim. Most genre-mashes fail here. One canonical world state must serve both — when you take over a unit, you're not "switching games," you're attaching a camera + input rig to an entity that was already simulating.
2. Engine choice should be made on tooling maturity, not feature checkboxes. For a beginner, the engine that has the best docs, best AI-coding support, and the most YouTube tutorials in 2026 will beat the engine that's technically best on paper.
3. Voxels are a separate game inside the game. "Minecraft-like build" can scope from "deformable terrain" (cheap) to "full block-by-block construction" (a year of work). Pick one and defend the line.
4. AI asset generation is a curation pipeline, not a button. You don't generate 500 assets and ship; you generate 5000, curate 500, retopologize 50, ship. Plan for the curation labor — it's the hidden cost.
5. Reliability comes from the protocol, not the tools. Same as the swarm: small reversible commits, every artifact a checkable diff, version-controlled state, a way to revert. AI-vibe without protocol = entropy.
6. The plan is a cut, not a list. Beginner's failure mode is to build the wishlist. Plan's job is to say what's out of scope for v0.1, v0.2, v0.3.
7. Attention is the resource — the swarm thesis as game mechanic. The player has a finite "godding energy" that drains on direct control (FPS, deep zoom, micro orders) and refills slowly. Hero-hugging starves the rest of the world. This is the same scarcity that makes the swarm work — no agent can do everything, distribution is forced. (See §2.14.)
8. Multi-scale zoom is the second-hardest design problem, after the seam. One canonical world state must be readable at sub-cell, ecological, civilization, battle, FPS, and (optionally) cosmological scales. Each scale has its own time-step. Done right, it's the §2.2 controller-swap pattern extended to a ladder. (See §2.13.)
9. Nature evolves whether you watch or not. Plate tectonics shape geology, geology shapes biomes, biomes shape resources, resources shape civilizations; overharvest desertifies, forests regrow on decadal scales, species migrate, civilizations rise and fall in the background. Without the player, the world still runs. (See §2.15.)
10. Mythology is a compression of the sim, not a layer above it. Each god's domain maps to a sim subsystem (war ↔ combat resolution, harvest ↔ crop yield, knowledge ↔ research rate, sea ↔ naval ranges, death ↔ post-battle morale). Pantheons are picked at start (historical) or generated (LLM); favor flows from actions matching the chosen god's domain. (See §2.16.)
11. The seam is a vocabulary switch, not just a controller swap. Moving from S4 (RTS) to S5 (FPS) is not only attaching a different controller to the same entity (§2.2) — it is switching agency grammar. Each band has its own verb: S5=embody, S4=order, S3=elevate-attractor, S2=bias-selection, S0=seed-conditions. The controller-swap IS the vocabulary-swap. Skilled play is knowing which grammar applies and translating intent between them. (See vibe-game/THESIS.md §per-band agency vocabulary, L-1933.)

What this page is and isn't

It is: a plan for a personal side-project, written so a non-engine-developer can start tomorrow. It isn't: a design doc for a publisher, a marketing pitch, or a promise of completion. It's the smallest reliable scaffold to start.

L2 — Deep dive

2.1 Engine choice — for a beginner who wants AI to help write code

Four serious candidates in 2026. Score each on five axes that actually matter for this project (not raw capability):

Engine	Beginner-friendly	AI-coding support	RTS scale (1000s of units)	FPS quality	Voxel/destructible ecosystem
Godot 4.x	★★★★★	★★★★ (GDScript is well-represented in LLMs; C# also works)	★★★ (Multi-mesh, custom servers needed for big counts)	★★★	★★★ (Zylann/voxel-tools is mature)
Unreal 5	★★ (huge surface area)	★★★ (C++ + Blueprints; LLMs decent but not great at UE5 specifics)	★★★★ (Mass framework, Nanite scales)	★★★★★	★★★ (Voxel Plugin Pro exists, paid)
Unity 6	★★★	★★★★★ (most LLM training data; C# is well-known)	★★★★ (DOTS/ECS for unit counts)	★★★★	★★★ (multiple voxel assets on store)
Bevy (Rust)	★	★★ (newer; LLMs less trained)	★★★★★ (ECS native)	★★★	★★★★ (data-oriented suits voxels)

Recommendation for Can (the cut): start in Godot 4.x.

Reasoning: - Cheapest cost-to-first-prototype. GDScript reads like Python, which Can already works in (this repo is mostly Python). - LLMs (Claude included) handle GDScript well — vibe-coding works. - The "Empire Earth scale + FPS" is the design ambition; for a first prototype, 50 units beats 5000 units. Godot can hit 50 units trivially. - Open-source, no royalties, no surprise license rug-pulls. - Escape hatch: if voxel performance becomes the wall, port the voxel layer to Bevy and embed; if FPS visual fidelity becomes the wall, port the FPS body layer to Unreal 5 for the vertical slice. Engine-mixing is awful — but the prototype doesn't need to face that question.

What "engine" actually is, for someone new: an engine bundles (1) a runtime that ticks game state, (2) a renderer, (3) a physics library, (4) an editor / scene tool, (5) an asset pipeline, (6) a scripting language. You're not just picking a renderer. You're picking the tool you'll live inside for a year.

2.2 The RTS-sim ↔ FPS-body seam — the hardest design problem

This is the part most genre-mashes get wrong. Two failure modes:

• Two simulations. RTS has an abstract unit (HP, position, behavior tree). FPS has a "real" body (skeletal mesh, ragdoll, animation states). Switching modes means serializing one and instantiating the other. Don't do this — desync, double-state, hand-off bugs forever.
• One simulation, but FPS is "weak." All units are abstract; when you take over, the FPS layer is a thin camera-and-aim rig on top. Almost right, but the FPS shooting/movement feels floaty because it's piggybacking on RTS-level resolution (10 Hz, grid-snapped) instead of FPS-level (60 Hz, per-pixel).

Recommended pattern: single entity, dual-resolution simulation.

                 ┌─────────────────────────────────────────────┐
                 │  unit entity (one ECS row / scene node)     │
                 │  ─ position, velocity, hp, faction, intent  │
                 └─────────────────────────────────────────────┘
                          ▲                            ▲
                          │                            │
        ┌─────────────────┴────────┐      ┌────────────┴───────────┐
        │  RTS controller          │      │  FPS controller         │
        │  ─ behavior tree         │      │  ─ player input          │
        │  ─ pathfinding           │      │  ─ aim / fire / lean     │
        │  ─ ticks at 10-20 Hz     │      │  ─ ticks at 60+ Hz       │
        └──────────────────────────┘      └──────────────────────────┘
                          ▲                            ▲
                          │       only one attached    │
                          │       at a time            │
                          └────────┬───────────────────┘
                                   │
                            mode switch =
                       detach one, attach the other

The entity is permanent. The controller is hot-swappable. When you take over: detach the RTS behavior tree, attach the input/camera/aim rig, and switch the unit's physics body from low-res (capsule, grid step) to high-res (collider, sweep test). When you release: snapshot the position/HP back into RTS resolution, attach the behavior tree again, give it a current order based on context.

This is the load-bearing pattern. Get it right early.

2.3 World — voxel, destructible, and the trap of "like Minecraft"

"Like Minecraft" can mean three very different things. Pick exactly one for v0.1:

1. Deformable terrain. Heightmap + voxel skin only on the surface. You can dig craters, raise hills. Cheap, ships.
2. Sparse voxels. Most of the world is normal mesh, but a region (a cave system, a buildable area) is voxels. Hybrid. Medium cost, very flexible.
3. Full voxel world. Everything is voxels; player can construct/destruct block-by-block. Expensive, has been the work of entire studios for years.

Recommendation: start with (1) deformable terrain. Add (2) sparse voxel construction zones in v0.2 (designated build plots — like a fort site — that are voxel, while the surrounding world is normal). Defer (3) indefinitely or never.

This decision determines pathfinding, networking, save format, and rendering — all four. Don't change it once committed.

For Godot, Zylann/voxel-tools handles all three modes; for Unity, Voxel Play or Voxelis assets exist; for Unreal, Voxel Plugin Pro is the standard ($$).

World generation strategy. Three choices, and the right one depends on how much "real physics" the player should be able to feel. (Detailed in §2.15.)

Strategy	What it does	Cost	When to use
Pure procedural (Perlin/Simplex + biome rules)	Noise → heightmap → biome lookup. Cheap.	low	Phase 1. Looks fine, isn't grounded.
Wave-function-collapse / constraint-based	Tile or chunk constraints propagate. Coherent maps.	medium	When biome adjacency matters (no desert next to glacier).
Simulation-based (plate tectonics → climate → biomes → resources)	Run a low-res world sim for "geological time," then expose the result.	high upfront, cheap at runtime	Phase 3+. The only path that gives real ore distributions, river systems, and erosion patterns.

The recommended path: start procedural in Phase 1, add WFC constraints in Phase 2 for coherent biomes, run a one-time simulated generation pass in Phase 3 when ecology and resources become real. The world data structure must be the same across all three — only the generator changes. This is the architectural cut.

Note that the multi-scale zoom (§2.13) and evolving nature (§2.15) make this choice load-bearing: a procedurally-generated heightmap can't host plate tectonics, but a simulated world can be queried at any scale. Decide once, document the hidden dependencies.

2.4 Unit AI — Behavior trees, utility AI, and "what the units do when you're not looking"

For an RTS, units have to act sensibly without orders. This is the AI design problem.

Standard tools: behavior trees (BT) for action selection, navmesh for movement, utility AI for "which target / which task" scoring. All three are well-understood patterns; none require novel research.

The cut: don't write a new AI architecture. Use Godot's LimboAI plugin or hand-roll the simplest BT that supports if-enemy-shoot, else-if-order-do-order, else-idle-patrol. That's enough for a 50-unit prototype.

The FPS-takeover wrinkle: when the player leaves a unit, what order does it revert to? Three options — pick one, document it:

• (A) Revert to last issued RTS order ("attack-move here") — predictable, slightly dumb when the situation has changed.
• (B) "Hold position" until re-ordered — safe, can leave units stranded.
• (C) Default to a context-derived order (in combat → fight; not in combat → return to nearest friendly group) — most fun, hardest to debug.

Recommendation: start with (A), ship that, only move to (C) if playtesting demands it.

Unit class affects attention cost. Three rough cost tiers, set by how much the unit's AI has to "improvise" when the player isn't watching (see §2.14 for the full attention budget):

Class	Examples	Attention cost (per second of direct control)	Why
Ambient	Birds, fish, deer, small mammals, livestock	1 unit	Already part of the ecosystem; player borrows them. Trivial behaviors (flee, flock, graze) cost almost nothing to swap into.
Soldier / worker	Spearmen, archers, peasants, miners	3 units	Standard military / economy units; behavior trees are meaty but well-defined.
Specialist	Scouts (long-range, terrain-aware), engineers, healers	5 units	Wider context window than a soldier; needs more sim awareness when taken over.
Thinker	Sages, priests, oracles, advisors, generals	8 units	Decisions ripple across many sim subsystems; the AI itself was running an LLM or large utility function.
God-king / hero	Player avatars, mythological heroes	15 units	Carries faction-wide effects when active; cheapest to leave alone, most expensive to babysit.

The "scout bird" pattern from the design brief — take over an eagle, fly it across a continent, see what's there — is cheap precisely because the bird's ambient AI is dumb. This is the godding move: the simpler the autonomous behavior, the cheaper the takeover. Punish complexity, reward distribution.

2.5 AI asset pipeline — what "vibe out the assets" actually looks like in 2026

This is the part Can is most curious about. Here is the honest workflow:

flowchart LR
  prompt[concept prompt] --> img[2D image gen\n· SDXL / Flux / Imagen]
  img --> ref[reference sheet\n· 5-10 views]
  ref --> mesh[3D mesh gen\n· Trellis / Meshy / Tripo / Hunyuan3D]
  mesh --> retopo[retopologize\n· auto-retopo or by hand]
  retopo --> rig[rig + skin\n· Mixamo / AccuRig / Mosaic]
  rig --> anim[animation\n· Mixamo lib · or motion-gen]
  anim --> mat[material / PBR\n· generated textures · baked]
  mat --> game[import to engine]

  audio[audio prompt] --> sfx[SFX gen\n· ElevenLabs SFX · Stable Audio]
  audio --> music[music gen\n· Suno · Udio]
  sfx --> game
  music --> game

  code[code request] --> agent[Claude / Cursor / Copilot]
  agent --> patch[small diff]
  patch --> review[Can reviews + plays]
  review --> commit[commit to git]

Tools that exist as of mid-2026 (verify before relying on any of these; the field moves monthly):

• Image: SDXL, Flux, Midjourney, Imagen — for concept art and reference sheets.
• 3D mesh from image: Trellis (MS), Meshy, Tripo, Hunyuan3D. Quality is "passable for prototype, not shippable as-is." Always retopologize.
• Retopo: Quad Remesher (paid, $$), Blender's auto-retopo, or by hand.
• Rigging: Mixamo for humanoids (free), AccuRig, Mosaic for non-standard.
• Animation: Mixamo's library is the cheapest path. For unique moves, Cascadeur or motion-gen models like Motion-X.
• Textures: Substance, or generate with Materialize / TextureLab / SD inpainting.
• Audio SFX: ElevenLabs SFX, Stable Audio.
• Music: Suno, Udio (mind licenses).
• Code: Claude Code (this tool), Cursor, GitHub Copilot. Same vibe-coding workflow Can already uses on godding.

The hidden cost is curation. Generating 100 monster concepts in an hour is real. Picking the 3 that share a style, retopologizing them, rigging them consistently, texturing them to match the world's palette — that takes weeks. Plan for the curation labor.

Style anchor. Pick one style early (e.g., "stylized low-poly with hand-painted textures, palette: muted greens + warm earth + steel grey") and feed it into every prompt. Inconsistent style is the single biggest tell of vibed assets.

2.6 Methodology — applying the swarm protocol to a game project

This is where the parallel to godding pays off. The same disciplines that keep this repo from degenerating apply to a vibe-coded game.

Swarm rule	Game-project translation
Orient → predict → act → diff → compress	Before each session: read what's done, predict what one small step will do, do it, look at the diff, write a one-line note about what you learned.
Repo IS the memory	Every asset, every script, every config in git (or git-lfs). No "the cool tank model is in my Downloads folder."
Small commits, structured messages	[game] add-deformable-terrain style. One concept per commit. Revert is your friend.
Lessons file	Keep a game/LESSONS.md. When something surprises you (e.g., "navmesh regeneration on voxel edit is too slow") write a 5-line lesson immediately.
Frontiers	A game/FRONTIER.md with the 5-10 currently-open questions, ranked. When you sit down, pick one.
Branch protection / pre-commit hook	A pre-commit that runs the game in headless mode for 5 seconds and fails the commit if it crashes on startup. Catches 70% of regressions.
Compress	Once a week: prune dead branches, dead assets, dead experiments. Game projects rot fast.

Concrete cycle for one "session" (1-3 hours):

1. git pull; read game/FRONTIER.md; pick one frontier item.
2. Write a 1-sentence prediction: "I think I can get the unit-takeover camera transition working in 90 minutes by reusing the existing camera rig and a tween."
3. Do it. Use Claude / Cursor for the code, generate any new assets you need.
4. Play it. Does it work? What surprised you?
5. Write a LESSONS.md entry. Commit. Push. Done.

This is identical to the swarm cycle. The whole point of this page is: you already know how to do this.

2.7 Phased roadmap — the cut

Single-player throughout. Multiplayer is its own project (§2.8). Each phase admits the next architecturally — the implementations land in their phase.

Phase 0 — Setup (week 1). - Install Godot 4.x. Watch one "Godot in 100 minutes" video. Build the official 2D and 3D platformer demos. Yes, both, even though they're not your game. You're not learning your game yet; you're learning the tool. - Set up the repo: git, git-lfs for binary assets, the swarm-style scripts adapted (see §2.12 templates). - Pick the style anchor. Generate 10 concept images. Pick one direction. Commit them as assets/style/anchor-*.png.

Phase 1 — Prototype (weeks 2–6). Goal: prove the seam works. - Flat green plane, one biome, RTS camera (top-down, zoom in/out). Two scales: S4 + S5. - One unit type (say, a soldier). 10 of them on the field. Plus 1 ambient unit type (birds). - Click-to-move, click-to-attack. Behavior tree: idle / move / attack. Bird-scout has flock + flee. - "Take over" a unit: F key. Camera drops, controls switch to WASD + mouse-look + LMB fire. Esc returns to RTS view. - Attention pool (§2.14): simple version — energy drains on takeover, recovers when idle. Visible bar. No variance check yet. - Deformable terrain: one tool, "raise/lower." That's all. - Architectural admissions (build the shape, ship empty): tick scheduler with band-registration (only S4 + S5 ship active); modifier system on sim subsystems (no gods yet, but the hooks exist); world state indexed by spatial cell + scale. - No mythology. No economy. No tech tree. No building. No voxels yet. No procedural world. - Exit criterion: the §2.11 ship-gate table passes. Demo to one friend.

Phase 2 — Vertical slice (months 2–6). Goal: one full game loop with first mythology. - Resource (one resource, "stone"). Worker unit gathers it. S3 hinted via simple city aggregation. - Building (one structure, "barracks"). Costs stone. Produces soldiers. - Enemy AI: opponent does the same thing, badly. - Win condition: destroy enemy barracks or unlock the age advance. - FPS takeover for soldier and worker. (Worker FPS = digging in first-person.) - Sparse-voxel construction zone for the "barracks site" — player can shape it. - First era loop: one age advance unlocks one new unit + one new building. - First pantheon (Greek): 1 major god + 2 minor; favor accumulates from rituals; 2 myth abilities; 1 god-power per age. - Attention variance check: if you focus on one area >80% in the last 10 in-game minutes, neighbors degrade (visible warning). - Real-resource skeleton: ore co-located with specific terrain types (not random). - One full era's worth of art (10–20 final-quality assets). Sound + music for one level. UI for orders, build menu, takeover prompt, favor, pantheon picker. - Exit criterion: a 15-minute playthrough that shows the genre-mash elements (RTS, FPS, mythology, era advance) in one run. Phase 2 ship-gate (§2.11) passes.

Phase 3 — Expansion (months 6–18). Goal: world that runs without you. - More eras (Empire-Earth-style: bronze → industrial → future). - More biomes — proper biome lookup, WFC-constrained adjacencies. S3 fully ticks. - S2 (ecology) ships: Lotka-Volterra populations, food chains, real wildlife behavior. - Evolving nature: soil quality, overharvest desertification, forests regrow, climate slow-drift. - More pantheons: Norse, Egyptian historical pantheons. LLM-generated pantheon option (constrained to existing sim hooks). - More ambient unit types: fish, deer, scout cats — broad cheap-takeover ecosystem. - More units, more buildings, voxel build mode beyond construction zones (if performance allows). - Stub S0 and S6 at this phase: zoom-out and zoom-in past S3/S5 lands on a "placeholder cinematic" — proves the scale ladder works. - Steam page / demo / release planning (optional).

Phase 4 — Cosmological + cellular tail (months 18+, open). - S0 cosmological: stellar evolution, galaxy structure. Ties into UNIVERSE-EVOLUTION-AS-COMPRESSION.md. Mostly cinematic at first. - S1 planetary: plate tectonics during long simulation runs. - S6 cell + S7 mutation: guided-selection mechanic; player biases selection pressure rather than editing genes. - Backwards-compatible saves: Phase 1 prototype saves must still load. The open-schema world state from §2.13 is the load-bearing decision. - Multiplayer, if ever, is its own project — expect 3–6 months alone, and it forces a data-model rewrite. Default answer is still no.

2.8 What's out of scope (loudly)

Single-player throughout the planned phases. Anything below is out:

• Multiplayer in any near-term phase. Forces a data-model rewrite. Default answer: no. Phase 4 may revisit.
• Procedural generation of the whole world in v0.1. v0.1 is a hand-authored small map. Phase 2 adds biome-lookup procedural. Phase 3 adds WFC. Phase 4 adds simulation-based gen.
• Story/narrative system as authored content. Emergent narrative only. Mythology layer (§2.16) provides the only authored slots.
• Mod support. Cool, but every hour on it is an hour not on the seam or the scale ladder.
• Console ports / mobile. PC-only until ≥ Phase 3 ships.
• Anti-cheat, leaderboards, accounts. Single-player local until proven.

Mythology, ecology, scale ladder, attention economy are NOT in this list. They're scoped into phases (§2.7), and the v0.1 architecture must already admit them. That's the architectural test: can a one-line change attach a real god-effect modifier to the combat resolver, even though we don't ship one in Phase 1?

2.9 Isomorphisms with godding — why this project is in scope for this repo

This is a vibe-coded game on the surface; underneath it's running the same structures the isomorphism atlas tracks. Naming them makes the design decisions transferrable, not bespoke.

Pattern (godding-native)	How it shows up in the game	Where it lives in the repo
Stigmergy — coordination by traces in the shared environment	The voxel world is the shared memory — units path around obstacles other units (or the player) left. No central blackboard required.	docs/godding/stigmergy.md
Swarm — N semi-independent agents act as one without central command	RTS units with behavior trees; one player-controlled unit is just one cell in the swarm that's temporarily forced.	docs/godding/swarm.md
Compression / rate-distortion — keep the signal that matters; drop the rest	Asset curation pipeline (generate 5000 → keep 500 → ship 50). RTS-resolution vs FPS-resolution sim is also a compression choice.	docs/SWARM-RATE-DISTORTION.md
Scope — where to cut so the work ships	Phase 1's "no multiplayer, no economy, no tech tree" — the cut is the plan.	docs/godding/scope.md
Build — leave it smaller and clearer	One commit per concept, weekly compression sweep, headless-start pre-commit hook.	docs/godding/build.md
Peak / reach — pick what is uniquely yours, defer the rest	The seam (RTS↔FPS on one entity) is the peak; engine choice, art style, voxel scope serve the peak.	docs/godding/peak.md · reach.md
Hidden dependencies — what breaks if you change this?	Voxel decision determines pathfinding, networking, save format, and rendering — all four. Document the dependency before changing.	docs/godding/hidden-deps.md

Candidate new ISO entries for the atlas, surfaced by this project:

• ISO-?: dual-resolution simulation of one entity. One canonical state, multiple controllers attached at different tick rates. Manifestations: this game's RTS↔FPS seam (§2.2) · the multi-scale zoom ladder (§2.13) · kernel/userspace context switch · LOD rendering · pyramid algorithms in vision · system-1 vs system-2 dual- process cognition · multi-grid PDE solvers · Wilson renormalization in physics.
• ISO-?: generator → curator pipeline as rate-distortion in practice. Generate far more than you ship; the bottleneck is selection, not generation. Manifestations: this game's asset pipeline (§2.5) · LLM sampling N completions then voting · biological evolution · scientific peer review · the swarm's lesson-then-Sharpe loop · Phase 1's "generate 10 concept images, pick 1 anchor."
• ISO-?: scarce attention as the binding constraint that forces distribution. An agent's finite cognition cannot drive every detail; distribution is forced, and the trace-of-past-attention becomes the substrate of coordination. Manifestations: the game's godding_energy mechanic (§2.14) · human working memory (3–7 slots) · the swarm's session-energy budget · bandwidth in networks · a manager's reports-to ceiling (Dunbar, ~7) · the central-bank attention problem · godding's "you can't do everything; pick the peak."
• ISO-?: high-resolution simulation compressed into low-resolution symbol/myth. Long-running sim states get summarized into a small set of named entities (gods, heroes, institutions) that downstream agents react to as if they were the underlying state. Manifestations: mythology layer (§2.16) · institutions vs underlying laws · legal precedent · brand identity · the swarm's belief variants · the LLM's "compressed worldview" in weights.

If any survive 4 weeks of contact with reality, propose them in SWARM-THEOREM-HELPER.md.

2.10 Anti-patterns — failure modes of ambitious vibe-coded games

The point of naming these is so you can catch yourself doing them, not so a reader can scold you. Each one has burned someone — usually the same person, twice.

1. Infinite Phase 0. You watch tutorials, set up the perfect repo, design the perfect art style, and four weeks later have shipped zero gameplay. Counter: First playable build with one capsule on a plane in week 1, ugly. No exceptions.
2. Magpie engine-shopping. Switching engines every time a tutorial looks cooler. The engine that ships your prototype is the right engine. Counter: commit to Godot for 6 weeks. Re-evaluate only at the Phase 1 exit.
3. Vibe-coded spaghetti. LLM writes 800 lines, you don't read them, three weeks later nothing works and nobody knows why. Counter: every AI-generated patch must be read line-by-line before commit. If you can't explain it, revert.
4. Asset zoo. 17 art styles in the project folder because every prompt was a blank slate. Counter: one style anchor file. Every asset prompt cites it.
5. Premature optimization for 5,000 units. "It needs ECS / DOTS / Bevy for the army battles." No it doesn't, not in v0.1. Counter: measure with 50 units first. Only optimize past a measured bottleneck.
6. Feature seepage from comments. A friend says "wouldn't it be cool if…" and it's on the roadmap by Tuesday. Counter: IDEAS.md for feature seepage. It does not migrate to FRONTIER.md without a measurable, scoped pitch.
7. Networking by week 3. Multiplayer breaks your data model. Adding it during prototyping rewrites the game. Counter: networking is a v0.3+ topic; nothing in v0.1 or v0.2 may assume it.
8. Demo-mode-only. The game runs great in dev mode but ships with broken release builds. Counter: every Friday, build a release binary and run it for 60 seconds. If it crashes, that's the week's bug.
9. The "real" engine fallacy. "Once I rewrite it in Unreal, then it will feel like a real game." It won't. Engines don't make games good; loops do. Counter: Phase 2 exit, not engine choice, decides whether to port anything.
10. Re-architecture as procrastination. Refactoring is a great way to feel productive without finishing anything. Counter: one scheduled re-architecture window between Phase 1 and Phase 2. None during.

2.11 Measurements & ship-gate — when is a phase actually done?

Soft exit criteria ("you can play 5 minutes without a crash") rot. Replace with numbers you can read off a screen. Failing the gate doesn't mean restart — it means name the gap, add it to FRONTIER.md, and decide: fix or accept.

Phase 1 ship-gate (binary pass/fail, all of these):

Metric	Target	How to measure
Frame rate at 50 units, RTS view	≥45 fps median, ≥30 fps p1	Godot's Monitor overlay
Frame rate during FPS takeover	≥55 fps median	Same
RTS↔FPS transition time	≤500 ms perceived	Stopwatch + recording
Crash-free playtime	≥10 min sustained	Manual run, repeated 3×
Headless start	exit code 0 in pre-commit	godot --headless --quit-after 5
Asset coherence	≥80% of v0.1 assets pass "style anchor diff" eye-test	Side-by-side with anchor image
FRONTIER backlog	≤10 items, none stale >2 weeks	Inspect file
LESSONS file	≥1 entry per session worked	wc -l game/LESSONS.md
Repo size	≤200 MB (LFS not counted)	du -sh .git
Reversibility	latest commit revertable cleanly	git revert HEAD --no-commit; git reset

Phase 2 ship-gate (additional, on top of Phase 1):

Metric	Target
Full game-loop playthrough	15 min, all elements visible
Final-quality assets	10–20 in repo
Win/lose path	both reachable in 3 of 3 test runs
Style coherence at 50+ assets	still ≥80%
External playtest	1 non-developer plays unaided for ≥10 min

What this gives you: a named threshold to argue with future-you about. "It's not done yet" stops being a feeling and becomes a row in a table.

2.12 Starter templates — copy these on day one

These are the godding-native files that turn the project from "a folder of code" into a self-correcting workspace. Copy them verbatim; replace the bracketed content as you go.

vibe-game/FRONTIER.md — the rolling open-questions file. Read it at the start of every session, update at the end.

# FRONTIER · vibe-rts-fps

> Open questions, ranked. Pick from the top when you sit down. ≤10 items.
> Drop anything stale >2 weeks unless you can defend why it's still open.

## bad (do first)
- F-001 — Can navmesh regenerate fast enough on deformable terrain edits? Measure with 50 units, 1 crater/sec.
- F-002 — Does the controller-swap on takeover preserve momentum and HP? Write a 30-line test scene.

## medium (do next)
- F-003 — Style anchor diff tool: simplest viable version that catches drift.
- F-004 — Pre-commit hook: headless 5s startup + exit-0 check.

## good (keep)
- F-005 — Era progression sketch (bronze → industrial → future). Defer to Phase 3.

## resolved
- (move items here with one-line resolution + commit hash)

vibe-game/LESSONS.md — one entry per session, max 20 lines per lesson.

# LESSONS · vibe-rts-fps

# L-001: GDScript signal handlers can't be async in 4.2
Session: S001 · Date: 2026-05-17 · Confidence: high
Finding: Tried `await get_tree().create_timer(0.5).timeout` inside `_on_takeover_pressed` —
behavior trees stalled because the callback returned to a closed scope.
Rule: For takeover transitions, use a state-machine node that ticks, not awaits.
Message: "Async-in-signal is a trap in Godot 4.2; tick a state instead."

# L-002: <next lesson>

vibe-game/IDEAS.md — the holding pen for feature seepage. Things here do not become work until they're pitched into FRONTIER with a measurable scope. Most of them never will. That's the point.

# IDEAS · vibe-rts-fps

> Park feature seepage here. Promotion to FRONTIER requires: measurable
> outcome, scope estimate (hours), and which existing item it displaces.

- weather system that affects unit pathing
- dynamic music that reacts to combat intensity
- a "diplomat" unit that converts enemies
- ...

vibe-game/STYLE-ANCHOR.md — the one-page bible for every asset prompt.

# STYLE ANCHOR · vibe-rts-fps

Palette: muted greens (#5a7d4a), warm earth (#a67b4a), steel grey (#6b6f72),
         accent sunset orange (#d6873c).
Mesh style: stylized low-poly, 500–2000 tris for hero units, 100–400 for crowd.
Texture: hand-painted look, no PBR roughness maps beyond 256x256.
Silhouette rule: every unit recognisable as a black silhouette at RTS zoom.
Lighting: top-down sun + cool ambient; no harsh shadows.

Anchor images: see `assets/style/anchor-*.png` (5 images).

Prompt prefix for new assets:
"stylized low-poly 3D model, hand-painted textures, palette muted greens warm
earth steel grey, recognizable silhouette, isometric RTS scale, in the style of
[anchor-001.png]"

vibe-game/.git-hooks/pre-commit — the cheapest regression catcher you'll ever write. Symlink it to .git/hooks/pre-commit after git init.

#!/usr/bin/env bash
set -e
echo "[pre-commit] headless smoke test (5s)..."
timeout 8 godot --headless --quit-after 5 || {
  echo "[pre-commit] FAIL: game didn't start cleanly. Fix before commit."
  exit 1
}
echo "[pre-commit] OK"

2.13 Multi-scale zoom — the architecture problem

This is the second-hardest engineering problem after the §2.2 seam, and it's structurally the same problem at a different scale. Where §2.2 lets you swap between RTS and FPS controllers on one entity, §2.13 lets you swap between scales on the entire world. One canonical state; many views and tick rates.

The bands (recap from L1 map):

#	Band	Tick rate	What ticks at this band	When the player is here
S0	Cosmological	~10⁹ yr / sim-tick	Stellar evolution, galaxy structure	Endgame · cinematic
S1	Planetary	~10⁴ yr / tick	Plate tectonics, climate, biome shifts, mass extinctions	Cinematic / Phase 4
S2	Ecological	~years / tick	Species populations, food webs, migration	Civ-builder mode
S3	Civilization	~months / tick	Economy, diplomacy, tech tree	Strategic overview
S4	Battle / RTS	~seconds / tick	Units, pathing, orders	The default RTS view
S5	FPS / first-person	~16 ms / tick	Embodied control, per-pixel	The unit takeover
S6	Cell	~hours / tick	Metabolism, signaling	Optional / Phase 4
S7	Sub-cell / mutation	~generations / tick	Selection, drift, gene fixation	Optional / Phase 4

Three architectural requirements that any v0.1 must already respect:

1. One canonical state, indexed by spatial cell + scale level. Don't store "the city of Athens" once and re-derive at zoom. Store the underlying tiles, resources, and units; Athens is a label/view computed from them. This is the rate-distortion ISO from §2.9 applied to representation.
2. Tick scheduler that can run any subset of bands. Each band registers its tick rate; the scheduler advances bands when their tick is due. When the player is at S4 (RTS), S5 (FPS) idles. When at S5, S4 still ticks at low priority so the rest of the world doesn't freeze.
3. Lossless re-aggregation between adjacent bands. When you zoom out from S4 to S3, you don't lose the units — they're aggregated into "Athens has 4000 citizens, military strength 800." Zooming back in restores them with the same identities. This is harder than it sounds; pick the simplest aggregation (sum, mean, count) that still preserves the entity.

Time dilation. Each band runs at a different game-clock-per-real-second. When the player is at S3 (months/tick), one real-time minute is ~30 in-game years. When they drop to S5, time slows to real-time. Other bands keep their real rates — at S5, the cosmological band doesn't suddenly tick 10⁹ years during a battle, it pauses. The player's chosen band dictates wall-time → game-time.

Backwards/forwards compatibility (the design ask). Adding S6 (cell) in Phase 3 must not break S4 saves. Adding S0 (cosmological) in Phase 4 must not break S3 saves. The trick: every save file is a stack of band states. Old saves load with missing-band defaults; new bands fill in from the underlying state when needed. The world data structure is therefore an open schema, not a fixed one.

Universe-scale start. The deepest zoom (S0) ties directly into the existing investigation UNIVERSE-EVOLUTION-AS-COMPRESSION.md: the same finite-energy-per-channel, dark-light cycles, and stigmergic state described there shape what a cosmological band can actually simulate. Don't re-invent the cosmology — borrow the page's framework. The game's S0 is its playable surface.

Cell + mutation level (S6, S7). The "select mutations" mechanic the design asks for sits at S7. The simulation runs a population-genetics model (selection + drift) on a creature's gene pool; the player intervenes by biasing the selection pressure, not by editing genes directly. This keeps the mechanic grounded — you pick environments and stressors, evolution does the rest. Spore got pilloried for letting players paint creatures freely; the more honest design is guided selection.

Phase plan for scales:

Phase	Bands shipped	Bands stubbed
Phase 1	S4 (RTS), S5 (FPS)	S3 hinted via city labels
Phase 2	+ S3 (civilization, era loop)	S2 hinted via simple food-supply
Phase 3	+ S2 (ecology), + S1 (planetary, light)	S0/S6 stubbed
Phase 4	+ S0 (cosmological), + S6/S7 (cell, mutation)	—

The cut: v0.1 has only two bands. The architecture must admit the rest. That's an architectural test, not a feature gate.

2.14 Attention as the core resource — the godding-energy economy

The design brief's "you have a certain amount of energy to focus on each character" is, in this repo's vocabulary, stigmergy as game mechanic. A single agent (the player) cannot drive every unit at full resolution; the world must mostly run on traces and standing orders. Distribution is forced. That's the whole game.

The pool. Player has a godding_energy value, capped at, say, 100. Recovery at ~5/sec when zoomed out and uninvolved; ~1/sec while watching a battle from S4 without direct control; 0 while actively controlling a unit at S5.

Drains. Per second of direct control: scaled by unit class (see §2.4 table). A bird is 1/sec; a soldier 3/sec; a thinker 8/sec; a god-king 15/sec. So you can pilot a bird across the map for ~100s; a god-king for ~7s before you must release them.

Why this is the right mechanic (not just a "mana bar"):

• It enforces the swarm thesis: you cannot win by hero-hugging. The other 95% of the world has to be set up well before you dive in.
• It rewards good standing orders. A general with smart orders is more valuable than one you babysit.
• It makes "ambient" creatures genuinely useful — a flock of birds is a free intel network.
• It scales with mythology (§2.16): a god's favor can temporarily raise the recovery rate, or let you "spend" favor for a burst.

Distribution requirement. The game checks the variance of where the player spent attention over the last 10 in-game minutes. If concentrated on one unit or area, the rest of the world quietly degrades — resources mis-managed, diplomacy drifts, scouts get lost. This is the negative feedback that closes the loop. It's mechanically equivalent to the swarm's compression cycle: leave parts of the work to autonomous agents or pay the entropy cost.

Anti-hero-hug failsafes:

• Hard cap: cannot stay in S5 (FPS) for more than ~60 real seconds per session on one unit. Forced ejection.
• Soft cost: re-entering the same unit within a short window costs 2× energy.
• Mythic exception: god-kings may exceed limits during myth events (§2.16).

UI implication. The energy pool needs to be visible at all times, like the mana bar in an MMO. The variance-of-attention meter is a secondary indicator ("you've focused 80% on Athens this turn — Thebes is starving").

Mapping to the swarm in this repo:

Swarm concept	Game manifestation
Session energy (finite per-session compute)	godding_energy pool
Spawning sub-agents	Issuing standing orders / behavior templates
Stigmergy (state in shared env)	The world itself is the queue — units read terrain, scent, traces
Compression cycle	The forced ejection after attention concentration
Frontier-driven work	Pick which unit/area to focus on, top-of-frontier

2.15 Evolving nature — ecology, geology, climate, real resources

The brief asks for nature that evolves and resources grounded in reality. The right framing: the world is its own simulation, and the player is one agent inside it. Without the player, civilizations still rise and fall.

The cheapest models that look right. Don't reach for AAA-level realism; reach for "passes the 30-second look-right test."

System	Cheapest plausible model	Cost
Plate tectonics	Discrete Voronoi plates on a sphere/plane; mass-conservation; collision = mountains, divergence = ocean trenches. Run once at world-gen.	medium upfront, zero runtime
Climate	Latitude-based base temperature + altitude lapse + ocean proximity + prevailing winds (Hadley/Ferrel approximation).	cheap
Hydrology	Rainfall from climate × terrain; flow accumulation on heightmap → rivers. Run after every terrain edit.	medium
Biomes	Lookup table: (temperature, rainfall, altitude) → biome. Tweak by hand.	trivial
Ecology	Lotka-Volterra style population dynamics per species per region; migration on biome change.	medium
Species evolution	Slow trait drift + selection events; rare speciation when populations isolate >N generations.	medium
Geology (resources)	Resource type co-located with geological context: copper/tin near igneous, iron in banded sediments, coal in Carboniferous bogs, oil in marine sediments, fertile soil in river floodplains.	cheap at gen, free at runtime
Soil quality	Per-tile fertility that drops with monoculture/overfarming, recovers with rotation/fallow. History matters.	cheap
Climate change	Long-run drift from civilization activity (deforestation, smelting, eventually fossil fuels).	cheap

Real-resource principles:

1. Resources have geology. Copper isn't sprinkled randomly; it's in copper- bearing rocks. Players who learn to read terrain do better. This is the single biggest "feels grounded" lever.
2. Resources deplete. Mines run dry; forests get clear-cut; fish stocks collapse. Overharvest has real consequences (desertification, famine).
3. Resources regrow on appropriate timescales. Forests on decades; soil on centuries (with rotation); ore on geological time (effectively never).
4. Trophic levels. You can't feed an army on apex predators. Calories flow up the food chain with ~10% efficiency per level — same as reality. Forces players to think about ecology, not just inventory.

Nature evolves means:

• New species appear via slow speciation (background; rare; surprising).
• Climate drifts on multi-millennial scales; civilizations may rise in tundra that, two ages later, is grassland.
• Disasters (volcanic winters, droughts, plagues) are emergent from the sim, not scripted.
• Civilizations rise and fall without the player. A neighbor civ may collapse from overharvest while you're focused elsewhere — empty land where there was a kingdom. This is the world honoring §2.14: it doesn't pause when you look away.

The cut for v0.1: none of this. Phase 1 has a flat plane and one biome. Phase 2 adds biome lookup + simple resource placement. Phase 3 is where ecology and real-resource sim actually run. Phase 4 adds plate tectonics + climate drift. The data structures from §2.13 admit all of it; the implementations land in phases.

2.16 Mythology layer — gods, favor, pantheons (chosen or generated)

Age of Mythology shipped this beautifully; the design here borrows that structure and extends it with LLM-generated pantheons. Mythology isn't a parallel mechanic; it's a compression of the existing sim. Each god's domain maps to a sim subsystem. Picking a god is a re-weighting of the world rules in that civ's favor.

Pantheon model:

• At game start, the player picks one major god (or generates one).
• At each age advance, they pick one of two or three minor gods offered.
• Each god has a domain (war, harvest, sea, sky, knowledge, death, fire, hearth, storm, wild) and grants:
• A passive bonus in the sim subsystem matching the domain.
• One or two myth abilities activated by spending favor.
• One god-power — a once-per-age large event (meteor, blessing, plague, miracle).

Domain → sim subsystem mapping:

Domain	Sim coupling	Example bonus
War	Unit combat resolution (§2.4)	+10% damage; better morale
Harvest	Crop yield / soil quality (§2.15)	+20% farm output; slower soil depletion
Knowledge	Research rate; thinker effectiveness	-25% research cost
Sea	Naval movement, fishing	longer ship range; +50% fish yield
Death	Post-battle morale, plague resistance	wounded recover faster
Sky	Vision, scout range (§2.4 ambient units)	bird-scouts have +50% range
Wild	Ecology, wildlife behavior (§2.15)	huntable animals more common; predators less aggressive
Storm	Weather control (small)	clear weather for an action
Fire	Smelting, siege	smelters produce more; siege weapons +25% damage
Hearth	Population growth, happiness	birth rate up; loyalty up

Favor as a currency. Favor accumulates from actions matching the chosen pantheon's domains: building shrines, performing rituals, winning battles in the god's preferred way (e.g., Sea favor from naval victories). Spent on myth abilities. This is essentially AoE-Mythology's favor — design problem already solved, no need to redesign.

Historical pantheons to ship in v0.2:

Greek, Norse, Egyptian, Mesopotamian, Aztec/Mesoamerican, Vedic, Yoruba, Shinto. Start with two (Greek + Norse, say); add more as content slots allow.

LLM-generated pantheons (Phase 3+). The player can choose "generate a pantheon" at game start. The LLM produces:

• Pantheon name + cosmology
• 1 major god + 6 minor gods + their domains (constrained to the domain table above — don't let the LLM invent new sim couplings, or the simulation doesn't know what to do)
• Names, iconography prompts, myth abilities mapped to existing ability slots
• One narrative myth per god, generated as flavor

The constraint is critical: generated content must map onto pre-defined sim hooks. Otherwise the simulation can't react to it. This is the same lesson as §2.5 (curation > generation) applied to design content.

Mythic events. When the sim conditions match a myth pattern (e.g., great hero dies in defense of the city), trigger a one-shot event: temporary boon, visual effect, narrative card. The event templates are pre-authored slots; the sim fills them in. This is the cheapest path to "the world feels mythic."

Cut for v0.1: no mythology. Phase 2 introduces one pantheon (Greek) with 1 major god + 2 minor + favor + 2 myth abilities. Phase 3 adds Norse + LLM- generated pantheons. The architecture must admit it from day one (god-effects must apply via a clean modifier system on sim subsystems).

2.17 Open questions to revisit in 4 weeks

1. Is Godot actually fast enough at 50 units with takeover, or do we need to switch sooner than expected? Measure, don't guess.
2. How bad is the AI-mesh → retopo → rig pipeline in practice for unique units (not humanoids)? Humanoids are easy with Mixamo; quadrupeds and vehicles aren't.
3. Does the deformable-terrain + navmesh combo actually behave when you blow a crater under a moving unit? (Most games cheat here.)
4. Is "vibed code" maintainable over 6 months, or does it accrue debt faster than a beginner can manage? Plan a mid-project re-architecture window if needed.
5. Does the style stay consistent across 100+ generated assets, or does it drift? Build a simple "style check" diff tool early.

2.18 First five tasks (this week)

1. git init a vibe-game/ repo as a sibling to godding/. Add LESSONS.md, FRONTIER.md, README.md. First commit.
2. Install Godot 4.x and complete the 3D platformer tutorial. Don't skip.
3. Generate 10 concept images with one prompt + 10 seeds. Pick the style anchor. Commit them.
4. Build "click to move a capsule on a plane." Commit. Try Claude Code or Cursor to help — see how the AI-coding feel matches GDScript.
5. Build "press F to drop the camera onto the capsule and walk it in WASD." This is the seam, in its smallest form. If this feels hard, the rest will too — that's a signal, not a setback.

References

• Godot 4.x docs
• Zylann's voxel tools for Godot
• Mixamo (free auto-rigging + animation library)
• Trellis (MS image-to-3D) · Meshy · Tripo · Hunyuan3D
• AI and Games (YouTube — Tommy Thompson) — best long-form on RTS AI patterns.
• Game Programming Patterns (Robert Nystrom, free online) — read the "Game Loop," "Update Method," and "Component" chapters before writing anything serious.
• HOW-TO-SWARM.md and SWARM.md — the protocol this project borrows wholesale.