RUP Reflection

This project was developed following the RUP methodology. See below a reflection on how we felt we utilized RUP's practices.

RUP 6 Practices:

Develop Iteratively

This project was broken into multiple phases. Because we had a goal of meeting the prototype milestone, which required basic features and implementations, a lot of work was done early on in the project. This allowed us to use the building blocks we had created to quickly make new levels, and we were able to spend the time that we had between the prototype and final phase bug fixing, polishing and implementing more advanced features. As features / fixes came up or we had new ideas, we found it effective to simply log an issue for it and work on it in the next iteration.

Manage Requirements

To track issues, we made use of the Github issue tracker and project management tool. These allowed us to maintain a list of requirements as issues to implement, organise who would be working on what by assigning the issues and ensured a good workflow as anyone could add or implement issues as they arose.

As well as spacing out work, the multiple milestones allowed us to gain valuable feedback early on in the process. This feedback let us gain more insight into what our client wanted. For example, we learnt that the client wanted the differences from the past to the future to be more accentuated than in our basic prototype. We were able to change the tiles as well as add music and decorations to emphasis the differences. The client also wanted the NPC interactions to build empathy with the player. To do this, we added the camera zoom on NPC dialogue.

We were very wary of scope creep and made sure that we were reasonable in the features we wanted to implement. A lot of small changes that wouldn't have any direct impact was cut and important features were prioritised. Instead of creating a game with many, less subpar features, we focused on one core idea (time travel). We ensured we implemented this idea well so it would be polished, engaging and pushed the narrative of raising awareness for climate change.

Model Visually

As part of our development process, we formed a UML diagram before coding. Despite this UML diagram not mapping well into Unity's ECS, it was helpful early to break up work and have a clear goal of what modules could be split up for individuals to work on. Elements such as level design, movement and characters were modelled on paper before being implemented in code. This allowed for earlier feedback and changes (on paper) to be easier to make so the design can be refined before it is implemented in code.

Use Components

As mentioned above, we broke the project down into modules that individuals/pairs could work on. Because of this, the prototype submission came together quickly and with very little merge conflicts. However, the closer we got to the end of the project, the more tightly coupled everything got, and we had to be more careful as to who worked on what.

Control Changes / Verify Quality

We used Git as our version control system, and defined early on into the project how we would leverage it in order to ensure our project could be worked on by anyone. For every feature, bug or enhancement, we created an issue that can be assigned for someone to work on. A pull request was made and another person would review it before it was merged into master. This maintained the quality of changes.

Playtesting often also helped us detect bugs. We constantly tried to break our own game so that our client and players of the game would not encounter anything that would take away from the experience. Having other people besides team members playtest the game, such as other SOFTENG students or our friends was extremely valuable as they gave feedback that led to better design, as well as uncovered bugs that we had not considered.