Access to the various core rules of Gumshoe games is helpful, as is the SRD. While I do refer to specific Gumshoe implementations, in general the topics examined will be more abstract and applicable to all Gumshoe games.
In this post we are going took at the most primitive layer of Gumshoe: simple tests. Consider it a recap, with the intention of building a framework for future articles.
A good place to start looking at any system is its kernel; I think of this as the ideas that underlies what you might think of as the core mechanic. Having the kernel in mind helps with adjudication, and for when you have to fall back to the games basic mechanics when you don’t have more specific rules available for what the players are attempting.
I want to look at three facets of the system that I think make up the kernel of the design:
- Player facing mechanics (where possible)
- Narratively meaningful tests
- Point spends
Player facing mechanics
This is an obvious feature to spot, not only because the text—and various ancillary material from Pelgrane—explicitly tells us, but also from the strongly asymmetric way Game Master Characters (GMCs) are handled vs the player characters.
The clearest example of this is the stealth and alertness modifiers: instead of having abilities to test, there are modifiers to apply to the players test difficulty.
I think the main thing to draw from this is that the game is entirely about the players view of the story. This is our first cue that the system is not interested in simulating a physical system for example. The mechanics are treated strongly as an interface to the story, specifically the players interface to that narrative.
Narratively meaningful tests
Having established that the system is interested in the players interaction with the story, let’s look at how nondeterminism is handled. Like basically every game, this is with tests, so to get started, let’s look at what the SRD has to say about them:
A test occurs when the outcome of an ability use is in doubt. Tests apply to general skills only. Unlike information gathering attempts, tests carry a fairly high chance of failure. They may portend dire consequences if you lose, provide advantages if you win, or both.
Even in the case of general skills, the GM should call for tests only at dramatically important points in the story, and for tasks of exceptional difficulty. Most general ability uses should allow automatic successes, with possible bonuses on point spends, just like investigative abilities.
In any given situation, failure either results in something fun, or it results in nothing at all. If it is not dramatically interesting, e.g. fun, the players are granted an automatic success, or to put it a different way, they are not presented with a chance for failure. This applies to uninteresting success too, although this is usually less of a problem.
We see this in one of the marquee features of the system: the split between general abilities (you can fail) and investigative abilities (you never fail).
Gumshoe goes further: the chance of success or failure is directly based on story pacing, rather than some notion of realism. The guidance is that difficulty numbers of 4 or less are used for maintain narrative momentum. My rule of thumb here is that if there are no other considerations, any situation where failure is possible, default to a 50% / 50% outcome: it’s equally possible, and equally fun, to succeed or fail. You will see the 50/50 split turn up regularly in the various specialisations of the base rule too, such as stability tests, or as the target for most contests.
This is a good place to start looking at the player’s primary means of influencing the story: their ability pool points. Unlike a lot of tabletop role-playing games, this interface is a limited resource. In contrast, most games use some fixed bonuses. In addition to being constrained, consider relationship between spends and difficulty number with respect to story pacing: players can directly control the pacing of the story, as well as indirectly indicating which complications they find interesting.
The nuances of this part of Gumshoe’s kernel give rise to a number of interesting and fairly novel facets of the game, such as Preparedness, and the retry rules. For now though, this is enough depth. I want to return to attribute pools, and point spends in more detail in future posts.
Tying it together
With say a d20 (or a percentile system!) you would require spends of unwieldy numbers (instead of spending say 3 points you would need to spend 10) which would in turn make the pools much larger, and potentially introduce an additional level of decision paralysis for players when they came to spend.
With say a 3d6 suddenly 1 point is not always worth the same with respect to probability. Not only would it depend on the target difficulty number, it would depend on how many points you spent.
Let’s take a step away from the abstract and look at how these probabilities are implemented with the concrete mechanics. Gumshoe uses a single six sided die for all its resolution. This means we have a course grained uniform distribution to work with. This is also means we have nice predictable math. 50/50 on a six sided die has success as a result of 4, 5, or 6.
A six sided die also means that spending 3 points will guarantee success on an average test, and make the easiest impossible test (a difficulty of 7) a 50/50 chance. This makes 3 something of a sweet spot in the system and you will see it crop up repeatedly.
That’s it for now. In the next post I want to look at the relationship between investigative and general abilities.
Postscript: Quickshock Gumshoe
Newer Gumshoe games such as the Yellow King RPG1, and the One to One titles, introduce a new set of mechanics called Quick Shock which make the game 100% player facing. As a result this changes up the kernel somewhat. I want to look at this in a future post.
- See also: my review of the Yellow King RPG