How does system matter?

There seems to be a mini-rash of “system matters” discussion happening at the moment. I’ve often found these discussions get lost in differing definitions – you can’t agree whether system matters if you don’t agree what system is. More importantly, different aspects of system matter in entirely different ways. So rather than debate whether it matters, I’m going to break down different aspects of “system” and consider what’s important about them. This will be a multi-part series.

Here’s a list of things I’m planning to talk about in this context. Possibly more will come up later.

  • Designer intent
  • Formal written procedures of play (“the rules”)
  • House rules, mods and hacks
  • Written principles and implicit directions
  • Unspoken rules at the table
  • Play culture

Let’s start with designer intent. You might think this is not part of system (and I pretty much agree) but it obviously shapes many of the other items on the list above, specifically the formal procedures, written principles and implicit directions.

A designer can have a greater or lesser focus on specific themes, a specific type of experience they want you to have, or particular styles of play that they favour. The important thing to say here is that designer intent only matters to the extent it’s communicated to actual or potential players. This can be done through the rules, through the background material, through guidance, through the game art, even through marketing or interventions on social media.

But let’s face it: in most cases, people will only have take in what’s in the game book. Anything else, no matter how important, is likely going to be missed by most of your target audience.

Regardless of how it’s communicated, it doesn’t matter what you meant when you designed your game, only what the players understand. This isn’t a philosophical point about the nature of meaning, but a practical point about the nature of game design. Of course different audiences will take different meanings from what you say, and with the variety of game culture that’s out there it is very likely that someone, somewhere is going to misunderstand what you intended.

In fact it’s even worse than that, because (in my experience) many people don’t properly read the rules at all. They skim, they grab the printouts and run, they make assumptions or ignore rules they don’t understand. This is one of the things that makes playtesting important, because you don’t know how people outside your circles will read (or not) your words.

Game design is communication. Communication is messy and imperfect. No amount of playtesting can eliminate misunderstandings. You aren’t designing a car, where the systems interlock and perform in exactly the way you imagined; you’re designing practices for humans, and humans never perform the same way twice.

Anyway, that’s a long and rambly way of saying that design intent is hella important, but ultimately once you put the game out there in the world, no longer matters.

So what does matter? Well, let’s get our teeth into what most people probably think of when they hear the word “system”: the rules.

Here I like to talk about procedures. A procedure is a structured way of doing something. It takes an input, and turns it into an output, according to a fixed, mechanistic formula. Or in the case of roleplaying, it more typically takes many and complex fictional inputs, turns them into fewer and simpler mechanical components, futzes around with them (in a structured, mechanical way) to generate mechanical outputs, which in turn are translated back into fictional outputs.

Still: the distinction I’m making when I talk about procedures is that they’re mechanical. No matter how complex your rules, the procedural parts of them can be boiled down into simple if-then statements. That’s not all there is to rules – we’ll get to principles and directions, later on – but it’s an important aspect of “rules” that dominates many people’s thinking, perhaps because everyone is familiar with rules from other contexts like board games and wargames.

But it is worth pausing to note that in a roleplaying game, you cannot activate a mechanical procedure without first making a fictional interpretation. Even something simple like an attack roll requires you first to recognise that someone has attacked someone else in the game’s fiction. You have to interpret the fiction to do that. “I hit him with my sword”, cool, make an attack roll. “Did I mention my sword is made out of marshmallow”, oh, uh… I guess not then. So, as I’ll discuss in a moment, clearly rules are important, they matter, but they only function as filtered through the human and fictional medium: your brain and the brains of the other people at the table and the stuff they’re trying to imagine together. (Maybe we’ll get back to that later.)

The key thing about procedures is that they are fixed. Once you’ve decided that it’s time to make an attack roll, you must roll a d20, and if it equals or exceeds the target’s AC, you must roll damage and subtract it from the target’s hit points. If the target’s hit points reach zero, they die.

Seems pretty hard-edged, and with examples like that we can all clearly see that the rules are going to matter. If the rules say that short swords do d6 damage, and a normal human has d8 hit points, we can see that humans will typically last a lot longer than if short swords do 2d6 damage and a normal human has d4 hit points, or if we skip damage rolls altogether and just say that a successful hit roll kills the target.

All this is deciding is how quickly we go from “roll initiative” to “everyone is dead”, but it will make a huge impact on the play experience. Would you want to start a fight if one successful hit roll will kill you? That will feel a lot differently than if you and your buddies each get 50 HP while your opponents get about 10. And that’s without even getting into whether the game includes rules for fighting in the first place.

So one way in which the rules matter is that they compel you to change the fiction, and they compel you to do it in particular ways. If your game rules say that one successful hit roll = death, you’re compelled to play a game where fighting is really dangerous, and so we either won’t have very much of it, or we’ll have a lot of people dying. If your game rules say that player characters have tons of hit points but NPCs don’t, we’re compelled to play a game where fighting is pretty safe for PCs, which is very different.

Compelled? Well, yes. If you use the rules as written. We’ll be coming back to house rules, play culture and all sorts of ways in which you can ignore the rules. But enough to say here: obviously if you ignore the rules then they don’t matter. Rules only compel you if you let them. Still, something isn’t really a rule at all if you don’t obey it, right? As long as you’re following the procedures to the letter, they really fucking matter.

One other way in which the procedures of play matter is that they generally cover only specific types of thing, not everything you could possibly do. D&D Basic*, the ancient and revered forefather of the biggest fish in the roleplaying sea, didn’t have any skill system. If you wanted to, I dunno, deceive a guard, there weren’t any rules for that. You could houserule it, you could make something up on the fly (and we’ll get to the ways in which a game can actively encourage you to do that, or not). But it wasn’t in the book, and that meant that deception was only a part of play if the group decided to make it part of play. Unlike stabbing things with swords, which was explicitly and formally coded into the game.

Now obviously many people put deception into their D&D Basic game. This may have been an inevitable consequence of the narrowness of the rules in that game, the massive gaps it left, and the incentives of play: obviously someone was going to want to lie to a guard at some point. Obviously someone would need to come up with a way to do that. And so a thousand house rules were spawned, and eventually D&D 5e. But meanwhile, there wasn’t any fixed way to handle deception, and very probably many games didn’t have it in at all. And practically nobody ran D&D without fighting in it. Because, amongst other reasons, that’s what the rules were focused on: fighting, not lying.

So that’s two ways in which the procedures of play matter: they fix certain ways of doing things by making them mechanical; and they channel you towards doing certain things rather than other things. Those are pretty big impacts!

Next up, we’ll think about some things that modify the procedures of play, and some things that aren’t procedures (as I’ve defined them) at all.

This article is supported through the Black Armada Patreon

Become a Patron!

*Ok, it wasn’t called D&D Basic** back then, and many people don’t call it that now. Probably it wasn’t even the first, because once it was chainmail or whatever. The point stands.
** I’m told I should head of pedants by saying I’m referring to the original edition of the game, circa 1974. Honestly, I’m not even sure. If that version didn’t have skills mechanics, great, it’s an example of what I’m talking about.

How I run investigation games (part 2: in-session)

Last time I wrote about how I prep investigation games. I’ll talk a bit more about that here, but I also want to move on to talk about what I do during sessions.

My aim in running an investigative game is twofold:

  • Make the players feel smart
  • Make the investigation challenging

Those two aims seem kind of contradictory, but in a way they support each other. You cannot feel smart if the game hands you everything on a plate. You cannot feel challenged if the game is simplistic or handled entirely through dice rolls.

As discussed in a previous article, you can break investigation down into various components:

  • Leads (where should I look next?)
  • Imprints (what clues are there?)
  • Patterns (how do the clues fit together?)
  • Conclusions (what is my theory of the case?)

I want as much as possible of the above to feel like they were investigated by the players themselves, using their own brainpower, without running up against the perennial problems of analysis paralysis and the thing that seems obvious to the GM not being at all obvious to the players. I’m not going to pretend those problems aren’t real – and more on how I tackle them below. But for now, let’s talk about how I handle the components above.

My initial lead is always given away for free. That’s a given: the game will be no fun if you can’t get started.

From that point on, I follow a simple set of rules:

  • If a clue is obvious, you don’t have to roll to find it
  • If a clue is hidden but you look in the place it’s hidden, you find it without rolling
  • You can find any clue with an appropriate roll
  • Once you’ve got the clues, it’s mostly down to you to figure out the logical leads, patterns, and conclusions

You can probably see for yourself how the above could easily lead to an investigation stalling. If the players don’t look in the right place, or roll badly, or can’t figure out the next lead, then everything grinds to a halt. There are three principal ways that I solve this:

  • Critical mass. I make sure there are enough clues available that it’s unlikely they’ll fail to find anything.
  • Keep some leads obvious. Signposting specific characters or locations as being of interest will ensure there’s always a next step to follow (but there’s always the potential to discover more)
  • Move the clock on. If the players are taking too long, then I look to the next event on my timeline and make it happen – so even if they get stuck, the story doesn’t

The aim here isn’t to make it impossible to fail the investigation. That wouldn’t be challenging, and it wouldn’t make the players feel smart. The aim, instead, is to make sure that they never get completely stuck – even if they’re failing, they’re moving forwards. So there’s always enough clues to find something out, and there’s always enough obvious leads that you have somewhere to look next.

Equally, my aim is to create a potential dividend from being smart, from being lucky, and from being quick. Players who get lucky on the dice find more clues; players who think their way around those clues and ask good questions discover patterns and start to reach conclusions; and those clues and conclusions can enable them to get ahead of my timeline. Those who move at the minimum pace enabled by following the obvious links, probably find themselves fighting for their lives at the finalé, having left a trail of murders in their wake. Those who leverage luck and judgement may be able to save some lives and catch the perpetrator unawares.

What this means is: being open to the players failing – so that another person is killed (or whatever consequences I established in my timeline happen); but also being open to them wildly succeeding, so that my villains fail and their plans are completely foiled. The critical mass of clues and obvious leads means that I’m hopefully leaning towards success over the medium-term, with occasional frustrating blocks that make that success more satisfying when it comes.

I cannot overemphasise how important it is for failure to come with consequences. If they get stuck, then those consequences mean that the game doesn’t get stuck; instead of their next lead being a witness they want to investigate or a place they want to investigate, the next lead comes in a body bag. And of course, this also means that when they succeed, they’ll know that it was earned, because they know what happens when they fail.

Very occasionally this means the players fail utterly. The villains complete their plan entirely, and escape. That’s great. It means there’s now a future recurring villain, who the players really want to take down, because they feel responsible for not catching them the first time. As long as things didn’t grind to a halt during the session, so there were always fresh leads to follow and tense pacing created by my timeline events, then failure is ok.

One last thing: do not let things drift towards out of character discussion of clues. To a degree all theorising is out of character, since you don’t actually have the skills, knowledge and brainpower of your characters. But try to keep people talking as their characters, because that will help to reinforce the sense that any frustration they may be feeling is fictional, it’s part of the story. They’re not sat on your couch feeling worn down by the investigation, they’re stood in a dark alley looking at a corpse and wondering when the next one will show up.

This article is supported through the Black Armada Patreon

Become a Patron!

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!

Investigating investigation

Due to popular demand (well, Blackrat demand), I am going to write a bit more about investigation and how it can be systematised.

Fundamentally, investigation in roleplaying is about searching for and discovering clues which can be used to draw conclusions about something happening in the fictional world of the game. If you over-mechanicise searching for clues (for example by making discovery automatic, as with Trail of Cthulhu) then you end up with something that feels like railroading. If you elide the discovery of clues and drawing of conclusions (something it’s easy for a GM worried about whether the players will be up to the task of deducing what is going on) then you end up with exposition rather than true investigation.

We can break it down further
– Following leads to direct the search for clues towards particular people, places, groups, events and so on.
– Finding the imprint left by the events one is investigating, especially if it is concealed (fingerprints, footprints, CCTV footage, a statement by a witness…)
– Identifying a pattern, an anomaly within a pattern or a definite lack of pattern (for instance, all the victims belonged to the same religion)
– Interpreting the imprints and patterns found so far to draw conclusions about what might have happened
– Making the link between an imprint, pattern or conclusion and a new lead, widening the investigation (a person whose fingerprints, footprints, etc were left at the scene; the local temple of the religious group being victimised, etc)
– Drawing a solid enough conclusion to allow a confrontation of some sort (arrest the murderer, grab the lost artifact, reunite the father with his lost daughter)

Each of these can in principle be broken down into appropriate skills or abilities (forensics, interrogation and so on), if the game system wishes, but most game systems don’t really use the above breakdown. Most systems concentrate almost exclusively on the second bullet: finding the imprint through awareness tests, while some that are more focused on investigation also move on to the third and fourth bullets, allowing skill use to draw conclusions such as “these footprints were made by a very large man”.

To me, at the heart of an investigation game is how you move through these steps, and how the elements highlighted in bold get you from one step to the next. What makes an investigation game enjoyable for me as a player (and vicariously as a GM) is taking those steps myself, not having the system do it all for me; but of course, since I am not in fact a forensics expert or arch-interrogator or whatnot, it must give me just enough information to make it possible for me to draw conclusions and decide on appropriate leads myself, rather than spoon feeding me.

A stone’s throw away from the answer

An analogy I often come across when describing investigative games is the “trail of breadcrumbs”. That is, a linear series of clues each of which points to the next in the series. It’s an approach that reaches its apex in the Gumshoe system, which advises the GM to write a “spine” of scenes, each of which contains a core clue which is necessary to progress to the next scene. The game makes discovery of core clues automatic for any character with the relevant skill, solving a genuine problem with investigative games, which is that they can stall when the players miss an important roll.

This is not an approach I subscribe to. Notwithstanding the fact that the “trail of breadcrumbs” is rather demeaning towards the players, suggesting they are simply mindless birds pecking their way to success – well. That is exactly what they are in Gumshoe, it seems to me. The system deliberately removes any element of challenge in the process of discovering the Truth, leaving the players with the job of describing how they do it. Whether they peck at the breadcrumbs furiously or idly, I suppose.

Let me give you my own pointless metaphor for the process I follow. Imagine the villain of the piece is standing on the shore of a lake, throwing stones. The stones create ripples, which spread out in all directions and persist for a long time.

If the stones are the villain’s actions, and the ripples are the clues they leave behind, then you should start to see where my analogy is going. The players are presented initially with some information about the “ripples” – the key evidence that starts their investigation off. Now they are in a position to look for more ripples. They begin to be able to piece together where some of the stones fell. If they are watching closely perhaps they can even spot some stones landing. But I as GM don’t plan out which bits of the ripple they’re going to find, or which stones they will discover the location of. Or in other words, I don’t know which evidence they will discover or what clues they will deduce from it.

Instead, I make sure that there are plenty of stones being thrown, with a varied size of ripple, so that I can be reasonably sure that they will eventually figure out who is throwing those stones. Finally, the stones continue to be thrown as the investigation is ongoing, generating still more ripples. By which I mean:
– My villain is doing lots of stuff
– He is, therefore, leaving lots of evidence behind for the players to find
– Some of it is really obvious, some less so, so there is room for skillful play
– My villain carries on doing stuff while the investigation is going on, so the trail never goes completely cold, and (this is important) there are consequences to failure

Think about the difference between these two approaches. Under the Gumshoe approach, no matter what the players do, they will uncover the mystery, and without any role for intelligent deduction, clever investigation or even just plain good or bad luck. The game (I read Trail of Cthulhu) strenuously denies it railroads the players, but this feels like a game on rails to me. Even a standard “trail of breadcrumbs” (not Gumshoe) game will feel a lot like this.

Meanwhile under my approach the players are required to use their eyes and ears and brains to piece together what happened. They don’t get any free passes. There is scope for them to solve the mystery slower or faster, and there are consequences if they fail. It is unlikely the players will fail because there is lots of evidence and the villain doesn’t disappear off the radar, but they can still screw up properly, allowing the villain to commit more mayhem, and conversely they can score a roaring success, catching the villain early.

A trail of breadcrumbs investigation means you are roleplaying an investigation, but not actually doing one. The stones and ripples approach means you get to actually investigate, not just go through the motions.

Final thoughts: my approach is not without problems. It’s a lot of work, and it requires the GM to think on her feet about every player action and what clues it might uncover. It can mean an unpredictable game length. The GM must pay a lot of attention to whether there is enough evidence to go on (so they will probably succeed) but not too much (so it just feels like childsplay, ruining the challenge). I think these are a price worth paying to get an approach that feels like real investigation.