Playtesting: A to Z
In one of my graduate school textbooks, Game Design Workshop (Fullerton, T. 2019) that I use for my Design of Learning Games class taught by Dr. Fengfeng Ke at Florida State University, there is a short commentary by game designer Eric Zimmerman and architect Nathalie Pozzi on playtesting. It lists a Cliff-Notes version of their playtesting "rules", one for each letter of the alphabet. I tremendously admire the collaboration of these two veterans whose playable installations have appeared at the Museum of Modern Art in New York, in Paris, Berlin and around the world. I am only going to discuss a few that really spoke to me.
A) Playtest before you think you are ready. This goes to the heart of so much I have read about game design including think out of the box, listen to everyone on your team (whether on the technical side or not), create prototypes early and test them, and more. All these suggestions are to help the designer flush out not just "bugs" in the game, but areas in the design flow, rules or mechanics that might make the game too hard in places, too easy in others, or they don't work at all. By prototyping and playtesting early, you hear the feedback early in the design cycle when it is easier and less expensive to make design changes.
F) Design the Learning Experience - This goes to heart of complex interactive games where the time and effort it takes a player to learn how to interact with the system is as important as the game itself. I've read feedback on players who played Portal for the first time, and complained about the difficulty of learning how to effectively interact with the game and to progress through it. In the learning game I designed, I had to consider that the designated audience for my game were children who were hospitalized. So ensuring the game was modularized and adventurous was critical for the ease of their learning experience.
N) Shut Up - Not being rude here, but it's good advice. As a designer, it's understandable to want to explain everything you can to your playtesters in advance, but that is not helpful to the design team because the designer isn't going to be there to do that for every player. Playtesters need to intuitively experience the game with as little impressionable overlay from the designer as possible for the design team to get the best, honest, most unfiltered feedback.
Q) Answer a Question with a Question - This is one of my favorites. If a play tester asks what something does, or how it works, ask THEM what the think it does or how they think it should work to help them succeed at the game. It not only gives you a deeper insight into a potential problem that needs to be fixed, or an asset that can be expanded, but it lets the playtester know that all their questions and feedback are appreciated.
Z) Break the Rules - The last "rule" is to not follow the rules. In short, there is no silver bullet, no perfect process that will provide the best playtesting for every game because every game is different, as are the playtesters. The best advice is to the design the best playtesting process you can for your game, and use these rules from Zimmerman and Pozzi as a skeletal framework to drape your process over.
 |
| Add caption |
A) Playtest before you think you are ready. This goes to the heart of so much I have read about game design including think out of the box, listen to everyone on your team (whether on the technical side or not), create prototypes early and test them, and more. All these suggestions are to help the designer flush out not just "bugs" in the game, but areas in the design flow, rules or mechanics that might make the game too hard in places, too easy in others, or they don't work at all. By prototyping and playtesting early, you hear the feedback early in the design cycle when it is easier and less expensive to make design changes.
F) Design the Learning Experience - This goes to heart of complex interactive games where the time and effort it takes a player to learn how to interact with the system is as important as the game itself. I've read feedback on players who played Portal for the first time, and complained about the difficulty of learning how to effectively interact with the game and to progress through it. In the learning game I designed, I had to consider that the designated audience for my game were children who were hospitalized. So ensuring the game was modularized and adventurous was critical for the ease of their learning experience.
N) Shut Up - Not being rude here, but it's good advice. As a designer, it's understandable to want to explain everything you can to your playtesters in advance, but that is not helpful to the design team because the designer isn't going to be there to do that for every player. Playtesters need to intuitively experience the game with as little impressionable overlay from the designer as possible for the design team to get the best, honest, most unfiltered feedback.
Q) Answer a Question with a Question - This is one of my favorites. If a play tester asks what something does, or how it works, ask THEM what the think it does or how they think it should work to help them succeed at the game. It not only gives you a deeper insight into a potential problem that needs to be fixed, or an asset that can be expanded, but it lets the playtester know that all their questions and feedback are appreciated.
Z) Break the Rules - The last "rule" is to not follow the rules. In short, there is no silver bullet, no perfect process that will provide the best playtesting for every game because every game is different, as are the playtesters. The best advice is to the design the best playtesting process you can for your game, and use these rules from Zimmerman and Pozzi as a skeletal framework to drape your process over.
Comments
Post a Comment