Hey There

Logan Coggins

Apex Ballistics Postmortem

 

 

Overview

Apex Ballistics is a first-person shooter where the player takes contracts on dangerous monsters. The player then must use precision and stealth to neutralize the monsters and make it home safely. The world is post-apocalyptic, and there is never only one monster. The monsters have adapted to humans and hunt them in ways humans have never been hunted. The team working on this consisted of two narrative writers, one system designer, two level designers, one UI designer, and one admin/technical designer. In this postmortem, I will reflect on what went right and what went wrong. In addition, reflections on what could be done moving forward will be included.

 

What Went Right

The team had an understanding immediately. The early development process was clean and concise. The ideas fell quickly, and we were able to really understand the direction we were going to take this. This benefited the team by allowing us to understand what everyone was thinking, provide prototypes that the team could see quickly, and prevent arguments and confusion as the project progressed.

The team was also multi-talented. Even though everyone had their desired role, everyone received assistance when needed. Several of us stepped into multiple roles to keep the team on track and resolve bugs. This benefited the team by keeping it on track and preventing a wall.

Finally, the third aspect that worked was scheduling. The team is a mix of online and in-person students. It was anticipated that this would cause significant scheduling issues. However, the team never once struggled with it. While some students (myself included) have full-time jobs outside of school, our absence was easily absorbed by the team. In addition, when those with jobs weren’t working, they contributed substantially.

 

What Went Wrong

The first thing to go wrong was a lack of understanding. Not a lack of understanding of what the team is doing, but a lack of knowledge of what we need to have presentable. Each week, the same complication surfaced. As a team, we struggled to understand what was required and what was not. This caused unnecessary stress and panic near each deadline.

The second problem the team ran into was scope creep. After week two, it was apparent we were attempting to add far more than the timeframe allowed. This caused a significant block on work until we figured out what we were going to cut.

The third thing to go wrong was the version control. A couple of people on the team knew how to use GitHub, but only at a basic level. In the first two weeks, the team struggled to use GitHub effectively. By the end of week two, the problems with how to use it were solved. However, in week three, a forced merge broke and deleted a lot of work. This caused the team to bottleneck while we scrambled to fix the bugs.

 

Reflection

The first reflection for future development is to spend more time in the early development stages. While the team synced up fast and understood what we wanted, there should have been more time to understand the scope of what we were trying to do. Making this adjustment will slow the team down in the early stages, but prevent hefty mid-game corrections to the scope.

The second reflection is to designate one person to handle GitHub.  While setting it up and making personal branches is simple, merging multiple people at once is not. A single person should have dealt with this to prevent overlapping merges that result in lost work. In future iterations, this will be necessary.

The final reflection is to increase communication between members. Having half the team constantly communicating and the other half only when it's convenient is not a recipe for success. In future development, maintaining open communication as often as possible will significantly improve the team's performance and reduce errors and misunderstandings.