Dawnveil

Problem

I want to ship an ambitious game as one person: a cozy city builder joined to a dungeon expedition RPG, with three distinct art styles, eleven playable companions, and a twenty-hour campaign. The engineering is not the bottleneck. The bottleneck is everything a studio normally staffs — art direction, animation, sound, economy design, production planning.

AI can compress most of that. But "use AI for the art" is not a plan, and a plan that lives in my head is not a plan either. The real question is narrower and harder:

Which specific tool does which specific step, what does that cost per month, how much of it runs without me, and how do I keep an AI assistant building the same game in session forty that it was building in session one?

This project is my answer to that question. It is a planning exercise, done with AI, about building with AI.

Solution

Three artifacts, each solving a different failure mode.

A design bible that compiles. One file holds every decision. A script extracts it verbatim into 41 documentation files and typed TypeScript modules — no paraphrasing, no second copy to fall out of date. A superseded block sits at the top so any agent reads the current ruling before the older prose beneath it. Change a decision once and everything downstream regenerates, verified by a typecheck and a production build.

A studio wiki. The generated modules render as a browsable Next.js site — systems, economy, classes, cameras, risks, the building costs. It exists so I can check a decision in ten seconds instead of searching a long document.

A live planning hub. Decisions still in flight live separately from the bible: open questions, a workflow diagram I can rearrange, a reference vault for the art that will anchor generation, and editable tables for the game's systems. Nothing in progress contaminates the source of truth, and nothing settled stays only in a chat log.

What the planning actually produced

The explorer at the end of this page holds the pipelines, the budget, the automation estimates, and the roadmap. The short version:

Three pipelines, not one. The game ships three art styles, so it runs three parallel lanes. Each has a named tool at every step and a price attached. This was a correction, not a starting point — I originally framed them as three candidates to choose between, which would have been wrong: the styles serve different parts of the game and all three ship.

A budget with two kinds of money. Cancellable seats and permanent purchases, tracked separately, because they mean different things to a solo runway. Peak is $82 a month during the vertical slice, dropping to $20 in greybox, plus $85 of one-time tooling.

Tool choices made on documented capability. The clearest example: Tripo over Meshy for 3D. Meshy is genuinely better on three counts — cheaper per rig, a far larger animation library, and the only one of the two that documents support for stylized figures. It still lost, because the game ships roughly twenty-four creature companions with avian, serpentine, aquatic, and multi-limbed bodies, and Meshy's own documentation says atypical body plans may need manual rigging. Tripo covers seven skeleton types including exactly those. That is a third of the 3D asset volume that would otherwise come back to me by hand.

The decision survived a later change, which is the real test of it. When modddif turned out to generate meshes and textures with no credit limit, Tripo lost its mesh job entirely — and kept its seat anyway, now doing only rigging and animation. The capability that won the comparison was the one thing nothing else on the list could replace.

An economy with real numbers. Twenty-five buildings, each carrying two independent costs — one to place it, one to staff it — shaped after Age of Empires and Warcraft III. The numbers are tuned so the first six buildings a player places exhaust both limits at once, which is the exact thing the vertical slice has to demonstrate.

How the AI was actually used

Claude Code is the implementer and I hold the locks. Concretely, that means:

Layer	Who
What the game is, and every decision that constrains it	Me, in the bible
Research, drafting, and structuring the plan	Claude, against the bible
Writing code and content modules	Claude, one outcome at a time
Playing the build and saying whether it feels right	Me, every session
Character specifications, before any asset exists	Me, always

The last row is the one that matters most. Every character gets a written specification — silhouette, palette, a signature shape that survives all three art styles, and a list of what that character must never wear or do — before a single asset is generated. A generator pointed at that specification stays on model. A generator pointed at a prompt invents a new look every time, and that is how a solo project ends up looking assembled rather than designed.

The plan also carries a list of non-goals written specifically to be quoted back at me later, because the failure mode of an AI-assisted solo project is not running out of ideas. It is scope, arriving one reasonable-sounding suggestion at a time.

What is not true yet

Nothing is built. This is planning, and the case study is about the planning.

The automation figures are estimates. Two cheap tests would replace them with measurements — a rigging test on a stylized character, and a style-model trial once the reference vault has enough approved pieces — and both are written as step-by-step protocols rather than left as intentions.

The building economy is stamped so work can start, and explicitly expected to move once the slice is playable. One blocker is still open: the eleven companion identities are unspecified, and until they are, no character art can begin. The hub shows it first, at the top, every time I open it.

I would rather a plan say that than pretend otherwise. A plan whose confident parts and guesses look identical is not a plan you can act on.