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!
  • 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

Culture: common modes of consumption, presentation, or interaction.