This will probably seem silly, but let’s compare two hypothetical games, game R and game F:
Game R is a guessing game where one player picks a real thing they can see and another player asks a series of up to twenty yes-or-no questions in an effort to guess what thing the first player picked. In game R, when the guesser asks a question the answerer uses their senses on the physical thing they picked, processes that information via the mental act of interpretation and judgment to evaluate what the answer is, and then says that answer.
Game F is a guessing game where one player imagines a kind of thing that exists in the world and another player asks a series of up to twenty yes-or-no questions in an effort to guess what thing the first player imagined. In game F, when the guesser asks a question the answerer takes the information stored in their imagination, processes that information via the mental act of interpretation and judgment to evaluate what the answer is, and then says that answer.
In both games, it’s possible to give bad answers if the answerer is bad at mentally comparing things. If they have an unrealistic estimate of the size of breadboxes, maybe they’ll give an answer to the question “is it bigger than a breadbox?” that unintentionally misleads the guesser.
In game F, it’s possible to cheat! Maybe the answerer will claim to imagine an object but then answer the guesser’s questions arbitrarily and then imagine their thing to retroactively conform to their answers. Maybe they’ll even imagine something and then change the thing they’re imagining to conform with the answer they want to give rather than answer the question based on the thing they’ve been consistently imagining.
In game R, it’s also possible to cheat! Maybe the answerer will claim to pick a real object but then answer the guesser’s questions arbitrarily and then pick their real thing to retroactively conform to their answers. Maybe they’ll even pick something and then change the thing they’ve picked to conform with the answer they want to give rather than answer the question based on the thing they’ve consistently been using as a basis.
Both games expect that the answering player will use a reliable, consistent, predictable, understandable process when evaluating the answers to the questions. If the answering player cheats and uses a different method to answer the questions then the game doesn’t work. Since the choice of possible target objects in game R is limited to things that the answerer can see, their ability to cheat in this way is more tightly constrained than the answerer in game F. Solving a highly constrained problem frequently takes more effort than solving a loosely constrained problem, so we can assume that it generally takes more effort to cheat in game R than in game F. There is natural variation among humans, and some may perform a cost/benefit analysis and be more likely to cheat in low-effort-cheating situations. In game R it is extremely unlikely for the real object to spontaneously transform itself mid-game into a different real object. In game F, the likelihood of the imagined object transforming into a different imagined object is based on the likelihood that the answerer will cheat.
In game F, it’s possible for the answerer to give bad answers because they’re bad at imagining things. Maybe they think elephants are smaller than they really are, so they end up giving answers that are accurate with respect to their small imagined elephant but are inaccurate with respect to real elephants, which would unintentionally mislead the guesser. In game R, it’s possible for the answerer to give bad answers because they’re bad at perceiving things. Maybe they misjudge the distance to the object and believe that the object is smaller than it really is due to the size-distorting effects of perspective. It’s probably reasonable to guess that “bad imagination” problems are more likely among humans than “bad perception” problems.
Is it valuable to say that game R and game F are categorically different games, where game F is a game with fiction and game R is a game with real stuff? For example, the increased likelihood of cheating in game F and the higher odds of incorrect imagination may mean there are important “reliability” differences between the games. Or are game R and game F largely similar, and the real-vs-fictional divide between them is a nuance rather than a meaningful distinction? When discussing games, sometimes that real-vs-fictional distinction can be central and important, and sometimes it’s a useful proxy for discussing consequences of the distinction, but it can also be an obscuring distraction in some contexts (e.g. the most interesting distinctions between RPGs and chess is not always that chess uses real-world playing pieces).
A problem I sometimes see in “RPG Theory” discussions is that it’s easy to go overboard in believing that features that RPGs have are unique to RPGs. I’m going to blog about some “low level” RPG Theory stuff, pointing out a few RPG Theory ideas that are true not because RPGs are unique but because they’re just like other games.
First, all games require group assent to the system of play. There’s a Lumpley Principle of basketball, too. It says “System (including but not limited to ‘the rules’) is defined as the means by which the group agrees to basketball-relevant events during play.” There’s nothing magical about the ball going through the hoop in basketball. The ball going through the hoop only matters because the group agrees that the ball going through the hoop gives a team points. And points only matter because the group agrees that they’ll use the number of points to determine the winner. And winning only matters because the group agrees that it’s important to determine a winner of the game. It’s agreement all the way down, just like RPGs! But, just because basketball requires agreement “all the way down”, that doesn’t mean the game is a constant committee meeting where everyone decides on an event-by-event basis whether or not to consensus-agree to giving it significance. Just like RPGs, people agree to certain principles, rules, etc., which guide play and decision-making going forward. Much of this agreement happens before play begins by using shorthands like “Let’s play basketball”, where the people saying it assume a common understanding of what it means to play basketball which incorporates a bunch of stuff like the ball/hoop/points thing. That doesn’t mean the assumption of mutual understanding is always valid! Maybe not everybody has the exact same understanding of “basketball”, and they’ll only find out during play that they over-assumed, such as when one player claims to get three points for scoring a basket from a particular position on the court and everybody else says that they hadn’t been playing with the three point rule. Different understandings of “the system” among different participants can lead to breakdowns, just like in RPGs. This is a normal human thing that affects not just all games but all human activities!
Believing that the Lumpley Principle is something unique and special about RPGs can easily result in mistaking “no rules except explicit event-by-event group assent/rejection” as a goal or idealized form of play, especially since there’s a tradition in RPG communities of putting “rules-less freeform roleplaying” on a pedestal as some kind of aspirational form. But the Lumpley Principle isn’t about value judgments of what good games look like, it’s just talking about a feature of all functioning games. Saying that basketball requires group assent isn’t an endorsement of rules-less freeform basketball as an idealized form of play, and the Lumpley Principle isn’t endorsing explicit moment-by-moment negotiations as the way well-designed RPGs should function.
This is a new draft of my tabletop roleplaying game Getting There in Time which is about a lone Chronomaster and his human companions and their travels through space and time. This version has a few minor tweaks based on some playtesting of the procedures in the previous version, mostly in the adventure creation section.
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”.
I’m posting a new draft of my game Getting There in Time. It’s a game about a lone Chronomaster who travels through time and space with human companions (any resemblance to a certain popular BBC television program is entirely intentional). This version has some revisions to the character creation and adventure creation procedures.
I’m posting a new draft of my game Getting There in Time. It’s a game about a lone Chronomaster who travels through time and space with human companions (any resemblance to a certain popular BBC television program is entirely intentional). This revision expands the previous Game Chef version to be a little less terse so that it’s easier to understand how to play. The initial playtests have pointed to a few areas where tweaks may be warranted, but so far the game seems to be working pretty well.
I recently created a game for the Game Chef 2012 competition. One of the guidelines was that the games should be no longer than 3000 words. I had a lot of trouble with this constraint. Even after a lot of verbal tetris, elimination of explanatory text, and compacting ideas as much as I could, I still ended up at 3545 words. And I’m pretty sure that many of the things I did to shorten the game made it harder to understand. I admit that I can be a bit wordy, but I think the bias toward short games in the Story Games community is hurting the development of games. One of the common complaints is that too many games don’t actually tell you how to play but rely on word-of-mouth and cultural osmosis in order for people to learn the procedures, but using shorthands or procedures that seem simple on the page but require pre-existing mastery of the technique is something that designers turn to in order to keep their games short.
A desire for short games is entirely reasonable – reading takes time, and that problem is magnified in a design-contest setting where one person might need to read multiple games in a short time period. But limiting game length isn’t a design-neutral decision. For example, parlor narration (i.e. the mechanics tell you what to act out, but what you act out has no impact on future events) and pass-the-stick designs (i.e. the mechanics tell you who can talk when, and the speaker says whatever they want, but whether what is said has any impact on future events is an arbitrary decision made by later speakers) are easy procedures to explain in a concise way, so games which emphasize these features are far easier to implement within the constraints of a design competition rather than a game with a robust interaction between mechanics and fiction would be. Games with parlor narration and games that are functionally equivalent to pass-the-stick storytelling are not generally regarded as well-designed games in the Story Games community, but the expressed preference for short games in that community creates an incentive to design more of them.
It goes beyond contests, as well. When I tried to participate on forums to seek feedback for my game Final Hour of a Storied Age, I noticed that people frequently exhibited a “sticker shock” effect when they saw the page count (currently 90 digest-sized pages). People seem much more eager to engage with a half-page idea-dump forum post than a game which has been developed to the point where it addresses common stumbling blocks that prevent people from getting to the meat of the game. Every example I add, explanation I expand, or rule section I recap to cement understanding increases the page count. There’s a catch-22: an overly terse game can’t be understood, but a well-explained game won’t be engaged with. It seems to me that forum threads with endless noodling over initial ideas are far more popular than forum threads dealing with the deep issues involved in actually developing a game to completion because developed games are too long to engage with in the context of a forum discussion (which creates a perverse situation in which the people who are doing what we say we value don’t get the support or attention that they need to keep them going through the tough part of making a game, while armchair dabblers get lots of engagement and attention).
It’s entirely possible that I’m too wordy and too fond of explicit procedures for my games to be a good fit for my desired target audience, but I personally believe that the community would be better served by obsessing less about length and caring more about clarity and completeness. Many rules-light games are complex even if they’re not mechanically complex, and many of them achieve their brevity by relying on the “culture” of the RPG community to do the work that isn’t done explicitly in the text. Leveraging ideas like “good GMing” can make a game book shorter, but they can’t be used by someone operating without the assumed context. Obviously a game book can’t be completely context-free (language is context dependent – someone who speaks a different language than I do can’t understand anything I’ve written), but a book that works for the uninitiated would also work for the in-the-know. As I said earlier, a desire for short games is entirely understandable, but I think it also has negative consequences that aren’t as visible as the benefits.
One of the games I was assigned for the feedback round of Game Chef 2012 was Last Chance to Tell the Tale of Coyote and Medicine Man by Bryan Hansel. Structurally, the game is a pretty straightforward storytelling game, but it asks the players to use shadow-puppets as part of the “acting out the scene” aspect of play. Before I read the game I figured the puppets would be a silly gimmick tacked onto a purely verbal game. But there’s a mechanic in the game where the Coyote character sometimes impersonates and takes the form of a different character, and the game tells you to portray this by talking in a funny voice while using the other character’s puppet. In order to mentally process how this would work in play, I had to imagine using the puppets in the first place, even if my first inclination was to dismiss them as silly. While doing the mental processing on this “impersonating” mechanic, the idea of using shadow puppets was in my brain, building up neural connections, and with each neural connection it becomes more familiar and less foreign and rejectable. Building the impersonation mechanic on top of the shadow puppets helped cement the credibility of the shadow puppets as an important element of play, similar to how adding a new layer of building-blocks on top will often serve to “lock in” the previous layer. I don’t know if I’m completely sold on shadow-puppet-based gaming, but the design of this game brought me much closer than I ever thought I’d be.
This is the same psychological technique as the loaded questions in Dread character creation. If the questionnaire asks you “why did you get fired from your job?”, the entire time that you’re busy thinking up possible reasons to put forward as an answer, the idea “you got fired from your job” is able to fly in underneath your mental radar and take up residence in your brain. When B is dependent on A, consciously thinking about B makes A more unconsciously familiar.
The same process is at work in the “fictional causes” or “rightward pointing arrows” that Vincent Baker was talking about for a while. If the mechanics say “you get +2 for having the high ground” or “you have to roll the dice when you Go Aggro”, your brain gets busy focusing on whether or not the fiction matches the pattern and rarely even considers the possibility of outright rejecting a fictional contribution. By building something mechanical on top of the fiction it helps us accept the fiction as important and significant. The “translating to mechanics” part is valuable not because numbers, tokens, or dice are somehow intrinsically important, but because any time that B is dependent on A, focusing on B helps give A credibility, and a big chunk of what RPG design is about is convincing our brains to give credibility to something as unserious and ephemeral as the fiction being created by a group of friends around a table.
In fiction writing, new writers are usually told to avoid adverbs. The idea is that there are better ways to say “he moved quietly” that do a better job of connecting with the reader and painting a mental picture. The theory is that the English language has a lot of rich verbs, nouns, and adjectives which do a better job than the “bland verb + modifier” approach that you can lean on if you let yourself use adverbs. Now obviously not all advice is universal, and masters know when to break the rules, etc., etc., but as a basic guideline I think it’s pretty sound.
I’ve been trying to read as many of the Game Chef games from this years competition as possible, and I noticed a few games that featured something I feel is analogous to adverbs in fiction writing, which is where the designer just tells the players that it’s their responsibility to inject the theme into the game. A designer who wants a game to be spooky will say “describe it in a spooky way”. A designer who wants a dreamlike atmosphere will say “play out the scene like it’s in a dream”. A designer who wants to evoke a sense of childlike wonder will say “make this decision the way a child would”. Obviously it’s important to give the players guidance toward what sort of content is thematically appropriate, but that can’t be the only thing a game does to deliver its theme. The rules, procedures, and creative touchstones that the game itself provides need to directly push the game into thematically appropriate content. For example, Kira Scott’s space madness game Into the Void tells the GM to introduce horrifying possibly-hallucinatory images, but also tells them to base the images on character traits that have previously been moved “into the void” by the mechanics, metaphorically grounding the horrific imagery as relevant to the protagonists’ characterization, which is a strong horror-fiction technique. The game has the “make it nightmarish” advice in there, but it doesn’t just use advice. Telling someone your intended end-goal isn’t the same as telling them how to get there, and I think a game needs to tell you how to get there, not just where the game designer hopes you’ll end up.