Tag Archives: technique

Initiation

B51-duskA friend of mine who just recently started playing D&D wanted to run a game. Previously, she had played a session or two with me using LotFP and separately a number of organized games (mostly Adventurers League using 5E but also one or two Pathfinder sessions). She asked me to recommend a module, planning to use 5th since that is what she had books for and was most familiar with.

I had no immediate candidate because 1) there are not that many modules for 5th, 2) most of them are wordy or bland, 3) while recently more directly usable modules have been published such as Forgive Us they still require prep especially for a new referee that will need to deal with stat conversions to 5th, and 4) I believe the true potential of tabletop RPGs lies in personal creativity. So, mindful of information overload and the value of time time limitation, I suggested a compromise approach that I felt would be capture the best of both worlds while minimizing low-payoff preparation.

Following is the advice I provided.

Option 1: use one of Michael Prescott’s one-page dungeons:
http://blog.trilemma.com/search/label/adventure

Option 2: pick one of Dyson’s free maps and stock it by hand according to guidelines I will send momentarily:
https://rpgcharacters.wordpress.com/maps/

Option 3: use one of Dyson’s adventures here:
https://rpgcharacters.wordpress.com/downloads-games/

For a guide to dungeon stocking, I sent a copy of pages B51 and B52 from Moldvay Basic. This is the single most useful short explanation that came to mind regarding what referees actually do for effective prep in D&D. In outline:

  • Part 8: Dungeon Master Information
    • A. Choose a scenario
    • B. Decide on a setting
    • C. Decide on special monsters to be used
    • D. Draw the map of the dungeon
    • E. Stock the dungeon
    • F. Filling in final details

I heard that she created a island scenario in mythical Ancient Greece and ran a session last night. I am hoping I can get her to write up a postmortem about how the game went and what was most useful as a new referee since there are a lot of opinions about decreasing the barrier to entry for new tabletop gamers but not so much thoughtful reflection on the experience of actual new players and referees.

Hazard System v0.2

The Hazard System is the gameplay engine behind The Final Castle. Though it assumes games of fantasy adventure and exploration, it is modular and should be easily adaptable to many kinds of tabletop RPGs. I use some variation on this approach for pretty much every game I run now and I don’t think I could go back to any other method of pacing or timekeeping. It is the natural outgrowth and generalization of the overloaded encounter die.

Gameplay proceeds in turns at different fictional timescales with each turn accompanied by the chance of a hazard. What “hazard” means will vary based on the context. For example, a hazard during a haven turn, when characters are recovering between adventures, might be a natural disaster, while a hazard during a dungeon turn, a much shorter period of fictional time, might be an encounter with a wandering monster. The hazard system also serves as a general timekeeping and resource tracker.

The text below the divider is released under a Creative Commons Attribution 3.0 Unported license. Attribution:

Necropraxis Productions Hazard System v0.2 http://www.necropraxis.com/hazard-system/

A PDF is also available.

Currently, several references to undefined terminology from The Final Castle remain, such as Ability Tests. It should be relatively easy to interpret these in light of whatever system you are using, but the final Hazard System text will likely be entirely system agnostic. Additional turn types will also likely be included (Domain Turns and Generation Turns, particularly).


Hazard System v0.2

The game proceeds in turns of several different types. The turn types are haven, wilderness, dungeon, and combat. Each represent a progressively smaller amount of fictional time within the game world, though the exact durations are usually abstract. The passage of time within each turn is a resource to be spent wisely, as the hazard die is rolled for every turn that passes to represent potential danger.

The Hazard Die

The six-sided Hazard Die deploys threats, manages resources, keeps time, and tracks light. In short, it is the engine that drives gameplay forward and the heart of the Hazard System. Every significant action, whether in town recovering, traveling through the wilderness, or searching a dungeon corridor for traps, takes a turn. Every turn is accompanied by a roll of the Hazard Die. The exact interpretation of the die result varies by turn type, but the outcomes are conceptually similar. A haven hazard might be a shortage of supplies while a dungeon hazard might be a wandering monster.

Players other than the referee should roll the Hazard Die to make the time cost salient. After rolling the Hazard Die, hand it to another player so that everyone gets a chance. If playing in person, rotating clockwise around the table works well.

Beginning the game

Start a new campaign with the first Wilderness or Dungeon turn of an adventure. Players should choose a clue or quest from the Tavern to pursue. Roll HP following Recovery guidelines to determine initial HP.

Starting and ending sessions

Sessions should begin and end in a Haven if possible. This allows the the players and PCs to vary between sessions. After a session, players should tell the referee if they are going to follow a different clue or Quest during the next session so that the referee can do any preparation required beforehand.

Haven turns

To recover and replenish resources in a civilized refuge, take a Haven Turn. The exact fictional duration of a Haven Turn can be anything from a few days to several weeks. It is rarely necessary to interrogate the details.

  1. Roll the Hazard Die and resolve any hazard
  2. Pay upkeep: accommodation, retainer, property, and so forth
  3. Recover (roll HP, applying accommodation modifiers)
  4. Process retainer loyalty
  5. Reckon XP gained and level up if appropriate
  6. Buy or sell items, repair damaged gear, or recruit hirelings
  7. Optionally, take one Haven Action (scribe scroll and so forth)
  8. Prepare spells
  9. Review rumors and news

Haven Hazard Die results

  1. Complication (introduce at any point during the turn)
  2. Clue about next complication
  3. Abatement of one or more (by referee whim) haven conditions

Ignore results of 4 – 6. Starred complications persist as conditions.

Haven complications
d20 Complication d20 Complication
1. Assassination 11. Insurrection *
2. PC challenged 12. Invasion *
3. Curse * 13. Jailbreak
4. Earthquake 14. Mobilization *
5. Flood 15. Monster attack
6. Falling star 16. Murderer on the loose *
7. Famine * 17. Pestilence *
8. Fire 18. PC slandered
9. PC impersonated 19. PC item stolen
10. Inflation * 20. Winter *

Wilderness turns

Wilderness turns alternate between day and night. Characters taking two non-camp wilderness actions in a row suffer 1 damage and gain a point of Exhaustion. Choose a wilderness action: travel, search, explore, hunt, track, or camp.

Travel

Move the party into an adjacent area or access a known landmark such as a haven or dungeon.

Search, Explore, Hunt, or Track

The party leader makes a Search Test to locate (and enter, if desired) a hidden feature. To Explore, Search without a stated goal. Success reveals a random hidden feature. Track is a Search to follow a quarry. Hunting yields 1d6 rations (adjust for terrain) per hunter. Night applies a -1 penalty to Search, Hunt, or Track.

Camp

Camping requires a bedroll and consuming 1 ration per character. One person may stand watch for each four party members without impairment. Ignore Hazard Die results above 3.

Wilderness Hazard Die results

  1. Encounter (may differ between day and night)
  2. Percept (regarding next encounter)
  3. Locality (mechanical change in environment)
  4. Percept (regarding hidden feature)
  5. Resource exhaustion
  6. Lost

Lost

Travel is no longer an option if a party is lost. Search must be used to locate a landmark before travel can be resumed.

Exhaustion

Each point of Exhaustion imposes a cumulative -1 penalty on all physical Ability Tests. This adds to Encumbrance penalties.

Dungeon turns

Some actions that require a Dungeon Turn include climbing, forcing a door, guarding the party, listening at a door, moving to a new area, searching the current area, and other tasks of similar scope. Each player may take a different action during a Dungeon Turn. Dungeon Turns can represent a fictional amount of time anywhere between a few minutes to an hour, though most commonly are about 10 minutes long.

In practice, the passage of Dungeon Turns can be more fluid than selecting actions by name, resolving any hazard, and iterating. However, always remain cognizant of lurking dangers and call for the Hazard Die whenever significant actions are taken.

Free dungeon actions

Minor actions often do not consume a full Dungeon Turn. Interacting with particular features such as looking under a rug, opening doors that are not stuck, and pulling levers are all free actions. Clever use of free dungeon actions can forestall the Hazard Die and thus decrease risk.

Dungeon Hazard Die results

  1. Encounter
  2. Percept (regarding next encounter)
  3. Locality (mechanical change in environment)
  4. Fatigue (take 1 damage unless the next turn is spent resting)
  5. Resource exhaustion (spell duration, etc)
  6. Light source exhaustion (any or all light sources go out)

Reasonable resolution

Fatigue and light source results may be ignored when they do not make fictional sense, such as during the first few turns of an exploration. Exhausted light sources rarely all go out at exactly the same time, but instead dwindle over the course of the turn, and may be relit given sufficient PC resources.


Released under the Creative Commons Attribution 3.0 Unported license

Attribution:

Necropraxis Productions Hazard System v0.2 http://www.necropraxis.com/hazard-system/

Player-safe maps

Lost river cave excerpt (full original)

Lost river cave excerpt (full original)

Too few products come with exploration-oriented maps (as opposed to something like a grid map for use as a battle map) that can be shared directly with all players. For example, consider this beautiful map by Mr. Logos. The under/over dotted line style gives away information that explorers should not know. Added work is needed to create a version of the map that can be revealed directly to players. I do not mean to single out Dyson; this was just the map that prompted these thoughts this morning. Other traditional referee-only features such as secret door annotations have the same issue.

If the map itself is a work of art filled with nuance and detail, it seems like a shame for it to be seen only by the referee in a play context. While I probably notice this more now that I often share maps with fog of war reveal on hangout games, it could be relevant to in-person play as well, since you can cover up parts and use it as a visual aid. If it really is just for the referee’s eyes, the functionalist in me might even prefer something more schematic and less polished.

Honestly I am not sure exactly where I am going with this. Do I think that all modules ever should be done in the most convenient form for me personally? No. Do I think that all modules ever should put more effort into game aids? Well, it would be nice, but there are resource constraints so again probably not. However, it is worth considering the way maps function as game tools. There are still many opportunities for improving the usability and format of modular content.

Two steps removed

Matt Finch just recently posted about an adventure design dilemma. He has a large number of areas that need consistent and thematic contents. There are, however, too many areas to make it practical to stock each individually. Thus, random tables for stocking. The choice is between many separate source tables versus one big table of results created from the results of said source tables (an X Y with Z complicated by A, with each variable drawn from a different table, or some similar composite).

I would suggest that the work involved in putting together the second sort of thing is a big part of what makes Vornheim easier to use than Seclusium. Despite the fact that Seclusium generates interesting results, they require a lot of post-processing. Which is time consuming. So it is worth realizing that what you are doing when you create tables like Seclusium is creating tables to create a table. That is (at least) two steps removed from something usable at the table compared to (potentially) only one step removed.

Related:

Monster design

Gus just posted about trick monsters, focusing on special attack modes (attacks that rust PC equipment, poison, and so forth). While I think attack modes can be a useful device to distinguish monsters, and can add to the puzzle nature of enemies, it is weaknesses and attack patterns that truly add distinctiveness to an enemy. Special attack modes can increase the danger of an opponent, and reward players for learning to avoid the attack (such as fighting poisonous giant spiders only from range), but can also make monsters more of a hazard to be avoided rather than a puzzle to be solved. This is not necessarily a bad thing–I certainly think pure hazard monsters have a place–but there are other opportunities available in monster design as well.

First, let’s review some weaknesses present in classic monsters. The basilisk can be petrified by its own gaze, though few guidelines other than requiring light at least equivalent to a torch are given. The bulette is AC -2 in most places, but only AC 6 under its raised crest and AC 4 at its eyes. Presumably those areas can be targeted using called shots. Chimeras have variable AC based on front, side, and rear. Dragons are vain, covetous, greedy, and vulnerable to flattery. Surprisingly, there seem to be few elemental vulnerabilities. Salamanders, which are fire based monsters, take an extra point of damage per die from cold attacks, and there are a few other cases like that, but, for example, while frost giants are immune to cold, they do not seem to take any extra damage from fire attacks. Many (all?) undead take damage from holy water. Rakshasas are killed instantly by blessed crossbow bolts. Puddings and oozes have a nice collection of reactions to various attack types that are too complicated to list here but have some interesting effects on gameplay. Giant slugs are not actually vulnerable to salt.

Many “vulnerabilities” are actually just the only way to damage a monster that is otherwise immune to attack. Lasting damage can only be dealt to a troll using fire or acid, for example, and wights can only be damaged by silver or enchanted weapons. This penchant for increasing monster danger by making them impervious to everything other than a few carefully chosen attack modes is appropriate for some creatures when easily intuited (ghosts being immune to physical blows, fire elementals being immune to fire, and so forth), but may not be the best approach in all cases.

Attack patterns are rarely seen in traditional D&D monsters, and this is a shame, because they potentially allow players to learn about monsters experientially in addition to via clues and rumors. 4E has a few nods in this direction, though they are more often phrased as capabilities and concerned more with balancing numbers than they are with encoding combat dynamics (the 4E approach to monster weaknesses was more about the four different defenses, which unfortunately are more about monster level than anything else). Giving some attacks a “recharge” limiting its ability to be used sequentially is a nice, usable mechanic, however.

I have been playing a lot of Dark Souls recently (more on that later in the form of a massive upcoming post), which has exceptionally good monster design. So as an exercise, I will stat up the Asylum Demon. Minor spoiler warning here I suppose, though this is only the first boss in the game. It is really part of the tutorial level, so I feel justified in potentially exposing some secrets. Now, this should be a massively punishing encounter if faced head-on, but should be possible to defeat, even for a basically equipped first level party, if approached intelligently. I added some touches of my own to help migrate from the video game to the tabletop context. I chose this monster in particular because it is essentially a physical beast that does not rely in its design on vulnerability to specific energy types or similar things and effectiveness fighting it should depend primarily on tactical decisions. Numerical scale assumes OD&D but would probably work okay in B/X or AD&D as well, with slightly lessened difficulty.

Here is a good video of the fight against the Asylum Demon.


Asylum Demon

Asylum demon gonna step on you (source)

Asylum demon gonna step on you (source)

HD 10, AC as chain (5/14), movement as encumbered human (lumbering walk and awkward flying). Any human not lugging a chest or similar oversized object will be able to outrun the asylum demon.

Asylum demons are horrific, bulbous, brutal demons. They are often guardians unable to range extensively from their post.

Several enemies near: horizontal weapon sweep attack, +10 vs. AC, 1d6 damage, compare one attack roll to all nearby enemies.

A good target at reach: hammer slam 2d6 damage, save (vs. stone?) for half.

No enemies near: fly awkwardly up towards biggest cluster of opponents and attempt to position for good attack next round. Any opponents that do not scatter additionally subject to stomp next round for 1d6 damage, save (vs. stone?) for half.

Weak in the mouth, back of neck, and rear shank. Called shot to the mouth is possible with reach (if adjacent or climbing/grappling) or missile weapons at -4. Accessing the back of the neck requires either jumping from above or climbing first. Successful attack against the mouth or rear shank deals +1d6 damage and to the back of the neck deals +2d6 damage (other additional backstab damage may also apply).

Immune to ranged attacks from human scale missiles such as arrows, bolts, or hurled spears. They “stick it its leathery hide ineffectually.”

Clues: it roars periodically, “exposing pink, fleshy mouth skin.” Anyone behind the demon should notice the “mottled, unprotected rear shank” (though note the demon will never expose this area unless proactively flanked). Consider including balconies or other high vantage points nearby to allow for jump attacks and make sure to mention them when describing the area initially. Asylum demons are huge, lumber brutes and their heavy treads can generally be heard though several walls.

Salvage: asylum demon hide is useful for making leather armor that is particularly protective versus piercing attacks (as plate versus piercing, 1d6 suits worth per demon skin). The weapons they carry are quite fearsome, but may require superhuman strength to wield effectively (yeah, this depends on some other subsystem or ruling that I am not going to get into here).


Is this too much text for a single monster? Perhaps. It is always hard to gauge for yourself how useful a writeup will be to others since, as the author, you already have a good idea in your head of what it is you are going for, but I think this compares favorably with many published monsters, and I think the trigger/action format, with important points emphasized, would be easier to use at the table.

The 2E monstrous manual presented foes as a collection of common game stats (AC, movement, HD, THAC0, etc) along with sections on combat, habitat/society, and ecology. While there are nuggets of useful game info buried within these page-long entries, and some creative world building, for purposes of running encounters it seems like some other categories might be more useful. Triggers for different kinds of attacks, clues to weaknesses, and guidelines for placement, as shown in the asylum demon entry above, are all candidates. Also, fears, hates, and desires. Some such things can often be derived from common knowledge (such as wild animals or carnivores being able to be distracted with rations or livestock), but other details may merit a mention (for example, the wraiths in the Vaults of Pahvelorn will often not molest intruders if they are brought sacrifices to drain). I clued that with remains of previous sacrifices.

All D&D examples in this post were drawn from the 2E Monstrous Manual because it was nearby.

Overloading the encounter die

Uccello - 24 hours clock (source)

Uccello – 24 hours clock (source)

The nature of the random encounter check is that of a timer. While it is not a literal countdown (since random results are mathematically independent), it simulates one. It is the danger clock, always ticking, giving meaning to the decision to search (or not), investigate just one more room (or not), or engage in any other potentially fruitful exploration activity.

There are a number of dynamics within the game that seem structurally similar to the periodic encounter check. Randomizing when light sources expire has also been suggested in several different places. Many systems as written specify that PCs should rest every sixth turn (though I have never once seen this in practice). Torchbearer imposes conditions on characters as turns pass to represent exhaustion and the abstract effects of other dungeon hazards. John B. suggests sometimes interpreting a random encounter as a monster spoor rather than an actual encounter.

Why not put all these things together systematically? Consider the following rule:

When the party moves into a new area or spends time on an exploration activity, roll the encounter die and interpret the results as follows.

  1. Encounter
  2. Percept (clue, spoor)
  3. Locality (context-dependent timer)
  4. Exhaustion (rest or take penalties)
  5. Lantern
  6. Torch

One might object: does this not lead to absurd results such as torches going out on the first turn or PCs needing to rest on the second turn? Well, yes, but you are an intelligent human, so ignore results that do not make sense. A result should be interpreted as not “X happens,” but rather as a prompt. A result can be deferred, but only so many times. The weight will naturally build up in the back of your mind as events proceed. As a guideline, ignore results above 3 for the first 6 or so turns.

You could have a general “light source” entry and just pick one light source randomly each time (this has the advantage of not having all torches go out at once), but I prefer to distinguish between the two main types of light sources given their differentiation on the equipment list. Conceptually, I think it helps to have different spaces in your short term memory for each, as you can have the sense that 5 has come up several times already and know that is relevant for lanterns. Torches should probably go out almost every time a 6 six comes up and lanterns should deplete approximately every third or fourth result of 5.

“Locality” is meant to be used for area-specific state that should be kept separate from standard random encounters. Examples: water rising, the stalker drawing nearer, a prisoner loosing an appendage to the torturer, doors locking behind PCs, and so forth. The possibilities are limitless and make every location potentially mechanically different in a way that is player-salient.

In addition to streamlining gameplay and decreasing intrasession bookkeeping, such a procedure also decreases null (“whiff”) results. Almost every turn result means something. This may or may not always be a good thing. Maybe there is something to be said for not having something happen on every roll. However, given how dungeon exploration tends to play out in real (player) time, I suspect this is about right.

The results table could be replaced with a custom one for a given location, but the above spread seems like a reasonable default to me.

See also: a method of play.

Optimal Number of Tables

Working through Seclusium, each game entity tends to draw from multiple random tables. The number of input tables can get rather large. For example, a single magical item requires around 20 tables. I think this is part of what makes using Seclusium feel somewhat cumbersome in practice, despite the large number of interesting juxtapositions.

This leads me to a hypothesis: the optimal number of tables needed to create a complex, unique game entity is around 7, probably at least 5, and almost certainly less than 10. Beyond 10, I suspect there will be diminishing returns from the the extra degrees of freedom. Less than 5 inputs, though perhaps useful for many things, seems to offer more room for elaboration (given that you are trying to create something that will play a large role and thus should have a decent amount of detail). It is probably not a coincidence that this seems related to the magic number seven.

What constitutes a single table is somewhat mutable, as two d6 tables could be combined into a single d66 table (36 entries), thus “number of tables” here is really a proxy for some other category relating to complexity, so you cannot take this “rule” too literally. That said, such combination of tables can be a technique in and of itself, as it allows the author to potentially do more work for the end referee at the cost of using slightly more storage (two d6 tables require 12 entries, while one d66 table requires 36 entries).

In general, I think this comes down more to an issue of layouts than anything else, but it is still worth considering the various tradeoffs when creating a tool. Compare the somewhat pre-integrated d100 tables of Vornheim to the many small tables required by Seclusium, for example. Another related technique is tables with multiple columns that can either be used with one roll (just read across all columns) or multiple rolls (one per column), as can also be seen in the Vornheim table below.

Part of the Vornheim aristocrats table

Part of the Vornheim aristocrats table, for comparison

Automating Random Tables

Abulafia, if you are not already familiar with it, is a Wikipedia-like site for automating random tables. It allows you to create tools like this page, which is an automation of Patrick’s excellent experimental complex generator. However, Abulafia is not always a good solution. Specifically, it:

  1. Requires the internet
  2. Is not appropriate for automating tables from books that are not free
  3. Needs a human to activate an account
  4. Has a format that is not as elegant as it could be

This is not to say that it should not be used, but just to point out that there is space for alternative tools. This became particularly salient to me recently when I was using Seclusium, which has a large number of tables for each entity generated, on the order of 10 or 20 tables per thing. Rolling dice and pondering at the same time can be a useful technique for creativity, and I don’t want to discount that process entirely, but when there are this many tables I prefer some automation. For this reason, I hacked together an ugly little Ruby script which would allow me to do this locally with minimal hassle.

I created* my own random table format because I wanted minimal syntax. Why should every item require programming language cruft? That is not very accessible to non-programmers. What is my format? One file per table, one entry per line. This ends up being barely any format at all, which is perfect.

Without further ado, here is the core engine of the script. I will explain below how to use it, and provide an example.

<%-
Dir.foreach('tables') do |item|
  next if item == '.' or item == '..'
  instance_variable_set(
    "@#{item}_table",
    File.readlines('tables/' + item).map(&:chomp)
  )
  define_method("#{item}") do
    instance_variable_get("@#{item}_table").sample
  end
end
-%>
<%- # Place template below this line -%>

Now, that may look like a mess, but you don’t really need to understand it. In english, what it does is read each text file in the tables directory into an array, which is also wrapped with a random accessor function (that’s what the define_method call does).

Just download this example, which is an automation of Telecanter’s magic item spur. You will need to have ruby and erb installed** and be willing to open up a terminal. I use the ‘$’ character to denote a shell prompt.

$ unzip telecanter_magic_item_spur-2014-01-20.zip
$ cd telecanter_magic_item_spur-2014-01-20
$ ls tables/
descriptor
noun
power
range
type
verb
$ make open

The “make open” command will generate random results, write them to a datestamped file, and then open that file in your default browser. You should see output like this:

  1. bright clothing that animates shadow of power level 4 (out of 10) with range touch
  2. wondrous/weird clothing that deludes space of power level 6 (out of 10) with range area effect
  3. scarred armor that dispels demi-humans of power level 1 (out of 10) with range area effect
  4. ornamented clothing that evokes earth of power level 8 (out of 10) with range area effect
  5. mundane weapon that conjures animal of power level 3 (out of 10) with range wielder
  6. scarred weapon that shields fire of power level 8 (out of 10) with range touch
  7. bright uncommon item that deludes monsters of power level 9 (out of 10) with range wielder
  8. ornamented armor that conjures mineral of power level 3 (out of 10) with range wielder
  9. ancient clothing that distorts animal of power level 3 (out of 10) with range distance
  10. dark clothing that divines mineral of power level 10 (out of 10) with range wielder

You can also delete all generated files by running “make clean” within the directory (but don’t do that unless you actually want to remove the result files).

To create your own generator:

  1. Copy the zip file to a new file and then uncompress it
  2. Rename the resulting directory to whatever makes sense for your new generator
  3. Create the new random table files within the tables directory
  4. Rewrite the random_table.erb template to reflect the output you want
  5. Zip that new directory if you want to store it as a single file or share it

The template is standard ERB format (you can google that), but the core of what you need to know is that to generate a random value, use:

<%= tablename =>

Hopefully it should be clear from the example random_table.erb file. The full generator-specific code for Telecanter’s magic item spur is, ignoring the loop:

<%= descriptor %> <%= type %> that <%= verb %> <%= noun %>
of power level <%= power %> with range <%= range %>

Given that this is ERB, you also have the full power of Ruby at your disposal if you want to do something complicated.

Remember, there’s nothing special about the random table files. They are just text files with one entry per line. Given that the template generates HTML output, the format of the resulting output can be customized using HTML however you like. You can see in the magic item spur example that it uses an ordered list.

Unfortunately, making this work on Windows is beyond the scope of this post, and for that I apologize. I suspect that all you would need to do is install Ruby though. Similar code in JavaScript would be more portable, but for various reasons the table file format would not be able to be as simple (because of browser security models not allowing direct access to filesystems), and I’m not really interested either in writing JavaScript data structures directly for the tables or in writing a converter.

I also know this is pretty janky beta-level code, and there are probably many ways to break it, but it has been really useful to me so I thought I would share it in any case.

One known issue: don’t include strange characters in the ERB file directly, as Ruby has some Unicode issues. Strange characters should be fine in the random table files, but may look ugly. You have been warned.


* “The nice thing about standards is that there are so many of them to choose from.” — Andrew S. Tanenbaum

** This should be true on all Macs with a relatively recent OS, I think.

Thanks to Josh Symonds for answering a few Ruby questions.

GM Lessons from Aliens

This is a guest post from Stuart of Robertson Games.

Originally, a year or more ago, Stuart shared this essay privately on Google Plus. I thought it was insightful enough that I saved a text copy for my own personal use, and recently while looking through some of my files I came upon it again. It was a shame, I thought, that it was not available to the general web, and so I asked Stuart if he was amenable to me publishing it as a guest post here, and he generously agreed. All words below the horizontal rule are Stuart’s, very lightly edited for flow in the blog post context.


Everything I Need to Know About GMing I Learned from Aliens

Aliens (source)

Aliens (source)

Aliens was very influential in the way I approach GMing. Over the years I’ve noticed that there are so many great tips for running the style of game I enjoy that can be taken from this movie. That doesn’t mean the genre or plot of the movie (although I think it could work) but rather little bits and pieces that are applicable to running a game about exploration and adventure with a lot of suspense and danger.

Very important is that the Aliens don’t show up until well into the movie, but you see lots of clues about them earlier in the film. Fighting a monster isn’t as scary as knowing there’s a monster somewhere in the environment and learning about how much you don’t want to be fighting that monster.

The monsters move around the environment and your actions (or inactions) have a lot of bearing on what will happen when you run into them. Aliens is not a “kick in the door, kill the monsters, take their stuff” kind of movie. When the Marines try that kind of thing in the Reactor Room… it goes very badly for them. Scouting, sentries, patrols — and fighting withdrawals are an important element.

When the Marines set off at the beginning of the film there’s a lot of bravado and they have lots of big guns, armour, and they feel very confident. They’re soldiers. But “It won’t make any difference” if they start making bad choices and their strategy is poor. The situation isn’t one they can make their way through on force of arms alone.

There’s a big group of Marines initially. Some, like Hicks, Hudson and Vasquez are more well defined characters (like PCs) while others like Crowe, Spunkmeyer and Frost aren’t around long enough for us to learn much about their personalities (like Retainers). Seeing the group suffer casualties lets you realize how dangerous the situation is and the main characters can shift their tactics before they’re removed from the game/story (“Drake! We are LEAVING!”).

Even the humour in the movie is what I think the right balance for a scary and tension filled adventure game. Monty Python jokes and “silly” jokes can spoil the mood, removing the tension and making everyone take the game less seriously. While darker humorous moments won’t do that. Characters losing their cool in humours ways (“Game over man! GAME OVER!”) or suggesting clearly ridiculous things that demonstrate they’re not handling the situation well (“Maybe we should build a fire. Sing some songs.”) adds levity but doesn’t take the players out of the game world.

Improved area keys

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

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.