Suppose you have two components in a survival game. BodyTemperature component and Clothing component.

BodyTemp component should calculate your characters current body temperature. Two factors in this equation should be the ambient world temperature and the insulation provided by your current equipped clothing.

The Clothing component might be responsible for equip/unequip clothing which would be changing some visual elements but also getting data about the clothing.
This data about the clothing - it's insulation value in this example - might be stored as float that could be used as an input over in the BodyTemp calculations.

This seems to create a problem however. As I understand it, the point of using this ECS (entity component system) design is that different components have broad usage and aren't tied to a class. But if one component needs data from another... that sort of defeats the point of separation?

I guess you can make some branching checks, like check if the entity is using the Clothing component, and if so, then get the insulation value to be used for calculating temperature. I don't see any problem with that, but I just wonder if that isn't sort of going against the premise of how it's all meant to work.

To my mind, even if the clothing component and bodytemp component would always be used in conjunction, it still seems consistent and logical that these two components remain separate. In thinking about designing a game framework that will be easy to maintain, I think consistency is probably the most important thing.

Just looking for any thoughts, opinions, advice. I pose this as a general programming question, but if it matters I am doing my programming using blueprints in unreal, and don't have any compsci background.

@fleabay thanks you are right, i am misusing some terminology.

I found this article: Introduction to Component Based Architecture in Games | raywenderlich.com which is helping to clear up some misconception I was having.

just for some closure, upon further research i found that a true ECS isn't really feasible in unreal engine without extensive modification of source of code - though in my case I was only looking at these different programming structures for benefit of maintainability. Low-level optimizations isn't a concern for the sort of work I am doing.

To that end though, some of the high-level, basic principles from ECS do seem easy-enough to accomplish in unreal - mainly just the idea of separating data from logic which might lead to flexibility in some cases. The principle seems most appropriate for what I would call “classic” games - games where you might make imaginative changes to the game rules in unpredictable ways throughout the course of development.

For a case like mine where the game rules are pretty much set in stone before production, it seems that there would be added verbosity with little benefit. There are simpler ways to decouple code and maintain flexibility that won't require more abstraction than needed, thus leading to easier maintainability.

Initially I had thought “composition” and ECS were synonyms, but that article I linked cleared up that misconception. THere is many different methods for a composition design, ECS is just one specific type.