Playtesting
Playtesting
Playtesting as part of design
- Have an idea for a game?
- Don’t spend time obsessing about its design until someone has tried to play it!
- Ideas alone don’t reflect how engaging a game is to play
- Thus, it’s always a good idea to prepare a prototype for playtesting ASAP
- By integrating playtesting to your design process, you emphasize the player experience
Playtesting uses people as a resource
- Be cautious before giving your game for the general public to test
- You don’t want to get the same bug report 7983 times!
- It’s better to first give your game for one person at a time to test
- The game doesn’t need to look and feel like a finished product
- But this process aims to remove biggest bugs before a wider release
- This way, you get better feedback from the bigger release
- Also, it’s notable to understand that after a playtest session, you have used up one person
- When they play the game again, their view of the game is now clouded by the earlier playtest
- To get more objective playtest results, you need a constant flux of new testers!
Playtesting in practice
Before playtesting
- Have a plan.
- What do you want to get out of playtesting?
- It’s a good idea to have some questions in mind you want answers to. Examples:
- Does X work?
- Do the players figure Y out?
- Does the game teach its mechanics to the players?
- Especially early in development, it’s important to focus on the first seconds of the game.
- Does the game grasp the players’ attention?
- Do the players do what you expected them to do?
- Also…
- Make sure your build works.
During playtesting
- Communicate the plan and set expectations:
- “Thank you for being here”
- “The game is still a work-in-progress so expect that it sucks”
- “Do not blame yourself for mistakes.”
- “Remember, you are not being tested, it’s YOU who are testing the game!”
- Ask tester(s) to think out loud while playing
- “Narrate what is happening on screen!”
- Remind that you will be quiet and take notes
- Be quiet! It’s the most important rule.
- …and the easiest to break when things go wrong
- Remember, you won’t be sitting next to people who you’ve sold your game to
- When the player does something “wrong”, or doesn’t get something, or is stuck, it can be interesting to see where it leads
- You can remind them, however, not to blame themselves for their “mistakes”.
- Even when the player asks how to do X, do not answer!
- Only help out if they’re stuck for a longer period.
- Now you know there’s something wrong with the game!
- …and the easiest to break when things go wrong
- If possible, have two people conduct the playtesting
- One who runs the test
- And one who takes notes
- Take lots of notes during playtesting:
- where they get stuck or confused
- what they enjoy
- what was unexpected
- any new perspectives on gameplay, user interface, etc
- Maybe even record gameplay for later analysis
After playtesting
- It’s time for Post-Playtest Debriefing
- When game is done (or tried for ~15 minutes), discuss highlights and problems
- List 1-3 big change suggestions to explore.
- Thank your testers!
Note about playtest feedback
- The feedback you get from playtesting is the most valuable data about the player perception of your game you have during development
- A note, however:
- To my experience, playtesters are good at pointing out what’s bad about the game
- …but their solution suggestions miss the mark more often than not
- This article highlights this phenomenon
Some good points from the article, actually
- Rule 1: Testers try to speak in fact, but they speak in emotion.
- Rule 2: Testers do not like features they don’t understand
- Rule 3: Testers have expectations that may not match the developer’s.
So anyway, now you have feedback.
- Iterate your game mechanics and interface with the feedback in mind… while also listening to your own instincts!
- You can’t implement every suggestion!
- Instinct for what the game needs and what it doesn’t is one of the most important skills for the game designer to develop
Why playtest?
- Creation is 1% inspiration and 99% revision. (Jason Wiser)
- Our reality is not the only reality. (Also Jason Wiser)
- Testing is how we come to understand our audience’s needs. (Yup it’s Jason Wiser)
- Also, remember: negative player feedback is very rarely a critique of the designer
- Rather, it is born out of wanting to see the game become its best possible version
Additional fleeting ideas
Two schools of game dev
-
PRODUCT FIRST: We have a game we want to make, and must identify the audience that will enjoy that game.
-
AUDIENCE FIRST: We have an audience we want to reach and so we design a game to fulfill their interests.
Focus testing
- Based on feedback, implement changes to your game
- Playtest your game with a focus group who get the new changes
- Send a survey to the focus group and implement changes based on that to the general audience
Radical revision
- Sometimes you get stuck in the development process, and need to shake things up in a major way
- Radical revision explores complete overhauls of your ideas
- Dangerously sweep away all of the sweat and blood you have shed so far and imagine impossible new directions.
- You don’t have to follow those paths!
- You just need to give yourself the chance to consider something novel
- What if you kept the way your characters move, but changed the victory and lose conditions
- Or what if you added new GameObjects that could be used to help balance randomness, or mess with other players?
Reading
- Most of what you just read is from Jason Wiser: Tufts University Game Design course