I hope we get to play a game together. Playing together is the foundation of every close relationship I have — everyone I love in my life, I can find some way to play with them. There are so many people I know and value solely because we took a few hours to play together, and I have friendships built upon a game played years earlier that will last for decades to come. Even people I dislike — if we have played together, we have found common ground. Part of the reason I design games is for the liberation of playing with others.

The difference between writing prose and designing games, for me, is one of loneliness. Prose is a solitary endeavor, one that I can only escape by constantly contriving new reasons to share with people. Game design, at its very core, is an activity done with others. “Can you read my writing?” Ugh! It comes out of my mouth so shamefully. But “can we play a game together?” Now that is a promise for an exciting time, a chance to dance together, a way in which we get to be in community.

A game only exists once people are playing it, and I would sometimes argue that the function of game design is recording a game which has already been played — even if it was only in your mind. While some are critical of playtesting, I delight in it. What better chance do I get to play the game with other people, and have a unique experience I wouldn’t get to have anywhere else? Is there a more beautiful opportunity to sit present with a game as a living, breathing thing, and change it to suit the needs of the table? I encourage designers to playtest, not because it improves the quality of the final project (although, if used well, it’s an invaluable tool) but because I find it to be a ton of fun!

I have an approach to playtesting, one that I’ve used since I was 13, that managed to feel entirely unremarkable until my friend Eclipse posted a short thread commenting on this method and drew my attention to its value and role, and approach that I think of as Community Playtesting.


In this article I want to explain Community Playtesting, talk through how I use it in practice as a playtesting method, give some advice on how best to implement it, and how to avoid some common pitfalls.

What is Community Playtesting?

Gold is spotted in the river. Prospectors arrive with shine in their eyes. Houses spring up around the creek. Shopkeeps rush to move their wares. Everyone knows in two months the whole place will be a ghost town, but for now it’s alive. Community Playtesting is a very similar project. It’s a temporary community space built exclusively around playtesting and getting feedback on a specific game. This community space is your Boom Town, a flurry of activity and excitement which will also eventually die down.

There are many ways to build a Boom Town in the digital age. In 2024, my advice would be a Discord server, but you could use a Facebook group, a forum, a subreddit, or even a strange camping expedition. The medium of choice should be based on the game designer’s comfort and familiarity with the medium, and the size of the Boom Town in question. If your Boom Town is just your regular tabletop team, maybe a group chat is enough.

It’s important to keep the Boom Town both temporary and focused. This is not a space for other games and their design unless it directly relates to the game you’re working on. If building a Discord server, avoid off-topic channels, vent channels, and meme channels. This is not the nexus of a broader community, a place to seek emotional support, or a game design jamboree. This is a space with a function, and when the function is done the space may be abandoned.

The Boom Town is your community for your game. Invite your friends and play buddies (but be understanding if they’re not always around!), invite your fans, invite people whose work speaks to you. You should be able to trust everyone in the space to have your best interests at heart and the desire to help you make the game the best it can be. They’re people you want to play with, who are enthused about your project, and who will engage with everything you make with good faith, compassion, and excitement.

The Boom Town is a space for both playtesting and iteration. Run games often, empower the community to run their own games, and encourage people to try out experimental ideas. Take advantage of having a room full of people who know the game almost as well as you do to bounce ideas around and work through tricky explanations. Run playstorming sessions, where you hop on a voice call with some of the experienced playtesters and tackle sections of the game you haven’t even made rules for yet, just to see how you improvise new mechanics and what you end up inventing.

At its best, a Boom Town can serve as a powerful engine for iterating on ideas within the game, refining core mechanics, and exploring new space for the game to function. It’s an early audience of people who will challenge your notion of what the game is supposed to be, and through this process refine it down into its most important essentials.

My History With Community Playtesting

Long before I ever even touched a TTRPG, I was a live-action roleplay (LARP) designer. By the time I was 14 I was running LARPs for almost a hundred people at a time, with a full staff and production budget with the Wayfinder Experience. These LARPs were all oneshots, and while they had mechanical overlap, I never had the capacity to playtest them — we’d run them once, and toss them aside, taking any good ideas on to the next one. The absence of playtesting meant I needed to get beta reading and peer feedback, but without actually playing it. How?

Those early Google Docs are a tangled mess of notes from upwards of twenty different people. Before comments were added as a feature to Google Docs, every friend would pick a different color to represent their text, and they’d have long meandering conversations beneath each paragraph of game text, debating its effectiveness. As I went into highschool, these rainbow exchanges were replaced with long comment threads and group chats with the staff working the event.

This was, notably, the first time I would have people brutally push back on my work. No one is harsher about a game mechanic than a production staff who’s been working for four weeks straight and is fueled by caffeine, nicotine, and bugspray. There’s a reason Grubby is my business partner, and why I ask her to leave comments all over my games — having a beautiful and intelligent woman be a dick to me is the only way I get things done.
The constant bustle around a game is the core of my creative process. I need people all around me giving me feedback, so I can sort through the storm and pull out what I can use. When I moved into tabletop games, I carried on this same process with playtesters, benefitting from the fact that I could spend hundreds of hours playing the game before I had to call it finished. I approach this in two parts, based on the size and intricacy of the game. Many of my smaller games undergo their Community Playtesting through the Possum Creek Patreon. This works for me, even though it’s not that Boom Town structure. When I’m working on these smaller games, I’ll be constantly sending ideas to my friends privately, or talking about stuff in a channel in the Creekside Community Center, but it won’t be a Boom Town. It doesn’t need that level of involvement.

My current passion project, an expansive simulationist wizardgame called The Seven-Part Pact, does. It’s a game that needs playtesters who have a lot of experience with the game’s structure so I can watch for pressure points and explore weak areas. It’s a large game which will take me months or years to finish, and so the Boom Town is going to be useful in one form or another for a while. And it’s weird, weird enough that if I threw it straight into the hungry mouths of social media without lots and lots of experimentation, it would be ripped to shreds.
So I built a Boom Town, out of certain specific friends and people interested in the Patreon server. It’s a pretty big community (more than 80 people as of this article) and it grows in drips and drabbles, as I let anyone running a playtest for me invite their friends to the server. It has the following channels in it:

• A #general channel, for broad discussion of the game.
• A #questions channel, when people are unsure how a specific rule works.
• A #feedback channel, where people can post their play experiences.
• A channel for organizing playtests. (In the case of the Seven-Part Pact, I’ve split it up between real-life playtesting, online voice playtesting, and play-by-post correspondence)
• Some game-specific channels (such as one for spell ideas and discussions around specific Wizards), which would obviously be different for different games.
• Three “read-only” channels for my own use, a #to-do channel where I post changes I plan on making, a #resources channel that includes the latest copy of the game for playtesting use, and an #updates channel where I post changes made to the documents.

I would also encourage having a code of conduct channel, where you explain the goals of the server (as presented earlier) and set some baselines regarding community behavior. I chose not to include this, as the server is a pop-up extension of the Creekside Community Center, so I’m using the same code of conduct as the Patreon Discord.

Every designer is going to need their own structure, and everyone can design their space however they want. This is just what I’ve found works for the Seven-Part Pact, even if I would structure it differently for future playtesting.

An Aside On Playtesting

Some designers don’t like playtesting, or say they don’t need to playtest. That’s true, in that nothing is required and life is just one big roller coaster. Smaller games, free games, experiments, lyric games — none of them need playtesting the way an enormous traddish tome might. That said; I can tell when a game hasn’t been playtested. Sometimes I’ll sit down and play a game, encounter something pretty obvious that’s against the designer’s intent, and I’ll recognize that the game would probably be a lot more interesting if someone had given it some polish, or if the designer had spotted this before they sold it to me for $20. That’s a very practical reason to playtest; it lets you predict the kinds of conversations held about the game, and anticipate moments like this. I think there’s another reason to playtest your game: ideally, your game is fun for you to play. If it’s not fun for you, who is it fun for, and would they be down to playtest it instead?

Advice for Community Playtesting

Community Management Is A Skill

I feel comfortable operating these Community Playtesting spaces because I’m familiar with how communities function and have more than a decade of community management experience. If this is unfamiliar territory for you, starting a community from scratch is going to take time and effort. People will be reluctant to talk at first, and there will be clashes as social norms are established. You have a few ways around this!

• Push discussion yourself. Keep posting updates, even if you’re not getting many replies. Run games and pull people in, then prompt text conversations after the game with specific playtesting questions. Post memes related to the game. You can’t promise everyone will engage when the game isn’t being played, but even if they’re not, try to get something valuable out of the space.
• Draw on another community. If the majority of people in your Boom Town are from another community, use those community norms as an explicit baseline. Treat the Boom Town as an extension of this other space, and new members will acclimate to the already-established community norms. People who know each other, or get to know each other through games, can bring together the creative focus to keep the space running.

There will still be conflicts and disagreements. Ideally, if the space is focused as a work environment, instead of a social hangout space, you can keep those to a minimum. Remind people of the goals of the space, and don’t let social drama overtake the server. We’re here to make art better! If your community members want to have stupid crushes, tell them to take that energy to the DMs.

You are the Designer, Not Them

When working in a Community Playtesting space, it’s easy to get overwhelmed by the sheer torrent of feedback and responses you may get. There will be people who are invested in your game, and they’ll have strong advice on how it should be. They’ll mourn when their darling little game mechanics are cut, and it might be tempting to give in and focus everything on making the playtesters satisfied.

You are the designer, not them. Say “no” to every idea unless you want to keep it. Kill their darlings and fight like hell to keep yours. Community Playtesting succeeds when its a rising tide that lifts you up and clarifies your process. It fails when it’s a raging storm that drowns you in a torrent of opinions. Ultimately, while they’re doing you a favor by playing your game, and it’s beautiful to see their excitement, you owe them nothing. Focus on making the game the best it can be, and use the community as a way to refine the game, not dictate it.

Questions, Not Judgment

A lot of useful Community Playtesting comes out of normal playtesting advice, but is amplified thanks to the number of people in the space. When presenting some new and fragile part of the game, create a culture around questioning and inquiring, rather than assuming and judging. If someone’s looking at a text for the first time, they may have a lot of questions about how it works, but they can’t know how it feels until they play.

A tool you can use to help mediate this conversation is to establish a particular set of social norms around providing feedback. I prefer using my own modified form of Liz Lerman’s Critical Response Process for feedback.
Similarly…

Feelings Are Valid, Advice Isn’t

This has been talked to death in other articles about playtesting, UX design, and beta reading, so I’ll keep it brief here. If a playtester has an emotional experience during the game, the feelings they had are accurate and valid. But the playtester’s advice on what to do with their feelings very well might not be. If a playtester is frustrated by how weak their class’s ability is, the answer isn’t necessarily to buff their skill, but instead perhaps to nerf another class, weaken the enemies, or change a mechanic. A game often feels like an intricate machine, and while someone can correctly spot smoke, they’re often wrong about what’s causing that smoke, or even if the smoke is bad.

Don’t Get Stuck In A Bubble

Eventually there will come a time when you’ve playtested the game to hell and back within your community. It’s time to take it outside and see how it handles the real world. Run the game with people who have never played before. Silently watch someone else run it. Hand the game to a group of people and watch them try to figure out what to do with it. The Boom Town is useful for creating high-skill high-involvement players, but it doesn’t do well at judging first impressions or new player instincts. Once the game is ready, take it out for a spin, and bring these observations back to the community, to see how the game can stand on its own.

Winding Down

The Boom Town is a transient space; you don’t want to get stuck moderating a community forever. Once the game is done (probably as you’re posting it on itch.io or running a crowdfunder for it), start winding down the Boom Town. Maybe do one or two big final sessions so people can feel satisfied. Encourage people to swap contact info and get in touch on other servers. If there’s people that are especially excited about your game, encourage them to make separate fan spaces. Provide some way for all of them to give you their names, so you can credit them in your final game.

There comes a time when you don’t need to playtest the game anymore, and you can shut the Boom Town down…until the next game.