Cycle Activity 7: Tu Thanh Nguyen – Play Testing

 

Unfortunately, my prototype was still in the incomplete stage, I was not able to work out the code that should be done by the time when the playtesting session started. This is the reason why I am not satisfied at all with my prototype, nevertheless, the playtesting section must be done.

The way I tested my prototype was about asking questions, taking notes about how do I improve my game better and what ideas should I use to make people play my game.

3 Documents of notes that I wrote from the 3 participants are down below.

tester 1
tester 2
tester 3

 

Advertisements

Cycle 1 Activity 7: Paul Dalgety – Play Testing

Due to some time constraints I was not able to test the game during the weekly practical with the studio group, I had to look for other people to test the game with. I used the data that I had collected from the play test sessions with the chosen people to make small improvements to my game. With more time and further design I believe a better end result would be vastly more achievable, but with the time we had I’m happy with the end result of my game especially after the play test changes.

My form of play test analysis was supervising them playing the game and during their time playing I took notes based on 3 important categories.

  • Usability of controls.
  • How long they were alive/what their score was.
  • What they enjoyed about the game/ what they would change.

The first two points are observatory and then after the session I asked them the question in relation to the last point.

Improvements made based on play test sessions:

  1. Player movement speed was the first problem identified in the game. Initially the player ship was too fast and this made it very easy to navigate past enemy bullets.
  2. Enemy spawn rates were too fast and there was time added between each spawn timer for the three enemies.
  3. Player controls were changed, initially the movement was done with “A” and “D” then shooting done with “Space” “Q” and “E”. I later changed this to using the left and right arrows to move, and the “Q” “W” “E” were now used to fire. This was done because it allowed ease of use in the controls.
  4. Enemy ship movement speeds were changed as well, the fastest enemy shipped now had a movement speed slightly under that of the player controlled ship.

Below is a link to the play test sessions documents.

Play Test 1

Play Test 2

Play Test 3

Cycle 1 Activity 7: Joel Aldridge play testing

For this cycle I decided to test my game with people outside of our studio as I worked tweaking parts of the game until very late in the cycle to ensure the play test version of the game was the best it could possibly be.

I collected information by watching and taking notes as the player played the game and after the session asking 3 questions:

1) what did you like about the game
2) what didn’t you like about the game
3) What elements of the game could be improved

(The 3 documents of notes I created from the play tests can be found here, here and here)

Improvements:
Adjusting the spawn rate of enemies so it becomes more challenging by having different enemies spawn at much different rates – Implemented
Adjust enemy colour changing rates – implemented
Add sound effects and improve the visuals – This improvement was not implemented as sound effects became frustrating based on the speed of events triggering them and upon trying to improve the visuals the improvement in quality was much less than the time to improve them.
Adjust weapon cycling time – implemented
clearer display of rules / controls – implemented
Show player health – partially implemented, added a “doom” style bar displaying when health is high, mid or low with an appropriate facial expression to keep the user interface from being too cluttered.
Over reliance on space bar – not implemented as no solution was apparent that would not simply over rely on another button