1
\$\begingroup\$

After searching through numerous sites on the Entity-Component-System, which is quite a lot to grasp since all my college career we've been taught variants of OOP (also that ECS isn't taught in any classes as well), I think I've got a hang on the main concepts. Exploring the web to further consolidate this information, however, has led me slightly confused. Many different alternatives exist to the approach, but I do want to make sure that I truly get the picture before I go off diving. I have some questions I'll list at the bottom of my summary. Excuse my extremely rough summarizations of the parts.

Entity: some unique identifier that we can refer back to. Meant not to store any data or methods. I suppose you can have something like PlayerEntity, which upon instantiation creates TransformComponent, HealthComponent, etc.. These components are added to their respective systems (?).

Component: contains data and the handling of the data. I typically see a BaseComponent class, in which we can abstract a method or two for handling in the system.

System: acts upon components. Usually independent from one another, but can access each other's components to perform tasks.

 

Questions

  1. What are some possible issues regarding thread-safety in ECS? At first, I thought the issue could arise between systems that try to access an object that is being removed, or so, but I wrote that off in the end since they're all trying to get, rather than modify.
  2. Managing your components? Sure, you have your systems, which grab the components for processing, but does that mean there should be a separate class that handles all the component insertion and removal? This then raises questions on how I can work with systems that require Component A and B. People spoke of maybe bitmapping or various ways to designate a combination of components, but this style is a bit confusing to me. Would it be wise to maybe store components in a system in an array, based on index according to the ID of the entity? And for checking if an entity is okay for updating based on a system, have the system check other systems if the entity ID is present in their respective index (or maybe maps? But in this case, I find a lot of people advise against maps)
  3. ECS is fine for a game that doesn't necessarily have a game loop, right? This might be a little confusing, but essentially some open source code I've gotten involved in the private server scene runs on purely packets coming in, and the packets it writes out. In that sense, everything is event-based, save for timers.
  4. Since an entity is supposed to be lightweight, is its only real purpose for when its destroyed, we can easily destroy components according to its unique id?
  5. Is the overhead for looping through all components unavoidable? If not, what are some work arounds to squeeze through? Aside from separating types of components to their respective systems, I'm finding it a bit hard to really see what else you can do.

Again, sorry if these questions are a bit noobish. I'm trying to get acclimated as much as possible with ECS, since it really does sound fun to work with. Also, please correct me if my summarizations on the ECS lack the primary focus.

I may or may not add additional questions if I get lost, if that's permissible. Also, I work in Java. I'm not sure if there's any additional insight to add between Java and ECS (since ECS is typically used with games, and games are often written in C++).

\$\endgroup\$

closed as too broad by DMGregory Apr 5 '18 at 13:25

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ Hi Jon, and welcome to GameDev.StackExchanfe. Right now, your question (or questions, really) is too broad for our Q&A format. Our structure works on one question at a time, so please edit your question to ask one specific thing and we can re-open it for answering. You can always post a second question, and a third, for the next bits you're wondering about. We also won't be able to give you a comprehensive list of "some possible issues" — this is too open-ended. Ask about a concrete problem to get a concrete answer. \$\endgroup\$ – DMGregory Apr 5 '18 at 13:25
  • \$\begingroup\$ Please also remember to check through previous questions about ECS systems — searching by keyword or clicking on the related tags pulls up lots. Several past Q&As have covered similar ground as what you seem to be wondering about above. A common theme is that there's not just one way to use a component-based architecture, and many of the details you're wondering about end up being judgement calls that each implementor makes for themselves based on their style, preferences, and what they need from the architecture. So they don't have one "correct" answer that should be used as a model. \$\endgroup\$ – DMGregory Apr 5 '18 at 13:29