Why One Rule Change Breaks Your Whole Layout (and the Fix)

One rule change breaks a finished layout because the layout file holds its own copy of every rule. The number you want to change has been typed onto several pages, and nothing connects those copies. The fix is to keep each rule in one place and build the pages from it, an approach called single-source publishing.

What happens when you change one rule after layout

You get five jobs, and only one of them is the change you wanted to make.

Take a spell called Cinder Lance. It deals 8d6 fire damage, and after three playtests everyone at the table agrees that is too much. You want 6d6. That is one character.

In a finished layout file, here is what that character costs:

1. Find every copy. The number sits in the spell's own entry, in the spell list, on the quick-reference page, in an example of play and on a ready-made character. Search helps, but "8d6" also turns up in spells you did not mean to touch, and it will never find the sentence where someone wrote "eight dice".
2. Fix each copy by hand. Miss one and the book now disagrees with itself.
3. Check what moved. Most changes are not as tidy as swapping a digit. Add one sentence to a spell and the text re-wraps. A stat block that grew by a line can slip onto the next page and take the rest of the chapter with it.
4. Check the page numbers. A generated table of contents can be refreshed. A "see page 84" that somebody typed cannot.
5. Export again, then repeat the fix everywhere else the rules live: the web version or SRD, the playtest packet, the manuscript you started from.

Layout apps do take some of this off your hands. Text re-wraps on its own. A generated contents page or index can be rebuilt. Cross-references that were set up as real cross-references follow their targets. Affinity's help says its cross-reference fields stay up to date as the content changes "with little or no effort on your part."

What the app does not know, unless you built the link yourself, is that the 8d6 on page 47 and the 8d6 on page 212 are the same fact. To the app they are two unrelated pieces of text.

Why is it so painful to change rules after layout?

Because in a layout file, the rule and the page it sits on are the same object. Once your text is placed in the file, the words are part of the page design. Two things follow from that.

First, every repeated fact becomes a separate copy. A rulebook repeats itself on purpose. It is a reference book, so the same number appears where the rule is taught, where it is listed and where it is summarised. Each of those is good design, and each is one more place to fix.

Second, the manuscript goes stale. The day the text is placed, the layout file becomes the real book and the document you wrote in becomes an old draft. Now there are two versions of the rules, and only one of them is right.

Games are not a special case here. Book publishers have priced this problem for years. SilverWood Books, a self-publishing services company, tells its authors that "sometimes even a relatively small change can mean that entire page layouts require re-formatting", and it charges for the time. BookBaby asks for "the absolute, fully edited, final draft" before design starts, and says in its formatting guide that text edits after the first proof cost extra.

So the standard advice is to finish the text first. That is good advice for a novel, which really is finished at some point. A rulebook meets playtesters, then players, then the errata thread. We think that is why game designers feel this harder than most authors do: the rules keep moving after the layout is done.

None of this is a flaw in layout apps. They are built to give you control over every page, and they do that well. The cost only shows up when the words change.

What is single-source publishing?

Single-source publishing is a way of working in which each piece of content is written once, kept in one place, and reused wherever it is needed, so a correction is made once.

Think of a spreadsheet. You can type a total into a cell, or you can write a formula that points at the numbers. The typed total is right until a number changes. The formula is right every time.

Technical writers have worked this way since the 1990s. Wikipedia's history of the method traces the first project to 1993, when one source file was used to produce paper manuals in several languages, and notes that Ford later generated owner's manuals for 12 model years from a single file.

For a game book, it looks like this:

• A spell, a monster or an item is a record with named fields: a name, a summary, a range. (Our guide to designing a consistent stat block shows what those fields look like for a creature.)
• A page does not hold a copy of the spell. It points at the record.
• The book is built from the records each time, along with the contents page, the index and the page references.

Change the record and every page that points at it changes with it.

One rule change, both ways

We ran the Cinder Lance change in RuleBindery, which we make, to show what the structured version looks like in practice. The screenshots below are from that run.

The spell was entered once, in the project's library. A short sample chapter then used it three ways: a mention in a sentence, the full entry, and a quick-reference line that pulls in the spell's summary. Then we opened the spell's record, changed 8d6 to 6d6, and saved. We did not open the chapter.

Both places updated. The "see p. 1" in the first sentence was never typed either. The build fills it in from wherever the entry lands.

Here is the same change in each kind of tool:

The last two rows are easy to overlook. If the rules are records, a tool can compare two versions of them and tell you what is different. We took a snapshot before the change and another after it:

That list is the raw material for an errata document, which RuleBindery can build from it on a paid plan. The details are on the pricing page.

Pointing at records does create one new way to be wrong: you can point at something that is not there. So the tool has to check. We added a line that refers to a spell we never created:

What do you give up?

You give up placing things by hand, and you take on some setup.

• Hand-placed design. A generated layout follows a template. If the look of each spread is the point of your book, a page-design app is the right tool.
• Setup time. Entering a spell as a record takes longer than typing it as a paragraph. That cost pays off at the first revision. It never pays off if nothing gets revised.
• A connection. RuleBindery runs in the browser and needs one.

A one-page game or a short zine with settled rules gets little from any of this. Lay it out in whatever you enjoy using. Our comparison of TTRPG layout software covers the options.

How to get part of the way in the tools you already use

You do not need to switch tools to make changes hurt less. Four habits help:

1. Do not type page numbers. Use your app's cross-reference feature for every "see page X". Typed page numbers are the copies that go wrong most quietly.
2. State each rule in full once. Everywhere else, name it and point to it. Fewer copies means fewer places to fix.
3. Use your app's reuse features for the things that will change. In InDesign, a custom text variable updates every place it is used when you change it. It is real single-sourcing, set up one value at a time.
4. Keep a change log from the first playtest. One line per change, with the date. It is the only record of what moved between versions, and later it becomes your errata.

If you are comfortable with code, Typst lets you define a value once and use it anywhere in the document. The Homebrewery has free variables too, though in our Homebrewery vs GM Binder test a longer stat block still cut off the text below it.

If your rules will keep changing and you would rather not maintain those habits by hand, writing in RuleBindery is free, and you can run the same test on your own rules.

Frequently asked questions

When should I start layout on a TTRPG?

In a page-design app, start when the rules have been through playtesting and editing, because every later change is paid for by hand. In a tool that builds the pages from your content, it matters much less. The layout is rebuilt each time, so you can look at pages from the first draft. Our guide to making a TTRPG rulebook walks through the whole sequence, from structure to errata, and our TTRPG rulebook template gives you a chapter order to start from.

Do InDesign and Affinity update the layout when the text changes?

Partly. Text re-wraps on its own, a generated table of contents or index can be refreshed, and cross-references you set up follow their targets. What they do not do by default is treat a fact repeated on several pages as one thing. You fix each copy, or you link them yourself.

Is single-source publishing the same as using paragraph styles?

No. Styles separate how text looks from the text itself, so you can restyle every heading at once. Single-source publishing separates a fact from the places it is used, so you can correct every use at once. They work well together.

Do I need special software for single-source publishing?

No. It is a method, not a product. Text variables in a layout app, a typesetting language like Typst, and structured tools like RuleBindery all do it to different degrees. The difference is how much you set up yourself.