19 The Design Process: More About Playtesting

In the early part of playtesting, when you are playing the game with your team, here are some things you should be looking for:

Does the game meet your design goals?

Is it fun, at least for you? While you are not the ideal playtester to judge effectiveness most of the time, if you are not having fun then most other people will probably not either.

Are there any holes in the rules?

A “hole” is a situation where the rules simply do not say how to proceed. For example, perhaps one of your rules is that a player’s army can attack another player’s army, but you don’t yet have rules for resolving the attack. What happens in this case? In practice, what happens is that the players sit around and wait while the designer figures out what to do!

As an example, consider these rules for Tic-Tac-Toe played on a 4×4 grid:

• Players: 2
• Objective: Get a straight line of symbols.
• Setup: Draw a 4×4 square grid.
• Progression of play: On your turn, place your symbol (“X” or “O”) on an empty square.
• Resolution: If either player on their turn has a set of four of their symbol in a straight line (across, down, or diagonally), they win.

If you try to play this game just following the rules, you’ll quickly realize that you can’t even start – nowhere does it say which player is X or O, or who takes the first turn! To fix this, you would add a situation to handle this. For example:

Setup: Draw a 4×4 square grid. Choose a player to go first, who is assigned the symbol “X”. The other player is given the symbol “O”.

Are there any dead ends?

A “dead end” is a game state where there is no way to proceed further, but the game is not resolved. Consider our revised 4×4 Tic-Tac-Toe rules above. Suppose that both players fill up all squares on the board without anyone winning. At this point the game cannot proceed, because the rules say a player must place their symbol on an empty square. There is no empty square, so the player cannot take a turn. But there is also no resolution, because neither player has won. In this case, a new rule would have to be added (such as: in the resolution, if neither player can make a legal move and no one has won, then the game ends in a tie).

Are any of the rules unclear?

It is natural for us to assume things that are in our head, to the point that we often forget to write them down in our rules. Try to look at your rules and see if there is anything you are assuming that your players might not.

Are there any really obvious rules exploits?

Is there a single strategy that wins the game easily? Try to find it. It’s much less embarrassing if you find and fix it yourself, as opposed to having it discovered by your playtesters (or worse, your players after you release the game). Clarity and exploits are often hard to find in your own game; you tried to design this game to not have any problems, after all. Still, make an honest effort, and sometimes you will be rewarded by finding and fixing errors early (which saves a lot of time in the long run, leaving you more time to iterate on other parts of your design).

You might think that looking for exploits is something to do later in the project when balancing the game. Sometimes it is. It is a matter of degree. If an exploit is so powerful and so obvious that it prevents your playtests from giving you real information about your game, fix it now.

At this point in the project, you should have a playable prototype of your game, and a set of rules. You should have playtested on your own with your team at least once, identified any really obvious problems, and iterated on your design. You should continue to do this until your design is at a point where you are confident that you can play all the way through without having to make major changes.

Once you reach that point, your goal shifts from “make this game work” to “make sure the core mechanics are fun” (or whatever your design goal happens to be, if not “fun”). Who would make the best playtesters to help with this?

Normal players (such as friends and family, or even complete strangers) are marginally useful here. By watching them, you can determine if they are having a good time and if your game is meeting its design goals. However, if there is a problem, a typical gamer will not be able to give you useful feedback other than “it’s great” or “it sucks.” It will be up to you as the designer to identify and fix the problems. Therefore, normal testers can be used if necessary, but their usefulness is limited.

Far better is to playtest with other game designers. Game designers can also let you know if the game is fun, and they can offer suggestions on where the problem points are and what can be changed to make your game better. You can often have wonderful discussion following the play of the game, on the design of your game and sometimes on game design in general. These kinds of discussions are important, and your game can get better much faster with them.

Being a Great Designer

As other people playtest your game, keep in mind the following:

• Your game is not perfect. If your game were perfect, you wouldn’t need to playtest.
• There will be problems. The goal of playtesting is to find and eliminate those problems. If all your playtest did was confirm that your game is perfect, you have just wasted your own time and everyone else’s.
• It is far better to identify problems in a small playtest, than for them to be found after the game is printed and ships to millions of players.
• If one of your playtesters finds a major problem in your game, they have given you a great gift. Do not be hostile or defensive; be gracious.
• When a problem is identified by a playtester, your goal is not to verbally defend your game or to explain why the playtester is wrong. First, even if your playtester is “wrong,” it probably means a lot of other players will also be “wrong” in the same way, and you can’t ship yourself in a game box in order to explain your Grand Vision to everyone. Second, the playtester is probably right – they are seeing your game through fresh eyes, and are more likely to have an unbiased view of the game.
• If your playtesters do identify problems, the correct response is to write the issue down in your notebook… and then discuss your design goals with the playtesters so that you can get some ideas of how to preserve your goals while changing the game.
• Not all people are tactful. Sometimes people will say things about your game (or even about you, personally) that are downright hateful. Sometimes people will make fun of your game, or will taunt or berate you for a problem with your design. Keep in mind that, no matter how it is delivered, this is still extremely useful content.
• It takes a strong person to hear a statement like “your game sucks, it is the worst game I’ve ever played, and by extension you suck and you are nothing better than a waste of space” and to genuinely reply: “You have just helped me identify some major flaws in my game. Thank you.” Getting to the point in your life where you are emotionally strong enough to have an exchange like this should be one of your long-term goals as a game designer. You do not have to be like this right now. I’m not. But I have seen an exchange like this before from a great designer, and it made me realize how far I have to go.

Running a Great Playtest Session

If you want your playtesters to keep coming back for your future designs, be as respectful of their time as possible. Here are some things to consider:

• Before you show your game to other players, make sure the rules are fresh in your mind so that you do not need to look them up. Try explaining all of the rules to yourself in the mirror to make sure you can do it. This will save time, if it only takes you a couple minutes to explain rather than half an hour.
• If you already know there are problems (and you just don’t have the solutions) or if you have specific design goals other than “make a fun game,” let your playtesters know this up front. It will help them to be more aware of potential solutions.
• End your playtest as soon as you can. If you have received as much useful information as you are likely to after a half hour of play, stop there (even if the full game would last three hours). Remember that the purpose of the playtest is to identify problems, not to “play games.” If you’re not identifying problems, you are wasting everyone’s time.
• Bring your playtest notebook and take good notes. You will forget everything that takes place, no matter how obvious your playtest results seem at the time, so make sure you write down every piece of information that you don’t want to lose.

Being a Great Playtester

Here are some of the things you should keep in mind when testing other people’s games:

• When testing, give the designer and the game your undivided attention. You would want others to extend the same courtesy to your game, after all.
• Don’t leave in the middle of a test. Aside from being rude, it can throw off the results (not all games can gracefully handle it when a player leaves). At minimum, if you know you have limited time or that you may get called away in mid-game, let others know this up front so they can handle it accordingly.
• Be as detailed as possible. Don’t just say that the game is “fun” or “boring,” try to analyze why. You should have enough of a background at this point to give meaningful feedback. Make use of your design skills!
• Allow some time after the game for discussion with the other testers and the designer. Talk about your play experience, and how it was related to the mechanics.
• Remember that there are many possible playtest goals. Are you playing to see if the game is fun? Are you playing to win? Are you playing to find holes in the rules? Play accordingly. We are so used to playing games in our own personal style, that it can be difficult to remember that there are other ways to play. Keep the goals of the playtest in mind.
• Be polite. Attack the game mercilessly, but do not attack the designer.

This chapter was adapted from Level 12 and Level 13 of Ian Schreiber’s Game Design Concepts course.