Blog Post Postmortem
Postmortem
This semester, I had the pleasure of working in an amazing group of three for CAGD 377 Mobile Game Development. This team consisted of Jen Davalos, our team lead and modeler, Liam O'Hare, our scene designer and general jack-of-all-trades, and myself, Kade Chambers, the lead programmer. Over the course of the semester, we designed and built our idle mobile game, RoboFactory. This development period included a series of 7 sprints, concluding with a playable game uploaded to the Google Play Store for public access and download. You can go ahead and check it out here!
.png)
Our game features 5 different factory levels for players to experience as they earn more gold, with each factory bringing its own theme, assets, and layout. Thanks to the work done by both our talented modeler and designer, we were able flesh these factories out with a lot of detail and character. As the player progresses, they are able to upgrade their factory components in order to make things move down the factory line quicker, increase production speeds, and more.
From the beginning of development, we knew that we were creating an idle game, with parts moving down the factory line, and eventually creating a full robot. We also knew that we wanted to include a turn-based combat mechanic for players, so that players could battle other robots using the bot that they were constructing in their factory. However, it wasn't until our first feature playtest when we discovered that players wanted chaos in this otherwise predictable factory line. We were using Unity's built in physics engine to shoot robot parts down our factory line, at a rate equal to the speed that the player could tap. And tap they did. Quickly, and a lot. Soon, robots were flowing down the conveyors stacked over one another, falling over the sides, and causing a huge mess. And players loved it. So we focused on that feedback and dove back into development with this in mind. Eventually, we realized that turn-based combat wasn't going to fit into this game, and we went all in on factory production based around the physics interactions.
What went Right?
We had a lot of things go right during the production of Robo-Factory. Key among them was our team's communication. We kept a Discord server updated with what we were currently working on, progress being made, any additional ideas, and any incredible art work created for the game. This really kept us motivated throughout the entire semester to keep building cool things for our game. This motivation and cohesion had us working from a place of excitement and passion, making work feel less like a slog, and more like a team endeavor to make what we could in the time we had remaining. Our team energy was high, which led us to fitting as much as possible into our game.
Additionally, the team had a great work ethic, completing plenty of work every sprint and having lots of content to show for every sprint review. Finally, the team collectively had a good understanding of all of our tools, meaning individual team members could get a lot done on their own. Having another member of the team that I could rely on to interpret code and modify it as needed meant that I had additional time to spend on other areas of the game, while they incorporated their additional work on top of the work that had already been implemented. This turned into a huge time-saver and was an experience that I do not usually have on teams as the programmer. This allowed for more features and assets to our game that we originally had not planned, which benefited our team greatly earlier in production. Later in production, however, we allowed our ideas to stretch well beyond the time remaining, which leads me into....
What went Wrong?
Scope. We got overly ambitious near the end of our allotted development time, going as far as to modify huge systems during the final sprint. Because we were attempting to add more features, we did not give the features already implemented enough time to be polished and perfected before publishing. On the programming side of this development, this put a lot of pressure on myself as I needed to spend time trying to make sure features were working while trying to deliver polished systems for my other team members.
Having our full team working in-engine sooner would have also greatly benefitted our team. Many art assets were not used in the final build, though they took a good amount of our modelers time to create, texture, and hand over to be rigged for gameplay. Many of these assets were created for an entire game system that never made it to prototype, as we pivoted away from including turn-based combat half-way through development in order to maximize the potential of the idle game experience. We just did not know how to properly include the mechanics while maintaining the same fun that players were having during playtests.
The final huge hurdle that really impacted our team throughout the entire development was inexperience with GitHub. Besides myself, no other team-member was comfortable resolving issues that might pop up when using the software with Unity. Because of this, there were a lot of late-night messages prompting me to check out the Development branch in case somebody had accidently broken the build, or lost progress. Having time to teach each member exactly what they were able to do before digital production could have saved a good amount of time, as well as stress.
What would I do differently next time?
Scope. We got overly ambitious near the end of our allotted development time, going as far as to modify huge systems during the final sprint. Because we were attempting to add more features, we did not give the features already implemented enough time to be polished and perfected before publishing. On the programming side of this development, this put a lot of pressure on myself as I needed to spend time trying to make sure features were working while trying to deliver polished systems for my other team members.
Having our full team working in-engine sooner would have also greatly benefitted our team. Many art assets were not used in the final build, though they took a good amount of our modelers time to create, texture, and hand over to be rigged for gameplay. Many of these assets were created for an entire game system that never made it to prototype, as we pivoted away from including turn-based combat half-way through development in order to maximize the potential of the idle game experience. We just did not know how to properly include the mechanics while maintaining the same fun that players were having during playtests.
The final huge hurdle that really impacted our team throughout the entire development was inexperience with GitHub. Besides myself, no other team-member was comfortable resolving issues that might pop up when using the software with Unity. Because of this, there were a lot of late-night messages prompting me to check out the Development branch in case somebody had accidently broken the build, or lost progress. Having time to teach each member exactly what they were able to do before digital production could have saved a good amount of time, as well as stress.
Moving forward, I would like to spend a considerable amount of time in pre-production, time that we are not afforded during the course of a single semester. The planning and considerations made in this stage of development would go a long way in ensuring that work is not being done that does not significantly affect the final product and would solidify a backlog of tasks to be completed. This was our team leads first time stepping into the role of producer, and it takes a lot of time and effort on top of their regularly scheduled roles to learn how to create a proper backlog and maintain it for a team. I believe that the additional time planning would have helped make Robo-Factory the best it could be.
On my next project, I would also like to improve the work pipeline between myself and other developers working in-engine. I was able to make most of our systems incredibly modular and easy to understand, allowing for quick setups between factories once they started being created, but I feel this could be improved even more to allow for easier modification once systems started to change. As I work to become a better game systems programmer, I plan to improve on this immensely.
Conclusion
I am incredibly honored to have worked with the talented teammates that I had. Jen Davalos and Liam O'Hare created amazing assets and content for our game that I am proud to have worked on with them. This semester has been an incredibly busy, stressful, and exciting ride, but I have grown immensely from the persistence and practice that this project and class have given me. I look forward to the future, ready to take on my next challenge. Here I come 495.
Comments
Post a Comment