What defensive programming taught me about running RPGs.
I have been part of some weekly table-top role-playing game (RPG)It bothers me that so many who hear “role-playing game” without the “table-top” qualifier think of computer games that don’t involve any role-play. for more than half of the weeks of my life, and been the game master (GM) for more than half of those games. I’ve read tens of thousands of pages of RPG rule books and GM tips books and articles and played with or observed dozens of experienced GMs. But it was not until I learned about defensive programming that I started to feel confident that I could GM any group any time.
Programming is the process of describing to a computer what the computer should do. Usually the focus of programmers is on the expected behaviors; the further we get from that expected path, the more likely we are to get to something that the programmers forgot to address. Your word processor probably knows how to handle short and long words, but does it know how to handle a word consisting of eighty-thousand non-breaking spaces?
Broadly speaking, there are three approaches to handling user behavior the programmer didn’t expect.
The simplest is “undefined behavior”: just blindly follow the instructions written for expected cases and whatever happens happens. Undefined behavior is the source of most security exploits: someone finds a specific input that just happens to make that set of instructions do something unwise, like grant an untrusted party complete access to the system.
Next up is “exceptional control flow”: in various points of the program we add checks for specific unhandled situations and if we find any of them then the program switches from its usual processes to a special “something went horribly wrong” mode. One goal of this solution is that maybe you’ll crash the program, but at least you won’t be able to make it do something awful. Alas, the part that handles the exceptional cases usually gets less use and testing than the normal part and thus often has its own undefined behavior, and we don’t always remember to check for everything we should, but in principle exceptional control flow can block many of the worst security problems of undefined behavior.
And then we have defensive programming. Defensive programming is a whole class of techniques, but they overall goal is simple: every piece of code has to explicitly and correctly handle both expected and unexpected cases. You can’t simply assume expected input; you can’t defer to a special mode when something exceptional happens; instead, you have to explain how you handle both the normal and strange case.
There’s a lot more to say about defensive programming, type systems, algebraic datatypes, checked exceptions, and so on, but they key takeaway for today’s post is this: always answer the “else”, the thing to do if the unexpected happens, and answer it in a way that keeps the program doing what it ought to do.
The great beauty of RPGs is that the players have infinite options. There are things that their characters can’t do, like licking their own elbows, but there’s nothing they can’t try to do. And the magic that makes that freedom work is that there’s a GM, a human who gets to handle how whatever unexpected thing the players do impacts the unfolding story.
But that’s also the most frightening part of being the GM. What do you do when the players do something totally unexpected for which you are not prepared? Early on in GMing I learned the four answers:
Just make up something that feels like a sensible reaction on the spot.
Ask one of the players to take on a bit of the GMing and explain what the outcome might be.
Stop the game and resume after you’ve had time to think through the outcomes of this unexpected choice.
Have the world conspire to reject their choice and get them back on to what you’ve planned.
Each of these has its place, and I do all four of them from time to time, but since I learned about defensive programming I can often prepare an entire multi-hour game where I don’t need to do any of them.
GM preparation involves many facets, but generally follows the GM’s expectation of what the players will chose to have their characters do. Only flesh out the contents of a cave or the personalities in a shop if you expect the players to enter that cave or shop. Typically that prediction is predicated on three things: your understanding of the players, their characters’ situation, and the hooks or leads that you place in their path. And it’s that last part that GMs are usually bad at understanding.
When players are given a plot-progressing beat by the GM, they generally recognize it as such and thus give some attention to the question of how they should react to it. But even if you design the beat to cause them to realize that x is the right choice, there’s always a good chance they’ll pick something other than x. If that chance isn’t high enough, it stops being a game for them and they’ll generally start bucking the system, making increasingly erratic choices to express their freedom.
However, most hooks result in two or three choices and you can be confident the players will pick one of them. For example, in a game I GMed last Saturday an older more experienced adventurer was going to offer the players her patronage. I expected the player to accept it, but I also prepared for what would happen if they turned her down or if they disagreed with some accepting and some rejecting. And by prepared, I mean I had not just how the adventurer making the offer would respond but also how their choice would lead to further events. Say yes and be given both a medium-term goal and a few short-term warm-up adventures to gain experience, reputation, and coin. Say no and attract the attention of someone looking for help outside the normal order of things. Split and be given both and face the two incompatible views of the city that result.
Prior to learning about defensive programming, I often prepared ifs without elses. If they accept this opportunity, things happen and the game progresses. If they reject it, then they’ve left my notes and I’m left to chose between improvisation, delegation, pausing, and railroading. After years of doing this, I got quite good at both improvising and railroading, but I’m happy to use those skills less now that I’ve learned to prepare defensively.
Looking for comments…