Post-mortem

Post-Mortem: What changed from our initial ideas?

We changed the amount of mini-games from our previous design, and recycled them across various days to accommodate for the change. We initially wanted to have around five or more mini-games the player had to interact with—completing various sets of tasks—to progress through the game. We had also initially planned on adding more narrative-based elements, including a storyline that explored the setting and the player character in-depth. We initially wanted to include journal entries that gave the player information regarding the premise of the game, and the various tasks needed for the player to progress. Due to time constraints, we had to reduce the amount of narrative elements, and focus on core functionality. We added passages to the title and end screen to include some passages that gave the player a sense of the game’s narrative. Due to our shift in priorities, we focused more intently on ensuring the timer bar would update across various mini-games, and the overarching game manager—which procedurally generated tasks and accounted for their completion—were functioning properly. 

Despite some of the changes in priorities—especially the shift away from including narrative elements—we were able to largely keep the structure of the game from our initial proposal. While time constraints also accounted for the deletion of some of the mini-game tasks, the overarching premise and structure of our game remained consistent. Our finalized product was similar to our initial proposal, consisting of a series of mini-games the player had to interact with to progress. Though the mini-games themselves were slightly altered due to some technical issues, their base structure remained similar to our proposal. The base structure of our game, including the day transitions, overarching timer, and mini-games remained consistent. 

While the base structure of the game remained consistent, there were some issues in the code structure and work distribution. The code structure was difficult to read at various points, and lacked comments or documentation that explained various functionalities. This was especially evident in both the timer and game manager‘s respective scripts. These scripts were not well documented, and lacked clarity for other team members to understand and expand on their implementations. Due to this issue, team members that had initially set up these scripts were delegated to further refine the code, and accommodate various changes. This created a bottleneck for the development of the game, introducing dependencies that effectively prevented other team members from contributing towards certain scripts. Another issue we encountered was the unequal distribution of workload among team members. This was predominantly due to how various roles—including code development and visual direction—were set up, creating situations in which certain members were not able to contribute as much to the game development as others. As such, the brunt of the game’s development was assigned to the code development team. Additionally, there were issues in scheduling that halted the progress of our game. Due to this, the majority of implementations of important structures including the timer bar, was created towards the middle to end of the project. 

We would create a schedule that allowed all team members to attend weekly meetings. This would ensure that we discuss our respective progress on the game, as well as any pending tasks or dependencies. This would allow us to collaborate on various tasks, and remain updated regarding implemented milestones. We would also distribute the workload more evenly amongst all team members. This would predominantly include assigning more code-based tasks across team members. While this would differ across team members due to other responsibilities, specifically for the art direction team, it would ensure each team member contributes to the code development process. This would also ensure that no team subset would be largely responsible for implementing the game mechanics, mini-games, or overarching code structures. Additionally, we would also document our respective scripts and implementations more thoroughly. This would ensure that each team member understands another’s code, and can directly contribute to it. This would also ensure that there were no inherent dependencies created, as other team members could alter remaining features or edit the base functionality. 

Given another week of additional development, we would include narrative elements, visual effects, and extend the gameplay through additional tasks (and their corresponding mini-games). We would implement a system that allowed the player to interact with objects near the captain’s quarter that displayed various pieces of information regarding the player character’s background, the premise of the game, and the tasks required to progress. This information would update as the game progressed, providing the player insight into the game’s world and their inhabited character. We would also implement additional visual effects to indicate the completion of an entire day, or include visual effects in mini-games. One example would be including a burst of smoke (or muzzle fire) from the cannon as the player interacts with it. Other examples could include unfurling the ship’s sails or pulley system. These effects could enhance the game’s feel, and appeal to the player. Additionally, we would also extend the gameplay through introducing more tasks and mini-games. This would allow the player to explore the ship’s environment, and interact with various objects. This would also give the player more insight into their surroundings, as well as the various tasks necessary to maintain the ship’s operations. Furthermore, from a structural perspective, this would make the current list of tasks feel less repetitive to players.

Team Member Comments:

Cal: I think I could have done more work - I did a fair amount, but at the end I definitely felt like I hadn’t done quite as much as some of my group members. I also could have commented and documented my code better. I did so very minimally, and that ended up making it hard for people besides me to work on systems I had created (like the game manager). For what I think I did well: I felt like I did pretty good staying in communication with my group, and organizing tasks for everyone as well as codifying our plan. I think my biggest takeaway from this for future group projects, for me, is definitely the importance of documenting my work so others can contribute and use it.

Isha: I personally think that because of challenges in scheduling, it made it difficult to communicate tasks and assign responsibilities to team members. While there were updates regarding various code and design changes in the Discord, due to the inconsistent meeting times or dates, it became difficult to understand the overarching progress of the game. This made it difficult to check-in on team members, and discuss the direction—structurally or otherwise—of the game. Additionally, this created instances in which there were weeks that team members heavily contributed to the game, and other instances in which there were virtually no updates. Despite this, as we neared the middle to end of the project, we were relatively quick to respond, and handle different responsibilities. Though this was in-part due to the deadline, it was greatly appreciated as team members contributed towards the game, and made our vision become a reality. While there were instances in which our team could have handled the situation better, given various course constraints, I’m proud of our game and the progress we made (even if some of it was last minute).

Shazer: Issues with team coordination limited the original vision of the project, however I do believe that the team managed to exide expectations despite the limitations. The biggest hudle was the independent additions of members of the project without proper direction. This cause the stability of the build to lessen, and it lead to a last minute crunch to be able to make the game loop be functional. With a stronger coordinated effort I believe that the team has the potential to accomplish larger projects.