The Crescendo - Postmortem

Video Game Production

    For this project, we were tasked with creating a 2D scrolling game prototype in a group of 3. My team consisted of the following: Anthoney the level designer, Myself as the programmer, and Alex, our team lead. This past semester while developing The Crescendo prototype, I learned a lot about the design process and development cycle of games in the industry. I also learned a lot about the Unity game engine. I will be covering the process of our game with what went right, what went wrong, and what we could do to further develop this game.

What went Right:

    To start, I am happy to say that having Alex as our team lead helped us immensely over the course of this development. Alex was eager to start building ideas for the game, and this helped us start working toward a unified vision of our core game concept. He went above and beyond to clarify upon mistakes being made, and to advocate for us as a team in class and for additional playtesting. Over the course of the semester, our team learned how to properly follow the AGILE workflow to track work being completed, and how to better collaborate on a project as a team.

    Another strength that our team had during this development cycle was our ability to gather feedback. During each playtest, our feedback forms provided to players allowed us to collect relevant and important data to better improve the player experience. We also had additional playtesters outside of our gameplay test group get hands-on experience with the game prototype and provide data. I believe this helped us improve our player experience early in development as we had feedback from players outside of game development.

    Where I think our team did best was pivoting from our original scope for this prototype to something that our entire team could handle. Early into development, we were able to see where our strengths and weaknesses were in the production pipeline in regard to our assigned tasks. Level design would end up taking much longer than originally anticipated, and it was clear that we were not going to hit the original goal of full fleshed out levels. After our initial kinesthetics playtest, our team would discuss which areas were taking the longest, and where we needed to allocate additional time for those weaknesses. Alex did a great job shifting this focus and reigning in our scope as team lead to focusing on core tasks.

What went Wrong:

    One of the largest issues we had during this production was scope. As a team, we originally intended for more levels and songs to be available to players. Level design was to be a core part of how play was to be varied and different for the player, as each level would be tied to a specific song. We discovered very early into development that level design would take too long for our level designer to complete, so our team lead stepped in to complete our 2nd full level. Iteration over these levels would take much of the next 2 sprints, and was one of the larger obstacles for our prototype.

    While transitioning over into the digital design of our game, we had issues finding a clearly defined way to set our project. As the programmer, much of this was left to myself to set up and verify our version control. Members of the group were unable to understand the application GitHub, so we settled on using Unity's Collaborate feature. Though this made collaborating incredibly simple, it led to a lot of confusion about what could be edited at specific times without causing merge conflicts.

   

Another issue that our group struggled with was accurately tracking our work being completed with Trello. Our team initially left a lot of work unrecorded, especially in areas of development that required assistance from other team members, as this was only tracked as a single ticket for a single member of the team. As Trello was advised to be left to the lead, our group members felt uncomfortable modifying the board, and didn't reach out to have small tasks added that were necessary. However, we were able to learn from this over the course of the semester, and more accurately tracked the work that was being completed as we moved through additional sprints, and received more feedback.

The Future:

    Moving forward with this project, I would heavily suggest to our team to move to different version control and learn the basics of GitHub, or another version control software. This would greatly alleviate the stress of Unity Collaborate from causing issues in the future. Our group would also benefit from a system(within Trello or another source) where a member of our group can request assistance from another member of the team for small tasks. In a team of three people with a single programmer, we ran into many instances where other members of my team needed help setting up a mechanic in their level or to implement a system so that they could continue on their task. These tasks were subtasks of the other group member, so this work often went overlooked in sprint reviews. I plan to use what I've learned from this develepment cycle to improve on the games that I make, as well as how I work as a member of a larger team.