Character from Total Party Kill generator

One of the more surprisingly effective character creation innovations I have come across during the last several years was when Ram decided to add a set of random appearance results automatically to the default output from his character generator. For example: Thief, Male, Child, in Uniform, Tall is so much more immediately intriguing than just Thief, especially along with STR 4 and WIS 5.

But there is nothing special about those particular appearance tables, and if anything they are somewhat mundane, apart from one third of characters being either children or decrepit, which is rare for starting player characters and so lends interest. Maze Rats characters have more unusual descriptions, but are still relatively literal and immediate: wiry, singed clothing, and so forth.

What if we tried for more suggestive descriptors, such as roles or life stages? In the following d66 table, I tried for a set of results that in a single word suggest gender and age, along with a dash of social status, without being quite as direct. And of course, one could interpret a role either more or less literally. Depending on campaign particulars, reynard could mean young adult trickster or it could mean that the character was an actual fox who somehow was transformed into a human. Or maybe it means halfling animal person foxling.

The entries perhaps still need some tuning, but the idea seems promising, especially if a few such rich tables could be constructed. I avoided more mundane pairs such as father/mother, husband/wife, king/queen, and so forth. I also tried to select pairs that were somewhat quirky without being ridiculously obscure and tried to avoid pairs that involved explicit hierarchy, though without complete success. Columns control implied gender, with odd male and even female. Rows control implied age, with higher number meaning older.

Though maybe unworthy at this point, here is a PDF of the table.

Table form inspired by Maze Rats.

Participants in a conversation on Google Plus suggested some of these entries (I generally post privately; you must be in my circles to see it).

Some other leftover pairs:

From An apology to some min-maxers:

In fact, if anything, my sub-optimal character builds were me being lazy, and not doing the homework other players were doing to build more optimized characters.
…
At the same time, as GM you should min-max the opposition to the same level as you have allowed for your players. Dig into the system and look for how to optimize NPC’s and monsters. That is likely going to be more work for you, as you may need to take stock stat blocks and beef them up, but it will create challenging opponents for the players, making encounters more exciting.

This concisely captures why I gravitate away from games that support or require significant optimization. It’s just making more work for everyone involved, and not in a way that adds to the play experience. It’s work inflation: everyone needs to spend more time in order to get the same result. And the result is the same, assuming that competition has no value (which it does not, for me, in RPGs).

Compare this to working more on setting detail or even character personality. Such preparation can consume as much time as you want, but it can also qualitatively improve the play experience. Optimization and what I am going to call (for lack of a better term) preparation can thus be seen as two independent dimensions of out-of-game work required by RPGs, leading to four rough categories of game: high-op/high-prep, high-op/low-prep, and so forth.

A railroad is a way of constraining preparation requirements. There may be some overall conservation law operating such that sustainable games on average tend to be low in either or both dimensions. This may be why it is difficult for me to find an example of a game that is naturally high in both categories. Games associated with high optimization (Pathfinder, 4E D&D) can be played using sandboxes or with more extensive world building, but doing so ends up being a higher-maintenance activity.

As an observation it seems that many games in the focused design tradition, especially Forge and Story Games, seem to prize minimization of both kinds of work. Games like Lady Blackbird and Apocalypse World, for example, put few barriers before getting started (AW requires the MC to create some fronts, but the instructions seem geared to avoid potential scope creep). Minimizing out-of-game work a way to increase approachability by decreasing cost. If the reliability of play experience varies with the prep time, that is seen as a flaw in this tradition. The system is seen as “not working” if play is inconsistent, as it will surely be if preparation is required given that different groups or players will invest in different amounts of out-of-game work. Other traditions seem to focus more on the other side of the equation: increasing value (such as the intricate setting and art of Warhammer, or atmosphere of the World of Darkness, separate from amount of work required). Obviously, the two approaches are not exclusive, but there still seem to be trends toward one or the other.

And yeah I may have been working on a data analysis assignment before writing this post…

Keying dungeons or wilderness areas has been around for as long as referees have been writing prep notes or sharing material for others to use. However, modules are still hard to use, and even personal notes (initially fortified by intent in mind) quickly become impenetrable, even to an original author. Just ask a programmer to revisit some inadequately commented code written several months or years ago. There has to be a better way.

I think I have found a better method, or at least one that works well for me, but before I describe my current approach, I want to revisit a few common styles and discuss what works and does not work for each of them. The most common style in published modules (and also probably the oldest, as you can see it in some of the earlier modules, such as B2) is the dreaded wall of text. Areas are described in lengthy, proper english prose. Sometimes particular game elements (such as monsters or magic items) are set off from the text typographically. Modules in this format can be pleasurable to read (if well-written), and can be a good source of ideas or inspiration, but are quite cumbersome to use in play. There is always the lurking fear that one will miss an important bit of info that should be presented to players early and clearly, in order to support informed decision-making. They just don’t work very well in play. Unfortunately, this has become the accepted format for modules.

Another older approach is the minimal key, exemplified by the few extant photos of Gygax’s Castle Greyhawk key. This is easy to use, but suffers in terms of being able to encode any kind of complexity. One is limited to very basic stocking information, and when complexity is added through improvisation, the details are invariable forgotten. Unsatisfactory. In terms of modern use, some one-page dungeons approach this level of concision and often (though not always) suffer for it. A few products have tried to split the difference (such as Stonehell Dungeon, with its two-page spread version of the one-page dungeon). Stonehell is notable for being one of the most user-friendly modules yet written, though the self-enforced simplicity limits the sophistication of described features, other than those described separately in “special dungeon notes” sections (which sort of defeats the purpose and requires page-flipping).

There are some new approaches that work better, such as Courtney’s “set design” hierarchical outline format. This method works admirably in terms of direct, in-game usability. However, based on my experience, it has two flaws. One, outlines are often not a good use of space in terms of typesetting. This is a minor issue, but still bears mentioning for a medium that remains often expressed in hardcopy book form. Two, it lacks poetry. It is just not pleasant to read pages of outlines. Despite those issues, I would still take this format over the two traditional examples described above, but I think we can do better.

When I read an area description, I have basically two priorities. The first is that the immediately relevant information be easily accessible. The second priority is that finding out more information about a particular element (“drilling down”) be easy. So the PC opens the chest; what’s inside? This realization led me to the following two principles: (primarily) immediately relevant features must be offset from other details and (secondarily) elaborative detail should follow so that it is easy to access when needed. Immediately relevant area features are not only nouns (a table in the room, a monster in the room, scorch marks that are a trap clue), but also event triggers (if the northern door is opened, if a PC steps on a central flagstone, and so forth). When I am writing new area keys, I bold the immediately relevant features. Basically, the key is a tool for the referee, so everything that the referee needs first should stand out.

Some modules tried to address this issue with boxed text, but as noted above, features that are important to the referee immediately include more than only what the PCs perceive. Boxed text is also flawed because it separated the initial impression (“treasure chest”) from elaboration (the contents are usually buried somewhere three paragraphs down the page, with no obvious connective element, from a usability perspective).

One nice consequence of this approach is that it can be applied to existing modules without requiring rewriting (at least, to some degree). Newly written material can benefit from these principles more (given that elaborative detail can be concentrated after the first mention of immediately relevant features), but even without that knowledge the approach seems to work well based on my experimentation so far. This is particularly easy to do with a tablet and a PDF reader* that allows annotations such as highlighting, though I imagine it could also probably be done with cheap desktop software.

From Tower of Mouths, by Matt Finch, in Knockspell 3

You will see that the immediately important features are clearly offset from information only required in the case of elaboration. A referee can take in the area with a glance (weapon racks, rushes, buckled floors, untouched alcove), secure in the knowledge that nothing is being overlooked, and quickly communicate the initial impression to players without needing to read any text verbatim. As players deliberate about what to do and ask clarifying questions, the referee can revisit the elaborative detail (check on the map again where the teleporter destination is, and so forth). The amount of text that must be read to get a handle on the area has been cut down by more than half without degrading the quality of the prose. Additionally, this was already a rather short description, and the savings yielded are usually greater.

This method is even more useful for a truly sprawling area description, the kind that has half a paragraph about room history, a digression about how the area is used, and a table of twenty potions to sample, especially given that each of these subsections is likely to communicate information that should be immediately obvious to players (water damage from the history, footprints from the usage, and a fabulously glittering jewelled potion decanter nestled between 19 plain clay jars).

Thus, the organizing principle should not be the nature of game entity (monster versus treasure, for example). Rather, features with higher referee immediacy should be emphasized.

* I use an iPad with the GoodReader app. This program syncs bidirectionally with Dropbox and automatically offers to create files with a “- annotated” file name the first time you start to add annotations to a PDF, which it then syncs back to the folder in Dropbox. It is extremely convenient.

Tower of Mouths, original design by Matt Finch

Of the many minor experiments I built into the first Grimmsgate session last night, one was using Hangout screenshare along with gimp to do fog of war reveal of the dungeon map.

Overall, I was pretty satisfied with how that worked, though it did require preparing a separate map beforehand without room numbers or hidden features (such as secret doors).

A side benefit of this approach, compared to something like Twiddla, is that the layered and partially revealed map can be saved in native Gimp format, thus preserving the last state of fog of war reveal.

No redrawing will be necessary during the next session.

I gather you can do something similar with Roll 20 (though I’m not sure about state saving). I kind of like the modularity of the approach that I used though, given that I didn’t need to learn anything new or test any software that I wasn’t already using.

Other minor downsides to this approach:

1. Unlike with Twiddla, players can’t make marks on the map.
2. Screenshare replaces referee video, which decreases interpersonal interaction slightly.
3. Erasing fog of war requires care to not accidentally reveal extra info.