... | ... | @@ -2,6 +2,45 @@ Playtesting occurred once a working prototype of the game was finished and testa |
|
|
|
|
|
# Methodology #
|
|
|
|
|
|
For the game, the most important aspect is the control of the car and how it fits in with the speed limit mechanic. I wanted to test first and foremost whether the game "felt" good to play. I also wanted to test whether the game was the right level of difficulty, as well as making sure the UI was easy to understand and readable. This meant that the prototyping I would playtest would be Mechanical Prototyping and Kinaesthetic Prototyping.
|
|
|
|
|
|
I therefore used the following methodology to playtest my game.
|
|
|
|
|
|
I would make sure that I constantly and continuously tested my game after every major scripting change. This would mean testing each mechanic as it was implemented to ensure it played well with the rest of the game and my vision for the final prototype.
|
|
|
|
|
|
While playtesting by myself was an essential part of the playtesting process, I knew that it would not suffice as the only playtesting. I knew I would have to remove the bias from playtesting that came from testing my own design, and the only way I could do that would be to create a working prototype that I could use to test on other people.
|
|
|
|
|
|
Playtesters would all have to sign a consent form.
|
|
|
|
|
|
The method of playtesting on other people I decided would be best for my game was a hybrid of One-on-One and Feedback forms. This method would entail watching the gameplay of as many participants as I could, to see different peoples approaches to the game and its mechanics and how it differed from what I intended. Observing this would show me areas that needed improvement, as well as areas that worked as intended. It also gave me the unique viewpoint of seeing different ways of playing the game that I may not have thought of.
|
|
|
|
|
|
I knew that it would be impossible to observe all of my playtesters play the game due to distance and technological constraints. While this would admittedly be disappointing, I would ensure I would still observe as many playtesting sessions as I could.
|
|
|
|
|
|
After the playtester had completed a play through of the game, they would fill in a feedback form with specific questions aimed at learning more about what that playtester thought about the game. The questions are as follows:
|
|
|
|
|
|
1. What was your favourite part of the game?
|
|
|
2. What was your least favourite part of the game?
|
|
|
3. Was there anything that you wanted to do that the game wouldn’t let you?
|
|
|
4. Did you feel in control of the car?
|
|
|
5. Did you understand the controls (i.e. how to move the car, how to drift)?
|
|
|
6. Was the game too difficult or too easy?
|
|
|
7. Did you find any section of the road too difficult to stay on?
|
|
|
8. Did you find the speed limit too hard to abide by?
|
|
|
9. Did you find the drifting mechanic easy to use?
|
|
|
10. Was the User Interface (i.e. the speed limit, the timer etc.) easy to understand?
|
|
|
11. Did you find any text difficult to read?
|
|
|
12. Did you encounter any problems with the game?
|
|
|
13. Did you find the game fun?
|
|
|
14. If you could change one thing about the game, what would it be?
|
|
|
|
|
|
I felt that these questions would be appropriate for getting useful feedback on the game, its mechanics, and the feel of the game. I also wanted to make sure that the UI was easy to understand so I asked if it was in the questions.
|
|
|
|
|
|
Some of the questions would tell me about specific things to do with the game, such as what the most and least interesting parts of the game were (Q1 and Q2) or if there were any bugs that I missed in development (Q12). All the questions would serve a purpose in providing a greater picture on the quality of the game and where it needed to be improved.
|
|
|
|
|
|
I believe this method was the best for playtesting this game, as it gave me a good amount of data that I could analyse to figure out what parts of the game worked and what parts did not. Observing playtesting sessions gave me information on how users would generally play the game, and give me an insight into where things should change to bring it closer to how I intended the game to be played. The feedback form let me know about how the users actually felt about the game, giving me an understanding of whether they enjoyed it, if they struggled with the game, and what they felt was good and what they felt needed work.
|
|
|
|
|
|
# Procedure #
|
|
|
|
|
|
I would throughout development continuously playtest by myself to ensure that the mechanics I were implementing felt good and worked within the scope of the entire game. This meant
|
|
|
|
|
|
# Reflection # |
|
|
\ No newline at end of file |