Jump to content
  • Advertisement
hs12503

Help understanding how ECS should be structured

Recommended Posts

I've just started to try and learn how to use ECS (Entity component systems) in games, but I've found it a bit hard to understand. Right now I have two main questions:

  1. In an ECS, is it preferable to store a boolean value in a component to flag an entity, and keep that component permanently on that entity, or to add/remove a component to flag an entity? For example, if I want some way of flagging an entity when it dies so it can be removed, is it better to have an AliveComponent with a boolean dead to indicate if it's dead or a DeadComponent that gets added to indicate if an entity is dead.
  2. Should adding more types of components, or trying to make a component reusable through its fields be favored? For example, if I'm trying to give all entities a shape for collision detection, should I have a different component for every shape (RectangleComponent, CircleComponent, PolygonComponent), or should I have one ShapeComponent, and in there have a field which is of type Shape, with Shape having subclasses Rectangle, Circle, and Polygon.

Also, I couldn't find many good resources on ECS concepts, so if anyone knows any good ones, it would be really helpful.

Thanks!

 

Share this post


Link to post
Share on other sites
Advertisement

I personally wouldn't add/remove components at run time to indicate state like alive/dead. It might be necessary to do this for some other kinds of functionality, like for example removing an animator and adding a ragdoll component on death, but for something as simple as a boolean I would include it as part of the component/interface that is responsible for returning health values or receiving damage.

The second question is similar to one I asked recently:

Share this post


Link to post
Share on other sites

Youve got generalities versus specific implementations with specific needs.

In general it is a concept, there is no right or best in general, although some implementations are better suited to different uses. In general it is a system of composition, building up things (entities) out of other things (components).

Different games implement the concepts in many different ways. Most programmers actually implement it multiple ways in their code, often not even realiizing they are following the pattern.

For most games the implementation details don't matter for performance nor space, as most games have many million cycles and many gigabytes to spare. In some cases they matter, and in those cases you need to understand the computer science behind it to know why, understanding data locality, access patterns and cache friendliness, and processing algorithm choices in order to know what to do diffrently.

Do whatever works for your game and makes sense to you.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!