See Page XX: SRD or SDD?

See P. XX

A column on roleplaying

by Robin D. Laws

SRD or SDD?

logogumshoe

Cover_Final_TitlesWith editorial for Hillfolk and Blood on the Snow completed, it’s time to take a break from DramaSystem to work on another of the obligations arising from our November Kickstarter. That would be the System Reference Document for Open GUMSHOE.

On one level, this seems like an exercise in cutting and pasting, taking the basic iteration of the rules as found in the upcoming Esoterrorists Enhanced Edition (the text of which you can grab now as a preorder benefit), cutting out the setting-specific bits and then adding in elements from the other GUMSHOE games. It does however require some thought on what an SRD ought to be doing.

When you decide to throw a game system open to all comers, you naturally give up control over what happens to it as others present it for their own creative purposes. This is a concern because GUMSHOE departs from some standard assumptions and becomes a better play experience when GMs and players understand where, how and why it does this.

For example, rating points in abilities mostly don’t represent a simulated resource in the fictional world. Instead they function as a sort of narrative conceit, measuring the characters’ spotlight time and how they grab it. (A few abilities, like Health and Stability, can be regarded as measurable resources in the game reality—although of course they’re still an abstraction. When you break your leg, you can’t consult a numbered meter to see how many points you’ve lost.) GUMSHOE seems confusing to some players until they grasp this. This explanation, though not a rule, strictly speaking, serves as a key tool to enhance play. So while you might categorize it as GM advice or a player note, it’s really a pivotal component of the game. As such, the explanatory text should be available to anyone publishing their own GUMSHOE adaptation. We can’t require adopters of the license to use it—as indeed, we can’t force them to make any particular choice. We call this Open GUMSHOE, not Passive Aggressively Controlling GUMSHOE. Still, we can encourage people to include it by making it part of the standard boilerplate text in the document.

This reflects a broader priority. We’ve chosen to make GUMSHOE available to other designers. Yet we remain its foremost custodians. If we’re going to let it out of the nest like this, we’d better provide excellent care and feeding instructions. We want others not only to produce GUMSHOE games, but to design great GUMSHOE games. It should therefore contain at least some guidance on how to do this.

The GUMSHOE SRD differs from the most famous versions of its breed, the D20 and its descendant, the Pathfinder document, in that it won’t also comprise a playable game unto itself. It’s not The Esoterrorists with the IP elements scrubbed out, but rather the set of components you need to build your new game on the GUMSHOE chassis.

If you’re designing a GUMSHOE game, we want you to be able to do it well. So it has to contain at least some signposting showing you how to adapt it to your needs.nba cover

For example, the build point totals for purchasing investigative ratings vary with each iteration of the game, depending on how many of those abilities the game includes. So the SRD can’t just give you the flat numbers as they appear in The Esoterrorists or Ashen Stars or whatever, because you might include a different number of investigative abilities in your GUMSHOE game. The document has to break from the text as third-party publishers might incorporate it into their rulebooks to provide the formula to calculate what the build point totals should be.

At least in these passages, the System Reference Document becomes something else—a System Design Document. We’ve gone from SRD to SDD.

 

Extensive passages on how to design GUMSHOE games go beyond the scope of the project. That sort of thing is better saved for occasional columns like this one. But the SRD does have to provide designers with the basic tools to construct GUMSHOE games without having to reverse engineer from the existing books. A balance must be struck here. If the document contains too much advice, it might create preconceptions that might lead other designers away from what would otherwise be brilliant leaps away from the game’s current assumptions. Too little, and it doesn’t give them enough to simply reproduce what we’ve already established in another setting.

GUMSHOE is not a generic system, but a chassis on which you can construct an emulation of any investigative Trail Covergenre. For a classic example, see the grenade. Grenades in the real world work the same regardless of the context in which they’re exploded. In fiction, they can work quite differently, depending on the reality level of the genre at hand. So in the Tom Clancy-meets-postmodernism-meets-visceral horror mix of The Esoterrorists, grenades are pretty deadly. Mutant City Blues treats them as less effective than the super powers at the heart of that setting. If you for some inexplicable reason decided to fuse high energy action movies with investigation, you might make yet a third choice, depicting them as wildly damaging to property and inanimate objects, while allowing people to escape harm from them simply by jumping and being carried away by the massive fiery explosions they generate.

So again the SRD can’t just pick one grenade rule and make that the default for all genres. It has to provide a quick design note about genre emulation and point you toward the solution that works for your design goals.

Likewise we won’t be providing a complete list of mutant powers from MCB or virology implants from Ashen Stars. But we will give you examples of each special rule structure so you can then kitbash it for your own purposes.

In the process I might even learn something new about my own game, as I figure out what is and isn’t essential to it.

This site uses cookies to offer you a better browsing experience. By browsing this website, you agree to our use of cookies.