Environments

In Word and Acrobat, you can make some limited environments, like a header. But in LaTeX, you can make literally any type of environment you want. Need 10 encounter environments? Just make one macro.

Arranging some encounter table then copy/ pasting it and filling in new monsters doesn't sound like a lot of work, because it isn't. What is a lot of work is changing how your columns work, and then redoing every encounter table.

Statblocks

Even the most ethereal story-telling RPGs out there have statblocks. If enemies don't have numbers then you're not playing an RPG, you're playing Fiasco. Those statblocks typically have derived stats. If your monsters has 8 Hit Dice, that means a number of Hit Points, which is something you'll have to work out. If they have a longsword (which deals 1D8 Damage) and Strength 14 (which gives a +2 Damage bonus), then the sheet should say Dam: 1D8+2 somewhere, or the GM will have to work out all the derived stats on the spot.

LaTeX not only prints the statblocks, but calculates all those HP, Damage, and anything else you want.

Treasure Type C

Old A,D&D listed monsters with things like 'Treasure Type A'. The DM was then supposed to open up the Dungeon Master's Guide, locate the Treasure Table, and note that this particular monster had something like '1 magical scroll, and 1D4 precious Gems, worth 1D6 x 10gp each'.

This then requires selecting a magical scroll (no random table would help you there), then rolling 1D4 to find there were '3' precious gems. Rolling 3D6, the now-tired DM sees the result of '2,4,4', and figures - finally - that the party has stumbled upon one gem of approximately 20gp value, and two more of approximately 40gp value.

Exactly what the griffin was doing with these gems, and how it got them remains a mystery which lies beyond the scope of my current bitching. The problem I wanted to address (before being waylaid by bling-ridden griffin-nests) was that THE BOOK SHOULD HAVE JUST GIVEN THE RESULTS.

BIND has similar treasure types, but the commands are things like \small_loot, and \magical_loot, which is a lot easier to remember and understand than 'Treasure type C'. Once the command is in, the elf/ griffin/ Tasmanian Devil in question simply gets that loot printed onto the page, and the DM reading the thing doesn't have to roll a single die.

Automatic Character Generation

D&D once had all goblins with exactly the same stat-blocks, and the Dungeon Master was supposed to add different weapons for variation. Newer D&D editions decided to add multiple creature types, so the entry for 'orcs' has a few different archetypes such as 'berserker orc', or 'shaman orc'.

The D&D books usually advise the DM to look up the stat-blocks, leaving the DM with two books open, and using make-shift bookmarks.

White Wolf went the opposite way and said that all Lasombra should be total individuals, so all Storytellers who want to include a story with 10 members of the Sabbat should hand-craft 10 character sheets.

The LaTeX solution here is to simply write:

You see a goblin.

1\goblin

This can then generate a goblin, (or indeed a Lasombra), and the stats can be as randomized as you like. It allows an easy way for writers to stick the stat-block down on the page, so all antagonists in the encounter will be there.

Tables upon Tables

RPGs rely on referencing more than most books. People will have to look up the rules on wrestling or how low-lighting works on the fly, while the GM is busy getting an overview of the story in a miniature table of contents just for that part of the book.

Adventures can also get a dynamic miniature table of contents. BIND's adventures always get two - one shows each part of the adventure, while the other table appears at the back, and shows each part by their location-type, so the parts of an adventure which should appear in a forest remain together for easy-referencing while the PCs wander in a forest.

Making indexes and tables of contents isn't anyone idea of fun, so for writing to remain fun, you need a tool which does all of this automatically, and nothing comes close to LaTeX.

Concurrent Versions

LaTeX has basic if-statements, which allows people to display one paragraph sometimes, and another at other times.

In the BIND core book, I've used this to create a standard book (with lots of flowery examples of combat, spells, and the rest, being used), and a reference version. The reference version simply contains the rules, without comment or example.

Various paragraphs state

1if {verbose}
2	{ blah blah long example } 
3else
4	{ add +1 damage }

This difference means I don't have to maintain a separate reference book - it's the same book, with a different toggle.

The BIND campaign setting (and sort-of Dungeon Master's Guide) has a different toggle to turn it into a player's guide. The player's guide contains only a dozen pages, talking about the world, but none of the monster stats, adventures, or lists of magical places.

Alternatives

Git vs Google Docs

People who want to work with others on an RPG naturally tend towards Google docs. It seems so easy. They send the link out, people make edit suggestions, and you click 'approve' or 'deny'. Spelling corrections are happening at 100 MPH, spells are being added, and it all looks great.

Git, meanwhile, looks like a technocratic chore, posing a massive barrier to entry for a great many contributors who just wanted to view the file and maybe add in their two cents.

However, problems will become apparent soon.

Once the document reaches 100 pages, it no longer loads properly. Flipping between sections is a bore, prompting a quick check on some website, and soon the work just feels like a stutter.

Next, contributors find they can't make any suggestions which consist of more than 1 line. Someone changing a spell will also have to change the example-text for that spell later on. Someone altering racial bonuses will have to account for that later in the document. People don't really want to suggest line-changes - they want to suggest ideas, which may consist of any number of lines being changed. However, Google Docs will only accept or reject changes to a block of text, not whole ideas.

Contributors also want to explain why a change is necessary, if it's not completely obvious. Their only recourse is that 'add comment' button, which then needs to place a comment on an already messy document, and the small box which pops up gives people the strong impression that they should not write too much.

Once the Google doc feels ready, it's time to export it to a more reasonable tool to do the actual formatting. At this point, the document is sealed - no more changes will be accepted without returning to the Google doc, exporting it, and preparing the whole thing again.

Git Gud

The natural LaTeX-friendly alternative here would be git.

Despite the massive barriers to entry, I prefer git to having the above problems. I also suspect that barriers to entry will raise the quality of suggestions. I've had a few ideas shot my way which (while well intentioned) simply showed that the commenter had not really read the book. This basic barrier to entry may ensure that only people with a solid idea of the work, who are sure they have something to contribute, will actually start using the tool.

Besides that, it's really not that hard to sign up to a Gitlab portal, press 'fork', then press 'edit'.

Adobe

It's important that an open project be the polar opposite of anything from Adobe. Adobe products tell people they're not welcome if they're using the wrong OS, that they need money before they can start working, and have no guarantees about backwards compatibility.

The 'Open Source' nature of LaTeX isn't just a principle - it makes open availability inevitable.