Post

Me, Myself, and I. As well as 5 AI agents.

A game like Barkbread needs a lot of systems. Combat, saving, quests, menus, and dozens of small things in the world you can pick up, open or set on fire. Every one of them is careful, fiddly code before it feels right.

It also needs a world, writing and a feel. That’s the part only I can do. And it’s exactly the part that got squeezed when I was also the only programmer.

(If you haven’t seen it yet: Barkbread is a dark fantasy RPG set where the sun went out.)

So I split the work in two. I do the world and the words. AI agents (Claude Code, in my case) do the systems. And the two run at the same time.

An agent's own Unity Editor mid-session, the console listing the cheat commands it ran to set up a test and the Inspector showing the player's stats An agent’s own Editor, mid-test.

Unlocking Parallel Work in Unity

Two parallel tracks: me on world, writing and playtests, agents on systems, both meeting on master Two tracks, one master branch.

While I’m shaping the forest, a few agents are each working on their own feature or bug. When one finishes, its work lands in my project and I pick it up a few minutes later.

Running several agents in one Unity project without them wrecking each other turned out to be a whole problem of its own. I wrote that one up separately: agent slots.

The Agent Runs the Editor

People still assume AI coding means “it writes a C# file and hopes”. A year ago, fair enough. The big change is that agents can now operate the Unity Editor themselves.

There’s an MCP server for Unity. And with some modification, damn does it scale. MCP (Model Context Protocol) is a standard way to hand an AI a set of tools, and here the tools are the Editor itself: look around the scene, change things, run the game, read the errors, take a screenshot.

The chain from Claude Code through the Unity MCP to a package inside the Unity Editor How a request gets from the agent into the Editor.

That last part is the big deal. The agent can see what it did. After building a torch you can light, it runs the game, walks over, lights it, and looks at whether the fire actually showed up.

To make that fast, I gave the game a cheat console. One line puts the player wherever the test needs them, with whatever items it needs, and prints the whole game state back. A setup that takes me two minutes of clicking takes an agent a second.

Every feature goes through roughly the loop I’d run myself:

  1. I ask, in normal words.
  2. It reads the project’s docs.
  3. It writes the code.
  4. It compiles until it’s clean.
  5. It runs the game and sets up the exact situation.
  6. It looks. Wrong? Back to 3.
  7. It hands the work back.
  8. I play it.

The eight-step loop for one feature, from my request through code, compile, play mode and screenshots, to landing and my playtest One feature, eight steps. Only the first and last are mine.

Step 2 matters more than anything else on that list. The project has a folder of short notes written for the agents, on how things work here and what not to do. When an agent learns something the hard way, the lesson goes in there, so the next one doesn’t pay for it again. The model is the same one everybody has. The notes are what make it good at my game.

And step 6 is where they beat me. They don’t get bored checking the same edge case for the fifth time. I do.

The Rules I Give Them

Agents are fast and confident. That’s exactly why they need a few hard limits, and mine all protect the same thing: the parts that make the game feel like itself.

  • Never change the look without proof. Anything that touches rendering gets before-and-after screenshots, and if the art changed, the agent stops and asks.
  • Never touch the writing. That’s mine.
  • Keep work in small, separate files. Unity scenes don’t merge well, so the less anyone touches the shared ones, the fewer collisions.

What They Built, and What They Can’t

Turn-based combat against a Draugr in the forest Most of the systems in this fight were built and tested by agents.

A lot of what’s in the Barkbread demo came out of that loop. The quests, the combat, the interactable world, the menus.

What they don’t do is decide what Barkbread is. They don’t know the forest should feel like a Swedish December. They don’t write the voices, and they can’t tell whether a fight is fun or just long.

They also get things wrong. Sometimes a fix passes its test and feels wrong in play. Sometimes an agent solves the problem it was given instead of the one I meant. That’s why the last step of the loop is always me, playing the game. Or let’s be honest, a taskmaster agent playing the game for me, and reporting issues for me to spot check.

But the balance has flipped. I used to spend most of my week on plumbing. Now I spend most of it in the forest.

For a solo developer, it is a gamechanger.

This post is licensed under CC BY 4.0 by the author.