In Harmony was developed in Unity by 30 seniors as a capstone project at Bradley University. It is a music-themed puzzle game that explores the relationship between a mother and her son. I was the programming lead for this project, where I organized programming tasks in addition to upholding coding and version control standards.
The slower movement of our Alpha build (top) compared to the faster movement of our final build (bottom).
As we were working toward our Alpha milestone, it became clear that our current player movement speed was far too slow and unresponsive. Our movement system involved various entities taking turns. So, the player would move, then enemies, then objects in the world. This process could often take multiple seconds and the player cannot move again until this sequence was complete.
At this stage of development, a full overhaul was unfeasible so I turned instead to modifying the existing systems. I drafted a proposed solution, documented here, that involved shifting when turns started and ended to allow enemies and world objects to move while the player character was still walking. The end result would be parallelized movement so the player could perform another input almost immediately after their character's movement ended.
After pitching this idea to production and our professor, a small strike team consisting of myself and two other programmers worked on its implementation. We completed our work within the two weeks between our Alpha and Beta milestones. This resulted in significantly more responsive movement, as can be seen on the left.
Another major component of my work as the programming lead was establishing code and version control standards. These can be viewed here in our Technical Design Document. In addition to defining good programming practices, there was a particular focus on making code that would be maintainable across our two semesters worth of work as that was a longer project timeline than most of us were used to.
It also covered our GitHub pull requesting process in which individual contributors make a thread in our team's Discord where reviewer feedback would be discussed. This aided in ensuring feedback could both be received and iterated upon in a timely manner. Following the standards laid out in the above document, we managed to go through the entire project without our main branch in GitHub breaking even a single time.
An example of a pull request notification with a discussion thread made off of it.