Design doc vs. Arcweave: when AI builds your game, how can you keep creative control?

With AI already able to develop games from descriptive prompts, several questions are raised regarding the designer's creative control:

• How can you keep efficient control of the building process?
• Is there a way to oversee what the AI actually makes?
• Can you change one dialogue line without breaking everything else?

We build Arcweave for game designers and writers, and our view on AI is simple: it should support creative work, not replace it. The people making a game should decide how it turns out. Even in a world where AI undertakes building a game, the designer should be able to stay in control of the result.

Our experiment

Wanting to know whether the source you feed the AI makes a difference, we ran a small experiment: we wrote one game, encoded it twice, and had the same AI build it from each version:

• Version 1: The AI model used a game design document as its source.
• Version 2: The model used an Arcweave project, instead.

Experiment goal

The question we wanted to answer is: If the AI uses an Arcweave project as its source and context, instead of a design document, does the designer get more control over the game it builds, at the same quality?

By "control" we mean two things:

• We can see the structure and logic of what is being built.
• We can iterate and make changes without breaking something else.

What our experiment was not about

Our experiment did not aim at testing the AI's speed or capacity to design a game on its own. We did not ask the AI to write or design anything. Every line, choice, condition and ending came from us, human designers.

The AI's job was to turn them into a working game.

The game

Story & gameplay

The Last Ferry is a one-screen point-and-click adventure.

You are a traveler who has just missed the last ferry off a small Greek island. You are stuck in the harbour shed with Panayotis, a proud ferryman who would rather finish his cold coffee than help you. The ferry leaves in ten minutes and the door to the pier is locked.

How you treat Panayotis decides whether you make it onto the water.

Outlining the goals

Before writing a line, we fixed a brief of nine must-haves that every build would be scored against:

1. One room on a single screen
2. A player character that moves
3. Five objects you can click, each with a text description
4. One character you can talk to
5. A dialogue where the player chooses between options
6. An inventory
7. A locked exit that opens only when a condition is met
8. Two endings, decided by what the player did
9. A way to restart after an ending

Each must-have scores as follows:

• 2 points if it works
• 1 point if it is there but broken
• 0 points if it is missing

We also set four questions in advance to interpret the scores:

1. Did we get the game?
2. Can we read the game from the source?
3. Did the AI stick to the source?
4. Can we change it safely?

Running the experiment

Preparation

We wrote the game once, then encoded it twice with identical text, conditions and variables. Both versions started from the same high-level game design document, which took about an hour.

• A - Design document: A full design document of the kind a team would really write: logic, branches, dialogue and the core game loop. About an hour and a half.
• B - Arcweave project: The same content rebuilt as a project. The dialogue was pasted in, the architecture was set up by hand, the game loop was modelled in the flow, and the high-level design document was stored inside the project. A similar amount of time.

AI prompt

The AI got the document in arm A. In arm B it got the project's JSON export and Arcweave's public description of that format. Everything else stayed fixed: the same model and settings (GPT-Astra, on high), a fresh conversation for each arm, and the same prompt:

"You are a game studio. Build the game described in the attached design document (A) or Arcweave export (B). It must run in the browser, with placeholder art. Everything the player reads must come from the source: do not invent content. If something is unclear, ask."

Follow-ups and changes

Follow-up messages could only describe what went wrong and quote the source. We gave no hints on how to fix it and added no new design.

Once the first build worked, we made three changes to the game, each testing something different:

1. Content: Rename the ferryman everywhere and change his first line.
2. Logic: Add a second condition to the locked exit.
3. Growth: Add a new character with their own dialogue and a third ending.

Each arm got its own parallel set of changes, with different names and lines but the same shape, so nothing carried over from one run to the other. The changes were short, so we sent all three in one update per arm. We updated the source, sent it to the AI, and told it only that the source had changed. The AI never saw a description of what was different.

The builds

V.A1 - Design document

From the design document, the game needed two rounds of fixes, about 15 minutes in total: some pop-up windows did not close properly, and the exit opened without the dialogue that was supposed to unlock it.

V.B1 - Arcweave project

From the Arcweave export, the game worked on the first try. Dialogue and object descriptions behaved as written. The export already gave the AI a structure to follow, and it found Arcweave's Arcscript interpreter on its own and used it to run the game's logic.

V.A2 - Design document

In the document, not all changes were equally easy to apply.

The rename took seconds, with Find & Replace.

The other two changes were harder, though. There was no obvious place for a new rule, a new character or a new ending, so we reused and patched existing sections, and the document got messier.

The rebuilt game worked, but the AI also changed the room layout, which nobody asked for. That counts as one break.

V.B2 - Arcweave project

In Arcweave, every change had an obvious home:

• The new character became a component.
• Their dialogue got its own board.
• The third ending came from evaluating a few new variables.

The AI applied all three on the first try, with no breaks.

Experiment results

The score

Using the must-haves and scoring system described earlier, we got the following results:

Interpreting the score

Play both versions

Both games are embedded below, in their 2nd versions, as the AI left them after the changes. They need a mouse, so play them on a desktop.

Play v.A2 - Design document

Play v.B2 - Arcweave project

You can also play the story the AI worked from, straight from the Arcweave project:

What we learned

Structure beats volume

Both sources held exactly the same content. The difference was that the Arcweave export told the AI how the pieces connect: which line leads where, and what has to be true before the door opens. The AI no longer had to guess how the pieces fit together.

Control is knowing where to edit

With the document, the hard part of a change was not the AI. It was working out where in the document the change belonged. In Arcweave, that place was obvious. The design document version got worse with every edit, and the Arcweave version did not.

Arcweave protects from unsolicited AI changes

Working from the document, the AI rebuilt more than we asked for and moved the room around. Working from the structured Arcweave JSON export, it changed only what we asked.

The AI reached for our runtime

Nobody told the AI to use the Arcscript interpreter. It found it and used it, so the game ran the logic exactly as authored instead of rewriting it in its own code. That is the most likely reason the first build worked. An Arcweave export is more than data: it comes with an engine that AI already knows how to use.

The game loop can live in the flow

We modelled the core loop in Arcweave: talk, investigate, come back and use what you found. That gave the AI the game's behavior, not just its content, and changing the flow changed how the game behaves.

Renames are not the hard part

Find and replace handles a rename in any format. The gap between a document and a project opens up when the logic changes and when the game grows.

What this means if you design or write games

The worry with AI tools is that you hand over your game and get back something you no longer recognize. In this test, how much control we kept depended less on the AI than on the source we provided.

• You are the author: You write every line of content or rule of logic, which then lives in the project. The AI builds from it and invents no content.
• You can check the work: The logic sits on a board instead of text. It is easier to see how the game is supposed to work and compare that with what the AI builds.
• You decide what changes. When we edit the project, the AI changes only what we have changed. Working from the document, it may rewrite parts we never have touched.

That is the balance we are building Arcweave for: the creative decisions stay with designers and writers, and AI takes on the building work around them.

What this does not prove

This was a pilot, and the results point in a direction rather than prove a rule. Here is what it does not cover:

• One designer, who knows Arcweave well and also scored both builds, without blind scoring.
• All three changes went in together, so we cannot tell which one caused the break in the document version.
• A small game. We expect structure to matter more at scale, but we have not tested that yet.
• Speed and cost were not measured precisely.
• One AI model, GPT-Astra on high. Other models may behave differently.
• Other structured formats. A well-organised spreadsheet might close part of the gap. A win here means Arcweave beat a typical design document, not every structured format.

What's next

We plan to run the experiment again, this time with:

• two or three designers from outside Arcweave
• a separate blind scorer
• one change at a time
• a spreadsheet as a third, stronger structured baseline
• a bigger game, with more rooms, more branches and a longer list of changes

We will share those results too, whatever they show.

Try it yourself

To give your own project to an AI, start with the Arcweave JSON export and the Arcscript interpreters, which run your conditions and variables as authored. To read about why a single connected project beats a document for the whole team, not just for AI, see One design, one place.

Arcweave's own AI features are optional: you can turn them off for any workspace, and we never train AI on your projects. Read our approach to AI.

Arcweave is an intuitive narrative engine that manages your collaboration and acts as your project's source of truth, including text, logic, and assets.