Systems Breakdown
Game Manager
This system was designed with the intent to be the backbone of communication for all of the features, smaller systems, UI, and Data Tracking for the game. I created a series of Blueprint Interfaces that sent messages to the specific blueprints that needed to know when things happened in the game. I felt this would be a much more efficient way to communicate because of our team structure. If we were to use other forms of blueprint communication it would have likely caused more issues and delayed progress further. We had several issues early in development while some of the team members were getting acclimated to using these systems instead of less efficient and more expensive forms of communication like casting. Having all of the data be collected in one place meant that I could debug any issues much faster than would be possible if the code was all stored in several different places. Toward the end of the project when we were focusing on polish and testing this became more apparent. Instead of taking days to squash bugs we were able to find, squash, and document bugs in a matter of hours. This gave us an advantage over other teams of a similar size because we could produce more iterations of our test builds thereby finding and squashing more bugs before the final deadline.
The Game Manager encapsulates variables necessary for the games economy, wave tracking, enemy tracking, player base health, game state, tower selection, and specific references to other systems. Where some game types would use individual components to keep track of variables, I instead opted for a manager that is persistent in each level of the game. This allowed us to create one reference and then from that reference facilitate the transfer of information to all of the other systems that make the game function. For example, the spawning in each level uses the variable in the game manager to know when to spawn enemies and updates the game manager in real time so that the player always knows the amount of enemies they are facing.
The Game Manager encapsulates variables necessary for the games economy, wave tracking, enemy tracking, player base health, game state, tower selection, and specific references to other systems. Where some game types would use individual components to keep track of variables, I instead opted for a manager that is persistent in each level of the game. This allowed us to create one reference and then from that reference facilitate the transfer of information to all of the other systems that make the game function. For example, the spawning in each level uses the variable in the game manager to know when to spawn enemies and updates the game manager in real time so that the player always knows the amount of enemies they are facing.
Tower Build Menu
The Tower Build Menu is a Blueprint Widget that went through several iterations before landing on the final version the game is currently using. Early on it was a series of hard coded buttons that did only specific things. As we progressed I took over responsibility of the menu from a teammate that wasn't comfortable doing the coding necessary to make it more modular for the future of the project. As it is now when the player clicks a tower tile this menu is created, it then communicates with the game manager to find out which level the player is currently in, it then locks and unlocks the buttons for tower creation according to our IPM chart for the current build of the game. This was a huge step toward an overall feeling of consistency according to our playtest feedback.
Color Coding Comments
Below in the slideshow is the color coding system I created for the entire team to use for the project. While this isn't a necessary system for the game to function it is one of of the most important systems for any design team to create. Each color code is unique to the project they are created for and needs to be agreed upon by everyone that has their hands in code creation. If everyone buys into using this system from the beginning then you start with very clear code. Having the coder's intent commented in each section for each event that happens made tracing down bugs and issues later in the process simpler. However, I learned a lot about my habits as a coder and the habits of other coders over the course of this project. If I have a say in my next project I will be championing a constant schedule for code and comment reviews. This isn't something my previous team did and by the end of the project I was wishing we had been. Over the course of our project commenting became less important to some team members and basically non existent to others which really slowed down our ability to trace down the causes of certain bugs. Given our tight schedule I'm very happy with what we were able to release to Itch.io and I've learned so much more about game design during this process that I'm excited to continue my journey and see what my next project holds.