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.