Post-Mortem Analysis

What Went Right?

• Everyone on the team had the opportunity to explore different roles/disciplines in game development. With a team of only 8 people, everyone had a chance to explore any and every relevant discipline during production, giving us not only a chance to explore our own interests and a deeper understanding of the work developers in other disciplines do.

• Everyone was able to enthusiastically contribute to and shape the game during its ideation phase, which gave us a lot of fun ideas and a sense of direction. Additionally, it gave everyone on the team an intense sense of ownership over our game and unity within the group.

• The dedication of all developers was intense. Even at our most stressful moments, everyone on the team was willing to get together, examine what had been done and what was left to be done, and try to work on the game to get it into the best state it could be in. We were willing to try and fix the problems we encountered for this game however we could, regardless of how long it took.

What Went Wrong?

• We didn’t properly balance scope with our capabilities as developers. For most of us, including myself, this was our first time formally working on a game—which lead us to greatly overestimate what we were capable of in a single semester.

• We struggled with transparency and communication of plans, progress, and completion of tasks. Both the created Discord server and HackNPlan board were sorely underused, and all developers on the team struggled to convey their thoughts, feelings, and intent with their ideas and work at least once during development.

• We had to crunch for every major deadline. With such a small team and such a large plan, everyone’s attention and time were pulled in enough directions that a concrete timeline was usually left unmade. This led to a lot of work being put off and many weekends spent crunching to get builds in a presentable state. 

What Would I Have Done Differently?

• I would’ve taken more time at the start to research how long a development cycle for a complex game usually is. Our original idea for the game was grand and intricate, lore- and plot- heavy with various levels and enemies, all culminating in a twist ending. However, we quickly realized that we did not have enough time to accomplish that, and most of our plans had to be cut and/or adapted to better suit the number of sprints we had. If I knew what I know now, I would have considered a much smaller story, possibly one with a cliffhanger to build the intrigue we originally wanted without being too out of scope.

• I would’ve emphasized the use of a task management platform, whether that be HackNPlan, Trello, or even Jira. While it can appear rather trivial to new developers, especially when everyone is working in multiple roles, having a board of tasks and knowing how they relate to each other, who is working on what, and where progress on a task is at is crucial for easy, effective communication. I can’t imagine working without a task management software now, and wish I had had this same view back then.

• I would have expressed concerns I had regarding our core mechanic. When a grappling hook mechanic was suggested during ideation, I was unsure if it’d really be as easy as we thought to implement, considering our lack of development experience at that point. However, I said nothing, and neither did anyone else on my team, leading it to be our primary mechanic. The grappling hook ended up being incredibly difficult and time-consuming for us new developers to program, and if I could, I’d go back to the start and express my concerns, as well as suggest we consider different mechanics that could help us achieve similar platforming mobility and provide more time for us to work without crunching.