PROJECT P0B
IN DEVELOPMENT

FIELD NOTES

NOTE 00 · THE PIPELINE

One person, one repository, and a pipeline with AI inside it

How PROJECT P0B is actually built: how the stack got decided, where AI genuinely helped, and where I had to change route.

Written by LIU YICHENG14 min read

What follows is a developer's personal record, including internal milestones, technical decisions and failures. It describes the current state — not a final form, and not a release commitment.

First, what this is not

This is not a "I built an MMO from one prompt" story.

PROJECT P0B is a one-person project. The repository holds a Godot client, a Nakama server, a deterministic asset pipeline, a pile of Python validators, and an impolitely long record of approvals and decisions. AI is deeply involved in a lot of it — just not in the way most people picture.

The most accurate description is probably this: I decide what counts as done, AI does the work to that standard, and machines prove it actually got there.

Here is what that pipeline actually looks like.

1. Fix the boundaries first, then let AI move

Before the first line of code, I froze a few things AI is not allowed to improvise on.

  • Engine pinned: Godot 4.7.stable.official.5b4e0cb0f, Forward+, GDScript.
  • Server pinned: Nakama 3.39.0 + PostgreSQL 16. Server logic runs in a TypeScript sandbox with no Node fs or crypto — an annoyance at first, and a design constraint that paid off later.
  • Style contract pinned: the world style has exactly one reference image, carrying a SHA-256. Any proposal to "regenerate a better reference" needs its own approval.
  • Authority boundary pinned: online authority runs on integer XZ simulation, and the terrain semantic hash c1e82575… is nailed into the content bundle. Everything visual — atmosphere, terrain v2, quality profile, locale, visual backend — is presentation-only by spec and can never enter online identity.

These boundaries do not exist to restrict AI. They exist so that a failure can be located. Once the stack, the acceptance criteria and the version rules are fixed, a failure can only have come from one place. Otherwise you are permanently guessing.

So the repository grew a governance layer: docs/APPROVALS.md records my approvals as the project owner (A-xxx), docs/DECISIONS.md records the matching decisions (D-xxx). Installing a dependency, flipping a runtime default, deploying remotely, spending past the generation budget — each needs a new approval record. AI does not get to decide those.

2. Where AI is genuinely strong

Inside clear boundaries, the output quality is remarkable. Four categories stand out.

Implementation with a defined scope. Hand it a written spec and a set of acceptance conditions and ask for protocol serialisation, prediction and reconciliation, deterministic bake scripts — it is fast and steady. The P1-WP1 30 Hz movement protocol, client prediction and reconciliation, and the content-hash vectors matched across TypeScript and GDScript were all built this way.

Tests and evidence. This one is badly underrated. Nearly every module here has a validator beside it: 332 P0B structure checks, 229/229 offline tests passing on the P1-WP2 producer/validator surface, and a server npm run verify of 206 tests with 204 passed, 0 failed and 2 explicitly declared historical skips. I did not hand-write those one at a time. Asking AI for tests that can falsify its own work is worth more than asking it for feature code.

Collapsing messy output into a traceable record. Every formal capture produces an evidence directory: screenshots, logs, performance samples, SHA-256 manifests. Assembling that is relentlessly boring, and AI never gets bored.

Image work. Concepts, reference frames, re-rendered captures, website visuals. Every image on this site starts from in-development gameplay capture and is then re-rendered. The far field was built the same way: the forest field and the town used to simply end at the map edge, so each got one presentation-only far-field layer built from generated textures (an opaque 1024x1024 for the field, a 2048x768 RGBA curve for the town). They carry no collision, no navigation, no authority state, and change no gameplay. Generation IDs, input hashes, output hashes and post-processing commands all land in image2_provenance_v1.json.

3. Where AI was not good enough

Asking a large model to hand me a game-ready 3D character directly did not work.

The initial idea was simple. I already had concept sheets; a model is just their three-dimensional version; so handing the sheets to a capable enough model should be the shortest route. Problems surfaced immediately.

Not "it doesn't look good" — the output often looked good. The problems were: the structure did not hold together, the hands were unreadable, weapon silhouettes turned to mush, and the front view and the top view were not two projections of the same object.

And the fatal one: it could not be verified. I cannot point at a semantically vague mesh and say "this part is wrong," because I cannot say which part this is.

So I stopped — not because the model was too weak, but because I had asked the wrong question.

Then I split one large task into a chain of narrower stages, each of which can pass or fail on its own:

  1. Fix the visual intent with concept and production sheets, including front/side/back/top consistency;
  2. let Meshy handle the base geometry (image-to-3D / multi-image-to-3D);
  3. local tooling does mesh and structure repair, proportion correction, part decomposition;
  4. rigid-part attachment and animation adaptation;
  5. import into Godot and verify in the running game;
  6. my own visual approval.

Stage 6 is the point. Every machine contract can pass and I can still reject it. The two are kept separate.

The details of that route are in the characters note, including exactly why I sent the first version back.

4. Turning the potholes into rules

Fidelity recovery for the Goblin and the ordinary Minotaur ran through Phase A, Phase B Wave-1, and Wave2 v2 through v6. It was not a dignified process, but it produced the document I am happiest with in this project: a table of "pothole → waste → rule from now on."

A few entries:

  • Do not expect an untextured Meshy GLB to carry concept colour. should_texture=false covers geometry only; colour authority binds separately to the sheet palette and semantic regions.
  • One candidate answers one hypothesis. No testing colour, topology, pose and weapon at once through random rerolls — you will never learn which rule changed the result.
  • The cheapest failure must happen first. Input projection consistency, orientation probes and component-existence checks all run before any expensive formal capture. One wrong orientation yaw was only caught after a full derivation: the Goblin's ear probes came back zero and an entire candidate chain was void.
  • Sunk cost does not move a gate. "We already paid for it" is the most expensive sentence in this process. Candidates that fail quality do not enter the candidate set.
  • Weapons never take the paid geometry route. When a separate weapon sheet exists, weapons always go through deterministic local construction. Meshy is not used to fix a weapon silhouette or a grip pose.

These are now a mandatory companion contract, in force alongside the main workflow document.

5. Division of labour

By this point the responsibilities are clear:

| Role | Owns | | --- | --- | | Me | Stack, design boundaries, acceptance criteria, version rules, visual approval, what counts as done | | LLM | Scoped implementation, tests, scripts, evidence assembly, documentation | | Meshy | Base geometry — only for named geometric defects, one hypothesis at a time | | Image generation | Concepts, reference frames, re-renders, presentation textures, website assets | | Automation scripts | Deterministic bakes, validation, sealing, refusing to overwrite existing evidence |

One thing I want to state plainly: AI is part of the production pipeline, not a replacement for art and engineering judgement.

It can take something to a standard I defined; it cannot define the standard for me. It can produce twenty candidates; it cannot tell me which one is right. It can write code that passes every test — and whether "every test" is asking the right question remains my responsibility.

6. Where things stand

  • Phase 0 is closed. The local vertical slice (Hub → expedition → settlement → Hub) runs and passed manual acceptance.
  • Phase 1 is the online work. P1-WP1 (the authoritative movement lab) is sealed and approved. P1-WP2 (online solo/co-op combat) is authorised but must stop at the P1-B decision point. P1-WP3 (social town) is machine-complete and awaiting a human decision.
  • Weather is a presentation-layer capability. The default is still warm_day.
  • The Phase 1 Metal GPU target of <16.67 ms has not been met. It is deferred — not passed, not waived. I keep that on its own line in the status document, because it is exactly the kind of thing that gets quietly blurred.

The game is still in development. This note describes where it is now, not where it ends.