Tuesday 19th, Monday 25th November 2019.
Release 1 - Sprint 5. Scrum Master: Caoilinn Hughes
Overview
This week, we focused on polishing our game ahead of the presentation on Tuesday. We conducted user tests throughout the week to gather feedback about our game.
Product
The main products of this week were:
- Redefined User Personas
- Selected Test Users
- Conducted User Tests
- Reviewed Tester Feedback
- Implemented Test Feedback
- Refactored Codebase
- Create Presentation
Process
Redefined User Personas
I felt that our user personas needed revision. I discussed the possibility of re-designing our user personas with the group. I wanted to cover a range of experience - young to old, novice to expert. This resulted in the creation of three user personas - the grandfather (has experience playing role-playing games, has experience using a keyboard and mouse, but has no experience using a gamepad), the father (has some experience playing role-playing games, has some experience using a keyboard and mouse, and has some experience using a gamepad), and the daughter (has no experience playing role-playing games, has no experience using a keyboard and mouse, but is experienced using a gamepad). Through these personas, we are covering a wide range of preferences and ability, which is fitting with our design principle of flexibility in use.
Selected Test Users
We invited various students from around the college, to come and test our game. We selected testers based on our user personas. We were looking for experienced gamers and novice gamers. We were testing against three main metrics - experience playing games, experience playing role-playing games, and experience playing with a mouse and keyboard. Through these metrics, we can determine how intuitive our game is, how simple the mechanics are, and how perceptible the information provided is.
Conducted User Tests
We conducted user tests on Thursday and Friday. We encouraged our testers to adopt a user persona before the test began. We used over-the-shoulder techniques to gather feedback from our players, based on their interaction with the game. We paid particular attention to our player's behaviour - both expected behaviour and unexpected behaviour. We also recorded any questions that they asked while playing our game. Once the test was complete, we asked the player a number of pre-determined questions. We recorded their answers via Google Forms.
Reviewed Tester Feedback
We reviewed our test data to improve the quality of our game. A common comment among testers was the lack of in-game visibility. Although this was a design choice (we implemented fog to add atmosphere), we decided that it was better to listen to our users. There were also comments about combat-balancing - many users felt that the game was too easy to play. Users also felt that the camera's control scheme was difficult to pick up. However, they further described it as quick to learn, and easy to master.
Implemented Test Feedback
I edited the fog effect to improve in-game visibility. The player can now see further in every direction. I was careful to not extend this distance too far, however, as I wanted to retain the atmospheric effect.
Refactored Codebase
I was unhappy with the structure of our codebase - I felt that too many systems were inter-dependant, instead of being self-contained. This was a recipe for disaster going forward. I spent considerable time on Sunday refactoring the codebase. I restructured major elements, and completely re-worked the collision system. I implemented a grid manager to keep track of elements within our grid - this includes the player character, enemy objects, and collectable items. Through this, I can considerably reduce the number of collision checks, by detecting collision based on the position of an object, rather than its collision skin. This also has the benefit of improving in-game performance, by reducing the usage JigLib. I pulled the collision detection system from the CollidableFirstPersonCameraController class, into the CharacterObject class, so that the PlayerObject and EnemyObject classes have access to it. This allows me to add collision behaviour to enemy objects, such as preventing them from walking through walls.
Create Presentation
I created a simple background presentation to assist in our demonstration on Tuesday. I adapted our previous presentation to save time. We decided to cover to main points in our presentation - our universal design principle, and our plans going forward. I also created a simple script for us to follow throughout the demonstration.
Issues
My updates to the codebase on Sunday caused many issues while merging our work on Monday. Luckily, the overall impact was quite small, and we were able to effectively merge all branches.