How it works
The agent does the plumbing. People decide at the gates.
How a team builds a game with gejm.dev, gejm.dev Bible and their own agents. Agents draft, check and reproduce. People own the canon, the art, the code decisions and the verdicts.
Who does what
Writer, narrative designer
gejm.dev Bible and its studio chat
Canon: characters, places, props, lore, the timeline.
Art director
gejm.dev Bible
Style records, the world style guide, accepted concept art.
Game designer
gejm.dev Bible, KiwiPow Server
Features and their rules, gameplay numbers.
3D or 2D artist
Blender, the engine's viewport
The look of every model and painted layer.
Developer
KiwiPow IDE or any agent client
Scripts, rulings on the code, the proof.
Tester, producer
Playtests, KiwiPow Server
Verdicts and playtest notes.
Agents
MCP to the bible and to their own engine
Drafts, proposals, checks, reproductions and fixes. Never canon, never a verdict.
The flow
-
Canon
Canon first
Writers and the art director
The world lives in gejm.dev Bible as records of kinds the team defines: characters, places, factions, props, styles. The agent researches and drafts; every change it offers is a diff a person accepts. A guard's height, a city's palette or a character's voice is decided once.
-
Plan
A feature is asked for and planned
Game designer
Someone writes a feature in their own words. With KiwiPow Server it becomes an approved spec that cites bible records: scenarios, one provable rule per line, named open questions. Without KiwiPow, the developer and their agent write the spec in the game's repository.
-
Split
Claim, map and split
Developer
The agent reads the spec, the records it cites and the game's scripts, and raises every place the game disagrees with the spec. The developer rules. The work is split into slices: a feature folder of scripts, a set of models, a room.
-
Build
Build in parallel, each session proving its own work
Agents
Each slice gets its own agent session and its own headless engine. A half-written script in another session cannot break it. In each one the agent writes TypeScript, sets up the situation in one call, steps the world and drives the player, queries what happened, walks a system line by line when something surprises it, and pins the behaviour with a test.
-
Draft
Drafts for artists, checked on every export
Agents, then artists
The agent drafts models at gameplay scale with surface roles, colliders and sockets working. The artist finishes the ones worth keeping in Blender; each export is checked against the game and reloaded live, and a broken export keeps the last good version in the world.
-
Play
Play it
Testers
A person plays the running game. A playtest note carries a replay, so the agent reproduces exactly what the tester saw, fixes it, and proves the fix with a test that replays the note.
-
Accept
Accept and close the loop
Testers, then writers
The tester judges behaviour by behaviour from the tests that prove it. What the build taught about the world goes back to the bible as a proposal: a door that had to widen, a character's final height. A person accepts it, and the next feature starts from updated canon.
Worked example: ten props for a market square
-
Brief
The bible says what each prop is
The agent lists the props from the place's record and fetches, for each, the record, its art direction, the accepted reference images and the style guide.
-
Fan out
Ten sessions start
One per prop, each with its own headless engine.
-
Draft
Each agent drafts at the game's real scale
A market stall the character can stand at, a cart with a socket for its goods, a well with a collider the player cannot walk through. It bakes, views the asset from fixed angles, and fixes what the checks report until the ready verdict is clean.
-
Review
The artist sees ten drafts side by side
Artist
Each next to a character-sized reference figure, with its triangle count against the budget and its gameplay checks green.
-
Hand over
The keepers get a starting Blender file
Artist
Surface roles and gameplay elements are already in it. From then on the artist's file owns them.
-
Model
The artist models properly
Artist
Each export reloads in the running game and reports, against the object it lies in, anything that broke: a flipped face, a door too narrow, a budget exceeded.
-
Record
The bible learns the model exists
The finished model is proposed back to the prop's record, so the next agent knows it is there.
The artist spent their time on the look. Scale, collision, sockets, budgets and export settings were never their problem.
Worked example: a playtest note
-
Stuck
A tester gets stuck between a crate and a wall
Tester
They take a note in the viewport, where they stand.
-
Replay
The agent replays exactly what the tester saw
The note carries the session's replay. The developer's agent replays it in its own engine and stops at the tick the tester stuck.
-
Cause
It queries the world instead of guessing
It sees the crate's collider overlapping the walkway, and traces it to the crate's model.
-
Fix
It fixes the generator, or tells the artist
If the artist's file owns the crate, the agent names the object to move. Either way it adds a test that replays the note and asserts the player passes.
-
Proof
The note is resolved with the test as its proof
Tester
What makes it fluent
One source of truth per kind of fact
The world's facts live in the bible, the build's rules in specs, behaviour in tests, the look in the artist's file. Nobody copies a fact between them by hand.
Every handover is text
Records, specs, scripts, generators, test results and reports are all text an agent reads and a person reviews as a diff.
Every agent proves before it reports
A session never says “done” without a test, a judge or a ready verdict behind it.
People decide at the gates
Canon changes, spec rulings, art and verdicts belong to people. The agent proposes at each gate and waits.
Not in the flow yet
-
next Fanning out
Starting ten sessions from one request and gathering their drafts for review is done by hand today.
-
next A brief for a model or a script
The bible's brief is made for concept art; one made for a model or a script is not built yet.
-
next Physical facts
Dimensions, scale and materials are not in the bible's starting kinds yet.
-
next Assets on records
An engine asset is not yet recorded back on its bible record automatically.
-
next Canon change impact
The bible does not yet hear when a canon change breaks something already built.