We should keep our components small because:
- It’s friendlier to the cache
- It allows us to run more of our systems in parallel
- It allows for finer grained change detection
Now this rule is not so cut and dry. By making our components smaller we gain the 3 benefits above but we also make certain queries harder in our systems.
As a counter point here is what LogLog Games says about fat vs thin components:
It should also be noted that the approach of “splitting up components into as small as possible for maximum reuse” is something that is very often cited as a virtue. I’ve been in countless arguments where someone tried to convince me how I absolutely should be separating Position and Health out of my objects, and how my code is spaghetti if I’m not doing that.
Having tried those approaches quite a few times, I’m now very much on the hard disagree side in complete generality, unless maximum performance is of concern, and then I’d concede on this point only for those entities where this performance concern matters. Having also tried the other approach of having “fat components”, both before and after the “separated” approach, I feel that the “fat components” approach much better fits into games that have lots of logic that is unique to what is happening. For example, modelling Health as a general purpose mechanism might be useful in a simple simulation, but in every game I end up wanting very different logic for player health and enemy health. I also often end up wanting different logic for different types of non-player entities, e.g. wall health and mob health. If anything I’ve found that trying to generalize this as “one health” leads to unclear code full of if player { … } else if wall { … } inside my health system, instead of having those just be part of the big fat player or wall systems.
In the end there is nothing wrong about making components fatter to make your game logic easier to write. Don’t feel the need to predict generality and make your code “clean” too early.
If your logic will treat mob and player health significantly differently there is a great case to have separate components. Consuming them within your systems will become much easier and let you iterate on your games faster.