Skip to content
This repository has been archived by the owner on Oct 10, 2024. It is now read-only.

ECS structuring #30

Open
fabiodr opened this issue Aug 15, 2020 · 2 comments
Open

ECS structuring #30

fabiodr opened this issue Aug 15, 2020 · 2 comments
Labels
currently not planned It's not on the roadmap. I personally don't feel the need to add this feature.

Comments

@fabiodr
Copy link

fabiodr commented Aug 15, 2020

Great project! It expands a lot the vision of what kind of interactive experiences can be done on the web with Three.js.

Do you have thoughts about structuring with ECS pattern, using a lib like ECSY ?

Here is an ECSY example project also using typescript and physics: https://github.com/macaco-maluco/thermal-runway

@swift502
Copy link
Owner

swift502 commented Aug 16, 2020

Very interesting! Is that basically the Unity philosophy of "everything's an object within a scene with components attached to it"?

I'll have to look into it more, probably once 0.4 is released. It seems like it would mainly make the code prettier, clearer to navigate and more maintainable right? But I'm just not sure I want to invest significant amounts of time into that currently, as I'm short on time. I'm glad to get any work done in this project. I'll probably always prefer implementing cool new features, rather than restructuring the whole project.

Also there's some custom systems and philosophies in sketchbook (like character states), and I'm not entirely sure how they'll fit with the ESC pattern.

I'm putting this in the research phase, as I need to look into what the transition would look like for my project.
I already restructured twice actually, from prototype JS to class JS, and then later to TS. Those felt like meaningful transitions. If this had benefts of similar magnitude, maybe some day.

If someone wanted to take a restructure a bit of my project, so I have an idea of what it would look like, that would help. But I don't expect anyone to do that... 😄

@fabiodr
Copy link
Author

fabiodr commented Aug 17, 2020

Yes, it’s like Unity in the sense that Components (MonoBehavior) can be shared between Entities (GameObjects) but there is a difference: behavior is defined in Systems, not in the Component itself.

It's much more similar to the new Unity DOTS, where data and operations/behavior are separated.

Components holds only data
Entity has components
Systems operate on entity's components

A System can specify a combination of Components it needs, then it filters and cache only Entities that have this combination to iterate them, implement the operation/behavior and transform the data in Components.

ECS favors reuse by composability over inheritance, it helps not to mix things that could be reused and to keep the operations focused and clean.

Some ECS libs in C++ (and also Unity DOTS in combination with Burst compiler) claims it improves even performance if used correctly, I don’t think it’s the case for JS but the overhead seems to be minimal looking at ECSY benchmarks.

In the long run, for medium to big complexity projects, I believe it helps with organization, reusability and maintainability.

As a reference for a future restructuration or experiment, Mozilla Hubs is large Three.js/Aframe application that is experimenting a migration to ECSY:
https://github.com/mozilla/hubs/compare/feature/ecsy-integration
https://github.com/mozilla/hubs/compare/ecsy-simple-entity-api
(I don't know if it goes further now with some sad recent Mozilla events)

@swift502 swift502 added the currently not planned It's not on the roadmap. I personally don't feel the need to add this feature. label Sep 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
currently not planned It's not on the roadmap. I personally don't feel the need to add this feature.
Projects
None yet
Development

No branches or pull requests

2 participants