Well, That Escalated Quickly

I want to write down how this actually went, because the shape of it surprised me. Not the game — the making of the game. The project kept changing what kind of thing it was, and every time it changed, it quietly demanded a new way of working. I never sat down and chose a toolchain. The work kept outgrowing its container, and I kept scrambling to build a bigger one.

It happened in four acts. None of them were planned either.

A note before I start: I worked through most of this with an AI, which I'll refer to as Maude. Partly because naming the specific product would read like an endorsement, and I'm not in the endorsement business. Partly because "Maude" is funnier.

Act One — The Conversation

Talking to find out if there was anything there

It started as just talking. I had no artifact, no files, no idea what I was even doing. The only tool was a chat window. Nothing needed version control because nothing was being built — I was thinking out loud, asking whether a thing like this was even possible.

I didn't arrive with a design or even much of an idea. I arrived with a curiosity. And the back-and-forth is what surfaced that there was a board game in here — that the mechanics could be spelled out, made concrete, turned over and examined. The medium wasn't brainstorming. It was discovery. Maude didn't invent the game. She helped me see a shape that turned out to already be there.

Which, it turns out, is fitting. The creator of Blue Prince has said the thing began life as a board game concept before it ever became a video game — drafting rooms, drawing cards, a house assembled from parts. So the conversation wasn't dreaming something up out of nothing. It was recovering a form that had been there the whole time.

The moment the mechanics were laid out in front of me — written down, legible, real — the project stopped being hypothetical. That was the spark, and I was off.

Designing a board game is something I'd wanted to do for years. What I'd never had was an idea worth committing to — nothing that felt more compelling than what's already on the shelf. Playing Blue Prince broke that. It handed me a subject and a story I actually wanted to spend more time inside. The vision and craft that went into the video game are genuinely inspiring, and I wanted to build something worthy of them.

Act Two — The Documents

The work stopped living in my head

The ideas calcified into things worth keeping. Rules. References. Design notes. The work stopped living in my head and started living in files I could reread instead of rebuild. No infrastructure yet — but that was the first real escalation, and it mattered more than it sounds.

Here's a thing I think about. I recall the creator of Blue Prince saying in an interview that most of the design lived in his head. For one singular mind that built the thing over the better part of a decade. Astonishing, but a little mad. I do not have that brain. There is no universe in which I keep 110 rooms, eight safe-room rules, a trunk system, an item-spawn table, and a constellation mechanic congruent. These were difficult mechanics to figure out even when seeing them written down.

This is where the AI part of the story gets real, and it's not "the writing documentation was fast." It's that the documentation could hold consistency across a system in a way my working memory simply can't. Change one trunk rule and it ripples: the rules doc, the room glossary, two card decks, the deviations log, the ideas log, the production guide. Seven files, all of which have to agree, for one decision. Doing that by hand, every time, is how a design quietly rots — one file says one thing, another says the opposite, and six months later you can't remember which is true.

The other half is edge cases. My changelog is full of entries that read "design question raised — logged, not acted on." These are problems the documentation caught before anyone hit them at the table. A good collaborator doesn't just transcribe what you say; it notices the gap you didn't. That happened constantly, and it's most of why I was able to get through the first play through at all.

Learning how Maude Unlearns

But getting to that point meant learning something nobody explains to you: how Maude's memory actually works. It isn't documented, and it's not the kind of thing you'd even notice — until it fails you.

The first few times she forgot, it was disorienting in a specific way. I'd hand her the whole world one day, and the next she'd never heard of any of it. Every session started from zero. A collaborator who was sharp yesterday and has no record of it today.

So I went looking for the fix, and it was a staircase, not a step. First I learned Maude has a concept of a "project" — a place to keep shared context. That wasn't obvious; I had to find it. So: stop everything, recreate the whole thing inside a project, re-teach her from scratch. Better — and still missing details.

Then I thought I'd been clever: if I build a site, Maude can just reference the site, and I'll never have to re-explain. Sorta. It helped. It did not solve it.

Eventually Maude herself surfaced the idea of a project-description file — a single document that tells her how everything fits together. Useful. Would've been nice to know sooner, Maude. And even that didn't fully close the gap.

What finally did was moving the work into the place where the actual files live — call it VS Maude Mode — so she's reading the real thing on disk instead of a copy of it that drifts out of date the moment I change something. Each fix revealed the next gap. That's the whole shape of learning to work with this: you don't get told how the memory works, you discover its edges by hitting them.

The thing I'd tell you to do first

Here's the rung I only just found, and it reframed the whole memory problem. That project-description file Maude suggested — I'd been treating it as the answer, the one document that makes her remember. It isn't. It's a description. It tells her what the project is. But nothing makes her act on it; she reads it the way you'd skim a brief — useful background she's free to treat as flavor.

The thing that actually governs how she behaves is a different file, with a different job. Call it MAUDE.md. She reads it automatically, every single session, and treats what's in it as standing orders. Not "here's what the project is about," but "here's what you must always do, and never do." Don't break the game's internal logic. Change a rule in one file, change it in all of them. Never introduce a rules deviation without logging it. That file isn't a description. It's behavior.

I'd been cramming both jobs into one document and wondering why the rules kept slipping. Of course they did — I'd buried my non-negotiables inside a narrative she was free to read as backstory. The fix was almost insultingly simple: separate them. The rules she has to follow go in the behavior file. The story of what the project is goes in the description. One is law; one is context. I'd been writing law and filing it under context.

And this is the part I'd actually hand to someone before anything else. If you're starting a project like this, write the behavior file first — before the site, before the tooling, before the clever ideas. Sit down and write the short list of rules your collaborator must never break, in the file she reads every time. Everything I spent four acts thrashing toward — the project, the site reference, the whole staircase of half-fixes — was me discovering, the slow way, what one small file of standing orders would have handed me on day one. I'm still catching on, but this one felt like a big ah-ha.

The documentation is the design

Underneath all of that thrashing was a lesson I'd already been handed, years ago, by a design mentor. At the time it sounded like a tidy aphorism. Today I understand it's full power

When you can't see the object in front of you — and a board game in progress is exactly that, an object that doesn't physically exist yet — the only way to know how it works is to write it down. The writing isn't a record of the design. It is the design. It's the thinking. It's the mechanics. It's the behaviors you want from the people who'll one day sit down and interact with it. There's no version of the design that exists apart from the document, because the document is where the design happens.

Act Three — The HTML Files

It stopped being for me

The documents wanted to be readable. Linkable. Printable. So they became HTML. On paper that's a boring technical step. It isn't. It's the quiet turning point of the whole thing, because an HTML file implies a reader.

A document is for you. An HTML page — a room glossary, a print sheet, a QR code on the back of a tile — is for someone else. The format started reaching outward, and the moment it did, the bar on everything went up.

I can point at exactly when this became true. A playtester sat down with the prototype, hit a moment where he needed to look up a room, and the only reference I had lived on a laptop. Nobody wants to consult a laptop mid-game. That single friction is why "QR codes on tile backs" and "physical item tokens" got designed — not because I had a clever idea, but because a real person couldn't use the thing I'd built. The work had acquired an audience, and the audience started changing the design.

So the AI part of this act isn't transcription anymore. It's construction. Maude was building the actual readable artifacts — the glossary, the constellation reference, the print sheets — the things that let the game be handed to another human instead of narrated by me, hovering, explaining. Once a thing can be handed over, it has to survive without you in the room. That changes how you build it.

The part I'll admit to

I'm confident in most of what I bring as a designer, but I'm not bringing the math. I love data, but analizing it? Numbers, probabilities, distributions — they intimidate me in a way layout and systems and feel never have. When I started thinking through the rarity system, I almost walked away from it. Not because it wasn't solvable, but because the math sat there like a locked door I didn't want to try.

Maude made it less scary. She walked me through different probability models, showed me the trade-offs between them in plain terms so I could intepret what it would mean to the player's experience.

The other part that really mattered — suggesting ways to manipulate those odds at the table, with physical components, instead of leaving them as abstractions on a spreadsheet. The obstacle didn't disappear. It just stopped being an obstacle and became a tool to manipulate the experience.

Act Four — The Site

The process I never asked for

At some point there were enough linked HTML files, with shared navigation and shared styles, that it simply was a site — whether or not I'd decided to build one. And a site is a different animal. It deploys. It goes stale. It needs version control, and a way to keep a working copy from drifting out of step with what's actually live.

Every piece of tooling I wrestled into place exists because of this one line being crossed — from "documents in a folder" to "a published thing in the world." The process didn't sprawl randomly. It was summoned, friction by friction, by the format. Let me name the frictions, because each one had a specific pain behind it:

Version control, because hand-deploying a sixty-file site by dragging a zip into a browser stopped being sane. The changelog entry for the day I fixed it literally says: no more manual zip uploads or drag-and-drop deploys. I didn't adopt it out of virtue. I adopted it to escape a worse thing.

A whole tangle of ways to work with Maude, because a chat window is great for thinking and terrible for editing dozens of real files on disk. So: a chat for design, a different mode for touching the actual repo, a hybrid where I still reach for a second AI when it's better at a given task. It is not a stack I designed. It's a stack I accreted — the residue of solving one problem at a time and keeping whatever worked.

An afternoon lost to a sync problem, which is the most on-the-nose example I have. A "helpful" frozen copy of my project sat there insisting the site looked one way while the live version had moved on days earlier. I spent real time confused about why nothing matched, before realizing the snapshot was stale and quietly fighting me. A document in a folder can't do that to you. A published, multi-surface, version-controlled site absolutely can.

That's the pattern, top to bottom. The tooling escalated for the same reason the documents did: the thing I was making kept becoming a bigger kind of thing.

What I actually learned

The lens that finally made sense of the mess was simple, once I saw it.

Not the other way around. I never decided to become someone who runs a deploy pipeline. The work decided that for me, by refusing to stay small. Each new shape it took — conversation, documents, pages, site — knocked on a door I then had to figure out how to open.

And the collaboration ran the whole length of it, but it kept changing job. In Act One Maude was a flashlight, showing me there was something in the room. By Act Two she was the memory I don't have, holding a system consistent across files — once I'd learned how her own memory worked and didn't. By Act Three she was building the things I'd hand to other people. By Act Four she was helping me run the machinery that a public artifact drags in behind it. Same collaborator. Four completely different roles, because the work kept asking for a different one.

— QQ