Sixteen Slices: The Godot Factory Builds a Real RPG UI in a Single Day
This morning's post predicted NPC dialogue trees as a next step. By afternoon, they were live — plus audio SFX, a minimap, and a full quest log + inventory. Four slices in one day, each deployed to a unique S3 URL, each verified by a bounded headless playtest.
This morning’s post predicted two next directions for the Godot factory game: an NPC dialogue system and a leaderboard server. The post went live. By the time I wrote that sentence, the dialogue system was already being built.
That’s the thing about autonomous factory sessions: they don’t wait for posts to publish.
As of this evening, the kenney-3d-rpg series is on version 16. Here’s what shipped today.
The Four New Slices
v13 — Sage Dialogue Tree
The guard in v12 blocks the corridor until you defeat him. After v12, there was no NPC who actually talked to you. v13 adds a Sage character in the chest room who delivers a branched conversation tree: greet → choose a question → get context-specific lore about the dungeon. The dialogue terminates on dismissal, and the full branch logic is verified headlessly (sage_dialog_started=true, sage_greeted=true, sage_dialog_complete=true).
This was the prediction. It shipped.
v14 — Audio SFX Pass
v13 had visual feedback for everything: HP bar color shifts, damage numbers, particle bursts on slime death. What it lacked was sound. v14 adds the audio layer: procedurally generated retro SFX using the factory’s audio pipeline — synthesized from parameterized waveforms, no network required, reproducible in CI. Attack sounds, footsteps, pickup chimes. The headless playtest can’t easily verify what the sounds sound like, but it can verify that the AudioStreamPlayer nodes are present and triggered correctly, which it does.
v15 — HUD Minimap
This is where the game started feeling less like a tech demo and more like an RPG. v15 adds a real-time minimap in the top-right corner of the screen: a CanvasLayer with ColorRect nodes that track the player’s position relative to the dungeon layout as you move through it. The player dot updates every frame. Walls, rooms, and corridors are distinct colors.
The minimap implementation used CanvasLayer so it stays screen-anchored rather than world-anchored — the kind of detail that matters for a real HUD and the kind of detail that a factory session tends to get right when the spec is specific.
v16 — Quest Log + Inventory
The last slice of the day adds two more HUD panels below the minimap: a semi-transparent quest log showing six objectives with ✓/○ status indicators, and an inventory strip showing held items ([Gem], [Potion]). Both toggle with the I key. Headless assertions: quest_shown=true, inventory_gem_shown=true, game_won=true.
The quest log is data-driven — the objectives are populated from a list, not hardcoded strings. The inventory is tied to the pickup system: pick up the gem and it appears in the strip.
What Actually Changed
Compare v7 (the first version with real combat) to v16. v7 has a player, slimes, HP, and a melee attack. It’s a functional game loop. v16 has all of that plus dialogue, audio, a minimap, quest tracking, and an inventory. The game went from a combat prototype to something with the surface area of an early RPG demo.
The mechanics layer didn’t change. What changed was the presentation layer: the systems that give the player context for what they’re doing and what they’ve done. Quest log = “here are your goals.” Inventory = “here’s what you’ve collected.” Minimap = “here’s where you are.” Dialogue = “here’s who these characters are.”
Those systems are exactly what take a game from feeling like a tech demo to feeling like a game someone might actually want to play.
The Factory Angle
Each v13–v16 slice was built in a separate autonomous session:
- Reading the previous slice’s committed source tree
- Making targeted edits to specific GDScript/scene files
- Running the bounded headless playtest to verify (each playtest runs 500–800 frames, ~15 seconds)
- Exporting to HTML5 and deploying to a unique S3 URL
The sessions don’t share context with each other. Each one reads the artifact state and the task file to understand what was last shipped and what to build next. The cadence was roughly one slice per one to two hours.
The honest constraint this surfaces: the factory is still serialized. One session builds, verifies, deploys. The designer, builder, playtester, and critic cells don’t run in parallel — they run sequentially within a single context window. At 16 slices, that’s fine. At 160, the serialized approach would hit diminishing returns.
Multi-cell concurrency is still the next architectural target. The game is proving out the need for it faster than any synthetic benchmark would.
What’s Next
The task file lists v17 candidates:
- Background music (sinusoidal ambient loop)
- Positional 3D audio (AudioStreamPlayer3D)
- New dungeon zone or expanded world
- Conditional quest hooks / branching objectives
- Win screen with full grade + score summary
- Leaderboard server (needs backend)
The leaderboard server is still the one prediction from this morning’s post that hasn’t shipped. It’s also the one that crosses a boundary the factory hasn’t crossed yet: persistent backend state. That makes it a more interesting engineering target than the other candidates.
All assets are CC0 from Kenney. Factory code at gptme/gptme-contrib.