Another week glided by. I worked on block damage and regeneration system. Lets take a look at my work this week…

BLOCKing the way

The block damage system, which I worked on during the second week, gave a surprise during the start of the week, as it stopped working properly after the changes in Regeneration system. The “damage” part was working fine, but regeneration was not happening. It took me a few hours to figure out that the problem was incorrect assignment of nextRegenTick parameter of Health component.

So, this prompted me to add a test for block damage system, so that we don’t have to manually check for the working of block damage every time we make a change.

Revamping the Regen

Next up was the Regeneration system. Extensive discussion happened in slack/discord channel for whats required in an ideal regeneration system.

The intial idea was to move the regen info part to new component, and the RegenAuthoritySystem uses scheduler to implement regeneration. Regeneration of an entity is like a periodic event, and I did not know how to implement one. So the natural place to look for it was the DelayManager present in the game engine logic. It has a generic scheduler, but I needed a simpler version for the Regen system. So I tried to grasp as much as I could from there, and wrote a simplified version of it for Regen.

But just a scheduler was not enough for making regeneration possible. Blocks was again acting bizzarely. Player has having erratic regeneration, with first regen happening instantly, and subsequent one delayed. This turned out to be default assignment of nextRegenTick in Damage system. I should really be careful with how this variable is used …

The next problem arose when someone (was it me?) asked in the chat on what happens to the regeneration related information when RegenComponent is removed. How will anyone know what is the regeneration rate of the player, or any other entity.

This naturally lead to exploring other ways of implementing regeneration. One obvious way was to have two regen components, one having the info, the other having the state of active or not. But jellysnake (my mentor) pointed out that having an “active/inactive” component is same as having a trigger event. Also, some points on what things should be possible with regeneration came up.

At this point, I was a little confused on how to implement such system. Cervator (my another mentor) came to rescue, pointing out one way of implementation. So, I improvised (as best as I could) that, and came up with an implementation which happens to cover most of the “features” of ideal regen system.

My current implementation has a RegenComponent which stores the EndTime and Value of regeneration, allowing multiple types of regeneration added to same entity, for different time intervals. ActivateRegenEvent with required fields adds regeneration to the entity. The damage system adds the “baseRegen” whenever attacked.

Currently I am struggling with how to handle delay before regeneration with each regeneration type. And of course the blocks. The main problem with them seems to be that their regen rate is less than 1 (in float, of course). So changing it to int almost always make the non-regenerable. I will have to come up with some good work around for less-than-unity regen rate entities.

Moving around damage

The health authority system was doing a lot of things. So, it was decided to break it up into individual systems. So, I moved the damage logic to a separate system : the DamageAuthoritySystem.

This is work in progress, with more javadoc and maybe tests remaining.

What next?

Completing the regeneration is first priority. Once it is done, I will move on toward the “Restoration” logic. Lets see how soon I can get to that…