[QUESTION] Project status/outlook about ecsy HOT 9 OPEN

We're meeting soon to discuss this, we don't have any answers to those questions at this time.

Here's some background though. @fernandojsg was laid off from Mozilla, he's currently in the middle of transitioning to a new job. As you could imagine, that combined with taking care of kids can take up a lot time. I'm currently in the middle of a large project on Hubs and I just don't have the energy to work on this outside of work right now.

As of now, there are no longer any projects at Mozilla using ECSY in any capacity. We've done some experimental work on Hubs to see if we can use ECSY as our official plugin API surface. I think the results were promising, but we haven't decided as a team if we want to go with ECSY, double down on Aframe, or some other API. We have a ton of legacy code so as you can imagine migrating to ECSY is a huge decision for us to make as a team.

We are trying to find a time for us to all meet this week and we'll have more to share soon.

from ecsy.

@fernandojsg @robertlong When can we expect an update on the project status?

With the last commit on Sep. 10th, and no updates on this topic, should we assume that the previous Mozilla contributors are moving on and that a new maintainer needs to step in and bring on new contributors? If so, let's start having that conversation and maybe add someone new to the org to start managing those efforts.

I just don't want to see this project die off.

from ecsy.

Any update?

from ecsy.

Hey, I just published: https://github.com/DavidPeicho/ecstra

A new implementation that is inspired a lot from the work done on Ecsy. Examples are directly copied from Ecsy and adapted so people can see the (minor) differences between Ecstra and Ecsy.

What's new

• Component static properties merging when using inheritance
• System ordering using UpdateAfter and UpdateBefore similar to what Unity does
• TypeScript decorators for component properties
• TypeScript decorator for system ordering and queries
• Better and more consistent typings

What's Missing

• Deferred deletion
• StateComponent
• Reactive queries
• A beautiful website 😄

From the missing list, I am not sure what is really used by the community... If you have use cases where it's absolutely needed, I can work them out. Alternatively, there may be better way to solve problems that are for instance solved by StateComponent?

If people want to use it, I would be glad to ear more about your use case and what we can fix / add to match the common use cases.

Thanks a lot to the work done by @fernandojsg and @robertlong on this repository! It's really good and I shamelessly copied a lot of stuff from here 😄

from ecsy.

Since we're pitching alternatives, also consider https://github.com/LastOliveGames/becsy. It's an "OOP monster" whose API is strongly inspired by ECSY and built to interface smoothly with OO libraries, but backed by low-level data buffers for performance. The project is still very young (no docs, missing features, etc.) but moving quickly. And ultimately, if things work out the way I'm hoping, you should get nearly-transparent multithreading for free!

from ecsy.

I wouldn't mind helping more on this repo, otherwise I may have to fork it. In my use case, I don't really need more feature from Ecsy. I simply need to continue to add bug fixes, and maybe clean up / improve some parts.

from ecsy.

if you're looking for a pure data oriented ECS, I've built https://github.com/mreinstein/ecs which was heavily inspired by ecsy.

I'm using this for 2 in-progress games being developed, I hope to support this for quite some time. Would happily accept PRs, contributions, etc.

It's got most of the features of ecsy, but not built with awful object oriented programming or classes.

from ecsy.

While I am in favor of data oriented when possible, it's not that worth I feel for JS because in the end you might interface with something clearly not data oriented (Three.js, Babylon, etc...).
If you end up writing a custom data oriented engine, then it would make a lot of sense.

from ecsy.

in the end you might interface with something clearly not data oriented

Yeah, I suppose that's true. But when I build games and simulations I don't use those particular libraries because they are big OOP monsters. :)

If you end up writing a custom data oriented engine, then it would make a lot of sense.

That is what mreinstein/ecs provides today; a low level data oriented engine. Coupled with other data oriented modules like https://github.com/mreinstein/collision-2d and https://github.com/mreinstein/boids etc.

from ecsy.