Getting Out of Hand
I have lately been struggling in the development cycle with this concept of “control,” where each and every element you add to a given application has some level of necessity from other components.
This can go for any application, whether you are creating a web page that has elements reliant on each other, like an e-commerce site where a product list interacts with a shopping cart and a user profile. If a product is removed from the catalog, the product list must be updated, the shopping cart should remove the product if it’s already added, and the user profile may need adjustments to saved preferences or items. Where should this logic live? Should the product list notify the shopping cart, or should the cart handle the changes independently?
In my case, when programming a simple video game, Imagine an RPG where a character has talents that they depend on for specific status updates. Let’s say a situation arises where the player must remove that talent from their list of talents. The Talent could have multiple levels that need to be taken into account, so handling that would be simpler from the Talent code. Ultimately, the talent resides in the character who has it, so resolving it in the character code would make the most sense. So what should I do?
When I have an Inventory system, should I have the System instantiate Game Objects representing Items, or should each Item manage its own Game Objects?
Praise Be the Tree
When I develop, I’ve found a sort of serenity in development from imagining a great upside-down tree. The root of this tree is where the game begins, and from it stems each component. These components can then reliably reference each other and be regrown from any section as long as the tree roots remain intact.
So take this diagram, for example. When Developing the Inventory system, we develop the system so that we can remove any of the outer nodes and replace them just as easily. For example, when a game is initially loaded, the Inventory populates itself with items. Shortly after, the visual inventory (Which is nothing more than a visual interface for calling Inventory functions) instantiates its own visual items, each corresponding to its respective items. When the User tells the visual inventory to get rid of an item, it simply removes its own visual item before telling the Inventory to remove that item from its own system.
This way, we can reliably let other systems depend on elements of that system without being too intrusive or resulting in Deadlocks, where each system requires an element from from another to operate.
Hopefully, every now and then, I’ll come back to this blog to recollect on this concept because, without it, you can hit some pretty heavy roadblocks in development…
