Engineering an agent-first art bible

Play ZERO KNOWLEDGE Play demo on Steam Wishlist on Steam Skills on GitHub Instagram devlogs

When I was twelve, my grandmother, seeing me carry my Game Boy Advance everywhere I went and spend every penny I received on Magic: The Gathering, somehow arranged a tour of EA Games in Vancouver through a loose connection in her mahjong circle. That day is still burned into my memory. I loved drawing, and the idea that I could work on building these worlds I spent so much time in stuck with me.

I took a less direct route. In 2013, I read The Singularity Is Near and ended up changing majors from Psychology to Computer Science. As I got further into the degree, I became increasingly interested in cybersecurity and hacker culture. By Q4 2026, it feels like the Singularity has arrived, and I am developing ZERO KNOWLEDGE, a cyberpunk deckbuilder, as a solo indie developer with coding agents involved in the software, art and sound. Building the tools around that work has connected software engineering to the ambitions I had before I knew what software engineering was.

The backbone of this process is an art bible that agents can find, interpret and use. I need to curate and preserve artistic decisions while the models and development tools keep changing, and make those decisions usable by agents working in parallel. This article describes how I build that resource: providing seeds, exploring different directions, constructing tools to review them, and turning the results into guidance that can support a coherent game.

1. The art bible as a development resource

An art bible defines the identity of a game and gives the people making it enough shared direction to extend it consistently. Its visual references establish composition, palette, proportions, materials, lighting and motion. Those choices come from a setting, a set of themes and an intended experience. A collection of attractive images leaves much of that unspecified.

In ZERO KNOWLEDGE, the player is implicated in attacks attributed to them by an escaped intelligence. They have to contest that attribution while protecting human sources. The setting combines clandestine infrastructure, hacker counterculture and occult imagery used as a technical visual language. A seal can represent a signature or access boundary; a mythic figure can label a behavior model. The writing needs to preserve that distinction. An agent should not see the card art and conclude that literal gods have entered the story.

For agents, I expand the bible into a more operational resource. It covers the setting and themes, writing style, sound, and the UI through which the player encounters the world. The copy bible specifies terse procedural system messages, precise rules text and sparse environmental writing. Interface guidance needs to carry that into typography, color roles, spacing, panel hierarchy, focus states and motion. These are also design-system decisions: how a button looks, what it says, and how it behaves should agree.

I organize this as linked documents and references. For a new project, I would start with something like this:

art-bible/
  README.md                 # Where to start; which decisions are current
  world-and-writing.md      # Setting, themes, voice and vocabulary
  visual-direction.md       # Composition, characters, environments and motion
  sound-and-music.md         # Instrumentation, texture and event cues
  interface.md               # Typography, color roles, layout and interaction
  references/                # Annotated seeds and accepted examples
  reviews/                   # Candidates, feedback and decisions

The documents link to the relevant generation scripts and review apps. For example, a character entry would include its accepted portrait, guidance for varying the expression without changing its identity, and a way to inspect those expressions in the battle UI. A world entry would include the setting, lighting references and the scene where I review its models. That gives the agent enough context to work on a specific part of the game without loading the entire project history.

2. One developer, many agents

When I began this project, much of the process involved pasting code into ChatGPT in a browser, writing image prompts by hand and moving the results around myself. By late 2025, it had started to feel like the exponential growth I had been reading about for years was showing up directly in what I could attempt. That feeling has only become stronger through 2026.

An idea that once required a separate tool search and a lot of manual work can now become a request to build the tool. I can ask an agent to connect a generation API, produce candidates, create a local review application and integrate the direction I select. The game originally had 2D maps; eventually I decided to try 3D environments, found workable model APIs and built browser-based viewers to inspect the results. The ambition has grown elsewhere too: different AI opponent types, character emotion frames, music and sound design. Each adds another area in which I can experiment, and another set of decisions that has to fit the game.

Parallel agents make the coordination problem more interesting. One can work on an environment while another works on the interface and another develops sound. Each needs enough shared context to produce something that belongs in the same game. More capable models can interpret that context in new ways, including proposing directions I would not have thought to request.

I want to be able to give this work to however many agents make sense as the tools improve, potentially hundreds or thousands, or more. I cannot personally re-explain the game to each of them. If one agent changes a character's design while another is generating its emotion frames, I could end up with a lot of finished work that no longer fits together. I need to give those tasks a specific version of the bible, keep their outputs separate, and review changes to the shared direction before other agents start using them. My ability to review and integrate the results still puts a limit on how much work I can usefully run at once.

For me, this is becoming part of the artistic process itself. I bring the references, react to the alternatives, combine things I like and revise my intentions as I see what is possible. The agents contribute interpretations and build the means to explore them. The bible records the direction that emerges from that exchange so it can guide the rest of the game. That is how I can remain one developer while attempting work across disciplines and parallel sessions.

3. Seeds, experimentation and cost

My cumulative estimate is thousands of hours and thousands of dollars spent on generations and the surrounding experimentation, across dozens of platforms and successive generations of models, since beginning this project over two years ago. Developing the art bible has taken a substantial part of that effort. It has also been one of the most difficult and enjoyable parts of making the game.

The process starts with seeds. I use that word for creative inputs: artists, games, music, writing, drawings, photographs, or a description of something I want to explore. A creative seed is different from the numeric seed exposed by some generation APIs. It gives the model something to interpret and gives me something concrete to react to.

Those inputs have included Shin Megami Tensei concept art and Gustave Doré's illustrations. I spent hours writing prompts, generating images, making rough edits and feeding examples back into the next attempt. As the tools improved, I could move that exchange into custom web apps and apply it to more of the game: copy, color palettes, menu styles, sound effects, music and 3D models.

Two of my references, with very different treatments of the figure: red-and-black shapes in the Nocturne PS2 cover, dense engraved shading in Doré. Left: Nocturne PS2 cover artwork, ATLUS. Right: Doré's illustration for Paradise Lost, 1866.

I was also learning what I actually wanted. A batch might reveal a composition I liked, an atmosphere that belonged elsewhere, or an entire direction I wanted to abandon. Starting with very different alternatives made that discovery possible. Five nearly identical images could help me refine a decision, but they could also keep me inside a small box I had chosen before seeing much of the space.

This is where a lot of the cost comes from. I am paying to explore, compare models, reject outputs, revise references and sometimes rebuild the environment used to inspect them. Generating entire worlds in one pass did not work well for me. Generating individual objects and assembling them gave me a more workable path. The experiments contributed to that decision even when their outputs never entered the game.

For each new pass, I now want a clear question, a set of seeds and a batch budget. I also want the previous outputs available. A new model may justify reopening an old experiment, but I should be able to explain what has changed and what I expect to learn. The accumulated references and decisions are useful even when the generation method becomes obsolete.

4. Design principles

4.1 Start with maximally different directions

I want the first pass to expose substantially different possibilities. If I ask for five flavors of the same initial idea, I may spend the rest of the process choosing between 5% differences without discovering something that excites me more.

Make the differences explicit. For an environment, vary spatial organization, architectural influences, material age and lighting distribution. For writing, compare different narrative distances and levels of technical specificity. For music, explore differences in instrumentation, rhythm and density. Keep the purpose of the asset and the game's existing constraints clear while giving the agent room to propose alternatives.

The next pass can combine selected properties. I might want the structure of one candidate, the material treatment of another and a lighting idea from a third. I describe that combination and generate it again so I can judge how those choices affect one another in the same scene.

Once I have accepted a direction, I narrow the exploration. If I am correcting the roof material, the composition should remain stable. The broad first pass helps me find the direction; the constrained later pass helps me understand the effect of a change.

4.2 Bring your own observations into the process

I have worked on this game while travelling through more than a dozen countries (...mostly using social dance, another very addictive passion of mine, as my compass). One of my favorite parts of the 3D work was going out to physical sites, finding something interesting, sketching it and taking photographs to bring back to the agent. While living in Spain, this gave me a reason to buy drawing supplies and return to something I had loved as a child.

It also addressed a practical problem. Describing a shape through text or voice can be frustratingly low bandwidth. A drawing can show the proportions I mean immediately. A photograph can convey a material, an arrangement of buildings or a particular quality of light that I would otherwise spend paragraphs trying to describe.

Madrid: the monument, its surrounding colonnade and my sketchbook. This is the kind of reference material I can bring back into a taste pass.

I annotate what I want to carry over. In a photograph, that might be the outline of a structure or the way light falls across it. I keep the original beside any crop or edit I give the model, so I can return to the observation that started the experiment.

This has become a reason to explore the places I visit. Something I notice outside can turn into a drawing, then a new direction in a taste pass. Software engineering lets me carry that observation into forms I could not have produced on my own when I first wanted to make game art.

4.3 Make the feedback environment easy to use

The game began as a React web app in its earlier life as a Web3 card game. I kept the web approach because distribution was convenient and it made these review tools straightforward to build. The current stack uses React and Next.js, React Three Fiber and Three.js for the worlds, and Electron for the desktop package.

This makes it relatively straightforward for an agent to build the tools I need to see and hear the work. A gallery, a model viewer and an audio comparison page can reuse parts of the game's implementation. I can get from a generated model to an interactive scene without moving between several unrelated applications.

One of my early 3D environment reviews, filmed on my laptop. Moving around the models makes their proportions, spacing and lighting much easier to judge than a thumbnail does.

I would choose a stack partly on how easily I can build that review environment. The viewer needs the game's camera, lighting and scale. If I were using another engine, I would have the agent build review scenes and capture tools there. I want to spend my attention on the work, with as little friction as possible when I ask to see another angle or compare an alternative.

Giving the agents access to my Steam Deck extended this loop. I had bought it to play and test games, although in practice it had almost exclusively been used to emulate my old PS2-era survival horror favorites like Silent Hill and Resident Evil. The SSH setup I already had became a way to give Claude and Codex access to the running game. Watching that work was one of the more convincing Singularity moments for me.

Technically, SSH provides access to the device and a forwarded Electron debugging connection provides access to the application. The automation can exercise input paths, capture screenshots and video, and inspect performance in an isolated QA profile. Some tests inject synthetic gamepad state through the production input provider. I still use the physical controls myself to judge how they feel.

My laptop and Deck during development. The terminal and the game on the device are part of the same feedback loop.

4.4 Treat model choice as an artistic variable

Model choice has changed my results enough that I want it built into the exploration process. A prompt that works well with one model is not a complete specification for another. Reference handling, editing behavior and the available parameters all affect what I can ask for.

For the modular 3D worlds, I have used gpt-image-2 for concepts and fal's Hunyuan 3D v3.1 Pro endpoint for textured models. A request looks like this:

{
  input_image_url: dataUri(await fs.readFile(target.concept)),
  generate_type: 'Normal',
  enable_pbr: true,
  face_count: 120000
}

The request asks for a textured model with PBR materials and a target face count. The endpoint documentation also describes optional reference views. The output still needs inspection; a requested polygon budget says little about whether the silhouette survived reconstruction.

The controls worth testing depend on the medium:

The ElevenLabs sound-effects API, for example, exposes duration, looping and prompt influence. I want the settings actually used recorded with the output. Keeping the media matters too: a saved request may not produce identical results after a provider update.

For a model comparison, hold the brief and review conditions stable while configuring each model appropriately. Otherwise, a better reference packet can look like a better model, and I learn very little about which change helped.

4.5 Keep the bible organized enough to use

After enough experiments, the organizational problem becomes very real. I may have several images of the same character, different model generations and notes that made sense when I wrote them. An agent joining the project needs to know which portrait to use without repeating my search through all of them.

The structure in the first section gives me a place to put that information. Each entry should show the current references, explain what I liked about them and link to the review that produced the decision. I keep experiments and superseded directions available, but outside the set that a new task should treat as current. If I change a character's design, its entry needs to say what changed and which emotion frames still need updating.

I do not think the whole thing needs a schema. Consistent headings and links are usually enough for the explanation. I use structured data where the tools need it, such as generation settings, asset lists and exported feedback. The organization should let me or an agent pick up the work after an interruption and understand where to continue.

4.6 Make reading it part of the agent's instructions

The bible needs to be in the agent's normal path to doing work. I use repository instructions to direct agents back to the relevant resources whenever they change the game. AGENTS.md provides an open format for project instructions; use the equivalent entry point supported by the harness you are running.

A useful directive names the authoritative paths and the work they govern. An agent changing a world should read the world bible. One changing interface text should read the copy bible and the relevant UI rules. The task then supplies the narrower context: the asset, the selected references, the unresolved issue and where I expect to inspect the result.

Before a substantial generation pass, I want the agent to tell me which references and decisions it is using. That gives me a chance to catch an outdated portrait or a discarded direction before it becomes another batch of outputs.

5. The workflow I use

5.1 Connect the coding harness to generation APIs

I start by giving the coding agent access to an API for the domain I want to explore. A platform with several models behind one key makes comparisons easier. My work has included KIE.AI for images and video, fal for 3D, and ElevenLabs for sound and music.

I have the coding harness implement a local script or server adapter that reads the credentials from its environment. The review app can then request generations and display their status without putting API keys into browser code or feedback exports.

For queued generation, separate submission from collection. My fal script saves the endpoint, concept path and request identity, then a later invocation collects the GLB. The fal queue API supports this lifecycle. If a process stops between submitting a paid request and saving its response, reconcile the accepted job before retrying. The batch budget should apply across all workers using the provider.

5.2 Assemble the seeds for the pass

Select references from the library and explain what each contributes. My references have included Lovecraft for writing, the soundtrack of Shin Megami Tensei III: Nocturne for music, and my own drawings or photographs for visual work. A useful brief translates that interest into the properties I want to investigate.

For a world module, I supply the relevant bible section, approved paintings, the object's role and its spatial constraints. For a copy pass, I would supply the setting, voice register, terminology and a few examples of the intended writing. For a menu, the same packet should point to the design system and the interaction being supported.

Ask the agent to propose different interpretations of those inputs before generating the batch. It should have room to find an unexpected direction while remaining clear about which constraints are already accepted.

5.3 Generate candidates and prepare them for inspection

Give each candidate a stable identity and retain the references, prompt, model settings and output. I need feedback to keep referring to the same thing when the gallery order changes or a later revision appears. Preserve the original output and make separate derivatives for review and runtime use.

For example, my 3D tools use glTF Transform to simplify geometry, apply Meshopt compression and convert textures to WebP. I compare the optimized model with the original in the review scene, looking for damage to the silhouette or materials. The reduction I can get away with depends on how large the object appears, its shape and the device rendering it.

A Dark Net kiosk concept used for 3D reconstruction. The base, roof and projecting details give me specific features to compare with the generated model.

5.4 Build a taste pass around the decisions

A taste pass is a review of candidate directions with an interface for recording what I want to keep or change. I have used local web apps for this across images, text, palettes, menus, audio and models. The interface can be quite simple, provided it lets me inspect the thing I am actually deciding about.

Images need close inspection and comparison. Models need orbit controls and the production view. Audio needs replay at a known gain, ideally in the event or mix where it will be heard. Video needs scrubbing through transitions. Writing and UI need to be reviewed in context, where text length, hierarchy and interaction affect the result.

Ratings help me sort a batch, but the next iteration needs reasons. For example: retain the silhouette, reduce the roof detail, and keep the central route clear. Sometimes the most useful feedback is a rough drawing or an edited screenshot. I want the tool to accept those forms of communication rather than force everything into a score.

Save or export the feedback with candidate identifiers and revisions. One of my local review tools saves JSON and produces a Markdown execution brief. That gives the next agent the decisions it needs without requiring me to explain the entire review again.

5.5 Iterate in the game

In ZERO KNOWLEDGE, a bridge can look good in the model viewer and then obscure the route when I put it on the map. Before generating another bridge, I want to inspect its position, scale and the player's camera. The bazaar layout code fits rotated model bounds into declared footprints, with tests for containment and separation. Those checks help with assembly, but I still need to see whether the player can read the route through the scene.

Character emotion frames have a related problem: an expression can look convincing on its own while appearing to belong to a different person beside the accepted portrait. I need to compare them together and use the selected portrait as the reference for the edit. Generating each expression independently makes that consistency much harder to maintain.

A line of flavor text can fit the setting while obscuring a rule, and a sound that works alone can become exhausting when it repeats during a battle. These are reasons to bring candidates into the game early. The agent can give me captures and measurements from the target device, and I can use them to work out whether I need to revise the asset, its implementation or the direction itself.

5.6 Lock in the direction and distribute the work

When I accept a direction, I have the agent update the relevant bible entry with the selected references and my feedback. I want it to record what I accepted specifically. Liking the kiosk concept, for example, still leaves the reconstruction and its appearance in the scene to review.

I keep the rejected alternatives with short explanations. They save me from rediscovering why I abandoned an idea, and sometimes a new model gives me a reason to try it again. The current direction needs to be clear enough for other work to proceed while I continue experimenting elsewhere.

For parallel tasks, I would identify the version of the bible each agent is working from and give it a separate place for its outputs. If I change the character design halfway through a set of emotion-frame jobs, I need to identify the affected jobs and decide which to revise. Updating the shared document alone will not update work already in progress.

I also have to size the batches around what I can review. Automated checks can reject missing files, broken models and outputs that exceed the rendering budget. Grouping related results helps me compare the remaining candidates. I still need to decide what I want to use, which becomes a substantial part of the workflow as parallelism increases.

5.7 Build a playable vertical slice and talk through it

Once the pieces are far enough along, I want a playable vertical slice that brings them together: moving through an environment, meeting an opponent, playing a battle and seeing its outcome. It needs enough of the intended art, writing, interface, music and sound for me to experience how they work together. I want that slice early enough that playing it can still change the direction.

I record the screen and microphone while playing and say what I am noticing out loud. I might lose the route against the scenery, miss an opponent's expression while reading a card, or find that a sound becomes irritating after several turns. Those are things I can miss when I spend the whole session looking at individual assets. I need to play the actual game a lot to develop a human sense of its look and feel.

I then give the recording or timestamped transcript to an agent and have it turn the observations into follow-up tasks. Each task should point to the moment in the recording, describe what I experienced and identify what needs investigation. If I say that I cannot tell whose turn it is, that should remain the problem to solve; the agent can investigate hierarchy, animation timing or a missing cue before proposing a change. Otherwise it is easy to turn a useful observation into an overly specific fix too early.

I review those tasks, have the agents work through them, and play the revised slice again. A change to the wider direction belongs back in the art bible; a local implementation fix belongs with the relevant task. Playing again is how I find out whether the change helped, and what the combined result makes me want to do next.

6. Prompt fragments for the next pass

These are fragments I would give a coding agent at different points in the process. They need the actual references and project files alongside them. Replace the braced values with the relevant paths and decisions, and use the fragments that fit the task.

Use the setting, voice and design-system references for writing and interface tasks too. For a playtest follow-up, include the timestamped observation and the part of the game in which it occurred. The fragments assume the agent already has your project instructions and budget.

6.1 Establish the resource

Read the existing art direction and project instructions. Organize the
authoritative art bible around {asset family}. Preserve accepted work.
Identify the current references, fixed constraints, open decisions and
the scene or playback setup used to inspect results. Annotate my drawings,
photos and recordings in {reference directory} with what each contributes.
Distinguish creative reference seeds from numeric generation seeds.
Add a short pointer to the bible in the harness's project instructions.

6.2 Explore broad directions

Using {bible section} and {reference IDs}, propose four substantially
different directions for {asset role}. Vary silhouette, spatial structure,
material and atmosphere. Keep {gameplay constraints} fixed. Explain what
each direction tests; avoid four cosmetic variations of the same object.
Give each a stable candidate ID and a brief I can compare before generation.
Use the authorized batch budget in {task brief}; if none is set, stop at
the briefs and cost estimate. Keep all candidates separate from accepted work.

Four is an example batch size. I would choose the count and variation axes to fit the medium, budget and amount of work I can review.

6.3 Connect generation models

Implement a local generation adapter for {provider and model choices}.
Read the current official API documentation. Credentials are available
through {environment variable names}; check presence without printing values.
Record the endpoint/model, actual parameters, reference IDs and output hashes.
Separate submission and collection for queued jobs. Reconcile uncertain
submissions before retrying. Keep keys out of the review app and its exports.
Compare models on {representative task} under the same review conditions.
Use the existing authorization and budget in {task brief}.

6.4 Build the taste pass

Build or adapt a local taste pass for {candidate directory}, using the
project's existing stack where it suits these media. Include stable IDs,
full-resolution inspection, relevant generation settings, Keep/Change notes
and acceptance scope. Save feedback and support export/import without
attaching old approval to a changed artifact. For {media types}, provide
the controls needed to inspect the actual issue. Compare candidates under
{camera, lighting, scale, gain or playback conditions}. Preserve previous notes.

6.5 Inspect the runtime

Put {candidate IDs} in {production scene or playback event}. Use the
actual camera, lighting, scale, UI and interaction constraints from the bible.
If target-device inspection is authorized, use {existing connection} and an
isolated QA profile. Preserve player saves and unrelated sessions. Capture
the result and record the build, artifact revisions and relevant measurements.
Distinguish observed device behavior from preview assumptions, and identify
anything that still needs physical controls, listening or human play.

6.6 Refine a specific property

Read {feedback file} against the exact candidate revisions it names.
Retain {accepted properties}. Change {unresolved property} and explain
which stage needs correction: generation, geometry, placement, lighting,
audio/editing or presentation. Create a new revision, preserving the baseline.
Do not infer that a liked concept is an approved runtime asset. Reuse passing
evidence only where the artifact and relevant conditions are unchanged.
Return the revised result in the same review conditions.

6.7 Record the accepted direction

Apply my acceptance in {feedback file} to {bible section}. Record the
selected artifact IDs and hashes, accepted properties, review conditions,
production recipe and remaining issues. Mark conflicting older guidance as
superseded while retaining its reason and reference. Keep approval scoped to
what I reviewed. From the normal project instruction entry point, verify that
a new task can find the current direction and the place to inspect its result.

6.8 Turn a play session into tasks

Read {recording or timestamped transcript} from my play session of {slice or
build}. Turn each thing I noticed into a follow-up task that points to the
moment in the recording, describes what I experienced in my words, and names
what needs investigation. Keep my observation as the problem to solve;
investigate hierarchy, timing, cues or the asset itself before proposing a
fix. Send changes to the shared direction to {bible section} through a review;
keep local implementation fixes with the relevant task. End with the list of
what I should play again to check each change.

7. Conclusion

I have packaged the workflow as Agent-first art bible: an instruction template, four skills, prompts and a worked example, using Markdown and the Agent Skills format.

AI has expanded what I can attempt as one person. I hope this gives you the inspiration and practical tools to tackle an ambitious art project of your own, even one you previously thought was out of reach.

Play ZERO KNOWLEDGE Play demo on Steam Wishlist on Steam Skills on GitHub Instagram devlogs