Unique Component System

One basic implementation for such "pools" is having a unique component + system for it.

Why this way and why not?

This way of implementation allows us to customize the system in any way, allowing additions, modification or deletion of underlying logic, event flow or component structure.

But one main drawback of this method is, in the end, we have a bunch of modules with possibly different logic handling and structure, performing similar functions. Maintaining all of them becomes difficult, with a lot of duplicate codes.

Implementation Details

Component

The component for such pool will look like:

public class PoolComponent implements Component {
     public int maxValue = 10;
     public int currentValue = 10;
     public float regenRate = 0.2;
}

The component stores all the required value for the pool system, and the events & system has all the logic for the features.

Events

This implementation will have unique events for handling the pool. Some example events:

public class FillPoolEvent implements Event {private int amount; public getAmount();}
public class DrainPoolEvent implements Event {private int amount; public getAmount();}

These events will trigger changes in the pool by other systems.

System

This system will handle only the events of this component:

@RegisterSystem(RegisterMode.AUTHORITY)
public class PoolAuthoritySystem extends BaseComponentSystem {
     @RecieveEvent
     public void onFillEvent (FillPoolEvent event, EntityRef entity, PoolComponent componenet){
          // Logic to fill the pool
     }

     @RecieveEvent
     public void onDrainEvent (DrainPoolEvent event, EntityRef entity, PoolComponent componenet){
          // Logic to Drain the pool
     }
}

This is a generic way of handling such a pool. This method is used in the present implementation of certain pools: Health, Hunger and Thirst