Alter class to provide formatting for different rules/themes

[BrianCriswell]

Starting a discussion here for how to support different themes and systems.

Systems are different sets of rules for playing a TTRPG

• D&D in each of its flavors (5e 2014, 5e 2024, 3.5, 4e, etc.)
• Pathfinder (1e and 2e)
• Starfinder (1e and 2e)
• and so on

Themes are different ways of expressing and formatting the information of the system. Within a group of themes for a system, the content might not change but its layout might. As an example, the dndbook class currently has a default theme based on 2014 books. I made my own custom theme for War of the Burning Sky . An Eberron-themed book might want to more closely follow the theming of an official Eberron book.

The dndbook class should be modified to be able to handle switching between the more crunchy bits of rules at a document level. This probably means some restructuring of the underlying file organization.

It also should make it as easy as possible to switch up the theming of a rule system (although I am not sure what else can be done at a low level). Maybe there is room to make it easier to encapsulate the elements of a theme together.

[xrogaan]

I don't know how you will be able to achieve this. I use this project for my pathfinder campaign, and I found that some elements would require a partial rewrite to properly fit the look & feel. The cause being the information written, which sometimes doesn't fit neatly or is missing from DnD5e.

I feel that it would be easier to have a variety of standard classes as template, and give the ability to easily extend them to whomever wants.

As an example of stuff mismatching, take a look at the following monster: the reefclaw. It has a Defensive ability, and it's CMB and CMD have conditionals. The information is structured neatly between defensive and offensive sections, but those are trivials.

What do you think about all this?

[BrianCriswell]

tl;dr: A new generic class for the generic stuff; system-specific packages/classes for the unique stuff; one or more themes per system. A user would start with rpgbook class, then load their system's package while possibly specifying a unique theme which modifies the system package, or we might have the system use the base class to help the user avoid dependency mismatches.

I think the points you bring up would go at the system level as described in the packages section. A Pf1StatBlock would handle the arrangement of the stat block with some helper functions for spitting out the various sections of the stat blocks.

One of the big parts of theming will be providing good entrypoints for end users to make their adjustments.

---

I guess to elaborate a bit, I'm trying to think of a good way to break this down...

rpbbook class

This holds any extensions to the parent document class as well as helper macros that most any RPG product could use, regardless of its system. Stuff possibly like:

• Font switching
• Sidebars
• Help set document dimensions
• Help with print on demand bootstrapping
• page background images
• Image placement that can overlap over/under text
• parameterized localization strings (e.g. placing numbers before/after/within text based on locale)

System packages

These might or might not be part of the rpgbook class. I think they might benefit from being separate distributions while depending on the RPG book class. These encapsulate the functions necessary for typesetting the unique concepts of the system and conventions of its presentation. Things like:

• Stat blocks
• Dice rolling
• Helper functions

Themes

A system would have one or more themes, one of which is the default, which controls how the document is presented. Users could create their own themes to load after the default or supplant it entirely. A theme entails:

• Font selection for the various elements
• Layout for headers, footers, tables, sections, chapters, etc.
• Modify the default behavior for the system package