How I run investigation games (part 1: prep)

A really juicy mystery, with the cool feeling of piecing together clues and coming to the correct conclusion, is one of my favourite things in roleplaying. It’s also something that I feel isn’t well delivered by existing RPG systems. Here I’m going to talk about my approach to building a mystery and enabling real investigation.

This isn’t the first time I’ve explored this terrain. Back in 2013 I talked about how mysteries are like stones falling into a pool, creating ripples. And I went on to talk about how investigation isn’t just about clue detection, but about deduction and reaching conclusions. But I stopped short of talking about how to construct a satisfying mystery, which is what I want to do now.

Just for the moment, let’s assume I have an ok system that will cover the business of discovering clues, and an ok premise that make sure the players want to investigate this mystery. I may come back to these later, but let’s imagine they’re solved problems for the purposes of this article. Let’s also assume I’m running something that has a substantial investigative focus, so there’s more than just one simple mystery to solve.

I then create my mystery in a number of fairly discrete steps:

  • Decide what the fundamental driver of the mystery is. Something like “There’s a cult trying to summon a demon through a series of ceremonial sacrifices”, or “House Rukh are planning to assassinate the governor and take over the planetary government”
  • Generate from this driver a series of events. These can be past events which the players are (presumably) going to be investigating, or future events which the players are (presumably) going to be trying to avert.
  • For each past event, I generate a footprint, that is, a set of clues which are out there waiting to be discovered by the players.
  • The footprint breaks down into physical clues and witnesses, which are obviously investigated in different ways. Each of these is amenable to assigning a location and/or time. I’m also thinking about the ways in which the players might discover the clues, though I’m leaving myself open to other ways as well.
  • For future events, I generate a timing and/or trigger, some consequences, and (in case the players don’t find out about it until after it happens) a footprint, exactly as for a past event.

For instance, let’s look at the cult example:

  • For events, I decide that the cult has already sacrificed two victims. One of them was pursued through a particular district in the city in the night, and then murdered in a junkyard. The other was killed previously and more quietly, in their apartment.
  • The pursuit generated some witnesses along the route it followed – people who heard screams for help and some who looked out of their windows to see a group of figures pursuing the victim.
  • Both the murders generate a corpse, some messy bloodstains, perhaps a footprint. They also include the identity of the corpse – for the junkyard murder that may not be obvious, while the apartment victim (if the players discover it) is in their apartment so probably can easily be ID’d.
  • The junkyard murder will be reported, which is the trigger for the players’ investigation. The apartment murder will likely lie fallow for a while, but might show up later.
  • I also create three future events: a near miss where someone is cornered by the cult and nearly killed, but escapes by jumping out of a window; and a murder that involves an initial kidnapping and the victim being brought to a specific site for the final sacrifice. Perhaps the near-miss will report in to the authorities and the players can find out about it that way. Perhaps the kidnapping will be reported, perhaps not.
  • At this stage I might also add in some kind of link between the various murders, be it geographical (the locations form a shape on the map, with the final sacrifice in the middle) or social (the victims are all highly religious people, say), or whatever.
  • If the final sacrifice is completed then the demon will be summoned and a whole new set of events will be generated after that (but I don’t bother thinking about that right now, because I’m expecting that the players will stop the sacrifice happening and/or kill the demon after it’s summoned.

Once I’ve planned all this out, I’ll review what I’ve got to make sure there’s enough there to give the players a fighting chance of cracking the mystery, but not so much that they’ll solve it in five seconds flat. I can add or remove witnesses and clues until I think I have got that right. Of course, my future events ensure that, no matter what happens, the players will have something to do. If time passes and they haven’t made progress, the next event happens.

I’ll then break the information down into a number of components I can use:

  • A timeline of events
  • A list of locations with clues that can be found there
  • A list of characters with motivations, information they might have and any key abilities

Once I’ve got all that in place, the game more-or-less runs itself. The players move from location to location as prompted by clues and/or a future event becoming a present event. Perhaps they discover clues which help them to get ahead of the timeline, perhaps the timeline runs ahead of them and they’re forced to confront a scary situation unprepared.

I’ll talk in a future article about how I use this prep in practice.

This article is supported through the Black Armada Patreon.

Become a Patron!

Game design: Torg

It’s my personal policy not to write reviews about games I haven’t played, and ideally multiple times. So this isn’t a review, because I’ve only read Torg. But it threw up some interesting game design ideas, so I thought I’d write an article off the back of it.

I picked Torg up second hand from Baz King’s big rpg sell-off some time back, along with bunch of other fairly old games that I’m slowly working my way through. The game was published in 1990, in a period when a lot of game designers seem to have been looking to go beyond the model of gaming exemplified by D&D, with innovative game mechanics becoming increasingly commonplace, but the overall paradigm of fairly mechanics-heavy, wargame-with-knobs-on style gaming remaining dominant even in these cutting edge games. You need to bear this in mind when reading about their mechanics, which (I believe!) were extremely innovative at the time, but now look fairly clunky and outdated.

The mechanics

Zero-based die rolling. Torg is the earliest example I’ve come across of a game where the average result on a die roll is zero. This is an important innovation, because it takes quite maths-intensive systems (roll 3d6 and add your skill, or whatnot) and simplifies them by saying “your expected result is equal to your character’s skill level”. By extension, an “easy” task is one which has a difficulty number lower than your skill level, while a “difficult” task is one which has a difficulty number higher than your skill level. Of course, Torg went and ruined it by requiring players to roll a d20 and compare the roll to a look-up table to find out what the actual result was, adding in exploding dice whenever a 10 or 20 was rolled for good measure. In other words, they took a great and simple idea, and made it complex and cumbersome. Only two years later, this model was simplified in FUDGE[*], which does the same thing but much more elegantly.

Cards. I have often commented that it is strange how board game designers avail themselves of a wide range of tools to make their games function well: dice, cards, tokens, and so on, while roleplaying game designers typically restrict themselves to one tool: polyhedral dice. Torg breaks with this trend. It makes use of cards which are said to be designed to inject drama into the game. The players use them to generate a hand of cards which provide one-shot bonuses and special effects usable in combat, enabling them to put extra “oomph” into a given action, or to get GM hints, or even to create sub-plots for their characters on the fly. The self-same cards, if flipped 180 degrees, have GM text which create special effects during conflict, always handing an advantage to the heroes or their opponents, and so creating an ebb and flow in combat. These effects even vary depending on whether you’re in a regular scene or a climactic scene. I won’t go into more detail here, but suffice to say that the cards do two further things. They really are jam-packed with game mechanical power. And, as with much else in Torg, this is their weakness. They go too far with a good idea, and what was an interesting and elegant mechanic becomes cumbersome and complex. Still, it’s interesting to observe that two decades on the idea of cards in games seems to be enjoying a mini-renaissance, with games like D&D 4th edition and the latest iteration of Gamma World allegedly (I have yet to sample these games) part of their mechanical set.

Possibilities. Torg uses a variant on what are typically called Fate or Drama points in other games, called “possibilities”. What’s interesting is that Fate points weren’t common in 1990 – indeed, as far as I know only Warhammer Fantasy Roleplaying had made use of the Fate Point mechanic at that point. Possibilities in Torg are usable to reroll dice, survive danger or as experience points. They also have a formal role in the metaphysic, such that competing paradigms can be temporarily boosted by their use – so that, for example, my wizard could cast his spells in a world where magic doesn’t exist.

These mechanics are all ideas which, at their core, are very similar to concepts I’ve been toying with as a way of getting a crunchy, simulationist system that nevertheless supports drama and the ability of players to steer events a bit more than, say, D&D, without going the whole hog and turning into, say, Fiasco. It’s interesting to me that they all existed in 1990, albeit in a rather baroque form.

[*] I have no idea if the authors of FUDGE were trying to improve on Torg’s mechanics. I simply observe that the one came very shortly after the other.