Sometime ago, I was on the lookout for a Typescript ECS that I could integrate with Babylon.js. I couldn’t find something that I liked so I decided to write my own.
My main focus was to squeeze as much performance as possible from using TypedArrays and minimizing cache misses.
I have build an Archetypal ECS based on the SOA ( Struct of Arrays ) approach that integrates pretty well with Babylon.js. I was just reminded that it was sitting there so I decided to open source it for the community.
It is not thoroughly tested and there are definitely things that can be added ( The Query system can be extended further ), however I thought if there is interest, this could prove useful for people who would like to squeeze every bit of performance out of Javascript.
You can find the repo here : GitHub - Null0924/BabylonECS . There is a small documentation in the readme and some tests files where you can see how to operate the ECS.
Thanks for the feedback. I haven’t tried it on a large-scale setup ( multiple entities updating ) where ECS’s would thrive to be fair. I have started porting some old projects to it but nothing concluded as of yet.
I can setup a small demo if there is enough interest though.
I believe the real value is in the way it structures projects rather than performance.
The main philosophy behind performance gain using a data-driven approach is accessing contiguous memory and lowering cache misses. Still, Babylon objects ( Camera, Lights, Mesh etc. ) will still be in Javascript Objects which afaik, are not contiguous. And most likely these would need to accessed in most of the systems when entities are iterated. So we avoid cache misses when iterating entities and numeric components, but we can’t avoid it when we access Babylon objects.
Of course, it’s better with an ECS than without one, also in terms of performance but, we won’t see a huge boost I’m afraid.
I really like it’s design. Seems like it’s more intuitive than what I have done.
On the other side of things, from a quick glance I don’t see it focusing on squeezing performance which might make sense for javascript but it’s not what I was looking for.
I focused on keeping data tightly together through the use of sparse sets and retrieving components through bitwise operators for increased speed.
I can definitely see this being used in real-life projects though. As I mentioned before, it’s not really possible to harness the benefits of an ECS system in javascript so maybe the focus should be on usability instead.