Dev Diary #10 – Playtest -> Questionnaire -> Pivot


For this Dev Diary entry, the intent is to explain the process of using play-testing and a series of well thought questions in order to seek out problematic game play mechanics and using this information to pivot the mechanic to something players will find more enjoyable. For the sake of simplicity, I’ll talk about this process in relation to our project 3 game Sound Vapour. Play-testing and pivoting also occurred in project 2 but there was not enough data to go off for the sake of this post.

The Process

Play-testing requires the game to be set up with recording hear and software. This is to help us as a team to be able to pick up on player habits, good or bad, in order to determine what we need to change and what we should further develop upon.
Screenshot of a clip from a play-testing session in Week 11
When the session is over we evaluate the footage and watch the players eye movement and facial reaction when certain events happen in the game. From the girl pictured above for instance, she seemed very frustrated at some certain points and bored at others, these reactions became apparently common among other testers at the same points of the game giving us grounds to pivot and tweak the note generation of the song to become more evenly generated over the quieter parts of the audio track. 
After the player has had their test, they are encourage to fill out a questionnaire made by us. The questions asked need to be thoroughly thought through in order to give us the best information possible that could help us with things we may not pick up on the video feed. For a secondary play-test we conducted in week 11, I put together a questionnaire with the following questions:
  1. How did you learn the controls?
  2. Did you feel overwhelmed? If so, approximately how far into the song were you?
  3. How often did you check your score/multiplier?
To explain my thought process for asking question 1, a previous play-test indicated it took players a long time to figure out how to control the game (this was before the Dial Menu was implemented). In this build for the play-test, I had completed the Dial-style Menu in response to the previous feedback. I wanted to see how effective the menu was as a means of the player learning the main controls for the game without actually needing a tutorial or a “how to play” section. Luckily, it did help! But for this kind of game, there was little time for the player to muck about with the controls freely in order to work them out. A tutorial feature became needed for this game (as an option that should be toggle-able).
For question 2, I asked this in order to get a general idea of average skill cap. Granted this is the first time these people have played the game but our goal was to not overwhelm new players but to make the game finish-able for most people during their play-test (in order to prevent a rage-quit). This inevitably led to being hard song and to account for new players we added more songs, some much easier than this one, making the experience much more enjoyable for those starting out.
In question 3, as the UI developer for the game I wondered if the UI needed a more attention paid to it. From what I read from the responses, most people did not care much about it and did not understand about when their multiplier went up or down, they just tried to hit shapes without a care in the world and hoped for a good score at the end. This told us we needed a way to make the UI text at the stand out more. So the pivot to animating the text size and colour plus adding in particle effects to travel from the destroyed shape associated with the multiplier up toward the multiplier UI text was born.
When working on pivots, the first step is to update the concept doc documentation to describe the new change proposed and get the team to agree. Once done so continue on to update Feature spec and Tech Spec docs as needed in order for all team members to have guided direction into the pivot. Then do it! 


For our project some pivots we unfortunately did not have the time to complete implementation into the game. Documentation should have been updated though. This process is a necessary step that should be taken as often as needed. It could be as rare as once per month or as often as once per day. As long as the full process completed properly, play-testing and pivoting should only ever be beneficial in the long run and never seen as a setback.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

Up ↑

%d bloggers like this: