The Problem: 

 One of the main issues I have encountered when trying to design an enemy system is tracking what the player is doing at any given time. The aim of knowing what the player is doing is to allow the ability to create responses for the enemy AI. For example, if the player decides to take a potion, I want to know about it so that I can tell the enemy AI, “Hey, now is a perfect time to rush the player”, etc. Being a novice game developer, this was not something I considered ahead of time when diagraming out all the systems of the game.

Yes, the player could deal damage to the enemies and yes, the enemies could see the player and attack, but that was about as deep as it got. In order to rectify this issue, I had determined it made the most sense to create a damage and attack component wherein the damage component would manage all things pertaining to health and the attack component would maintain all things dealing with attacking. On paper this all sounded grand. The intent was to design a modular damage system that would account for variables such as I Frames, whether the player or enemy was blocking at the time of taking damage, etc, and the attacking system would just house all functions related to attacking.

In order to test the systems, I had created a testing player as to not interrupt work being done to the player. Once the damage and attack systems were created and tested, I was ready to move to implementation process of taking these systems and adding them to the player. This is where the issues started to pop up.

One of the variables I did not consider when designing the damage system was the fact that the player already had a health component attached to it but also how many other systems were tied to that health component. In this case things like the HUD, potions, and hurt functions were all tied to the health component. As you can imagine this created quite the dilemma.

The Solution:

At the time of writing this blog post, a permanent solution has not yet been implemented. In an effort to stay on schedule with our milestone submissions, we opted to instead create a soft fix just so that the base functionality would work. This resulted in essentially calling both the damage system variables as well as the health component variables whenever the health was touch or effected. This gave us the desired result that we wanted but it did not solve the over arching problem. Moving into this week, there are plans to solve this issue more formally. Instead of the damage component housing its own health variables, add a health component variable to the damage system that uses the health components variables to both get and set the health. An implied tasker to this is to ensure that the enemies also get a health component so that the system to continues to operate correctly.

<Reference image of locations wherein both the damage system and health component health variables had to be called in order for the health to update properly>