The board game design process,
in one living record.

21 categories · 138 entries

Identity, then categories, then a template per category, then entries. Everything else is built on those four.

The reason is mechanical rather than stylistic: a category decides what fields its entries carry, whether those entries are pieces in the box, and which product they belong to. Write entries first and you end up editing every one of them when you finally set the template. Meridian has 21 categories holding 138 entries — the categories were named before almost any of that was written.

It is the unit the whole tool thinks in. Not a folder — a declaration.

One category carries: the fields its entries get (the entry template), whether its entries are a Deck, a Token supply, Board Tiles, a Figures index or Story Book situations, which expansion it belongs to, and the columns you get when you export it as CSV. Change the category and every entry filed under it follows.

That is why ⚙ Category settings is one dialogue rather than five scattered switches: they are all the same decision, made once.

No. Set the category's entry template first, then export a blank CSV from that category — its columns are the template's fields. Fill in one row per entry and import it back.

Do it in that order and the import maps cleanly. Import first and you get entries with no structured fields, which is the thing the template exists to prevent.

It counts entries, weighted by each entry's Copies field, in every category you have switched on as a component.

Nothing is entered twice. A card is an entry in the compendium; flag its category as a Deck and the same entry becomes a card in a pile.

Copies lives on the entry, so one entry can be a token and a figure at once and be counted in both — the Content Summary says so explicitly rather than quietly double-counting.

Because it is two things. A hazard can be a token you place on the board and a miniature you paint.

Loruna counts it in both and then tells you, under "counted in more than one kind" on the Content Summary. The alternative — forcing you to pick one — would make the piece count wrong for the box or wrong for the painting checklist.

48 rules compile the book

Because a written rulebook goes stale the moment you change a rule at the table, and you find out three playtests later.

Rules live as records in the Rule Manager — a statement, a status, an optional tunable value. The Rulebook is compiled from them, so a change at the table is a change in the book. What you do write by hand are chapters: setup, the opening, worked examples — the prose the rules cannot express.

So you can say which book a game was played from.

The working draft always reflects your rules right now. Publishing an edition freezes a copy with a version number. The home page then tells you whether the draft has drifted from it, and by how many rules — which is the difference between "we tested the current rules" and "we tested something close to them".

Because every log is recorded against it, and every number in the Findings report is derived from it.

The loop is your phases, the values you track each round, and the ways a game can end. Log ten games against a loop that does not match your game and you have ten logs that cannot be compared to anything. Changing it later does not retro-fit the games you already logged.

It is the one setup step worth doing slowly.

Rate every phase, every round, and write the friction in the moment. That is the whole discipline.

A rating is one click and it drives phase health, the reception trend and the early-versus-late comparison that tells you whether a fix landed. A friction note is a sentence and it is what the report groups by phase to show you where the game actually hurts.

Everything else — outcome, player count, which expansion was on the table — is set once when you start the session.

Both, and the disagreement is the finding.

The reception trend is every game in order, including different scenarios. If your last two games were a solo variant that does not work yet, the line dips even though the main game is improving. The "How each scenario is landing" table separates them, and that is where to look when the two disagree.

This is exactly why the report breaks the same logs down several ways rather than giving you one score.

That you wrote a rule nobody reaches for.

Each phase of your loop declares the actions available in it. The report compares that list against every action ticked in every logged game. An action at zero after a dozen games is either priced wrong, placed in the wrong phase, or not needed — and it is invisible everywhere else in the tool.

Library → Auto-generate layout on the category you want. It reads that category's own entries, lays name, tagline, the fields the entries actually use and the body onto a plain black-and-white card, and opens it.

What comes out is an ordinary template, not a locked "generated" thing — open it in Component Studio and change anything. It only lays out fields your entries have actually filled in, and it steps the body's type size down until the category's typical entry fits, so nothing clips.

Then export a print sheet from the Templates page: it gangs the whole category onto A4 or Letter pages with cut lines.

Design the back on the same template — Component Studio's Data column, Editing side → Back — then use Duplex deck print on the Templates page.

It writes one PDF ordered front, back, front, back, one card per sheet, so a double-sided print puts each card's face and back on the same piece of paper. Pick Short edge if that is how your printer flips; the backs are rotated to match.

A back can be uniform (one design for the whole deck) or mirror (bound to each entry, for double-sided cards).

No — Component Studio carries a searchable icon library: suits, dice, resources, meeples, hexes, arrows, timers, and the usual interface marks.

They are vector, they take the same colour and size controls as any shape, and searching matches the tags rather than only the name, so "money" finds the coin.

Layout numbers throughout the editor are millimetres because that is what a printer wants; type size is shown in points because that is what type is measured in.

An expansion is a grouping, never a copy. You tag a category as part of it, and every entry filed there belongs to the expansion too.

From that one tag: its content takes the expansion's colour wherever it appears, it gets its own rulebook and its own story book, the Content Summary counts its pieces in a separate column, the promo sheet gives it its own segment, and a playtest can record that it was on the table.

Deleting an expansion never deletes content — its categories and rules are released back to the core game.

Once the base game is steady enough that you are no longer changing its core loop.

An expansion multiplies everything you have to keep track of: another rulebook, another column in the summary, another thing to have or not have on the table when you log a game. The Findings report will tell you if you have added one and never played it.

Everything that shows it. That is the point of keeping one record.

Change a card's Copies and the deck's total, the Content Summary's piece count, the promo sheet's "in the box" list and the home page's drift warning all move together. Rename a category and its compendium section, its pile name, its rulebook section and its CSV columns follow.

The only things that do not move are the ones you deliberately froze: published editions and locked deck versions. They are snapshots, and that is what makes them useful.

Who they are for. The Rulebook is for the player: how to play. The Story Book is for the table: the situations you play through. The Findings report is for you: what the playtests are telling you, and it is marked internal because it shows the numbers.

All three are compiled from the same record, and all three print from the Print & share box on your project home without leaving the page.

Both read the same logs. The difference is what you are doing.

Analytics is the working view: filter by mode or by expansion, and it is the only place with tracker curves over a game, per-card impact on outcome, win rates by locked deck version, and which entries have never appeared in a game. Use it when you are asking "why is this happening?"

The Findings report is the finished view: fixed, printable, and the only place with the scenario and player-count cuts, the pacing curve, the reception trend and the momentum block. Use it when you want to hand someone — a publisher, a co-designer, yourself in a month — where the game is.

Both live under Statistics & Findings in the sidebar, along with Content Summary and Compendium Health. Each links to the other.

It is where you write down what you learned from playing something else, while you still remember it.

One log per game: what you played, with how many, what it does well — and, the part that matters, what that implies for your game. A note that ends "their map matters because goods are scarce, not because movement is expensive" is worth something six months later; "Concordia — good" is not.

It sits in Tools next to Todos, because both are things you keep beside the design rather than inside it. Meridian ships with five worked examples, several of which turned into todos.

In your browser, per project, and out through Project Settings.

Export a backup and you get one file holding that project's entire compendium, rules, rulebook and editions, playtests and component designs — restore it into a new project on any machine and you get the project back. Individual categories export as CSV, the rulebook and sell sheet export as standalone web pages, and any lineage tree exports as a PNG or SVG.