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!

• 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