 |
| artist: Stefan Poag |
What if we design the random encounter table to function as computer RAM- to store short-term information/change without having to dig into the module or track on another sheet? This is a space for innovation given that the random encounter table is one of the three most DM-referenced tables in an adventure outside of the dungeon map and the room keys.
Now let me back up a minute to explain how this arose. A dungeon I am working is a wizard’s home in a barrow that was subjected to a magical explosion. Some areas of the dungeon are cracked and falling, especially the entrance, which is cracked, slumped and in danger of collapse. Traditional ways of handling this might be:
The entrance is a trap. Rocks fall, hireling (or PC) dies- too cheap, too sudden
The entrance can collapse right when PCs enter the first room of the dungeon- eh, too haunted house
The entrance collapses after the first exit from the dungeon- too delayed requires remembering
Then I thought, “What if the entrance collapse is an event on the random encounter table?” That seems to have potential because it permanently changes the dungeon, but I don’t know it will occur. But this could also still invoke #2. Okay, so let’s put a countdown clock on the random encounter table. I can just check off circles until the entrance collapses until then its a free breather for the PCs. Again, the dungeon changes which is interesting, but I’m not having to track it or review it in the next session prep outside of what I’m already looking at at during play. Here’s a basic example:
BASIC (RAM)DOM ENCOUNTER TABLE: Crypt of the Orc Hole Level 1
1d6+2 Skeleton Orcs
1d6 Zombie Grave Makers
1d6 Hobgoblin Desecrators
2d8 Stirge Throat Lovers
2d4 Robber Fly Defilers
Unstable Entrance in Rm #1 (_)(_)(collapse!)
But then I started to wonder if there was a place for factional activity, patrols, and/or other permanent states that operate in a local area (the dungeon). Or permanent events that impact during the shorter time frame the dungeon is played that are natural extensions of play and player choice?
Let me explore this idea first before considering this “RAM” idea in light of the overloaded encounter die (i.e. “dungeon weather”) and faction turns which are two other popular ways of tracking change for dungeon campaigns. I will revamp the table above by adding another change in the dungeon (black) and adding a factional event in two places (gold):
EXPERT (RAM)DOM ENCOUNTER TABLE: Crypt of the Orc Hole Level 1
1d6+2 Skeleton Orcs
1d6 Zombie Grave Makers
4 Hobgoblin Desecrators continue to loot crypts, increase #, & gain treasure:
(_)+1, +150gp (_)+2, +300gp (_) +3, +600gp (_) leave Crypt2d8 Stirge Throat Lovers
2d4 Robber Fly Defilers
Unstable Entrance in Rm #1 (_)(_)(collapse!)
Leaning Statue of Ishtar Rm #15 (_)(_)(falls! Bridge to Room #23)
2d4 Kobold Sappers, mercenaries (_)(_)(_) creates additional hallways trap
Alright, so we have a more dynamic encounter table, but entries are a little ambiguous. Is the intent that a check-mark occurs AND an encounter in the case of factions (#3 & #8)? And does nothing happen on a roll of a dungeon event (#6 & #7)? Let’s move these events into the “Random Encounter Check” procedure in lieu of the precise “Random Encounter Table”. I don’t think you are really creating any more work for yourself and it is simple enough to have a column or sheet listing both. Rarely are random encounter tables so extensive they might preclude a modified check procedure. Here is our example reformatted a third time:
COMPANION (RAM)DOM ENCOUNTER TABLE: Crypt of the Orc Hole Level 1
Encounter Check
Encounter!
Spoor…
Hobgoblin Desecrators loot crypts: (_)+1, +150gp (_)+2, +300gp (_) +3, +600gp (_) leave Crypt
Kobold Sappers place additional hallway trap: (_)(_)(_)(_)Eat 3rd Breakfast in Room #7
Unstable Entrance in Rm #1 (_)(_)(collapse!)
Leaning Statue of Ishtar Rm #15 (_)(_)(falls! Bridge to Room #23)
Random Encounter Table
1d6+2 Skeleton Orcs
1d6 Zombie Grave Makers
1d6 Hobgoblin Desecrators
2d8 Stirge Throat Lovers
2d4 Robber Fly Defilers
1d6 Kobold Sappers
So how does this fit in the scene alongside of the overloaded encounter die, underclock, and overclock? In terms of the overloaded encounter die, the “COMPANION” table above quite similar, but the entries are endowed with “memory”. For instance, I could easily put “weather” events in there too: “SLIME BLOOMS: Green slime appears in the hallway outside the current room (_)(_)(_)”. For the overclock, there is a 6 x 6 grid that James uses to denote when a random encounter occurs, so one could easily place a mark for each faction or event in unused squares. Finally, in terms of the underclock, a “3” in this method causes a spoor or clue, similarly another number could be keyed to events so that when rolled or passed, a check is made on some event and the underclock ticks down.
What if I’m already using faction turns? Isn’t this the same thing? Faction turns are mostly an in-between session activity that is used to track campaign factions' operations on a world level. I view the mechanism here as more “faction actions”. Its a way to have different factions, here I mean relative to the dungeon and irrespective of the world, do things as the players are moving about. Returning to the central premise, it requires a memory of what the players are doing to employ effectively or generate real-time feed back. A more explicit example that could be added to the “COMPANION” table above could be: “* Special: Replace +2 with +4 to Skeleton Orcs if PC break 3 crypts open (_)(_)(_)”
In summary, I am not advocating here that designing the encounter tables with memory is superior to other methods of encounter table design, but more as an interesting alternative strategy. By endowing a table with memory I believe it can help increase the dynamism in a dungeon as well as provide feedback to players resulting from their actions inside the dungeon. This inturn helps create opportunity for more meaningful choices- the fuel for old-school play. As a reviewer pointed out, the method here provides an opportunity for story while other methods focus more on the “right now, in front of you”.
No comments:
Post a Comment