See P. XX

a column about roleplaying

by Robin D. Laws

A well-designed modular element for an RPG, whether we’re talking about a GMC, location, conspiracy, or occult tome, does more than extrapolate from an evocative premise. The text you write, explicitly or otherwise, indicates to the GM how it will be used in play.

Let’s look at roleplaying’s archetypal modular element, the one that has launched a thousand bestiaries, the creature. Or, if your core game prefers, monster, or foe, or alien life form.

In some cases the utility of a creature, or other modular element for that matter, goes without saying. That happens when the core activity of a game is so hard-wired to its modular elements that their function at the gaming table needs no further elaboration.

Take the venerable first mover and perennial market leader, Dungeons & Dragons. Its core activity is: fight monsters in fantastic environments.

(This greatly accounts for the enduring popularity of D&D and its stickiness as a concept. Not only does it have an exceptionally clear, easily enacted and highly repeatable core activity, it tells you this right in the brand name. Fantastic environment = Dungeon. Monsters = Dragon. It’s all right there.)

A well-wrought D&D creature design requires you to address its activity by showing the GM how it behaves in a fight, and how it interacts with its environment. In 5E, the stat block focuses on the former, and the descriptive text on the latter.

Different iterations of D&D have favored one over the other. The classic “Ecology of the X” magazine article format traditionally goes into way more extrapolative detail on a creature’s relationship to its environment than any DM can possibly put into play at the table. 4E, and its spiritual descendant 13th Age, focus much more on what the creature will do in a fight than in the broader world. A stat block might represent not a category of being, but a particular sort of orc or demon or pirate who attacks in a specific way, with its distinctive spell effect or weapon.

D&D casts such a shadow over trad RPG design that the very term “trad design” might mean “has a little D&D influence in it somewhere.”

It’s easy, then, to lose track of what you’re doing by applying D&D assumptions to the creation of creatures for other games. Making an adversary useful and easily playable in another rules set requires you to step back and consider the core activity you’re writing toward.

GUMSHOE games all have slightly different core activities, all of which can be expressed including the verb investigate.

  • Intrepid volunteers investigate the cosmic secrets of the Cthulhu Mythos.
  • At the behest of a benevolent conspiracy, trained professionals investigate an occult conspiracy to tear apart the world.
  • Ordinary people investigate their way out of horrific situations.
  • Burned spies on the run investigate the vampire conspiracy intent on destroying them.
  • A freelance starship crew investigates interstellar mysteries.

To design a GUMSHOE creature requires not just a focus on the tropes and themes of the setting—an eldritch abomination, a psychically invasive modern horror, an alien life form—but the creature’s role in the investigative action.

GUMSHOE’s emphasis on structure helps you do this. If you look at the scenario format, you can see that a creature might be:

  1. central to the scenario’s key mystery
  2. a secondary obstacle adding challenge and suspense along the way

In case 1, the creature is either the source of the mystery, or adjacent to the source. The PCs have to interact with it in some way to bring the case to a close. That’s your:

  • salt vampire feeding on the crew of the mining outpost
  • resurrected sorcerer bumping off anyone who uncovers his secret
  • ghost taking vengeance on its killer’s descendants

Many instances of case 2 fall into the broader category GUMSHOE calls Antagonist Reactions. When the heroes start poking around, the primary villain sends some lesser creatures to harry them. Secondary creatures might also be keyed to specific investigative scenes, as guardians or obstacles the characters must overcome before gathering clues. Examples include:

  • the gargoyles the corrupt priest sends to trash your studio
  • the mutated dogs in the abandoned lab
  • the faceless homunculus hitman known only as Mrs. Blank

Your description of a GUMSHOE creature might suggest ways it can appear in either role. When writing up Mrs. Blank, you could indicate how she acts when the PCs are tracking her through her trail of victims, and then what she does when she shows up at the behest of the vamp conspiracy to treat the agents to some silencer music.

Accompanying any core activity is a game’s default identity, the description of a typical PC group: ordinary people, trained professionals, burned spies, starship crew, or whatever. Take that into account also as you design your creature. Show the GM how to get the characters into contact with your entity. In other words, your description needs at least one plot hook demonstrating its introduction into play.

Super easy, again, in D&D: unless you say otherwise, the creature occupies the fantastic environment, ready to defend itself when adventurers show up to fight it.

The more specialized the default identity, the more guidance GMs need getting your creature into their games.

Let’s say you’ve designed a ghost that materializes out of printer’s ink. What motivates the typical group for this game to confront it? The answer differs if the PCs are ordinary people (Fear Itself), burned spies (Night’s Black Agents) or security pros who respond to assignments from their handlers (The Esoterrorists, Fall of Delta Green.) The question in the first two examples is “Why do the PCs care?” In the last case, it’s “Why do their handlers care?”

Keep these essential questions in mind as you first envision your creature, and again as you revise your text. You’ll probably spot passages that explore a rabbit hole of iterative detail but don’t figure into a GM’s key concerns:

  1. What does it do in my scenario?
  2. What does that scenario look like?
  3. Why and how do the PCs encounter it?

A Column about roleplaying

by Robin D. Laws

Many moons ago I encountered a phenomenon I later termed an unrule.

A rule, as goes without saying, is text the designer includes into a game to explain how it is played.

An unrule is text you have to include to prevent players from making a mistaken assumption about your game, based on their experience of other games.

This first cropped up during playtesting for the Shadowfist card game. Players were tripping themselves by expecting its characters to act just like Magic: the Gathering creatures.

If you came to Shadowfist cold without having played MtG, it would never occur to you to expect characters to act in this way.

But if you had already learned Magic, as of course many potential Shadowfist players had, you might have assumed this. Or you might see that we didn’t use same rule, but ask rules support just to be sure.

So we had to include an unrule–a piece of rules text telling you not to do the thing you would do if this was Magic you were playing.

Unrules needn’t arise from comparison to a specific equivalent rule in another game. They can come about simply by substituting general familiarity with a game form–roleplaying let’s say–to general familiarity for a close reading of the rules.

We all do this. Roleplaying games are full of rules, and we learn by analogy. The more previous RPG books we’ve read, the greater the chance that we let our eyes dart quickly over a section that seems to be saying the standard thing we’re used to seeing that section say. Missing out how a given part of the system works is absolutely par for the course.

For example, Simon recently spoke to a GM who was having trouble with GUMSHOE because you can run out of points in an investigative ability, and therefore can’t continue to use it, stopping you from solving the mystery.

Which would in fact be a terrible flaw in the game, given that the whole point of the system is to ensure that investigators always get the information they need.

The rules directly explain, in clear and explicit detail, that investigative points are never required to get the crucial clues you need to move through the mystery.

You are never required to spend to get pivotal information–especially what we call core clues, the ones that signal the appearance of brand new leads and avenues of investigation. If there’s a new person you need to talk to, place you need to poke around in, or area of research you must embark on, you always get that info, period. No point spend required.

Instead point expenditures give you special extra spiffy benefits above and beyond access to vital clues. In early GUMSHOE scenarios you sometimes got especially impressive information that didn’t directly impact the case, or gained the standard clue in a particularly impressive way. Over the years we’ve put that thought aside in favor of practical benefits to the character. You might learn how to kill a creature more easily, cement an alliance with a helpful GMC, convince an angry bystander not to slug you, and so forth.

Spending every single investigative point on your character sheet never stymies you. You can always continue to gather the clues the scenario provides, just as before. Assuming your character looks in the right place and has the needed ability, you get the info. If you look in the right place but don’t have the ability, another PC will have it. Is that player not present this week? We have workarounds for that, too.

Since you don’t need to spend investigative points to gather key clues, running out of investigative points is extremely rare in practice, when playing the rules as they appear on the page. Spending them all means that you’ve accrued a bunch of benefits, and can’t garner any more of them. It never stops you from proceeding.

Likewise if you have a general ability, used to overcome practical problems and dangesrs, and spend all of your points in it, you continue to use it. You have less of a chance of succeeding, as you can no longer spend points to add a positive modifier to your result. But you will still succeed at least half the time against the most common difficulty number.

Mistaken assumptions like this are hard to head off. Where players are reading a rule into the text that doesn’t exist, you can write a rule telling them not to do that. Though it may be odd to explain what a game doesn’t do, implicitly heading off a comparison to another game can be done.

Reaching players who assume Y when you explicitly write X is a tougher conundrum.

Misperceived rules prove particularly thorny during playtest. Playtest draft documents are a mess, littered with bits to be written later, sections not yet optimally placed, and no index or graphic elements to help one’s saintly playtesters find the references they’re looking for.

You may get an account of a failed game session but never realize that the results were based on misunderstood versions of the rules. Ideally you get enough context to see what has gone wrong and take action. Depending on the misperception, you might flag the existing rule with more insistent visual cues, add redundant text to hammer the point harder, or emphasize it through repetition in various sections of the book. The best way to have this problem is to find out you genuinely wrote an unclear rule, because then you can simply fix it by rewriting for clarity.

The real headscratcher comes long after playtest, when most everyone gets the rule as written and you discover a surprising misinterpretation standing between a pocket of players and enjoyment of your game. Simon has been investigating the possibilities of a squirrel-based system, where his favorite urban rodents fan out from Clapham and across the world, watching Pelgrane’s games play at the tabletop and then reporting back in their distinctive angry shriek when they see rules misunderstandings in action.

Until we get that up and running, GUMSHOE fans, we’re going to have to rely on you to keep watch for misperceptions preventing unfortunate others from enjoying a rules system that works perfectly well for you. Show them the light with the gentility our readers are known for. Remind them GUMSHOE always wants them to get the information. It always wants them to have what they need to solve the mystery. When it comes to clue-gathering, GUMSHOE says yes.

When the Dark is Gone cover_350

by Becky Annison

It all started with Fiasco, a game by Jason Morningstar. Until then I’d loved and played many traditional games but nothing like Fiasco. It had no GM, required no pre-game prep and everyone created bits of the world and story. I’d never see anything like it before!

The idea of no prep and no GM was intriguing for a busy lawyer also studying for a Masters degree. Could I still have a satisfying gaming experience without hours of prep?

But as intriguing as it was, something troubled me. I struggled to imagine how a short game with no prep could reach the depths of emotional engagement I loved about traditional campaign play. Could I really get deep into a character in a game like this? This was the inspiration I needed to take me from player, GM and occasional LARP writer to RPG designer. If a short, prepless yet deeply emotional game did not exist (to my limited knowledge!) then I would simply have to write it. I was skeptical at the time – was what I wanted even possible?

The first hurdle was simple. Fiasco was designed for a completely different style of game. It is tragic-comedy, over-the-top and at times, farcical – just like the Cohen Brothers films on which it is based. A more serious topic, a therapy setting where players create troubled and hurting people would be a short cut for a deeper experience of character.

But then came the challenge. It is difficult for one individual to carry the weight of improvising all the material external to the player characters in any game e.g. the background, story, world building and non-player characters. A GM falling to improvise with sufficient speed, certainty and consistency damages the player’s ability to suspend disbelief and emotional buy-in to the world created. This is why traditional style games (game with a GM who directs all details of the world and story) tend to require large amounts of preparation. Prepless or low prep games tend to divide the work of improvising all this material (to greater or lesser extents) amongst all the players e.g. in Hillfolk by Robin Laws –  scene set ups are described by each player rotating round the table (indeed there is an argument as to whether Hillfolk even needs a GM!), in Dream Askew by Avery McDaldno scene setting rotates around the table but each player also has responsibility and creative control over a different part of the world the characters inhabit, even in Vincent Baker’s Apocalypse World, the GM (or MC) is required to continually ask the players questions, getting them to define aspects of the setting which are then folded into the story by the MC.

There are many techniques and ideas out there for dividing creative control over the world, setting and story amongst multiple players. But they all held the same problem for my game. They all require the players to step out of character and think as a director or author of the story, rather than a participant in it. These are two very different mind states, often requiring different and occasionally contradictory agendas) I knew that in order to achieve deep character immersion in only 2-4 hours players would need to stay completely in character and that the culture of staying in character would need to be enforced by the group. In a traditional style game with a GM directing the story and the world, players can stay in character for the majority of a game, but even those games require players to refer to stats, roll dice or ask clarifying questions about the system and/or world.  I wanted to dispense even with these out of character moments.

This gave me a number of problems to solve:

  1. How do you get the players to create details about the world and the story entirely in character?
  2. How do you maintain consistency and resolve conflicts entirely in character?
  3. How do you enforce a cultural norm in character?

The setting of a therapy session provided me with all the answers.

  1. The players create details in character because they are remembering something which has already happened. They cannot react to the things they create, except in so far they react to the memory of it having happened. Creating memories of a fantasy world as in When the Dark is Gone allows the players to have a lot of fun, but isn’t compulsory.
  2. You don’t bother with consistency or conflict resolution. Memory is fallible, people remember the same event differently all the time. If the memories created are inconsistent or conflict this it is brilliant – the characters can explore why their memories differ. It just creates more story.
  3. The last problem led to the creation of the Therapist character. Each session has a facilitator who is entirely in character as a Therapist. They ensure that interesting ideas get prompted and then explored by asking the players lots of in character questions. The Therapist constantly reinforces the in character culture and maintain the momentum and pacing of the session.

A surprising amount of the design for When the Dark is Gone went into the guidance for playing the Therapist. At first glance this might appear like a typical GM role. In fact it is very different.  The Therapist has no creative input in the story at all – they are a true facilitator and yet it is a surprisingly satisfying role to play.

I’m pleased to say that in all the play testing rounds it was clear that When the Dark is Gone really produced a deeply emotional game, without prep and in a single session.

When the Dark is Gone is part of the Seven Wonders anthology by Pelgrane Press, available for pre-order here.  I hope you enjoy playing it as much as I enjoyed writing it.

See Page XX

A Column About Roleplaying

by Robin D. Laws

A while back Cat asked me for guidance on an unheralded facet of tabletop RPG production, the gentle art of collating feedback from a group of playtesters into a single document of greatest use to the designer. After writing it up I figured that it might be more generally useful to budding line developers. They perform a tough job without access to as big a pool of advice to draw on. So I polished that memo up, inserting some strategic diplomacy, and here you have it.

As Cam Banks did a killer job assembling playtest feedback for Feng Shui 2, an alternate title for this piece could be “Cam Banksing Your Way To a More Efficient Playtest Feedback Document.”

Perennial playtesters could reverse-engineer this advice into guidelines for providing more effective feedback. However, if you fit that description, you’re worth your weight in gold already. Just keep on doing what you’re doing, and let the developer and designer worry about turning your reports into design and presentation changes.

The “you” found below refers to the line developer. The designer is either a singular “her” or a plural “us”, as context dictates.

The number one most useful thing you can do in assembling a feedback document is simply to group all of the comments in order, by chapter and major subject breaks within each chapter. Depending on how the designer laid out her manuscript, breaking it down to Header 1 categories ought to do the trick. (If your designer hasn’t formatted her document with headers, you need to have a talk with her about that.)

This ordering process alone saves the designer a ton of time. She now won’t have to jump around randomly in the manuscript as she addresses issues from various groups in sequence. Ordered collation allows her to consider possibly opposed views on particular issues at the same time.

The second most important task the developer can perform is to strip comments of any emotional petitions playtesters are making of the designer. Boil them down into tonally neutral observations of actual problems encountered during play.

A natural disjunction exists between the desires of playtesters and the needs of designers. People like to have opinions and to feel that they’re being heard. They want to feel their impact on the process when they read the final product. The designer, on the other hand, wants to drill past opinions into descriptions of experience. Here the line developer jumps in to reconcile those two divergent requirements.

In the able developer’s hand, “We hated hated hated the scuba diving rules. They were too complicated and disrespected the glorious field of oxygen tank repair” becomes “One group disliked the scuba diving rules, finding them too complicated.”

As developer, you will also find yourself encapsulating “It’s irresponsible in this day and age not to include a full character build system” as “one group wanted a full build system.”

By doing this you allow the designer to skip the cognitively costly step of processing the playtester’s unhappy emotions, moving straight on to fixing the problem, if indeed she finds that there is one.

Conversely, the stripping of pleas and demands from the original context prevents the designer from dismissing a valid concern because the respondent couched them in an off-putting way.

In the typical playtest, count on one group to vehemently reject the game’s entire premise and all of its attendant design goals. For a new iteration of an existing game, it is not unusual to get a group that asks for alterations to established elements of the core system that work perfectly well and are not up for grabs in the current playtest. You can safely drop these from your feedback report.

Sometimes the first class of objections, reframed in emotionally neutral terms, help the designer write the expectations management sidebars that explain why the game works as it does.

Now and then you’ll get feedback from groups expect the rules to serve their very idiosyncratic play styles, or to solve issues concerning their specific problem players.

“These rules don’t constrain Randy nearly enough. You know, Randy! He’s a jerk but he drives the rest of us to game.”

“When we heard of your English parlor mystery game we were really hoping for a rules set that fuses our favorite parts of Nobilis and Rolemaster. Your investigative game could still be that if you added fifty pages of combat results charts and dropped mystery solving for mythic interaction. And we’re going to keep emailing you about it until you see how important this is. Because everyone else must want that too.”

As developer, your job is to run interference, keeping your designer focused on meeting her design goals and undistracted by passionate campaigning to deviate from the premise. After all, it might be you who assigned her this remit in the first place.

When you do include a bit of feedback you find off-base, flag it as such. The designer can enjoy a chuckle and keep going.

Playtesters naturally find it way easier to spot problems than to call out the segments of the game that already work. When a group does do this, it is helpful to know, so the designer doesn’t drop a thing most groups have success with in order to satisfy a problem had by a few.

Whenever possible, indicate how widespread a particular issue is among groups. “One group found the procedural rules too complicated” calls for a very different response than “Two thirds of the playtesters found the procedural rules too complicated.”

You can safely omit another common strain of feedback: “We didn’t like the look of that rule so we made up our own and here’s what happened.”

If you sense, or are told, that comments are based only on a reading of the rules, throw them in the garbage. Do not waste your time sifting them for pearls. They’re guesses at what might happen at the table. Plausible-sounding guesses are the worst, as they can prove deeply misleading. The designer needs to hear what actually happens when rule X or Y hits the table.

Proposed solutions to design issues are almost always unhelpful. Nine tenths of the time they add additional complexity without taking the whole of the rules engine into account. Share them only if the designer asks.

As a designer, I’d rather just see the problems: combat was too slow, we had a TPK in the first scene, the players refused to get out of the starship once they realized there were Class-K entities on the planet, we found the procedural rules too hard to learn, the character with telekinesis outshone everyone else, the example of initiative doesn’t agree with the rules text, the arithmetic is wrong in the Fleeing example.

Specific notes on the balance of particular crunchy bits are quite helpful, even if I wind up disagreeing with some of them. Here theories by someone who has actually played the game but not seen a certain hosy combo come up can in fact be useful.

Comments rendered in the language of game theory or general philosophizing are of almost no use, except in expectations management.

Some groups really love composing detailed write-ups of what happened in their games. I’m always abashed at the work that goes into these, because I have to admit that I skim them at best.

One big exception: if play write-ups list what character types got played (in a game that has them), and you can collate those, that’s very useful. Here we might discover that every group has a hobo in it but none of them have professors, in which case we might want to buff up the professor because this is Trail of Cthulhu, dammit. We might also want to determine if people just really love hobos, or if we’ve accidentally assigned them twice the build points other starting PCs get.

Organizational complaints always arise in playtesting but are devilishly hard to evaluate. A raw manuscript without an index and page numbers is hard to learn from. Lacking the mnemonic qualities of art placement and layout, a work in progress is by definition a mess. Many observations stem from not being able to find a rule in a raw document. This one you simply have to expect and hope to address during production.

Like most designers, when I get a stray idea for a game mechanic I try to exercise the discipline to make a note of it.

Here’s where I can’t speak for other designers: I almost never use them, because they are misconceived by dint of their very nature as stray ideas.

Mechanics for their own sake don’t serve the games we try to fit them into. The standalone rules idea is invariably aesthetically pleasing in the abstract. And that’s not rules should be. They should solve a problem arising from your design goals, not sit there looking all pretty and innovative.

For example, I’m glad I saved the following note, and even gladder that I didn’t build it into DramaSystem:

Grid you fill out to keep track of identically framed scenes –- repetition alters odds of success, as you can’t have the same outcome more than twice (and then only when you haven’t advanced the conflict in any other way.)

The idea of a grid you have to fill out seems momentarily engaging. It gives players a concrete way of interacting with the rules. You can imagine yourself behind a booth at Gen Con opening up a book and showing it to a someone you’re pitching the game to.

Yet in practice it would pose a distraction from the organic creation flow DramaSystem aims to facilitate. The occasional transfer of a drama token, and the even more occasional play with procedural tokens and cards, provides more than enough ritual gaminess.

It is worse than distracting, in that it sets out to solve a hypothetical problem that in practice never occurs in DramaSystem. Once it gets moving, the story moves so quickly that you’re not tempted to revisit an exchange that has already been resolved. Players searching for a scene to call naturally reject this option, without needing a rule at all, much less one that has them filling in a freaking grid.

No matter how beautifully graphic designer Christian Knutsson would have made that grid look.

Lesson: jot down those free-floating rules ideas for what they might teach you about design. But don’t wedge them into your designs, inflicting them on unsuspecting players.

As Gridlock the Stray Rules Idea, pictured at right in full tentacled glory, might say, “If I’m aesthetically pleasing in my own right, I’m too complicated!”

Hillfolk is a game of high-stakes interpersonal conflict by acclaimed designer Robin D. Laws. Using its DramaSystem rules, you and your friends can weave enthralling sagas of Iron Age tribes, Regency socialites, border town drug kingpins, a troubled crime family, posthuman cyberpunks and more. Purchase Hillfolk and its companion Blood in the Snow in print and PDF at the Pelgrane Shop.