Week 4 Reflection – Collecting and Analysing Data

On Monday 16th February we had another guest talk from friend of the course Venezia Georgieva, this time on the topic of playtesting/user testing games.

We were taught about the differences between QA testing and user testing: how the former revolves moreso around technical issues/bugs and documenting them, and the latter for observing the behaviour of players and using it to critique specific parts of the game design.

Smoke testing was another key topic; tests to ensure the fundamentals of a game are working as requied. We were shown examples of them and a list of requirements — they are typically made using spreadsheets, one for each individual test, and document the steps to achieve each requirement, as well as the expected result, the actual result, and a pass/fail mark.

We were also briefed on the many stages of user testing. Without going into too much detail, they are:

  • 01. Paper Prototype — the quickest way to playtest, particularly suited for 2D puzzle games, RPGs and narrative games
  • 02. Greybox — used to test function, usablility and flow without requiring any high-effort visuals
  • 03. External Players — test with around 5-6 players, ideally first-time players. Record screen, ask them to think out loud; pick up on subtleties.
  • 04. Results Analysis — people will try to be polite – beware of apathy! Some players might love something unexpected, so if they do, lean into that!

–

Regarding development of our game, I made a decent level of progress on the peacock minigame I tasked myself with developing; I did some further research on shaders in Unity, and gained an understanding of how to implement them in the game to achieve the painting mechanics.

I also made the challenging decision to rewrite my code for the minigame from scratch, as I had since found some new resources that gave me a new, clearer view on how to build the program.

My code was also quite convoluted and messy, and was providing a challenge with a range of bugs that I didn’t understand. Because of this I felt my decision would benefit me in the medium-term, especially when me and Misty would work together to implement it in her build.

The script is now much more consise and understandable, in my opinion, and should provide an easier experience for myself and others going forward.

Leave a Reply

Your email address will not be published. Required fields are marked *