I'm new to ECS concept and trying to refactor my app with an ECS manner. After reading some articles, I still don't get a sense about how to organize hierarchy for such pattern. My questions are

  1. Is a component allowed to have another component inside? For example I saw a RenderComponent that contains a Mesh inside. Is the mesh also a component or the raw data of it, which should be stored inside the RenderComponent?
  2. What happens when an instance of component needs to be shared by two entities?
  3. If an entity should be just an integer, how do you organize the relationship between entities? Should it have a parent/child/linked entity or should all these relationship be managed by the system?

Thanks!

  • I'm not sure if I understand these questions. 1) Usually a mesh would be an asset, not a component. Many renderer components on different entities might re-use the same mesh. Do you have an example where the child item behaves like a component? 2) Do you have an example where a component would need to be shared? Implicitly components usually describe an attribute or behaviour of "this" entity, so I'm not sure what kind of component would need to be shared this way. 3) What kinds of relationships do you have in mind? Transformation hierarchy? – DMGregory Nov 3 '17 at 13:06

There is no "proper" practice for this. There are many ways you can approach it, each with pros and cons that need to be evaluated against all your other requirements.

Is a component allowed to have another component inside? For example I saw a RenderComponent that contains a Mesh inside. Is the mesh also a component or the raw data of it, which should be stored inside the RenderComponent?

If you want to support the concept of having compenents nested inside or otherwise attached to other components, you can. There is nothing wrong with it. It can add some amount of flexibility, although it tends to also add complexity as a tradeoff. It's up to you: do you need or want this to accomplish your goals?

What happens when an instance of component needs to be shared by two entities?

The same thing that happens when any piece of data needs to be shared. Generally you either simply share it (by having the entities refer to the component via some kind of referential semantics, and have actual lifetime of the component controlled elsewhere, not by the entities themselves), or refactor the system so you don't need to share the data.

If an entity should be just an integer, how do you organize the relationship between entities? Should it have a parent/child/linked entity or should all these relationship be managed by the system?

An entity does not have to be just an integer. That's just one way to look at it. That "entity is literally just an integer" approach can present these kind of relationship problems: you can't store anything else with an integer, directly. Instead you can either make the entity more complex, so it can directly reference related entities, or store relationships externally in a table mapping integers to lists of related entity integers, et cetera. It is up to you.


Your big misconception here is that "entity component systems" are a single thing with a single objectively-best way to build them. This is false. You'll find lots of writing on the internet describing various different ways to implement entity systems, many of them will be written in a dogmatic style or otherwise implying strongly that this is "the" way, and that all other ways are wrong.

This is true of almost nothing in software engineering, and it's certainly not true of entity systems. As you can guess from the common theme in my responses to your specific questions, you can structure your entity system however best makes sense to solve the problems you need to solve. I'd advise you to prefer the simpler solutions first, but beyond that it is up to you.

What you build won't be "so and so's entity system," as described on their blog, but it will be your entity system and that's more important.

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.