CAGD 377 - Postmortem
- Els Fouche
- Dec 12, 2025
- 7 min read
Plague Break
Plague Break is a match 3 game with combat and roguelite elements where you play as a survivor struggling against the zombie hoard. Creating matches allows you to damage enemies - defeat them quickly before they overwhelm you.
Sprint Review
HDRI & Light Baking
This sprint primarily focused on wrapping up the last in-progress features and ensuring that the game was ready for release. There were a few last-minute modifications that were required as well. Specifically, we learned that our use of a high-dynamic range image taken from Polyhaven under CC BY 4.0 was not allowed for this project. This image was being used as our cube mapped sky dome and for our environmental lighting. Needless to say this resulted in a short scramble as we tried to figure out what to do.
To resolve the issue I created an HDRI in photoshop. I'm unsatisfied with the result, even considering the limited time window we had for the image's creation. The new HDRI meant that the lighting for each of the levels needed to be baked again. Light baking in Unity can take a significant amount of time - as could be expected, the team and I were quite worried. Fortunately, the whole process from image creation to light baking to new build creation and release only took about three hours.
Visual Updates
Prior to this mild fiasco I worked on some visual updates to the game. The first element I was asked to work on was the attack indicator. We felt it was too easy to overlook, resulting in players not building an intuitive sense of when damage would be dealt.
This upgrade was quick to implement. The countdown timer was written in such a way that made it simple to hook the flashing icon into it. Following this, I implemented a flash when enemies take damage.
This feature was surprisingly tricky to implement. Some of our enemy models are already using emission on their materials which meant that changing it was ineffective for conveying a damage flash effect. In order to get the effect shown above I needed to store a reference to the enemy's material and swap it out temporarily for the flash material. This approach had unexpected consequences. Specifically, despite having written the function to flash the enemy's material several times it would, no matter how I changed the settings, only flash once. Overall I'm not happy with the result.
On the opposite hand, I implemented a screen shake when the player takes damage that I feel is quite effective and improves the experience significantly.
The screen shake effect was simple to implement. I did encounter, and correct, a bug where the camera didn't return to center when the device running the application was experiencing extreme thermal throttling. This was corrected by extending the window of time in which the camera would attempt to return to center and by implementing a check that would re-attempt the centering co-routine if not centered.
Postmortem
Now that the game has hit full release there are a few things to discuss.
What went wrong?
Initial Build
This project had nearly no significant, progress-halting problems. The only issue we encountered that wasn't able to be solved with, at most, a few extra hours of work was during the initial build. We were given guidance on how to create a mobile build for Unity. This guidance was exhaustive but had not been updated recently; following the guidelines laid out for us seemed to guarantee that the build would fail. I eventually resolved this by upgrading our version of Unity but several days of potential progress were wasted trying to understand and resolve this.
Documentation
Aside from that, there were some minor issues we encountered. Personally, I found the lack of documentation meant I was often left with no alternative but to directly ask the producer or designer. That issue persisted throughout the project and also resulted in cards that were insufficiently detailed; this sometimes bogged our team down.
Above I've included a snippet of the final version of the GDD. Our team's designer was very responsive to questions and happy to assist in eliminating any confusion but it's unfortunate that we were unable to rely on the game's design document. I would have preferred if we were able to avoid having to ask those questions in the first place. This was not a major issue at all, but I feel the project outcome would have been improved if the documentation was more fleshed out.
Planning
An effect of the above issue was the difficulty it created in planning out the code architecture of the project. Improve documentation would have allowed me to implement structural components in the code base early on which would have facilitated faster, cleaner feature additions. This problem was compounded by my unfamiliarity with the genre conventions of match-3 games which made planning ahead challenging.
Injury
Finally, I must note that I suffered a significant injury to my arm during this project. The inability to type that came with this injury halved our progress during one of our sprints. Fortunately, our team had a planned break around the same time as the injury which allowed me an additional nine days of recovery time, resulting in our overall progress not being hindered too much.
What went right?
Communication
This project ran very smoothly. Our producer was on the ball and helped ensure that communication between team members flowed smoothly and continuously. The project was continuously maintained and updated by our producer on our project management software of choice. Our team established a Discord server, as is the standard practice among teams, and as always it was extremely helpful in facilitating both immediate and asynchronous communications. Aside from the tangible communication elements, the intangibles also functioned well. There was no team friction, individual goals and work ethic largely aligned between team members, and each team member shared or could code-switch to match each other's preferred communication style.
Source Control
It was noted by the team that they were grateful for how well-managed our Github repository was throughout the duration of the project. Based on my observations, other teams often experience various slowdowns such as merge conflicts largely due to inexperience with Git and Github. In order to avoid these problems I've taken to setting rules in Github that prevent modifications to the repository without approved pull requests. This has vastly reduced the number of issues my teams have faced, and this project was no exception to that.
API Documentation
It must be mentioned that the documentation provided by Unity is extremely helpful. I strongly prefer working in Unreal due to the quality of its lighting and the improved speed of prototype creation but the two engines could not differ more in their approach to documentation.
Much of Unreal's API docs contain no more information than input parameters and return values with no discussion of why or how it does what it does. In some cases, it has no documentation at all such as is the case with many nodes available in the material editor. Meanwhile, Unity's documentation is extensive and features both an API and a manual. There are some elements of the API that aren't documented well or haven't been updated but overall it's so, so much better than Unreal. There is something to be said about being forced to read the actual code to understand what something does, in the case of Unreal, but that discussion is outside the scope of this postmortem.
Lessons Learned
There is not much to say here. A bit of advice - don't lean your motorcycle aggressively through a corner that's covered in wet leaves. And always wear a helmet. Joking aside, I did take some important lessons away from this project.
The Importance of Documentation
Though I was not responsible for the documentation of this project, it drove home to me how important it is to have a strong point of reference to fall back to when questions arise. In addition to that and despite this being a lesson I've already learned, it further reinforced how important it is to have a fairly solid plan for the end-state of a game. Being able to adequately convey this to the team is critical to do early on, as is reminding them of the goal periodically.
The Importance of Planning
Building on the above point, this project reminded me how important it is to plan a project ahead of time. Though I maintain that full UML class maps are overkill for short-term projects, having some sort of specific architecture in mind for a project is very important. For this project I sketched out much of this architecture on paper. During my injury I obtained a tablet so that I could still take notes with only one hand and I intend on switching my approach to include the tablet when creating diagrams and system architectural planning so that there's no friction with digitizing the notes.
Summary
This project went smoothly. Almost all of the planned features made it into the release build and we even included a unique hard mode that really changes up the gameplay. The team worked well together and despite two relatively minor setbacks we were able to complete the project with a minimum of scrambling, crunch, or other symptoms of mismanagement.
Issues
Old Issues
Issue #14: Blocks appear to vanish after matches.
The fix implemented in the last post has proven successful at guaranteeing blocks return to their home locations which has eliminated the bug.
Issue #15: The level select screen persists into levels.
This bug has continued to be a very minor, relatively rare occurrence. There are now three (3) reports of the bug occurring, one of which I've observed personally.
The circumstances under which the bug occurs have been difficult to pin down. Testing has not proven fruitful in narrowing down the potential trigger(s).
The issue is game-disrupting but not game-breaking. It can be corrected by restarting the application.
Due to the project's conclusion this bug persists into the full release.
Issue #16: The game board has shadows cast on it by enemies.
This issue was fixed by a workaround that turns off shadows for the enemies in order to prevent them from obscuring the game board.
New Issues
Issue #17: Enemies only flash once when hit.
It would be more aesthetically pleasing if the flash flickered in a way that showcased damage had been dealt to the enemy.
This bug's cause has yet to be determined.
The bug persists into the full release.
Comments