Frequently asked questions

Why “Wyrd Builder”?

The word wyrd is Old English. It usually gets translated as “fate,” which is a lossy translation. Fate is fixed in advance and indifferent to you; wyrd is what unfolds — the accumulated weight of what has already happened, acting on what happens next. The Anglo-Saxon wyrd and the Norse Norns are cousins: both describe a future being woven, not a future already written.

That is what a game is. A rulebook is not a description of outcomes. It is a machine that produces them. Change the cost of one resource and you have changed the endgame of a design you finished a year ago, whether or not you noticed. The interesting object was never the static description. It is the system that generates consequences.

The second reason is plainer. It sounds like world-building, because that is what it is — you are building the thing the world runs on. And it deliberately does not name a genre. Games are where we started, not where the idea ends.

What does Game Designer actually do?

Game Designer, a Wyrd Builder product, is where you write your game down as a structured specification instead of a pile of documents. Resources, actions, phases, components, costs, scoring, the relationships between all of it. From that specification, Game Designer does four things:

It validates — checks that your design obeys its own rules. It analyzes dependencies — answers “what breaks if I change this?” before you change it. It simulates — runs your economy thousands of times to show you where the balance actually sits. And it generates — produces a rulebook draft, a component manifest, and a machine-readable spec that a developer or an AI can implement against without guessing.

The specification is the real artifact. Everything else is derived from it and can be rebuilt from it.

Where did this come from?

A friend’s game. He designs heavy euros, and one of them was complex enough that the table wanted a companion app. I offered to build one.

To build the app I had to write the rules down formally — every resource, every action, every cost, in a form a machine would accept. And the formal version started disagreeing with the rulebook. Small things at first. Then a card that the rules referenced, that the scoring section counted points for, and that was not in the deck. It had never been in the deck.

The game had been playtested dozens of times by people who knew it well. Nobody caught it, because nothing in the workflow was capable of catching it. Playtesting finds what happens. It cannot find what is missing.

That was the moment the app stopped being the point. The checking was the point.

Why start with euro-style strategy games?

Because they are the hardest thing to model, and we would rather find out now.

A worker-placement euro with an interlocking economy, a tech tree, variable player powers, and three scoring tracks that feed each other is one of the densest dependency structures in the hobby. Every number is load-bearing. Every rule touches four others. If a system can represent that faithfully — and tell you what a single cost change does to the whole thing — then representing a dungeon crawler or a party game is a much smaller problem.

It does not work in the other direction. Build for the simple case and complexity breaks you when it arrives.

There is a second reason, and it is about people rather than software. Euro designers already think in systems. They keep spreadsheets. They know what a dependency is. They can look at the output and tell us it is wrong, which is exactly what an alpha needs.

Is this an AI that designs my game for me?

No. The AI does not design anything. The system catches what the AI gets wrong.

That distinction is the whole product. Large language models are good at generating plausible text and bad at knowing whether it is true. Ask one to write you a set of faction abilities and it will produce something that reads beautifully and quietly contradicts a rule you established three pages earlier. It has no ground truth to check against, so it cannot tell the difference between correct and merely coherent.

Wyrd Builder is the ground truth. When something is proposed — by a model, by a collaborator, by you at one in the morning — it gets checked against the actual specification, and you get told what it breaks before it lands.

Doesn’t this take the creativity out of design?

The creative work is deciding what the game is about, what tension you want at the table, what a player feels on turn three when the position they wanted is gone. None of that is what this does.

What this does is the bookkeeping. You renamed a resource and now eleven cards are wrong. You moved a phase and two abilities no longer have a legal window. You cut a building and something still references it. Nobody’s creative identity is bound up in remembering which eleven cards. That part is not craft, it is overhead, and it is where designs quietly rot.

What if I don’t want AI anywhere near my game?

Then don’t use it. Turn the assistance off and Wyrd Builder is a validator, a dependency analyzer, and a simulator. It will still tell you that a card references a resource that does not exist, still tell you what a cost change ripples into, still run your economy ten thousand times.

We are aware of how this hobby feels about AI, and we think a lot of that feeling is earned. Our position is not that you should generate your game. It is that if anyone in your process is generating anything, something should be checking it.

Is my game data private? Does any of it train a model?

Your work is yours. We do not use your content to train machine-learning models, and we do not sell personal information. Both are commitments in the privacy policy, not intentions.

The detail worth knowing: the LLM-assisted features — rulebook ingestion, extraction, review — send the material you hand them to Anthropic to process, and that happens only when you invoke one of those features. Nothing is shipped off in the background, and with the assistance turned off nothing goes to a model at all.

There is no analytics, tracking, or session-recording tooling in the product. You can export your specifications in a machine-readable form whenever you want, your content stays until you delete it or close your account, and a deletion request clears your personal information within thirty days.

The privacy policy is the complete answer, including every processor we use and exactly what each one receives.

How is this different from a spreadsheet, or Notion, or an LLM and a folder of markdown files?

The folder of markdown is the real competition, and we are honest about that. It is free, it is flexible, and a lot of good games have been designed in one.

What it cannot do is tell you when you are wrong. A document store holds text. A chat model reinterprets that text on every call and produces a fresh, confident, unverified answer. Neither one holds a model of your game, so neither one can check anything against anything.

Wyrd Builder holds the model. That is the entire difference, and every feature is downstream of it.

What comes out the other end?

A rulebook draft, structured from your actual specification rather than transcribed by hand. A component manifest for print quoting and production planning. Dependency and impact reports. Balance simulation results with distributions rather than single numbers. And a machine-readable runtime specification — the thing you hand a developer, or an AI, when you want a digital implementation that matches the game you actually designed.

Regenerate any of it whenever the spec changes. That is the point of the spec being canonical.

Is this only for board games?

Right now, yes, and we would rather say so plainly than gesture at a roadmap we haven’t earned.

The engine underneath does not know what a game is. It knows about specifications, constraints, dependencies, provenance, and time. Those are the same problems a novelist has with canon and continuity, that a worldbuilder has with history, that an investigator has with evidence. The shape is identical: a body of interlocking commitments where changing one thing silently invalidates others.

We have a writing product in early work for exactly that reason. It is not shipping, and Game Designer is not waiting on it. First product stands on its own or nothing else happens.

Who is this for?

Designers who already think in systems and don’t have tooling for it.

If your game lives in three spreadsheets, a Google Doc, and a text file of things you keep meaning to fix, you are the person we built this for. If you have ever discovered mid-playtest that a rule you changed in March broke something you wrote in January, likewise.

If you design light, fast, mostly-vibes games, this is real overhead for not much return. We would rather tell you that than sell you a subscription.

What’s in the alpha, and what isn’t?

The alpha is small, rough, and real. You can author a specification, validate it, see dependencies, run balance simulation, and generate artifacts. Expect sharp edges and expect us to ask you a lot of questions.

Not in it yet: polish, breadth of game genres, and about half the quality-of-life features you will immediately want. Alpha users get to decide which half we build first.

Who’s building this?

O’Side Systems, which is currently one person and a very patient test designer.