As I said last week, this week I’m going to go over what we do during and after play tests.
We ran another play test at the IGDA Melbourne meet up last night, so I’ve got a bit more recent data to use as examples for this post.
Here we are set up at the meetup last night.
Unfortunately, I only have a small laptop, so we weren’t as eye-catching as we could have been. But we were set up to face out into the room, so that people would notice the screen and be drawn over to watch other people play (and thereby be enticed to play themselves!). Ideally this would be done using a larger screen that was set higher so that viewer could see it over those playing, but the facilities last night didn’t allow for that.
However, this set up did allow for the player to be sitting down, and that meant that people standing behind were able to watch.
(This is a bit of a catch 22 for us. Level Squared is a puzzle game, so a lot of the fun comes from working out how to solve puzzles and progress. However, a person watching the current player will see the solutions and that reduces their desire to play. But at the same time, we need people to be able to see gameplay in order to be drawn in to want to have a turn. It’s a problem that I’ve never really managed to work out a solution to.)
At least, it didn’t seem to be too much of a problem last night, because there were a steady stream of players wanting to have a turn.
While people were playing, I would sit next to them and watch what they were doing, while also talking with them. I also took a bunch of notes when I saw things that needed fixing, or puzzle elements that were causing trouble, or when they said a particular thing was good or bad.
It’s super important to take notes as you watch people play. I’ve done the whole “I’m going to watch then write down my notes later” and it 100% does not work. You won’t remember stuff, you’ll lose a huge amount of feedback, and the play testing will be significantly less effective as a result.
Seriously, that’s my number one game dev tip – always have a note-book for play tests and always write down what you see as you see it.
Once I get home I enter all of these notes into a Google Doc that we maintain for play testing records. It breaks notes up into disciplines like level design, programming, art, etc so that we can allocate a team member to address it.
Then finally, we convert these notes into tasks and make a list so that we can allocate those tasks to team members to make changes to the game.
You can see that the second last note in the pad above says “Camera snap back is too fast”. That’s the note that I took as I saw it happening. This is referring to the way that the game zooms out while you are projecting, then returns to a regular field of view once you release the projection.
When I got home, the note I entered into the team note document was, “The camera snap back is too fast – many times players did not see where the projection was left before the FOV shifted back.”
Finally, this is converted into 2 task as follows:
- A task for the programmers – “Make camera zoom speed controls public, so that they can be adjusted to a suitable speed for play.”
- And a task for the designers – “Investigate camera zoom to find more comfortable speed for play”.
The we’ll adjust the camera zoom speed to a speed that we think is about right, and take it back out to test with people again.
And just keep doing that til we get it about right!
So that’s how we turn a play test into a success. Setting up properly, taking plenty of notes of what the players do, then turning those notes into actionable tasks that we can feed back into development.
It’s sort of like a conveyor belt that makes more work for us! Wait, that doesn’t sound as good as I thought it would…