Teaching the GM to Fish

We’ve all heard the adage, “Give a man a fish and he’ll eat for a day, teach a man to fish and he’ll be fed for a lifetime.” It’s way overused and often very inappropriately applied. However, there’s a grain of truth to it when it comes to game mastering.

You see, you can give a GM a rule for every situation, and they’ll be able to run the game as long as they keep referring to the rulebook (or, I suppose, memorize it), but if you give the GM a widely applicable mechanic and instruct them how to implement it in a variety of situations, they can run the game and never (or practically never) refer to the book.

In other words, teach a GM how to assess a challenge and deal with the consequences, rather than trying to create rules for a varied number of situations and corner cases.

Having a discrete rule or modifier to cover every different situation is appropriate for certain kinds of games. Cypher, however, is not one of those games. Neither are a lot of other, more narrative games. Such games need a generalized mechanic for penalties and bonuses, like the concept of advantage (roll twice and take the better) or disadvantage (roll twice and take the worst). Or, in Cypher, easing or hindering the difficulty of a task.

To explain why I feel this way, consider a bespoke rule for how to handle a character’s chance of drowning. Such a rule frequently creates one of two situations:

1. The PCs fall into the water and play stops while the GM looks up the rules for drowning.

2. The PCs fall into the water, the GM handles it as seems appropriate, and the players see the rule later and "fact check" the GM.

I don't like either of those situations for games like Cypher. In fact, doubly so specifically for Cypher because in addition to creating a system where gameplay moves quickly, we’re trying to portray multiple genres, and it's likely easier to drown in, say, a real-world setting than in a sword and sorcery one.

Similarly, I don't want to have things like jumping distances or climbing difficulties in the player-facing rules, either. The GM should have suggestions for such things, but they should be presented as examples of how to set modifiers or make rulings. And again, genre influences this heavily. An accountant in the normal world might leap a decent distance, but Indiana Jones leaps farther. Daredevil leaps farther still. One might argue that’s a function of the character in question, not the genre, but it’s likely a middle ground. Some genres change what is considered realistic. Regardless, the GM needs to be informed of all of these factors, so they can affect the difficulty of the task.

Teach them to fish.

A hard lesson for many game designers is that most players don’t think like game designers. And I’m talking about players specifically, here, not GMs. A designer might want to include a rule to cover a situation so that a player will know what to expect in that situation. Telling the player what sort of modifier they can expect if they try a certain action—it sounds good, right? But this assumes that players read the rules and, perhaps even more unrealistically, refer back to them. Most players look to the GM as their guide through the rules. Instead, overly specific rules teach both player and GM that they are supposed to stop playing and refer to the rulebook when the situation arises (the first of the two likely outcomes that I previously mentioned). It slows down play.

The “teach a man to fish” adage doesn’t apply to players. Or at least, the players of somewhat more narrative games like Cypher. For players, the goal is to teach them the general rules—state your action, and circumstances will likely modify your chance of success, but let the GM worry about the specifics. That’s one of the main reasons why we’ve decided to have one book for the players in Cypher, and one for GMs.

But, for a very tactical, very mechanical game, the bespoke rules approach might be perfect. Players of such games want precision and detail, to increase the ability to play tactically, and for their game to simulate what they feel is most realistic. The precision, not the speed of play or ease of use, is the important part.

The task of the designer is to know what kind of game rules they’re working on.

Share