Opening with a picture — P0B dev notes

Preface

This game started from a picture. Not figuratively — on 13 July 2026 the repository did not even have a project.godot yet; the first thing that happened was generating four candidate images for the world's style, picking one, naming it Lush Fine, and only then writing a line of code. As I write this it has been exactly thirty-five days: one person, one repository, and the skeleton of an online ARPG that can leave town, finish a run, and come back.

This entry is the opening notes: how the stack got picked, what the workflow looks like, and which holes the first month fell into. The scene, the combat, the characters and the verification each get their own entry.

The stack

Client: Godot 4.7, GDScript, Forward+. Server: Nakama 3.39 with PostgreSQL 16, server logic running inside Nakama's TypeScript sandbox. The sandbox has no Node fs and no crypto. That looked like a nuisance at first and turned out to be a favour: every piece of deterministic logic that has to agree on both sides was forced into the plainest possible shape, because the GDScript side has to reproduce the exact same result.

As for the code itself — bluntly, most of it is written by AI. Cursor, Claude Code and Codex in rotation, for implementation, tests, validators and evidence bookkeeping; base geometry goes to Meshy; concept images and far-field textures come out of image models. In 2026 that is hardly news for an indie project, so it sits here as one ordinary line in the stack. The part that actually costs time is not "getting it written" but saying precisely what is wanted, then verifying what came back — once generation is fast, the bottleneck moves to specification, verification and choice. That observation runs through the whole project.

Which is why the repository grew something that looks a bit bureaucratic: every paid generation, every runtime-default change and every remote deployment gets a written approval; every module ships with its own validator; every formal capture is sealed into an evidence directory that cannot be edited afterwards. Slow to write and tedious to read, but a one-person project has no code review, and this is the code review.

Opening with a picture

Picture before code, for a practical reason: working alone, the first thing to slip out of control is not features but direction. A wrong feature can be fixed; a drifting direction is hard to notice, and by the time it shows, a lot of things that should not exist already do. Nail down what "right" looks like first, and every later step has something to be compared against.

Something else from the same day turned out to be more educational than the choice of picture: the first two in-engine builds passed everything on the machine side — frame times in budget, twenty enemies on screen, no leaked nodes — and failed by eye. Torn down, done again. From then on the process had two gates: metrics are the pass mark, the picture is judged separately. Countless later checks followed the same routine — run the validators, and only when they are green look at the frame; the other order just gets you talked into a wrong state by a pretty screenshot.

2026-07-15·First playtest

On 15 July the whole line held for the first time: leave town, finish a run, come back. The acceptance note written after the playtest says, in Chinese, roughly "played it, found nothing wrong" — and then the sealed sixteen-item checklist had not a single box filled in, so it reads 0/16 to this day. Embarrassing, but the rule is that sealed things are never edited afterwards; the approval is a separate record added later. All three languages have been in since that day too — Chinese source, Japanese and English complete — because "we'll add translations later" is a day that never arrives.

The next day the swordsman and the warlord got their final look and Phase 0 closed. Four days.

The online month

Phase 1 was networking: authoritative movement, online combat, the social town, remote deployment, one work package after another. The most painful stretch was proving one thing on a server in Tokyo: if the server restarts mid-fight, settlement must be voided correctly and nobody may be paid. The thing itself is not complicated; what is complicated is that every failure had nothing to do with restarts, and each was more absurd than the last — the details can wait for the combat entry. Each failure meant writing another one-shot approval and going again, because the rule was "this kind of operation is never simply re-run". A dozen or so attempts in, patience ran out and the agent got a line — in Chinese, "don't make me approve, I approve anything this work package does" — which then genuinely became a formal standing authorisation. The rule was fine; its granularity was not.

The same day surfaced another hole: 1,007 files in the repository had never been tracked by Git. Nine days earlier an approval had explicitly allowed commits and pushes, but the documents the agent reads before starting any work still carried the old "don't touch Git" line, so the new rule had never taken effect. When documents contradict each other, the newer one loses.

Afterword

State after one month, as plainly as possible: town, party, one expedition into the forest, the warlord behind the gate, settlement — that line runs end to end locally and over a LAN, for one to four players. Three hundred and some commits landed on nineteen of the days, seventy on the busiest one. The vampire is playable but his final look is still under review; the last restore of the Tokyo server did not succeed, the rollback did, and those are two different things.

IN-ENGINE CAPTURE · IN-DEVELOPMENT BUILD

The images on this site come in two kinds: most are re-rendered gameplay captures, redone for mood; a few, like the one above, are straight out of the engine and only downscaled. The former look better. The latter are real. The game is still being made — on to the next entry.