Final Reflections

Final Reflections

Our team developed a solid foundation for the initial prototype. Because of this, we were able to adapt and extend the application’s functionality for the final submission with ease. The design decisions made early in the development process allowed us to seamlessly scale the game to include more levels and gameplay elements. We thus had ample time to focus on perfecting and polishing the existing aspects of the game for the final submission. Extensive play testing and user interface improvements were carried out in the weeks leading up to submission.

In playtesting our game, one feature that we found particularly effective was the job advertisements, which is a feature we based on real world research presented to us in lectures. This part of the game involves constructing a job advertisement by selecting certain words that will attract either male or female applicants. This feature aims to make the player aware of the fact that the way job advertisements are worded do matter, and to be inclusive we must choose our words very carefully so we don’t unconsciously target a certain demographic. In certain situations during gameplay, the applicants will be all one gender and the player will need to hire the opposite gender and think carefully about which words to choose. We found that a collateral effect of this feature was that it caused the player to identify any unconscious bias they might have, by really questioning why they are associating the words with either male or female.

Before the project began we were apprehensive towards the merging issues posed by the project. We had heard that previous years had struggled with merging scenes using Unity, and we wanted to avoid this by working on scenes separately throughout development. However after planning we came to realize that our game idea lended itself to functioning within one Unity scene. This is because our game centers around a single ’office’ view, with menu interfaces layered on top of this. Initially this worried us, but when starting development we found an effective strategy for avoiding most potential merge conflicts.

We would each develop and test our own views, assets and sprites in a scene of our own and save them into a prefab object. Coordinating changes within team members, we would then add our prefabs to the main scene, and would only need to ‘wire up’ our changes with the existing scene objects. This worked effectively throughout the majority of development and we experienced very few major conflicts as a (what we believe) direct result.

However, towards the end of the project this method did not work quite as effectively, as we would make multiple changes spanning the unity scene base, and it was difficult to isolate these changes. This meant that we had to resolve further merge conflicts closer towards the deadline which increased stress level throughout the team.

We had group 3 playtest our game before submission, and it proved to be a valuable experience for the team and it exposed several issues with our game. The highlighted problems centered around the game’s intuitiveness and difficulty. Specifically, the play testers found it difficult to know what to do when confronted with the scenario of not having enough employees to start another project. To remedy this we added introductory tutorial dialogue that would explain what to do in this situation. With regards to the difficulty, the play testers highlighted the issue that employees leaving incurred too high a cost, and that the number of employees required to complete the final project was too high. These parameters were then tweaked before submitting to ensure the game was more playable.

Coming into this project, we anticipated that coordination of eight busy students would be difficult. When it came to the actual project, this manifested itself as problems with finding times where everyone was free, and equally and fairly delegating work to members. To remedy this, we came to the decision that having all members present during minutes was not necessary; any members that weren’t able to make it, would catch-up on progress via usage of the recorded meeting minutes. Additionally, the team leveraged technologies supporting team coding projects, such as Microsoft Teams (e.g team conferencing, which supported strong peer programming).