Today’s guest article is by Richard Dansky, who tabletop gamers are most likely to know for his extensive work with White Wolf, particularly Wraith: The Oblivion. He’s a GM, a 14-year veteran of the video game industry, and the author of six novels, including Firefly Rain. His latest novel, Vaporware, comes out May 24th. Thanks, Richard!

Nobody gets GMing right the first time.

To be fair, most people don’t get anything right the first time, but GMing can be particularly tricky. After all, the novice GM is presented with not only an entire world to run and personify, but also a group of players -— often with deeply conflicting ideas over how a campaign or session should go — who are counting on that GM to provide the evening’s entertainment. And there are a million ways for the new GM to fail. Hand out too much loot. Hand out insufficient loot. Focus too much on one player. Get bullied by a rules lawyer. Get vindictive and kill everyone off.

Those are the big ones. But there are a million smaller things that a GM at the start of a campaign will get wrong —- even if it’s an experienced GM, even if it’s an experienced group. Every new campaign brings with it a new mix of players, roles, and interactions, and even a group that’s been gaming together forever is going to need some adjustment time to get to a point where everyone’s expectations are both reasonable and met.

Now, you can try to run roughshod over the messy bits, which tends not to go well. Asking someone to suck it up and just deal in their leisure activity is a great way to encourage them to find a new leisure activity, especially if it’s something that can be easily corrected. At the same time, oversteering in response to player kvetching at the slightest inconvenience can be just as bad, leading to one-upmanship and allegations of favoritism.

And this is where good old fashioned GMing can steal a page from video games, or specifically, from video game development.

The thing many people don’t realize about gamedev work is that it is both slow and detail-oriented. Back in my White Wolf days, if we found a problem with a book, we could pretty much (with sufficient bribes to the layout artist) fix it right up until the moment it went to the printer by the simple expedient of adding/cutting text. That —- and making sure it didn’t bork the page layout —- was all it took. Measure vaguely, cut as needed.

In video games, however, laying something down is both time-consuming and expensive. Changing something is both of those things in spades. And changing something last minute, well, you don’t want to know. (The hell I —- deservedly — caught for asking if we could add a rock to a level in a Ghost Recon mission pack was enough to melt lead.) So to make sure teams don’t indulge in this sort of inefficient, expensive sort of production, we get iterative.

By iterative, I mean we do a lot of prototyping and rough drafts, we test them and give feedback, and we revise until we get to a point where we’re comfortable going ahead with full-fledged production. It’s not always the most exciting way to do things, but it is the one that saves the most heartache at the end.

Now I’m not suggesting that GMs go iterative in the same way. There’s a reason that this stuff is done on dev teams long before material goes out in front of the public. But what a good GM can take away from it is the idea of iteration, of adjustments through slight changes to reach a state that everyone agrees on. It’s as much a philosophy as it is a formal technique.

Let’s take a simple example —- play time. If your party splits up, after the session, actively ask your players if they felt like they had enough time at center stage, or if they felt the balance of play was disproportionate. Do that and, congratulations, you’ve got data. Adjust your behavior according to the data —- make sure one sub-group doesn’t monopolize the session, or forcibly re-integrate the party, or give the players from the underserved side of thing secondary characters to play —- and you’ve improved your GMing. And it’s all better, right?

Wrong. Because if you’re iterating, you don’t stop with just one iteration. Make your adjustment, get your data on the revision. Adjust again, ask again, and keep tweaking until you’re at a place that feels good. And don’t assume that “making everyone happy” is the way to interpret feedback, because it’s not. For one thing, odds are you won’t make everyone happy.

For another, there’s the fine art of interpreting the feedback you get to actually make it actionable. “I didn’t get to play enough” doesn’t always mean “I didn’t get to play enough.” Sometimes it means “I didn’t get to do interesting enough things” or “I want more content geared toward my character” or “your pace as a GM is too slow and you need to pick it up so we accomplish more.” Learning to translate what your players say into what they want —- and then trying to give them that -— is absolutely necessary. The thing to remember is that while not every bit of feedback you get when you move to this model is accurate, every piece of feedback you get is indicative of something, and you ignore or dismiss that at your peril. So you have to learn what they’re really saying and not reflexively push back against it. It doesn’t matter if your stopwatch says everybody got precisely two hours front and center, if half your players don’t feel that way, the clock won’t convince them. It’s up to you to change —- based on their feedback —- and adjust the perception for next time.

And of course, there’s not just one thing you should be iterating on. Every aspect of a session can potentially be improved, so there’s no reason not to try to improve them. Now, this doesn’t mean you should formally grill each player after each session, complete with pre-printed feedback forms. That sort of mandatory compliance defeats the point of the exercise. Rather, approaching players and actively but informally soliciting their feedback is the way to go. Making them a partner in improving the experience and encouraging them to come forward with information that will make your life as a GM easier is the best way to figure out where you need to improve, and maybe, how to improve it.

The how is important, too. The point of iteration is to give things a dry run, to experiment. To try different approaches and see what sticks. So when you get feedback, sticking to the safest fix defeats the point of the exercise. Try all the fixes and don’t feel bad about the ones that produce negative feedback. The point is not for the first approach to fix everything, the point is to get to a place where things are fixed, and to do that means using all the tools at your disposal —- even the funny looking ones.