Designing, RPG

You Can’t Design a Game in Your Head

Have you ever had a really great dream, and tried to tell someone about it, and realized that it didn’t come together as a coherent story the way you thought it would? That’s because it’s difficult to have any perspective on ideas while they’re still inside your head. The same thing can happen with game ideas. If you get your ideas down into a concrete form like a game draft you can look at them with some perspective and make sure that they work as well on paper as they seem to inside your head. Additionally, people can’t play your thoughts. If you get your ideas down into a concrete form like a game draft you can get it into the hands of playtesters. If you’re relying on explaining your previously unarticulated ideas on the fly, you’ve got to worry about whether you can spontaneously think up a good way to explain the game while you’re also using brainspace to run the game and monitor the playtest. Why take that risk? Write your game draft – in an ideal world playtesters can read it, and in the worst case you’ll at least have a working baseline from which to explain the game. If you get your ideas down into a concrete form you can also keep track of what incarnation of the game you’re actually testing (it’s really easy for a designer to get confused about the current draft of the game, because every idea the designer ever considered seemed like it was part of the game at some point, and memories aren’t always reliable, especially under the stress of running a playtest). It’s really tempting to endlessly noodle about game ideas in your head – it feels like you’re doing something important and you never face the risk that your ideas won’t work as well as you hope they will. But designing in your head is just pretending to be a game designer, real game designers write game drafts (it’s fine to just pretend if you want to, but there are probably more fun ways to pretend, such as by playing an RPG).

You’ve Got To Do the Work Before You Can Ask For Others’ Time

If you know there are problems in your current draft, and you know how to fix them, you need to fix them before you offer it for playtest. If you ever end up in a situation where somebody gives you an observation about your game, and you say “yeah, I knew that already, I just haven’t gotten around to dealing with it yet”, that’s a symptom that you’re wasting people’s time and goodwill. Don’t do that.

Record Your Playtests

If you can, record audio of the sessions. There are a lot of benefits to this. When you’re actually playing the game your attention is usually pretty focused, which means you miss nuances and details of things that are going on in the game. When you listen later you can pick up on things you missed during the actual session, like mistakes you’re making with the procedures, or people getting confused or frustrated. Additionally, based on listening to recordings of my own sessions I’ve found that my subjective recollections of sessions aren’t very reliable — for example, in one case I mentally exaggerated some problems to the extent that I nearly concluded the game was worthless, but when I was able to listen later in a less emotionally-charged state I realized that they were minor hiccups in an otherwise fun session. If you have a recording you also don’t have to worry as much about remembering what the problems were, etc., because as long as it gets said out loud you’ve got a record of it.

Be Careful About Playtesting a Game in an Artificial Manner

Games are designed to be played in good faith, and no game can work if players are intentionally trying to subvert it. If playtesters go into a playtest with an agenda other than “play this game like you’d play a normal game”, there’s a risk that they’ll veer into territory where the game shouldn’t be expected to work. For example, taken to an extreme, an agenda of “do what you can to break this game” can encourage players to drift into obnoxious or tendentious territory, which can easily provide false data or mask real data. I can’t say categorically that all artificial play agendas are worthless for playtesting, but at the minimum they should only be employed carefully and thoughtfully.

Playtest Games On Their Own Terms

Because of the long history of games that claimed to be all things to all people, many players have internalized a habit of projecting their own style, tone, and general aesthetic preferences onto games, regardless of how the game was designed to be played – e.g. for some players every game is slapstick. This can have an impact on how the game plays. When you’re playing a published game with your own group those consequences (positive or negative) are only felt by that group, but if you’re playtesting then the consequences of your outside ideas overriding the decisions designed into the game are baked into your playtest and feedback results, which may make the data much harder to interpret. If issues crop up in a game-played-unusually playtest it’s much harder to attribute the problem to a root cause because the “played unusually” aspect can be a confounding factor.

Don’t Fall in Love (or Hate) With Mechanics

Confirmation Bias is insidious. I’ve observed game sessions where the players come in raving about how much they love the simple rules and evocative theme of a game, play a game where they’re constantly confused and struggling with the clunky procedures and deviating dramatically from the tone they set out to achieve, and end the session crowing about how great the system is. When you get invested in whether or not an individual mechanical element is good or virtuous (or bad or evil) you start to mentally edit out any evidence to the contrary. Obviously you think the ideas you implement in your game drafts are better than other ideas (otherwise they would have gone with one of them), but leave yourself open to disconfirming evidence, and don’t wall yourself off from other POVs, especially while you’re still designing or developing the game. Maybe a game mechanic you think you love only works in concert with other mechanics that you didn’t include in this game. Maybe a game mechanic you think you hate is only bad in the specific context you encountered it, and would actually be a good tool to use in your game if you stripped the other stuff away from it and put it in a different environment.

When You Discover an Issue, Note it. Don’t Dwell On It, Find the Next One.

It’s important to note problems whenever they crop up, but once the problem has been noted and acknowledged you have to move past it, not harp on it. When you’re in an information-gathering mode (say, during a playtest), spending time talking about how terrible the problem is or how much someone hates that the problem exists is usually just a distraction, and it’s rarely a good idea to try to stall data collection so you can do some on-the-fly design to figure out what a fix might be (or worse, get into a debate about whether it’s really a problem at all). During a playtest when a playtester runs into a problem they find particularly egregious there can be a huge temptation to try to get the designer to commit to a particular fix then and there. That’s not usually a productive way to do things. Good playtesters learn to accept “I heard and understood your issue” as a response and don’t hold up the test pressuring the designer to make the change they want to see in the game.

Don’t Insert Self-Editing Between Observation and Reporting

Ideally, you want to remove as many problems from your game as you can, and you’ll usually find those problems through playtesting or getting people to read the text of the game and reporting their impressions. Anyone reading this post has access to essentially limitless free information storage, so recording information about problems is relatively low-cost. Problems in your bug database (or written in a design notebook) don’t go stale and don’t require you to address them immediately, so recording information about the problems isn’t a drain on your design or development time. This means that there aren’t many good reason to ask playtesters or people giving you feedback to restrict their feedback in a particular way (e.g. “I only care about big picture issues right now, so don’t both telling me about minor issues” or “I only care about the dice math right now, I don’t care about what you like or dislike about the theme or tone of the game”). If you get them to self-censor themselves now there’s a very good chance they won’t remember later, and if they spend a lot of time with your game they may become so accustomed to the way the game works (or doesn’t) that they may stop noticing issues. Fresh eyes and honest, unbiased observations are a scarce resource, so artificially cutting yourself off from them in order to keep your open-issue list short doesn’t make a ton of sense. If you decide that you really don’t want to change the game to address the issue (maybe it’s a matter of taste, and you’re going with what you prefer rather than what a particular playtester prefers), you can just note that as the resolution in your “bug database”.