Following a discussion on AlterationEffects on Slack, we had a long discussion on what do with PhysicalStats. Currently, AE has a larger scope that what PS contains, but has fallen outside of the original scope of containing effects related to the "Alteration" branch of magic.
PhysicalStats covers seven physical stats, but what about other attributes/stats that an entity may have? @manu3d pointed out the example where an entity can be a snake, and have a "venom potency" stat. Having a component dedicated to that may lead to component-bloat, as it may not be used in many places. Plus, a modder would have to implement the component and systems related to it by themselves. So, one solution to this problem would be to implement an AbritaryStats module.
If we have concrete/granular definitions of attributes (like Health or maybe PhysicalStats), they can be separate. After all, having more concrete components like these allows for type safety when dealing with things, as well as custom behaviors/information. But for other more minor ones, we can create a mapping of 0 to n arbitrary stats - where each stat has a value (or can be a MappedContainer) and is associated with a String ID. So, an outside system can access/modify these stats by accessing a mapped table of attributes.
@Cervator mentioned the idea of having a three-layer approach based on how concrete they are and how often they are used.
What do you all think about this matter?
PhysicalStats covers seven physical stats, but what about other attributes/stats that an entity may have? @manu3d pointed out the example where an entity can be a snake, and have a "venom potency" stat. Having a component dedicated to that may lead to component-bloat, as it may not be used in many places. Plus, a modder would have to implement the component and systems related to it by themselves. So, one solution to this problem would be to implement an AbritaryStats module.
If we have concrete/granular definitions of attributes (like Health or maybe PhysicalStats), they can be separate. After all, having more concrete components like these allows for type safety when dealing with things, as well as custom behaviors/information. But for other more minor ones, we can create a mapping of 0 to n arbitrary stats - where each stat has a value (or can be a MappedContainer) and is associated with a String ID. So, an outside system can access/modify these stats by accessing a mapped table of attributes.
@Cervator mentioned the idea of having a three-layer approach based on how concrete they are and how often they are used.
- Health, discrete, used very fundamentally.
- PhysicalStats (and potentially MagicalStats), discrete, tied to specific effects (buffs and debuffs), other common magic system stuff etc.
- ArbitraryStats with a single Component that anything caring about any arbitrary stat would have to check (less efficient, but more rarely used).
What do you all think about this matter?