h1

Designing Random Event Tables

June 20, 2019

I’m hacking a fix to a game I play – one of the tools is a random event table that is helpful about 2/3rds of the time.  It’s enough it does add value, but the bad points stop play and make things harder – which is not what you want to have happen in play.  Between this, and thinking about a couple of other games I’ve played in the past with these things, I wanted to draw out some basic design principles, which I’ve seen a lot of games fail on.

The Bullseye of design

When you make a random event table, the first large field of ideas is “CAN this happen in the game?”  You’ll write down a lot of possibilities.   But maybe you’ve already jumped to the second step, the smaller subset within that – “SHOULD this happen in the game?”  Within that, “What makes this fun, and is it likely to occur in play?” etc.   It narrows down like a target board, with smaller and smaller areas of ideas, better suited for the game you are designing/playing.

Anyone can throw together a giant list and put it on a table – you can go on forum boards and see these lists, check out blogs, and even pay a few bucks from publishers who do nothing but make lists.   And – yes, these lists will often have some neat ideas in there.  But do all the neat ideas fit together in the game you want to run?  Are they disruptive to the scale of game you want to play?  Do they fit the theme and color of the game?  That’s where it gets harder.

You’ll note in old school D&D, people often joked about how often the magic item The Deck of Many Things could disrupt a whole campaign, because it’s been known to drop disasters, curses, super monsters as much as a mild, silly effect.  It’s the same sort of issue, and also why later editions keep curtailing how far it can go.

So whatever list you make, go back and look hard at whether the ideas fit together, whether they push the game too hard in a direction or if they rely on too many specific conditions to be fun.  (Fun doesn’t necessarily mean good for the player characters, challenge and conflict is also fun, but in both cases, it has to fit the game.)

Communication and Ease of Use

How well does the table immediately translate into use in play?  If you have to stop the game and think for 5 minutes and have a discussion about what it means or how it might work, the table didn’t actually make things easier.  (This is what is going on in the mechanic I’m hacking).

This can also happen because the entry is too vague or broad.  You don’t want to spend too much time trying to puzzle out what it actually means, and, it also means the real work of making it interesting is falling upon the GM or the players and instead of being a thing that helps play speed ahead, it’s a thing you drag along.

So make sure the chart entries are easy to grasp, don’t require too much explanation, and if they require secondary steps or actions, that it’s not too deep or involved.

Lock-in vs. Flexibility

One of the better design features in recent years has been making random tables either with multiple choices within them, or giving a mechanic to bounce the result a bit, to find something more fitting.

The former, we see a lot in the Apocalypse World family of design – “You rolled a 7, pick 2 things from this list of 5” “You can have X, Y, or Z.” etc.  This doesn’t always have to be a thing for an advantage or challenge – it can also be picking things that are just appropriate for the game situation.

The latter, we see in say, Tenra Bansho Zero’s Emotion Matrix – you roll an entry, but everyone can choose to spend some Aiki to bounce around the result to something that is more appropriate or exciting for everyone.

Flexibility gives you wiggle room in the design and helps mitigate the possibility of weird results or things not fitting in.  It is still best to have thought deeply about the entries, however.

When to use?

When should a random event table be used?  Sometimes this is a strictly mechanical thing – “X numbers of turns pass in the dungeon, roll for wandering monsters”, “If a character’s stat goes above X, roll for Corruption Effects”, “At the beginning of each session, roll to see what problems beset the Town”.   Sometimes it is a fictional trigger – “When an NPC is angry enough to take action, roll on this chart”, “When your character loses hope, roll to see what Scar affects them.” – which means it’s a judgment call from someone playing.

Either way, it’s good to be clear when and how often you expect a given random event chart to be used.

The Actual Odds

First, consider how often a chart is getting used.  Then consider how often something interesting should be happening from that chart roll.

If a chart is rarely used, you don’t want entries where minor or inconsequential things happen, because it basically is doing extra steps for little content.  If a chart is being used a lot, there’s a point after which you might see the same things happen a lot, in which case – would it be interesting if it happens repeatedly, or will it get old?  Will it be hard to rationalize why it happens repeatedly?

So just keep these things in mind, as I’ve seen both ways happen in charts that have turned them from a play aid into a detriment.  It’s not hard to make a chart, it’s hard to make a chart that aids play.

If you find my blog entertaining and valuable, consider supporting me on Patreon.

%d bloggers like this: