Final Reflections

Reflection on Team Dynamic and Development Cycle

Prior to the development of the game, our team had concerns about managing and evenly splitting the heavy workload across 7 people. As none of us had any previous experience in game development, we were cautious of scope creep. However, after the first development iteration where we produced the prototype game, we felt that coordination between team members was relatively flexible. This was due to there being many aspects of game development that could be worked on in parallel, such as creating the game world UI and setting up the backend game logic. Thus, in the final iterations, we were more confident and were happy to expand the scope of the project by introducing several new features to the game, such as more dynamic interactions with the world through weather events, an achievement system, sound and SFX, and custom cutscenes. The solid foundations set out in the prototype allowed us to easily implement and integrate more features due to the extendable nature of our game architecture. For example, implementing achievements tied in closely with the logic of our game metrics.

One issue that we struggled with was merging different feature branches. While there were rarely semantic or syntactic merge conflicts in our codebase, there were often merge conflicts residing in unity generated files. It was the first time any of us had used git LFS and thus we also found issues when tracking these LFS files. This is because they would occasionally disappear after merges, resulting in conflicting world assets across the branches. The merging workflow also made for a more confusing commit history due to the multitude of merge commit messages. Reflecting on this experience, we felt that a rebasing workflow would have allowed for a cleaner commit history.

Playtesting with other teams proved to be a valuable experience as it exposed many core issues in the game mechanics while also highlighting aspects of the game many people enjoyed. Although we playtested the game extensively within our team, we felt that balancing the game mechanics (how much each metric gains and lose after a decision) proved to be difficult due to our inherent biases towards how the game should be played. As we know which decisions are "good" and "bad" at each stage we would subconsciously pick paths that allowed us to progress to the next level. Thus, when playtesting with other teams, we found that our game was extremely difficult for first-time players as one or two bad decisions would easily put them at a position where they are vulnerable to losing in the very first level. Alongside showing the rough areas of our game, playtesting also showed us what we did well. Many playtesters enjoyed the narrative aspect of the game and found the game world and plot very engaging and thus we decided to emphasise this aspect more by adding more dynamic elements in the game world, such as cars, NPCs, weather events and building events. Reflecting back on this experience, playtesting for other teams also proved to be a valuable experience as we were able to witness how other teams decided to manifest climate change elements in their game.

Overall, we all thoroughly enjoyed working together on this project. For many of us, it was the first time where we had to coordinate the efforts of each team member while using a technology stack that was entirely unfamiliar. Learning to use the Unity engine proved to be a more manageable task than expected due to the extensive support available online for the platform. A big challenge instead was actually coordinating meetings, delegating tasks and making sure everyone was on the same page as we were all busy students who had many other commitments to fulfill. The use of GitHub projects and Google Drive allowed us to coordinate efforts much more easily rather than assigning work through verbal or online communication. Following the RUP process also helped with this delegation issue.

Reflection on RUP

To ensure that the final product met the requirements specified by the clients, an adaptive agile process was followed. Characteristic of the agile methodology is the iterative development of software, involving the development phases and the creation of a prototype based on the previous iteration. It is mainly achieved through feedback, where developers are able to evaluate and revise the project after each iteration. This adaptive procedure was able to be implemented through regular presentations that were scheduled with lecturers of the Software Engineering Design II course. Consequently, at each stage of development, revaluation of the product ensued, and an iterative approach was engaged with the development of SunnyTown. To achieve this, the four main phases of software development processes were considered at each iteration:

1. Inception, which involved consulting the specifications outlined in the project brief, as well as interpreting the responses received from the clients at each week’s design meeting. Abstracting the requirements correctly was a significant factor to ensure that the product would satisfy the clients of SunnyTown.
2. Application design which included high-level design decisions followed by more detailed low-level design decisions being determined from knowing the requirements. To assist with the development of SunnyTown prototypes, models were created to represent the look-and-feel and the functionality of the application. For example, screen diagrams and Lo-Fi prototypes were drawn to depict the GUI, scene transitions and features.
3. Implementation of code which included recreating scenes from the screen diagrams of the previous design phase, as well as implementing features discussed in the previous phases.
4. Testing which involved ensuring that the features implemented in the produced prototype were working as intended, and detecting faults that were introduced into the system

Overall, adopting an agile software development process ensured that a functionally sound game was built that met the quality requirements set out in the project brief. The adaptive approach was beneficial to our project because we were provided with feedback from the clients at every stage of development. Therefore, as a team, we were constantly able to re-evaluate the application and consider further improvements and we are confident that our game, SunnyTown, will satisfy the client's vision.