Some improvements I've made

I’d been weighing the pros and cons of various different options (using ecsy/jecs, writing my own). I spent some time on the latter, but ecsy is the far better documented option, and with things like wasm support in the future, it could really take off!

My own game engine is client/server, uses Babylon.js in the front-end, Babylon.js’s NullEngine in the backend to handle server-side physics, and websockets to link the two.

I’ve decided to go with ecsy, but saw some deficiencies which I improved in my own fork:

  • Server-side/Node.js doesn’t have access to window.performance, so I integrated perf_hooks, which exposes the same.
  • Since I will need to run multiple instances of the Server application, I can’t rely on Integer-based identifiers for Entities, so I replaced the auto-incrementing Integer ID with a UUID v4-generator.
  • (future plan) I’d probably look into the Entity (de)allocation scheme and how it stores Components, there might be some performance improvements switching it from hash-lookup Objects to indexed Arrays.
  • (opinion) I’m not a huge fan of needing to transpile server-side code; it’d be swell to have a pure-JS solution for back-end, and transpile that for the front-end. That’s purely personal opinion, but I thought it worth mentioning. There’s likely great value in having an ECS library that works in front- and back-end (SpatialOS dropped their JS support, so here’s a huge opening!) out-of-the-box, which is something I’d been working toward in my own fork.

I’m not sure how desirable these features are (they are to me, but I’m building a specific thing). Perhaps at the very least, introducing configurable strategies for ID generation (passing a function.bind() belonging to a module whose job it is to increment integers or generate UUIDs, for example), and definitely keeping the performance piece would go a long way to make the library more appealing to a wider audience.

Anyway, I’d appreciate feedback on how to contribute; I can’t dedicate a lot of time, but at the very least I can submit PRs for what I’ve done and see where the changes go, but let me know whether that’s appropriate. :slight_smile:

Cheers!

1 Like

Hi Peter!

Welcome to the community and thanks for sharing your feedback!
Overall I like the proposals you mention. The window.performance it’s a good point, as I haven’t thought about the backend piece so it would be great to get a workaround for that.
Regarding UUID, I would like to revisit the work that three.js was doing in that front as I remember they were having performance issues with their previous uuid generator and the worked on improving that.

I’d appreciate if you could open separate issues for each topic, or a PR if you are willing to collaborate and we could move the discussion on each topic to the repo as these seems interesting issues to address.

Thanks again! :wink:

In addition to importing performance library in Node.js, the other thing you have to do for backend is use setImmediate(run) instead of requestAnimationFrame(run). requestAnimationFrame is a browser rendering concept and makes no sense on the server-side. setImmediate should be used since that is called on the next available Node.js event window.

I’d recommend using NanoID instead of uuid. That will solve your performance issues.