There’s currently no established consensus about how to develop a tabletop game once you’ve gotten past the initial “burst of inspiration” design stage. Most people more or less agree on the end goal, which is that they want a promising initial design revised until it’s “good enough” that it would be able to comfortably sit on a real or virtual shelf next to other published games (the issue of commercial vs. free publishing sometimes complicates that further). Most people intuitively expect that “playtesting” needs to be part of that process, and many people use “playtesting” as the blanket term to describe what they’re doing. Different models of how this development process should proceed will lead to different strategies and tactics for success. In this blog post I want to describe two different ways to look at it.
First, I’ll describe what I’ll call the “funnel” model. This model starts from the premise that a designer needs feedback about the gameplay in order to get to the game to a publishable state. And then the thought process goes: In order for the designer to get feedback, someone needs to hear about the game, get the playtest materials, read the materials, decide to play, organize a playtest, run that playtest, generate feedback from the playtest, send that feedback to the designer, and the designer uses the useful feedback to improve the game. Then you apply some insight and notice that there transitions between the steps: Not everyone in the world hears about the game. Not everyone who knows about it will get the materials. Not everyone who gets the materials will read them. Etc., etc. You can diagram it like this and notice that the “dropoff” at each level creates a funnel shape:
Since you’re trying to increase the bottom level (useful feedback) until it hits something analogous to a critical mass, the diagram suggests several strategies: Maybe you can widen the top of the funnel by talking about your game in lots of places. Maybe you can address the dropoff between “get the playtest materials” and “read the materials” by giving the playtest document a snazzy layout that makes it very readable. Maybe you can develop notoriety in another field, like blogging or podcasting, thereby expanding your audience. Maybe you can develop a great “elevator pitch” so that hearing about the game is very likely to lead people further down the path. Maybe you can develop a reputation for being smart or trustworthy in another medium (or with previous games) so people are likely to give you some benefit of the doubt to cover transitions where they might otherwise drop off.
Maybe you’ll also notice that the variables aren’t as independent as the diagram may make them seem, and you’ll figure out a way to simultaneously optimize some of the dropoffs. For example, perhaps you’ll conclude that one reason that people might hit the “read it but didn’t want to play” barrier is because they don’t want to play games in genres they dislike. You can avoid that problem by primarily communicating with fans of the game’s genre instead of a general audience: the top of the funnel is narrower, but you won’t have to deal with genre-rejection at the lower levels.
This funnel model has a lot going for it. It tells a story about how to succeed that sounds consistent, and it suggests tactics and strategies for how to make progress towards achieving that success, which is what you need from a development model. It also looks very similar to the way some people envision marketing a completed product, so solving the problems that this model tells you to solve may be helpful for also achieving success with the published game. It also has some downsides which I’ll get to later.
A different model starts from the premise that a well-designed game product will generate enjoyable play, people who experience enjoyable play will want to tell their friends about it, some of those friends will want to also have that enjoyable experience and seek out the game product, they’ll enjoy playing it, and thus you have a self-reinforcing word-of-mouth marketing strategy. Step one in that strategy is having a well-designed game. Few people are lucky enough that all of their ideas are perfect in their initial form, so in order to get a well-designed game you need to develop it from your initial conception into something that works. In order to do that you need playtests to generate data about what is or isn’t working, and you use that data in a successive-refinement game design/development and playtesting cycle until you’ve got a game that reliably generates a good experience. Once you have a game that does something good you can build the rest of your marketing strategy on top of that strong foundation. Let’s call this the “organic growth” strategy.
In this model, instead of assuming that playtesting is something that “happens naturally” to some variable percentage of the population when exposed to an in-development game, it treats it as a task which requires work, and it leaves it to the implementer to develop the strategies or tactics to get that work to happen (just like the previous model left it to the implementer to figure out how to get people to read the materials once they have them, or figure out how to get them to play the game once the materials are read). One “strategy” for getting playtesting to happen might be to have a cadre of supportive friends and acquaintances who will playtest your stuff for you because they like you as a person. Another might be to have employees who playtest as part of their job. Another might be to form a system of mutualism where designers participate in playtests of each others’ games for mutual benefit. (This last one is analogous to the way many writers develop novels: They have a writers’ group who read and give reactions to each others’ drafts, even if they might not be the exact target market of the novel). Finding effective strategies or tactics for this part of the model is hard!
But there are hard parts with the funnel model, too. For example, if you’re relying on “natural” playtesting you have to deal with the fact that many people don’t know how to playtest well (maybe they go into “how can I break this game?” mode when what you needed to know was “is this game fun when played normally?” and playing with someone who’s trying to break the game can contribute anti-fun for the other players). You also have to deal with the tricky process of separating useful feedback from distractions, or figuring out the alchemy that transforms feedback into progress on the game design (there’s an old chestnut about how people giving you feedback are almost always right about there being a problem but almost always wrong about what the solution is, but this is complicated by the fact that many people put on their game designer hats while playtesting and see “problems” that are hard to distinguish from “you haven’t implemented my preferred solution”). In fact, these sorts of difficulties have convinced some people who use the funnel model that playtesting itself is a largely useless process, except as a testbed for exploring a marketing strategy (this stance, naturally, is hard for the people using the organic growth model to wrap their heads around, because for them abandoning playtesting would mean bailing out before step one). Another issue with the funnel model is that discovering a success strategy at one level may provide constraints on the rest of the process. For example, a subsystem with a grabby gimmick can help convince people to play a game once they’ve read it, but if the success path of the game becomes contingent on that subsystem then any further game revisions will necessarily involve changing the rest of the game to work with that subsystem rather than the other way around.
In the independent tabletop RPG design communities that I’m aware of, most people seem to be operating from the assumptions of the funnel model. Personally I’m not sure that’s wise, since some of the level transitions seem to encourage strategies that can easily turn into wasteful zero-sum arms races (for example, if lots of people spam “please playtest my game!” messages on a forum then they’re competing with each other and also wearing out the patience of the forum’s readers). The big downside of the organic growth model is that the “get playtesting to happen” process looks to many people a lot like “and here a miracle occurs” in the current environment.
Let’s imagine a chess game. Two players who both know the rules sit on either side of a board with the appropriate pieces on it. To play, they’ll use their knowledge of how the pieces move, their mutual knowledge of the rules and victory conditions, the current position of each of the pieces on the board, and a mutually remembered bit of information about whose turn it is to make the next move. Obviously there are a few things that could mess this game up. A freak windstorm, for example, could blow all the pieces off the board. Or maybe a loud noise will distract the players for a moment and by the time they’re ready to return to the game their memory of whose turn it is won’t match because one of them (which one!?) got confused during the interruption. Or maybe one of them will do something that uses one of the more exotic rules, like en passant, and they’ll discover that their mutual understanding of the rules of chess isn’t as mutual as they initially thought.
Now let’s imagine that one of these chess players goes on an expedition to Antarctica but still wants to play chess with his cold-averse friend. They still can! What they decide to do is set up two different chess boards, one in Antarctica and one back home, and communicate their moves back and forth through whatever form of long-distance communication they can. When Antarctica-guy physically picks up a pawn on his chessboard and moves it to a different space he just tells his friend which pawn he moved where. The at-home friend picks up the corresponding pawn on his chessboard and moves it to the corresponding place to represent his friend’s move. All the rest of the stuff is the same: the important thing about chess isn’t that there’s a single physical board between the players, it’s that there’s an agreed-upon representation of the current game-state between the players. Having a single physical board certainly makes that easier and more convenient, but the important thing about the game isn’t how it’s physically implemented, it’s how it looks to the players. Each of the players can look at “the” chessboard and make their moves based on the current game-state. It doesn’t matter if “the” chessboard is a convenient fiction for two different physical chessboards that are being kept in synch by an extra process that isn’t normally necessary.
But what if these friends realize that they don’t really like chess that much and want to play something a little more action-oriented? They decide to switch to a first-person-shooter video game played over the net. Conceptually this isn’t too different from the long-distance chess game, but there are a few details that contribute some nuance. One important difference between chess and an FPS is that the turn-based nature of chess provides an easy interface-point for long-latency communications. If it takes much longer for one player’s move to get communicated it just looks to the other player like a really long turn. Since FPSs need to maintain a smooth, continuous-action flow of play they need to have the effect of the moves represented immediately. When the Antarctic player presses his “shoot” button he’d better see his character start shooting right now! The two computers are both running instances of the game, but the other guy’s doesn’t realize the first started shooting until a message dispatched over the network gets to his computer. But maybe at the same time that the Antarctica guy decided to shoot his gun, his target pressed his “run” button and started moving. In Antarctica, the player thinks he’s shooting (right now!) at a stationary target, but at his friend’s house he thinks he’s moving (right now!) and not being shot at. From the Antarctica perspective the shot should hit (assuming the aim is good) and the target should be wounded. From the other perspective he shouldn’t be wounded at all: nobody was shooting, and even if they were his character wasn’t at the place that the bullets would hit! The two simulations aren’t perfectly consistent. But they don’t have to be! As long as they’re close enough, the players won’t notice. As a human player, the warm guy doesn’t know with perfect certainty where the Antarctica shot was aimed, so if the game has an under-the-hood mechanism that gives “hit detection” precedence to the shooter’s POV then the Antarctica computer can tell the other one not only that a shot was fired but that it hit. The at-home computer can play its “gunshot” sound effect, display the “shooting” animation for the other character, reduces the hit points of the target, and most of the time it will seem perfectly normal to the at-home player that the other character shot and hit him at his current location. The important thing to notice is that there doesn’t need to be a single authoritative game-state in a single place in order for both players to feel like they’re playing the same game with the same state. As long as it looks close enough they won’t realize that their two computers are not exactly on the same page at every instant.
As players they maintain the convenient fiction that they are in the same world because the “game” involves making decisions as if you were, just like it makes more sense to interpret what they see on their screens as a window into a 3D world rather than a bunch of pixels on a flat display. Just like it’s not useful when playing long-distance chess for them to dwell on the fact that they don’t have a single physical board between them, it’s not useful for them to dwell on the potential artifacts of network gaming (unless the distortions become so extreme that they overwhelm the suspension of disbelief and they have to give up because there’s “too much lag” over their network). By buying into the illusion of consistency between the somewhat-independent computers they can play this type of game together.
Now let’s imagine that the adventurous friend returns from Antarctica and the two of them get together to play another kind of game they enjoy, a tabletop RPG. Here they also need to maintain a sufficiently-synchronized game-state in order to play. To do so, they buy into the convenient illusion that there’s a single “fiction” or “Shared Imagined Space” between them. They probably have some concrete common physical touchstones like dice or character sheets as part of the game, but a big part of play involves their brains independently keeping track of the current game-state of imaginary people doing imaginary things, and they send messages back and forth to keep each other more-or-less in-synch (using high-tech “talking” technology). Since their brains aren’t as simple as chessboards they can’t rely on being perfectly in-synch at all times, so their game needs to be constructed in a way that encourages and eases synchronization on important points. For example, if their game has a mechanic which gives a “high ground” advantage then the players will be primed to pay special attention to character altitudes relative to each other in “the” imaginary world. Maybe their mental picture of the characters won’t agree on points like whether or not they have mustaches, but they are likely to agree on who is higher than who if they both believe that is important to the game.
Being sufficiently synchronized to game is the foundation for a functioning RPG (and the astute reader will notice how weaselly a word “sufficiently” is). Many RPG techniques and design elements serve to maintain that synchronization. For example, the “fictional trigger” in an Apocalypse World move can serve like the snap-to-grid functionality of a computer painting program to snap the “fuzzy” mental images of the different players around easily-communicated concrete templates. If my character seems close to “Going Aggro” on somebody I am pulled toward embodying that in my roleplaying because I know that the other players are watching for whether characters are Going Aggro and will understand what I’m thinking better and be more easily synchronized to what I’m imagining when they can use that concrete and mutually-understood pattern as a touchstone for how the scene should be playing out in their imaginations. Agreeing with the other players that the “Go Aggro” move should be invoked and starting the corresponding mechanical procedure gives us an explicit way to acknowledge synch-points without drawing unpleasant attention to our efforts to keep synchronized.
I’m not an expert on Topology, but one of the ways I think about the games I like is that they make use of the idea-space inside the human brain as a gameable space. Now, by that I don’t mean that you can imagine places that aren’t real and think up activities people might engage in in places like that. What I mean is that the way we think actually provides “dimensions” along which you can design meaningful interactions in a game. From my reading of what contemporary psychology and cognitive science tell us, we’re capable of perceiving the appropriateness or congruence of matches between ideas. You know the confident “that feels right!” feeling you get when you figure out what the answer to a riddle must be, or when you come up with the perfectly apt humorous remark? Or the “that’s not right” feeling you get when Hollywood miscasts a part in a movie adaptation of a story you know? That’s what it subjectively feels like to have different levels of connection between ideas, which is apparently how the intuitive side of our cognition works. Even though we don’t have scientific units for it, we can get a feel for how “librarian-y” someone is by intuitively comparing them against the idea of “librarian” we have in our brains. We can even get a feel for how weaselly someone is.
This is the entire basis of the game Apples to Apples. In it, one player puts an “adjective” card on the table (for example, “Hot and Sticky”). Then all the other players consult their hand of “noun” cards and put forward the one they think the initial player will select as the “best match” (for example, “The Equator”, “Cinnamon Buns”, “The Sports Illustrated Swimsuit Issue”). Some people have a hard time grasping that there is no single way that people are required to make that “best match” comparison. It’s not always “the most similar” or “the most opposite”. Sometimes it’s the ill-defined “funniest”, but even inveterate jokesters will sometimes feel compelled to pick a straightforward match if it’s dead-on. The way it works is that the player compares the “adjective” they put forward to the various options and picks the one that feels like the “best match”. We don’t need to put a name to a comparison to feel how strong it is. Strictly speaking Apples to Apples tends to be about emphasizing the minor variations between people rather than the commonality because it asks the player to pick a “best” match on each round (thus the way to win, if you care about that, is to “play the player” and put forward cards with matches that are likely to resonate especially strongly), but it illustrates the point that there are dimensions of play that games can lean beyond simple factors like tallest/short, fast/slow, near/far, big/small, etc. Personally I’m not a huge fan of the gameplay in Apples to Apples (my sense of humor tends to run a little more cerebral and surrealistic than average so my joke answers nearly always lose out to the more obvious jokes) but since it uses this abstraction as the central element of play it’s a useful example.
While they don’t always foreground it the way Apples to Apples does, Roleplaying games make heavy use of this concept to inform and constrain play. The old-school “puzzle solving realism” style of play, for example, leans heavily on the ability of humans to mutually imagine “that’s what would happen!” to explore the consequences of poking things with ten-foot poles or pouring acid on them. The Burning Wheel family of games orients players to judge characters by looking through the lens of written character Beliefs, rewarding players for acting along (or dramatically against) the line of those Beliefs. Games with oracle mechanics like Ganakagok use abstract concepts to guide play (“figure out the most ‘Woman of Storms’ way to conclude this scene”). Even something as fuzzy as “what’s the most dramatically appropriate (or dramatically ironic) thing?” or the dreaded “what’s best for The Story?” can be used in a game context. Stories and storytelling have a huge role in human culture and the way that human minds work, so it shouldn’t be surprising that we have a lot of intuitions related to stories and imagination. These intuitions can be built into the “space” of play in these games in the same way that features of human locomotion are as important dimension of play in sports as ball-physics and field geometry.
When analyzing systems that operate on information it’s often valuable to consider how that information matters to the control flow of the system, and games definitely fall into this category of system. One big distinction between types of information is discrete vs. continuous, or digital vs. analog. A continuous “variable” can be any value within a range: think of something like temperature, distance, or time. A discrete variable can only be in one of several mutually exclusive states: on/off, in-bounds/out-of-bounds, too-big/too-small/just-right, etc. Continuous variables are really useful because that’s how almost everything in the actual world we live in works. Discrete variables are really useful because it’s possible to build simple procedures around them: if A do X, but if B do Y.
As a simple but nontrivial example think of a thermostat. It has three continuous inputs: the current temperature, the low set-point and the high set-point. The thermostat is in charge of the heater and knows and controls whether it’s currently on or off. Internally it doesn’t really do anything with the temperature directly, it uses a comparison to create a discrete variable from two of it’s continuous ones: “is it currently hotter than the high set-point?” and “is it currently colder than the low set-point?”. Operating on these discrete concepts lets it make a decision that’s simple enough for it to apply to the binary world of “should the heater be burning right now?”: if it’s hotter than the high set-point and the heater is on, turn it off, but if it’s colder than the low set-point and the heater is off, turn it on.
Lots of games have things like this, too. In soccer, the ball is somewhere in the three-dimensional space where the game is being played, and this feeds into discrete categorical concepts like “is the ball currently in-bounds?” that are used by the game procedures to control the flow of play. In baseball, whether a pitch counts as a “ball” or “strike” corresponds to where it travels through the strike-zone of the batter. In the UFC mixed-martial-arts organization some moves are legal and others, such as punches to the back of the opponent’s head, are illegal. When you look at these distinctions from the digital side of the analog/digital divide there are obvious and categorical differences between them: the difference between an in-bounds ball and an out-of-bounds ball are night and day! From the analog side it can be fuzzier: what if the ball is right on the edge of the line? What about a pitch that’s just grazing the edge of the strike-zone? Heads are kind of round, so the distinction between side and back is not always obvious, right?
In games, translating from the continuous/analog domain to the discrete/digital domain of the rules and procedures of the game usually involves human interpretation or judgment. Oftentimes games will give one participant, such as a referee, a special privilege of having authoritative judgments or interpretations, but even in games like that all of the participants need to understand how those interpretations and judgments will be made and make their own. Soccer players don’t want to play on a field where the lines are invisible to everybody but the refs, they need to be able to predict the rules-consequences of their interactions with the ball in order to play. They may not be able to exactly predict how the ref will make the call in edge-cases, but they can reasonably expect that their own interpretation will be similar to the “official” interpretation, so they can use their own interpretation as a good proxy for evaluating what kind of move they want to make in the game. (And plenty of casual sports are played without an officially designated ref, the players just use some other process, sometimes ad hoc, to resolve edge-cases if there’s no widespread consensus interpretation). Similarly, the intention of the “no strikes to the back of the head” rule in the UFC isn’t to give penalty points to inaccurate punchers but to discourage fighters from engaging in behavior that the UFC has decided is too dangerous: the ref makes the authoritative call in the octagon, but the most important impact of the rule is on the fighter when he decides whether or not to throw a punch based on where he thinks his opponent’s head will be when the punch lands.
Many RPG rules operate on things happening in the analog world of “the fiction” so they have lots of these interpretation elements cooked into them, so looking at the nuances of these interpretative processes is obviously very important in RPG Theory. But we shouldn’t mistake the importance of this concept to RPGs for the idea that interpreting or translating from continuous to discrete concepts is something unique to RPGs. The interplay between the interpretations and judgments of different participants in an RPG is an interesting and important topic if you’re trying to understand RPGs. The interplay between the interpretations and judgments of different participants in a pitcher/batter interaction is an interesting and important topic if you’re trying to understand that part of a baseball game.
(Also, I’ve tried to use simple examples in this blog post in order to write with clarity, not to deny the existence of subtlety. My claim here is that both “is that really Go Aggro?” and “is the ball really in-bounds?” are both examples of interpretation that feed into rules. It can be easy to get distracted by the simple one-dimensionality of the in-bounds/out-of-bounds thing because we can easily imagine constructing a simple mechanical or electronic device that we could rely on for official in-bounds/out-of-bounds rulings while the only thing currently known that can do the Go Aggro thing is a human brain. That’s an important difference worth thinking and talking about! But it’s also worth realizing that “how hard would it be to build a robot referee?” is a different question from “how are the players interacting with this game?”.)
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.