Blog Post Postmortem

 

Konner Rooney

2258-CAGD-370-01-4196

12/2025

Postmortem Blog Post

    Over the course of Autumn 2025, I worked with Andrew Fuentes and Jose Vargas as JAK Atlantic, to develop a prototype for a game called Color Clap, a hack-and-slasher in which the player takes color theory and it's mixable colors and utilizes them in combat and puzzles. As the Lead Designer, it was my job to shape the idea of our core mechanics, design different kinds of levels, and ensure that playtesting feedbck effected future versions of our prototype. In this postmortem blog post, I will reflect on this process: What worked well, what did not, and what I would change if I did it all over again!

    What Went Well?

            The most notable success out of our playtests was the game's main mechanic: color absorption. By defeating enemies of different colors, the player can absorb that color and use it themselves. Players can have up to two colors equipped, and can use color theory to mix colors together to create new ones to use. They can then use these colors for both combat and traversing the levels. 

Early playtests showed that this mechanic was engaging early on. Even when some playtesters found the mechanic confusing, they still communicated they liked the idea. This validation gave us confidence in this system, and indicated that we may have created lightning in the bottle! 

The team did an excellent job of responding to feedback, seeing it as data rather that insults. This mindset helped improve the prototype’s readability and accessibility. This willingness to adjust level layouts and pacing showed growth in our design maturity. Rather than designing only for ourselves, we increasingly designed for players who lacked prior knowledge of the system. This resulted in Color Clap receiving positive feedback, especially from frequent playtesters who acknowledges the changes in a positive manner.

I would also say that we did a good job responding to feedback, both the good and bad, and appropriately changing the game in a satisfactory manner. For example, testers struggled with remembering color theory rules and executing zipline traversal reliably. Instead of ditching these systems, we adapted level design to be more forgiving by expanding platforms and improving visual readability of the ziplines. 

Another aspect that went well with our group was the Agile process. We found that using it helped us maintain our momentum across the school semester. On a personal note, as the Lead Designer, Agile encouraged me to think about testable ideas first and abstract ideas second, keeping my expectations in check and not overworking my team. Breaking mechanics into user stories forced clarity and allowed features to be implemented incrementally. Additionally, regular stand-ups and sprint reviews created opportunities for feedback and alignment across disciplines, which helped prevent major miscommunication during most of production.

    What Didn't go so Well

            One recurring issue throughout production was unclear or unevenly scoped user stories. Some stories were too vague, leading to misunderstandings or rework, while others underestimated the time required despite being labeled as low-point tasks. This inconsistency would affect our sprint predictability and cause avoidable setbacks in our progress.

A big issue for our team was technical, particuraly when using GitHub. Conflicts via merging, branches, and miscommunications caused a notable amount of delays. There was even a time where the latest version of our resporitory got corrupted, and we had to go back to a previous version!

On a personal note, I've had a very negative experience with GitHub in the past, and it made me afraid to use it at times. This is something I need to work on learning, and hopefully doing so will make this happen even less.

Our amount of points in each sprint, particuraly at the midpoint of the semester, was notably inconsisennt. While early sprints were dense with tasks, especially during paper prototyping, later sprints sometimes lacked sufficient backlog depth. Additionally, unexpected circumstances such as illness (admittedly, this was mostly on my part) reduced output during certain periods, resulting in fewer completed levels than originally planned.

Although we adapted to this by polishing already-completed features, the uneven distribution made it clear how important to maintain a healthy backlog (and a healthy body in my case).

    What I Would do Differently

            If I were to do it all over again, I would try to plan out a daily schedule towards working on my Trello tasks, as there were days where I admittedly got lazy and didn't work when I easily could have. I also would've set myself to a better commucation standard and clearly signal what files I was working on so the rest of the team feels assured that work is constantly being worked on, rather than just sending something and/or updating the project once I finished it.

    Conclusion

            In conclusion, based on feedback and personal pride for my team and myself, Color Clap was a successful prototype that achieved it's goal of testing color theory as a combat and traversal mechanic, as well as satisfactory zipline functionality. While there were challenges in planning, technical workflow, and workload consistency, these issues provided valuable lessons that will directly inform my future projects!