Tabletop Game Prototyping, Playtesting, and Development

In yesterday’s video I discussed my process of prototyping, playtesting, and developing tabletop games. This is a deep-dive topic, so in addition to posting the video, today I’ll recap each of the different stages/categories in writing.

Introduction

• This is the heart of game design: The idea inception and brainstorming stages are fun, but they’re just the tip of the iceberg. Most of the work of game design is making prototypes, testing them, iterating, and repeating.
• The goal of playtesting and development is to make the game as fun, functional, intuitive, and balanced as possible.

Early Prototyping and Playtesting

• Rapid prototyping, minimum viable product, early expectations: For the first attempt, I try to design just enough of the game so I can play a little of it. That is, if it’s a game I hope to someday have 100 cards, I don’t design all 100 cards up front, as most likely the game will change significantly over time. Instead, maybe I’ll design 10-20 cards, just enough for the game to function.
• Tools: I use InDesign for file creation, an HP Laserjet 200 color printer, lots of spare tokens collected over the years, and a Cutterpillar to cut cards.
• Sometimes playtest by myself, particularly before I know the game is even functional. I get the most value from other human players at the table, but I can smooth out the big rough patches on my own before subjecting anyone else to an early prototype.

Local Playtesting

• I observe for moments of joy, frustration, or confusion. I also sometimes frame the playtest for what I’m looking for and where the game currently is.
• I prefer to play, not just observe. Various designers differ on this, but I learn the most from local playtests if I’m there at the table too.
• Allow edge cases but once you find them, steer away: It’s always great when a playtester finds a loophole or a broken element. But after they demonstrate it, it’s no longer useful to the playtest for them to repeatedly use the loophole to crush their opponents–if they can’t seem to stop doing it, I’ll physically remove the element from play.
• I take lots of notes (I’m always surprised when a designer doesn’t take notes during a playtest), then I set them aside for a day for a little separation before I sit down to process the playtest and implement changes.

Blind/Unguided Playtesting

• When a game is fun and functional, and I’m shifting the focus more to balance and intuitiveness, I start the blind playtest process.
• This is typically when I write the rulebook (though I may already have a patchwork outline in place). A major reason for blind playtesting is to improve the rulebook. Every question playtesters ask about the rules is important, even if the answer is in the rules–that’s an opportunity to highlight it better or say it more clearly.
• How to find playtesters and how to select them (full article): I use a quiz to find people who are good at share examples of what happened, why it happened, and how it made them feel. My best lead playtesters really do lead their playtests with some level of intuition, avoiding wasted playtests, and finishing on time. They enjoy writing, and they are willing to provide constructive criticism.
• I send an initial note to potential playtesters to see if they’re available, and for those who are, I send a detailed note with the playtest timeline (typically 3 sessions within 3 weeks), privacy, urgent questions, a request for them to fill out the quantitative survey after each session plus a report at the end, and compensation (we pay our playtesters in their choice of store credit or PayPal).
• Most of my session surveys ask for some consistent information, along with a few data points specific to the game: name, email, player count, length, winning/losing details, rating, bad, good, playtester names
• I wait until the wave is over before I look at any results; I’ve found that if I read each report as I receive it, I may start to process the information without the full picture. After I have all reports, I either process them by myself (if I’m the designer) or I process and summarize them for the designer if I’m working with someone else (they also see the data and the full reports). Then I iterate, playtest, and do it again!

Development

• What’s the difference between a playtester and a developer? Playtesters raise questions; developers propose answers.
• A big part of the development process is data analysis. Having a critical mass of playtests and playtest data is important, but unless you know how to look at that data–particularly for balancing–you’re not getting the full utility out of it. We have a data analyst look at our playtest data.

Beyond

• Limited digital testing only as a secondary option: I appreciate the option to playtest on Tabletopia–it’s great for rapid prototyping and remote playtesting. But there are so many elements and issue that can be obscured by digital playtesting but that are clearly apparent when you play with real components on the table.
• Sometimes designers ask playtesters to record their sessions on video. I tried this with Charterstone and didn’t find it particularly useful–you need playtesters to have a really good audio/visual setup for it to work.
• If you’re playtesting a campaign game, you’ll need to find playtesters to commit to many sessions of the same game (and significantly increase their compensation as a result).
• Ruts and research: Sometimes I get burned out during the development process, particularly if I’ve can’t seem to get past a certain barrier to make the game shine. Two things help me when this happens: One, I always try to work on multiple games, so if I need to take a break from one, I have another to focus on. Two, I research other related games, either by watching videos about them or playing them (even if I’ve already played them) to remember how they solve the problem I’m facing in my game.
• How many waves of playtesting are needed? When do I know the game is ready? It really depends on the game. At minimum, I put a game through 3 waves of blind playtesting, but it’s often more than that. I always ask playtesters to rate the game from 1-10, and if those scores are all 8, 9, and 10 and most of the feedback is just related to fine-tuning the game, that’s great. I pair that with my gut feeling from playing the game myself–part of it is logical, but part of it is me being really happy with where the game is in the process.

Here is the video detailing these different stages and steps:

What have you learned from the prototyping, playtesting, and development process?

***

Related videos/articles:

• 10 Steps to Design a Tabletop Game
• 4 Steps to Pitch Your Game to a Tabletop Publisher

If you gain value from the 100 articles Jamey publishes on this blog each year, please consider championing this content! You can also listen to posts like this in the audio version of the blog.

• Tweet