Structuring Code in Multi-Interactive Systems by Diogo Vieira Avila

BEFORE YOU READ: This post will not be about anything flashy, I did mostly backend work in this sprint, and the front end was not that interesting, but bear with me, it is still very cool.

As you develop a software, even with good planning, there is a chance, if you are working on a small enough team and limited budget. That additional requirements will pop up, that may enter in conflict with your initial architecture plan. It is my belief that two deal with such an issue two things are needed: a stingy dependency mindset, and well defined polymorphism line.

As a strategy game, project banner has a lot of interconnected systems, and with increasing demands for functionality, its easy to get lost, or default to the easiest way out, when some part of the code is inaccessible (if I need something, search for it and pull the reference). I had to deal with this problem a lot when trying to fully lock the player behind the "turn combat ruleset". The player is in reality controlling a "brain" this brain interacts with mostly all systems in the combat scene even if indirectly, the player characters, the enemies, the grid points, the game mode and event spawner. So what is the best way to accessing it all? YOU DONT!

To solve this problem in a way that made the code remain scalable with the new demands, and retain a lean dependency list, instead of adding behaviors to my centralized location (the player "brain"), I added and moved them out of it! I refactored the brain into a simple reference checker and action demander to the player characters themselves, which had the actual relationship with their base class and the game mode (which was given their ownership by the spawner). This paid of, as the number of bugs that would normally come from such a interwoven system to be minimal, directly contributing in the fastest build deliverable this team ever had!