Playtesting Thoughts

Posted by Thorin Tabor on Oct. 18, 2018, 6 a.m.

Welcome to the latest post in our design series, wherein I talk about the design of one of our upcoming games. The goal of these posts is to have a frank discussion on game design, both what works and what doesn't.

Recently I've been running quite a few internal playtests, and have been thinking a lot about our playtesting methodology. Today I want to talk a bit about it, both in how it applies to Saga Machine and to We're All Going to Die Here, our upcoming comedy horror card game.

Playtesting Layers

I like to think of most games as consisting of multiple layers of mechanics, each built on top of another. The mechanical systems in each layer are dependent on all of the layers they are build on top of. Change the mechanic of one of the base layers and you are likely to see the effects of this change ripple throughout the upper layers.

For example, Monopoly consists of a basic mechanic for moving around the game board. This is its lowermost layer. On top of this it builds a system for paying rent and buying properties. This is the next highest layer. On top of that is a layer consisting of the systems for developing properties, as well as trading and auctioning them.

Note how each of these systems is dependent on the layers beneath it. Also note how changing one of the lower layers will have ripping effects throughout the upper systems. For example, how would the game be different if instead of rolling dice to determine movement, each player simply picked what space they land on? Think about it. That would completely change (and break) all of the other systems in the game, until they are likewise changed somehow to accommodate.

So how does this apply to playtesting? I like to think of our playtesting methodology as starting from the bottom up. I aim to identify the game's layers, and begin by paying attention to the game's lowermost layer.

Ideally, you need to make sure that this layer is solid before moving on to playtest the next higher layer, because if it's not, and you change it, you're going to need to tweak systems to accommodate and playtest all of the layers all over again.

Placeholders

The basic advice of "playtest your system from the bottom up" makes sense, but it is also kind of pie in the sky. The truth is that sometimes you need to have the upper layers to have a playtestable game. For example, imagine playtesting Monopoly with only the dice movement mechanic and no money. That would be a very incomplete game!

In this case, I like to use what I think of as a placeholder system. That is, if I know I will need a particular upper level system, and I'm still focusing on playtesting a lower level, I will just make up something for that upper system and throw it in. It doesn't need to be particularly thought through; it's a placeholder. It's simply there to fill the void that will be occupied by the upper level system, until the real system can be designed.

That said, when making up a placeholder system, my advice is: Keep it simple. Don't do anything too novel. If you're building off an existing game system, do things the way the system has done them before. Remember, the role of a placeholder system is simply to fill a void. You don't want it to distract from the lower level system, which is what you're really trying to playtest at that point.

One potential problem of this method is that playtesters may not know which systems are being examined in the playtest and which systems are just placeholders. My best practice is to try to include notes on this in the playtest rules (for example, using the comments feature in Google Docs), but the truth is that when pressed for time, this often gets dropped. It's something I need to get better at.

Example: We're All Going to Die Here

The lowermost layer of We're All Going to Die Here is its pools of cliché and spotlight points, and how each round the victim with the highest cliché is killed. On top of this is a layer consisting of the various trouble cards and how players play those cards on their turns. On top of this a layer consisting of the different monster and victim cards, which vary the strategy and help give the game replayability.

Example: Saga Machine

The way we develop our Saga Machine games benefits from this method of playtesting. Because these games rely on a shared basic system, by now the lowermost layers are quite solid and well-playtested. On top of these base layers we then build custom systems to fit the themes and genre of each specific game.

In Saga Machine the action and consequence systems form its lowermost layer. On top of this is a layer consisting of the core supporting systems, such as skills and extended actions. On top of this are the game-specific systems, such as the systems for combat, magic, chases, etc.

Conclusion

That's it for my thoughts on playtesting methodologies. I hope it's been useful to anyone interested in game design or who might be interested in the games we have in the works.

You may have noticed that this post was made two weeks after the last one. For the time being, the design series is going to be once every few weeks instead of weekly. That will buy me some extra time to work on the design of these games. So tune in a couple weeks from now for the next post in the design series!

Sign up to be notified when the games are available!

Email Address

---

Share Post

---