How To Playtest

1. Playtest Overview

2. Preparing your Questionnaire

3. Assignment: PlayTest

It’s time to put your game in front of real players!

You probably feel like you’re not ready for this – like you just need to finish that one feature, or fix that bug, and then you’ll be ready. Getting through that feeling is by far the hardest part of this assignment. But it’s what professionals do, because it really is the only way to know if your design is working while you still have time to fix it.

Following the process described in the videos, you’ll be ready to get the information that is most relevant to your game and most useful to you as a designer.

You are encouraged to do some of your testing with other members of the course if possible. Participating in other students' playtests will help them out and help you feel more comfortable showing your work.

Take a deep breath. Remind yourself this is just one game project out of all the games you’ll make. Then go run your test!

Write a questionnaire

The first step is to think about what information would be most useful to you as a designer. Then you’ll know what to ask in your questionnaire. The provided questionnaire template includes five starter questions that apply to nearly every game. Look below for some examples of questions that are more specific.

Make a copy of the questionnaire template and put your questions after the five provided.

Print out several copies of the questionnaire and be sure to bring them with you to the test. If you prefer, you can turn the questionnaire into a form on Google, SurveyMonkey, or another online service.

Here are some examples of questions you might write that are specific to your game:

• The CAMERA always worked in a way that best supported game play.

• Overall I ENJOYED the MAGIC system in the game.

• I think the AIMING controls were EASY TO USE.

• I felt I had ENOUGH CHOICES for moves on the board at any given time.

• When my SCORE changed I understood why.

• I understood WHY Izuku wanted to stop the helicopter.

Add analytics (optional)

Analytics, also known as metrics, are data automatically gathered by your game through scripts. They can help you see patterns in player behavior and experience. For more details, see the next step. For reference, this is also offered as a PDF in Tutorial Materials.

Run playtests

Now that your build and your questionnaire are ready, go ahead and run the tests. Remember, try to avoid explaining things to your players! Review the videos for this week for the details of how to prepare and how to get the most useful information out of your test sessions.

Analyze results

Once you’ve collected all the data, it’s time to think about what it means and decide how to respond. As you saw in the video, you’ll start by carefully reviewing your notes, the questionnaire answers and any analytics you collected. Look for patterns in what your players did and said, but take note of anything that seems important, even if only one tester reported it.

Write down a bulleted list of the 5-6 most important results – that is, the ones that surprise you or tell you the most about problems with your game. Phrase them as neutral observations, like “only one of five players ever used the double jump”, rather than “double jump broken”.

Next, think about what might explain those findings. For example, here are several reasons why players might not use the double jump in a game, because:

• they don’t know it’s there or think it’s a bug

• they think it’s doing something else, like a wall jump

• the controls for it are hard to use

• the controls for it are turned off or don’t work properly

• there’s nothing in the level that actually requires it

• it’s more satisfying to wall jump

• the animation is confusing or distracting

Think about what you observed in the tests, look through your notes again and choose what seems like the most likely cause (or causes). Write this down next to the observation.

Make a plan

Finally, think about whether and how you want to change the game in response to these conclusions. You don’t have to respond to everything every player tells you – for example, many potential players might say that a detailed sports sim like Madden is too complicated, or a physics game like Angry Birds is too simple. The designers of those games chose to accept that their games weren’t for everyone.

But your game does need to work for some audience, not just you. Professional designers put their pride aside for the good of the game. If your players simply don’t understand what’s happening, figure out how to give them more or better feedback. If they consistently tell you it’s too hard, find a way to build up to the challenging sections.

Think about the smallest adjustments you can make to address the problem without introducing new ones. If you’re close to the end of development, that might mean simply cutting a feature that isn’t working or simplifying a puzzle that’s too hard. Choose what you’ll do and add it to your product backlog and/or sprint plan for this week.

Here are the steps:

1. Write a questionnaire based on the template we’ve provided above.

1. Test your game and use the questionnaire to collect information from playtests.

1. Optionally, add some simple analytics to your game.

1. Summarize the most important results, and how you intend to address them, in a bulleted list. Take screenshots or do a video capture of the takeaways of your playtesting and share them to the gallery.

4. Optional: Adding Analytics

Analytics, also known as metrics, are data automatically gathered by your game through scripts. They can help you see patterns in player behavior and experience. For example:

• Players die twice as often in Level 6 as in any other level.

• Players never use the “stun” move.

• On average, players spend only a few seconds getting through Level 3.

• Players never choose to save the space spiders from extinction.

• Only 2% of players solve the ham sandwich puzzle.

Here are two options for adding analytics to your game.

Text file

The first option is to use the bare-bones metrics script we’ve provided in a demo project for this assignment.

You’ll have your scripts call the MetricManager when something happens that you want to track, e.g. a player death. The script will write out the results to a text file when your player closes the game. The text file will be called something like YourGameName_metrics_120719.txt and it will appear right next to your game’s executable – that is, YourGame.exe or YourGame.app.

This option is simple and easy to set up, but it has limitations. It will only be useful for a small set of simple metrics, and you need to be able to get to the text file once it’s generated. So either players will have to play the game on your computer, or you’ll have to ask them to find the text file on their own computer after they’ve played the game.

Unity Analytics

The other option is to use Unity’s free, built-in analytics. Here are a couple of tutorials on setting it up:

Brackeys How to use Unity Analytics (12 minutes, also covers Remote Settings)

Unity3d.college shows a somewhat more sophisticated setup with a more realistic example.

And here is Unity’s documentation.

The analytics feature sends out information to Unity’s online analytics service, which then displays the data on a web-based dashboard. The dashboard has several kinds of graphs and filters to let you explore your data. Unity Analytics is only a little harder to set up than the text- file option, and the dashboard’s built-in graphs are great for most basic analytics.

However, it has the downside that you won’t see your data right away. As you’re setting up your events you can see the data inside the Unity Editor, so you can test your setup. But it can take several hours to a day before you see the results in your dashboard.