I’ve been a GM and game designer for years now, and one thing that’s always struck me about the process is how much skills overlap there is in the process, and how many nuggets of wisdom carry over from one to the other. I’ve been thinking about some key points now that I’m working on two projects that should see the light of day relatively soon.

Keep it Speedy, Stupid

The thing that’s sort of the bane of every tabletop game is speed. You want to have interesting mechanics, but you also want to have sessions that involve every player and let everyone shine.

And the ironic thing about that is that you need to let some players have fancy mechanics to let them shine.

So, how do you do this? You’ve got to keep things speedy.

That’s not the same as simplicity. Your job as a game designer is to focus on making a game that gives players a chance to roleplay, not just focus on the rules. That’s not the same as foregoing rules for the sake of storytelling, because then you wind up with free-form roleplaying, which can work well or poorly depending on the players.

The secret is to make sure that your mechanics are easily understood and executed. You also need to cut down the amount of referencing content players have to do.

Mechanically, you need to make sure that you have a defined and focused core mechanic. The more you wind up jumping around the less you will be able to really deliver a playable system to players. Give players a tool for success, and you don’t need to give them tools for success. Keep as much as possible contained in a single system.

Reducing the amount of references a player has to do is important as well. You need to think about the playability of the system; I’m in an Only War game, and it both thrives and dies on this: it’s very reference-friendly, but you’ll need to jump around the book a lot to find stuff. Whenever people get badly injured, you need to use a look-up table that’s not on the GM screen. However, until you get to that final moment of combat, everything flows really smooth.

One of the things I want to do for Project Hammer is to have 90% of characters only use the front of their character sheet, despite it being a fairly detailed game. I include a notes section there, which is probably not really enough but it allows a player to pull out frequently referenced material. Since the back is open, it’s theoretically possible to include a quick-reference there.

Know Your Tools

I saw a GM the other day, while in a game of Eclipse Phase, suggest that a player reroll a result.

It’s not like this is awful: roleplaying is still playing, and so long as nobody’s really bothered by it it doesn’t matter, but it was an indication that the GM didn’t have the familiarity with the system because his first choice was to use a mechanic that wasn’t in the system’s toolkit, and didn’t mesh well with some of the other mechanics.

The first step of designing or running a game is to become comfortable with the core mechanic. In D&D 5, the Advantage mechanic is awesome, because it serves as an alternative to modifiers: instead of letting characters break the game’s scale, you increase the chance of success without ever guaranteeing success.

In a system where success depends on the degree of a dice roll, however, Advantage is a clunky mechanic; everyone will always roll twice for the best result (where Advantage in D&D is often more of a confidence booster than a necessity), and it doesn’t necessarily interface with other mechanics like sneak attacks or the like.

Back when I was a game reviewer, one of the signs that a game would have trouble is if it didn’t really make its mechanics coherent. You have beautiful games like The Legend of the Five Rings with a relatively complicated system that was pretty elegant and used its mechanics to their full extent, but for every wonderful design you saw games that didn’t do the math of probability or didn’t really use the design space wisely.

To bring myself back on point, use exactly as many tools as you need and make sure you use them consistently. D&D 3.5 and Pathfinder really suffer in my opinion because they pretty much just interface a d20 roll with flat modifiers. You can get situations where characters always/never succeed, even when it would be logical for there to still be a chance, and D&D 5 was able to fix that by reducing the amount of modifiers and giving Advantage to really make people shine. When characters get bonuses, it’s often Advantage: it doesn’t allow exponential scaling because it doesn’t stack, and it’s useful at all levels because most people have at least a slim chance at all but the most impossible tasks.

Don’t Break Your Back

One of the most important things as a GM or designer is not to overdo your process. I’m a bit of a perfectionist, so it pains me to say this, but you really don’t want to go for a perfect, foolproof system.

Why?

Well, first, unless you are personally going to go to every group that plays your game and explain it, you will never get 100% adoption of that perfect system, as each table will diverge in their own way and come up with their own rules, either by preference or ignorance.

As a GM, when I first started, I was so heavily into rules as written that I would spend hours before each session familiarizing myself with core sections of the rulebook (this was Shadowrun, so there were lots of rules for different things). I would stop play and look up rules and we would all sit around (and I had something like 8 players) while we did that.

The result was that we just didn’t use certain game systems because I was afraid of getting them “wrong”.

As a designer, you don’t want to overcomplicate things. Your job is to create rules that help tell a story, and you don’t want to go in and worry about a 2% shift in probability if you’re going to frustrate your players and make it difficult to actually use the rules you have. I’m pretty heavily fond of simulation, but it needs to be secondary to play and story.

Once I learned to stop trying to have micromanagement level controls and make sure that everyone got “their” slice of the action by enforcing rules hyper-strictly, I found that both my design and GM output reflected a more fluid process that was a better experience for everyone.

The lesson I learned too late in my career (fortunately I’m still some semblance of young) was that user experience trumps numbers.

Let Players Carry the Ball

A final thing that I found interesting as I’ve observed dedicated players is that they are almost universally invested in the game. If a player isn’t invested in the game, they won’t keep playing. There’s a counterpoint to that as well: I’ve seen players who are quite interested and willing to put in a lot of effort, but weren’t able to for any of a variety of reasons.

One of the regrets I have from my time as an early GM was when I had a friend who really wanted to join us for a session. I did all the stuff: made him a character, gave him a super nifty handout with all his abilities and stats, and even told him how to play his character.

He never returned for a second game.

I don’t know why, exactly, that friend of mine only joined us once, but I have a few suspicions, and the most pressing one comes down to this: I didn’t let him carry the ball.

Players need to get an opportunity to shine, to bring in their creativity and agency, as well as be treated like responsible players. Give players tools in your games, settings, and systems to actually do what they want to do. Roleplaying is about creativity and storytelling, not following a set path of options and choices like in a video game or simply following along like in a novel or TV show.

Wrap Up

The biggest thing I learned in my time as a GM and a designer is to give up on pursuing notions doggedly and learn to achieve an optimal result, even if you sacrifice an occasional design paradigm or don’t do a “best practice” as it’s found in a textbook.

Having an opportunity to study and reflect is important, and as I reflect on my old games in preparation for my new games I’m seeing trends and patterns. If there were one thing I could change about my old games, it’s that I didn’t ever see them as anything more than a vehicle to a system, a coded set of rules and laws as programmatic as a loop of code.

That’s not to say that games won’t work out a certain way: there’s fun to be found in the investigators looking into Cthulhu only to find that they’re outmatched, and that’s not wrong.

But as I look further and further into successful games I’ve run and the things that have made games great, I find increasingly that it’s based on a sort of purity of purpose: fun in light of process.