Playtesting, as most designers will tell you, is the bulk of what we do. It’s tough, time consuming, and needs to be done at every step of the process. I’m about to tell you three different steps in the process to playtest, and what makes them different.

Proof of Concept

This is pretty self-explanatory. You just came up with a game idea or something, and you just want to test it out. Your game is currently the minimum viable prototype, the smallest version of the game you can make. Maybe it’s even just enough to play a single turn. Often the game pieces are very rough and ahndmade.

When playing a game in this state, there’s some important things to consider. The main use of this type of playtest is to understand if the game is even possible. You don’t need to make any assumptions, just ask what the designer wants. In fact they will probably tell you a lot of things while you’re playing. They might even make stuff up as it’s going. Scoring and skill is going to be basically irrelevant. This is the state of the game where the existence of the playtester is most minor. They’re there just to follow instructions and notice if something breaks or not through normal play.

Play Testing

After the proof of concept, a lot of work usually needs to be done before more playtesting happens. Maybe this version looks a lot nicer, but not always. But pretty universally the biggest change is that there’s more of everything.

This is the most “normal” type of playtesting. You’re basically just playing the game like you would a normal board game. There’s a chance the game is more broken than it appears and you may have to ask questions, but the assumption is that those questions would be something minor that would be better explained in the rulebook. What feedback is needed changes a lot, but the feedback is super important in this step. Whether it was fun or functional or any number of other things could be important to the designer. Ask what they need, or hope that they tell you.

Breaking

The last step, and one some games don’t do or don’t even need is the breaking step. In this style of playtesting, you’re supposed to try and break the game. Do a strategy that seems terrible. Run out of resources that would be nearly impossible to run out of and see what happens to the game. Feedback is a little strange in this version, because it should be pretty obvious. If you do end up breaking the game, it’s possible the designer might ask you whether the game broke “enough” that a player would dislike it happening, or it would make the game worse if it weren’t fixed. This type of playtesting is often most necessary for very intense, mathematical games, or games that have rules that are very open ended. I realize those sound like opposites, but what I mean is that games where everything is very tightly knit are also very fragile, whereas games where a lot of things are possible can often make things too possible. A ticking clock breaks easily, but so does a water balloon. A lot of games based around communication need to be tested like this to make sure there aren’t any loopholes like writing things down or speaking in a certain way.

Conclusion

These are not all necessary for every type of game, I just wanted to go through them. Even though I’d say about 90% of playtesting is that middle step, it’s important as a designer and a playtester to know which one you’re doing, both to set expectations appropriately and to make sure everyone gets what they need out of it.