The Joys of Automation

I don’t think any sane individual could write something like BIND without automation tools. Games with a similar scope require a team.

(I also require a team - everyone who’s helped me with editing has improve the book immensely, but that’s not today’s topic)

Changing Rules

Starting small - these rules appear in the core book.

Rules for Intervals

However, they also appear in the little rules booklet, and the two must be kept consistent. That probably sounds like an easy job when someone presents the idea to you, but when writing, and thinking ‘I should change the symbol for “day” to be more clear’, you will probably not remember to change everywhere that symbol appears in every book.

Booklet Rules for Intervals

The booklet cannot simply receive the same text - it needs different formatting, as the rules comes in A4, while the booklet is A1 paper - one eighth of the size.

Rules Glossaries

Each adventure modules receives a short list of the rules, along with everything most relevant to it. In this case, the module has lot of rules for underground fires, walking in the dark, and hypoxia. Ordinarily, those would have to be in some obscure section of a rules book, but automated glossaries mean that the module which references these rules has them, while the other modules simply don’t. Everyone can safely ignore the main rulebook if they wish to.

Glossary of Rules

Rules in Footnotes

It’s a well-known fact that nobody can remember the details of grappling rules in RPGs. This is where footnote summaries come in handy.

Rules in Footnotes

Once again, these notes are just links to the actual text in the Core Rules, so if the rules update there, then they will also update in all books. The page number automation also means those page numbers will be correct, even if all of the books gain or lose a few pages.

Rules in Footnotes

The first few footnotes here just tell the reader where to go for more information, but the last one links to a rule, and any time something has a reference to that rule, a summary is presented.

The three primary rulebooks all cross-reference each other, creating a circle of links:


             ref
  ┌────────────────────────────────────────────────┐
  │                                                │
  │                                                │           cross-ref
  │                   ┌────────────────────────────┼───────────────────────────┐
  │                   ∨                            ∨                           ∨
┌──────────┐  ref   ┌────────────┐  cross-ref    ┌───────────┐  cross-ref    ┌─────────┐
│ Module 1 │ ─────> │ Core Rules │ <───────────> │ Judgement │ <───────────> │ Stories │
└──────────┘        └────────────┘               └───────────┘               └─────────┘
                      ∧
                      │ ref
                      │
                    ┌────────────┐
                    │  Module 2  │
                    └────────────┘

Spells

This spell in the Core Rules is called Delicate Audience. It comes with a complete description, but no notes on how a witch might construct this spell, because that’s not important here - we just want to know what a character needs to do cast the spell, and how it works.

Delicate Audience in Core Rules

By and large, only large companies have big spell indexes, presumably because making an alphabetical list of every spell in the book takes time and skill. However, with some LaTeX automation, it takes neither.

Delicate Audience in Index

Here, all the spells appear, but this time Delicate Audience only has the basic information about casting the spell, not the long form. It also has a couple of new words - ‘Detailed, Devious, Witness’ - in case anyone wants to see how the spell was constructed from basic parts.

Here the spell appears beneath a creature.

Delicate Audience on Dragon

When players look at their spells, they can easily remember to roll the dice, and add their Charisma (for all spells) and the lowest Sphere they need for the spell (in this case, ‘Fate/ Water’). However, the Judge has a more difficult task, as they need to jump between multiple creatures who use different stats.

The Dragon Tsosh has a Charisma + Fate/ Water total of +5, so the spell lists that total, so the Judge doesn’t need to work it out.

Tsosh rolls with +5

However, the spell below that - Mind’s Chatter - reads quite differently. The players will be rolling directly against the dragon’s Traits, i.e. they will be rolling at a TN of 7 + the Dragon’s Charisma + Fate. But the spell simply lists the total - it says the players roll against ‘TN 12’.

(Once again, it doesn’t seem difficult to work out 7 + 2 + 3 = 12, but in the middle of a dramatic scene, with a load of things to do, anyone running a game can easily forget how to tie up their own shoelaces)

Statblocks

And while we have a statblock up, you’ll notice a hell-of-a-lot on there, like the chunky line of combat-numbers at the bottom. These help the Judge summarize a monster’s common combat actions, just like the spells above, while keeping all Traits available in case the Judge needs them.

Elven Statblock

Notice the last number: “CR 9”. That’s a ‘Combat Rating’.

Combat Ratings let you eyeball creatures at a glance, or give you an objective way to measure which NPC would probably win in a fight, without making you stop and roll dice alone for five minutes.

Eyeballing the CR won’t always work, because you will inevitably eyeball it wrong, which means the jumpy little street-rat you introduced three scenes ago will get a CR which is higher than the CR you eyeballed for the guard (who you narrated as being kitted out in shining plate-armour, with a fancy sword).

However, working out a CR for a creature is incredibly tedious. Once again, automation brings the goods - any two NPCs which are broadly the same will have an equal CR, and if one has a particular advantage (like more HP) then that one will have a higher CR.

Stablock Tick-Boxes

Just under the statblock, shapes can be used as tick-boxes. Our elven prince here has a number of Fate Points equal to his Charisma, and HP equal to 6 + Strength.

Notice that one HP has a little marker, showing how much Weight he carries. This is yet another element which is irritating to work out for one statblock, and nearly impossible to work out for the hundreds of statblocks in the book. And why would you? During a full Chronicle, you might find the NPCs really suffer from the amount of weight they carry once or twice.

General Statblocks

When the scene calls for yet-another-bloody-bandit, I just use a generic template for a human soldier, like this:

\humansoldier
\humansoldier
\humansoldier

This template produces a different human soldier each time it’s used, so various groups of bandits won’t look identical.

3 Soldier Statblocks

This also makes statblocks cheap, which stops a common problem in RPG modules.

Three drow warriors attack, along with their mage (in the appendix), and two rust-monsters (see the Monster Manual)

When modules pull this kind of thing, the GM must have a hand on the drow statblocks, one finger holding the module’s appendix open, and their toes ruffling through the Monster Manual.

Most RPG modules don’t re-print NPC statblocks, and when they do, they will print identical statblocks. Any variation in a monsters statblock means you have to recompute the derived stats - the final Damage, HP, CR, et c.

The automation means I can guarantee that every encounter has the required statblocks printed within one page of the encounter. There’s even a command to check if a statblock is nearby, so that if the book changes, and I don’t notice that some statblock is no longer on the next page, then it will be printed on the current page.

Treasure Type C

Back in days of yore, when I played A,D&D, treasure was assigned categories. When the PCs slew an owlbear, the DM was forced to open the Dungeon Master’s Guide, locate the Treasure Table, and roll a 5% chance of finding a scroll, and a 32% chance of finding 1D6+2 gems, each worth 1D10 gp. The DM would then have to pick a scroll from the book, because the random tables didn’t actually tell you which was found, just that the owlbear had happened upon a magic scroll at some point, and decided to build its nest from the scroll.

If anyone ever wants to claim that RPGs cannot be objectively good or bad, and there’s nothing wrong with someone wanting to play A,D&D, you should ask them to generate the treasure for a dryad riding an owlbear, then set a five minute timer.

Having gone through this insane process, it brings me great joy to simply let the computer roll up the random treasure, which is why the bandits/ soldiers above not only have random coinage, they also have specific rations.

Side Quests

BIND tells stories through Side Quests - a system where each Segment of the tale can take place anywhere within a broad region.

Umiel’s statblock above comes from a Side Quest called ’the Little Prince’, with a little summary of the two Segments.

Little Prince Side Quest Intro

It’s easy to read one Side Quest, but once you read six, each of which have anywhere from two to eight Segments, you then have the players say ‘we go into the forest’, and then what do you do? How can you check for the next available Segment in the forest?

The only way to answer this question is a per-region list of each Segment:

Side Quest Summaries

On the left, Segments from the Forest appear. On the right, Segments from the Roads. Each one has its Side Quest’s title.

This kind of summary is completely impossible without automation. Not only are there a lot of Side Quest Segments, but each of them must be placed in the correct area.

The hard bit here is probably not what you think.

  • It’s not dividing every list of Segments into their regions.
  • It’s not going through all those Segments and noting the page numbers.
  • It’s not the point where you add the summary at the start of the book, and which makes all of those page numbers wrong, so you have to go find them all again.

…all of that is nothing compared to the real task: every time you write another paragraph and shunt some material down a page, you have to do the entire thing again.

Nothing is ever perfect, so everything must make itself easy to update. And nothing which does a ’table of contents’ is ready to do something like this.

Automatic Maps

Notice area ‘3: Library’, on the map. LaTeX just needs to know where that room is, and it places the room’s name and number above it.

Automated Map

Once again, that seems easy if you do it once, perfectly. But writing never works like that, especially when writing RPGs. So the real benefit here comes when we need to slip another room in, or change the order of the rooms.

For example, if we place the library after the Dark Pit, everything changes to automatically.

Automated Map

The names on the map are automatically pulled from the room names, so if we rename ‘Library’ to ‘Study’ then the name would also update.

Tags :

Related Posts

The Module Decalogue

Ronald Knox wrote ten rules on how to avoid ruining a murder mystery with an unsatisfying solution. They apply very well to writing and running RPG modules, with a little alteration.

Read More

Random Encounters Disarm Chekov's Gun

Chekov’s gun poses a real threat to some games.

If a group playing Vampire: The Masquerade (‘VtM’) encounter a Ravnos, spinning illusions, and confusing mortals, then the next time they hear about unusual events, they will assume that the Ravnos did this. Clearly - the Ravnos is part of the plot! After all, VtM draws heavily from literature; or rather, it draws a lot from the idea-spaces of people who like to analyse literature while telling you that they analyse literature.

Read More

Why BIND Rules Don't Allow Players to Go for the Eyes

(a story about spreadsheet failure)

I’ve considered changing BIND’s ’to-hit’ system to let players ‘go for the eyes’ (or a headshot, or otherwise decide to attempt a vitals shot), and decided against it. My reasons sit below, but expect lots of boring numbers. You have been warned. (or just skip to the conclusions)

Read More