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.