separating vital stats out into each their own subsystem and component type: HealthComponent, WeaponComponent, ArmorComponent, StrengthComponent, DexComponent, AttackComponent, etc. What would combat look like for an entity like this?
To me a single vital's component would be best. ...don't 90% of entities that might interact in away that involves vitals all have basically the same set of stats
If we think about componentized entities as being a data oriented approach, the guiding principal is to separate the entity into chunks of data which will be processed together.
If we envision all those stats being used for the purpose of producing a feature (like combat) through some sort of complex interaction, then we're envisioning processing all the stats together, so they should form a component. Breaking each stat into it's own component is a violation of data oriented design
. Well formed components make it relatively easy to write the code, as well as letting that code run more efficiently.
Now if you find that you have various different types of entities which actually only need subsets of those stats, then you'll find it pretty difficult to code those interactions which process all the stats together, because those interactions would make no sense for entities which you've decided don't need those stats. In that case, you've identified some subsets of the stats which should form smaller components.
Rather than thinking of it as data oriented, I like to think of it as feature oriented. Entities have features, or aspects, or abilities, etc., like the ability to be placed in the 3d game world, to be rendered, to animate, to participate in a physics simulation, to collide with other entities, to give and receive damage
, etc. Each of these features involve it's own (mostly) unique data, and the code which operates on it
. In general, a component should contain the data (specific to a given entity) which a subsystem processes. If it doesn't make sense to create two subsystems, it probably doesn't make sense to create two component types.
One area of stickiness is when multiple features are equally dependent on a common piece of data (e.g., AI, physics, and rendering all depending on entity position). The only two approaches that come to mind for dealing with this are either to factor that data out to a separate component (which breaks data orientation, forcing components to look it up while processing), or to duplicate that data (forcing components to synchronize it, and opening the door to copies being out of sync). At the moment, I tend to lean heavily towards the first approach, especially in the case of entity position, since there is a sub-system which makes sense for dealing with position data only.