Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ECS Organization #1

Open
rjewson opened this issue Dec 1, 2017 · 1 comment
Open

ECS Organization #1

rjewson opened this issue Dec 1, 2017 · 1 comment
Labels

Comments

@rjewson
Copy link

rjewson commented Dec 1, 2017

First - Nice project! was considering something similar.

I've built a and used a few ECS's. I was wondering why you explicitly declare the systems on an entity? Why didn't you declare components as children of entities and let some other code match the entity to the right system(s)?

e.g.

<Entity name="cube">
    <PositionComponent x="0" y="1"/>
    <TweenComponent prop="x" from="0" to="100"/>
</Entity>
@brochington
Copy link
Owner

Thank you! 😊

Is the <TweenComponent /> in your example a System?

In ECS, data is passed around mostly through Components. In React, data is passed via props.

I've developed another project called Akkad that tried to implement an ECS system over top React. In it Entites(which were React components) had children which were Systems (React components as well). I bypassed the abstraction you have above, and injected the "Components" via props directly into the Systems. This worked...okay. One of the problems with this approach was that in order for Systems to be decoupled from the entity itself, they would have to be passed in as children. It would be hard to pass Entity id's, and hard to correctly time when child Entities or Systems should "render" themselves.

I took a lesson from how the A-Frame project handles ECS, and moved systems to a special prop. This has simplified things A LOT, especially in the decoupling department.

Another huge win has come when trying to teach how Declarity works to others. I found that many thought it hard to understand the difference between an <Entity /> and a <Component /> especially when React's main structure is called a <Component /> as well. Being able to look at anything that is JSX, and know that it is an <Entity /> of some sort, helps to make things explicit.

Personally, I like the understanding that when I look at a render method's output, I'm looking at the "tree" of my structure. When I'm looking at an array of Systems, I'm looking at the horizontal processing that occurring on the state related to the entity.

There is more to it than just this, but hopefully this will give you a better understanding of why I've chosen the API that I have. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants