swift502 / Sketchbook

3D playground built on three.js and cannon.js.

Home Page:https://jblaha.art/sketchbook/latest

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

ECS structuring

fabiodr opened this issue · comments

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

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... 😄

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)