General design notes and overarching guidelines. I’ll usually put ‘actual design’ of various topics in blog posts and keep just the current thoughts in this living document. The pages in this section are about the process and system as a whole.
Simple Writing
Pathfinder, like Dungeons & Dragons 3.x before it, tends to have a somewhat academic or technical style. My professional background is largely technical, so I fall into that style myself.
It is good for defining technical processes, and in my mind gaming rules are in fact technical processes. However, I find it dry and at times unpleasantly wordy.
The expression “accuracy can be succinct, precision tends to need more words” comes to mind.
There are some style changes that can make the writing simpler and more approachable, and often shorter.
- Favor active voice. Active voice is usually more engaging and often shorter. Passive voice is good at removing the subject from a sentence, and there are places where it is useful, when the focus should not be on the actor. For instance, when writing up a lab experiment it isn’t really important who actually Did The Thing, but that The Thing Was Done. Passive voice can also be good for hiding the actor: “mistakes were made” is a very convenient noncommittal phrase, compared to “I made a mistake”.
- Use simple word choices. Don’t utilize anything, use it. “Gain the ability” can almost always be reduced to “can”.
- Focus on the player. The game is for the players and about the player characters. Write that way. Write about character options from the player perspective, not some abstract third-party. Specifically, never mind the convention of referring to iconic characters in class descriptions. Don’t write “at third level a rogue gains the ability”, write “at third level you can” (combining two simplifications).
- Take big bites. Make choices significant enough to matter. I have no interest in choices that lead to a +1 bonus to checks of a certain type under specific circumstances. ‘Numbers’ don’t interest me in the first place, but carefully choosing character options to maximize small differences in numbers interests me even less. I’d rather see a +4 bonus every few levels than a +1 bonus each level that I need to carefully shepherd up… or a +4 bonus to each of four abilities (one ability per level) rather than +1 to each of four abilities each level. This can be more interesting to me and make stat block maintenance simpler.
Design Guidelines
There are places the data model for the game can be greatly simplified. I believe this will also make the game easier to understand overall.
- Share common definitions. One of the most valuable design guidelines I know is “Don’t Repeat Yourself”. Where things are exactly the same, they should use the same definition. This can be done to some degree by using standardized text, but that runs the chance of people skimming the text and missing differences, or of transcription errors introducing unplanned differences. It is better to have a single definition shared by several objects.
- Pathfinder first edition did this fairly with the universal rules (the ‘darkvision’ universal rule described how darkvision works, and monsters just say how much they have).
- Pathfinder first edition did not do this so well with class features (many classes point at the rogue class for the definition of the evasion ability).
- Keep mechanics accessible. Pathfinder first edition has a habit of burying mechanical details in text, where it is very easy to miss details unless you read the text carefully. Look at the bardic performance feature of the bard class for an example of a feature with multiple abilities buried in it, or the claws bloodline power of the draconic bloodline. Use natural text for flavor or to explain in greater detail, but have the key points of the mechanics very evident and accessible.
- Often, if the mechanics need explanation, there’s a good chance the underlying rules are not presented sufficiently. If the mechanics can’t be summarized in a stat block there’s a good chance the game element is not the best place to explain the rule.
- Design with cohesion. In software, ‘high cohesion’ means an object is well-focused on a single purpose or use, while ‘low cohesion’ indicates a lack of focus. Keep things cohesive, well-focused.
- Avoid having game objects that do too many things. The first edition monk class has very low cohesion… it has many abilities that do many unrelated things. It can probably be reduced to several more cohesive elements.
- Avoid having huge books. Have smaller books that focus on single topics: a book for core rules, then books expanding on various topics such as magic or divine power or combat options.
- Limit coupling. In software, ‘tight coupling’ means objects are highly dependent on each other. This can limit the ability to use them independently.
- Decouple things where feasible. In Pathfinder first edition many common actions are defined under the skills that make a character good at those actions, such as the Acrobatics skill describing the rules for moving on narrow surfaces, moving through threatened areas, and jumping. Decouple these by describing the different types of movement under ‘movement rules’, then the skill can be defined in many ways (and changed as needed) without affecting the underlying rules.