davidpeicho/ecstra

Fast & Flexible EntityComponentSystem (ECS) for JavaScript & TypeScript

ecstra's Issues

Feature: add TS decorator for properties, etc...

TS decorators will help TS users create component without using manually the Properties static attribute.

Events / Signals on entities and queries

When interacting with WebGL there is init/destroying of external buffers. Having events fire when a query changes inclusion of an entity is must for decoupled systems.

Feature: RenderWorld

Update / Rendering are often different in several way:

• Render target rendering should occur
• Per-view elements: aspect ratio, canvas, etc...
• Per-view pass: one view might need a postprocess, but not another one?

I am not sure yet if this concept exists, but it would be nice to be able to feed a World into a RendererWorld or something.
Let's imagine a simple cases like:

• One world, multiple views per-view data (camera, etc...). Each view has its own context
• One world, mutiple views with different per-view data (camera, etc...). All view share the same context though.
• One world per view

Version out of sync with DOC.md

The DOC.md is mentioning some nice and useful features, that the version I got from NPM (0.0.2) does not seem to have, like

 Property 'onEntityAdded' does not exist on type 'Query<Entity>'.ts(2339)

seems not to be defined. Also there are some other changes to the NPM version, like different names of decorators.

When is it coming out?

I just switched from ecsy to ecstra. And I like it so far :-)
Need some help? I plan to build my next game with ecstra, if that works out. :-)

Archetype component order matters

Most likely should sort component by constructor name as currently the order component are add probably with effect the hash.

Command Buffer: delay removal of entity / component

It looks like the community still needs deferred removal. I think a good way to go for that, would be to implement CommandBuffer in the same way other ECS work.

Command

Commands contain semantic about how to apply the its state onto the world. We would need command such as:

• RemoveComponentCommand
• RemoveEntityCommand

Later on, this can go even further with other types of commands.

CommandBuffer

CommandBuffer's contain a set of command to apply. For instance, an entire group of system could register command in a single buffer that will later be applied.

The key here is to let the user choose when to apply the commands. We could create default basic command buffers:

• Per-System command buffer: applied after a system is done running
• Per-Group command buffer: applied after a system group is done running
• Per-World execution command buffer: applied after all groups and all systems are done running

Internals

Using command buffers would make the implementation simple. There is no need for the internals to track what is removed and when to remove it.

Drawbacks

No deferred removal possible outside of systems

With an implementation like that, it seems impossible for someone to remove in a deferred fashion a component / entity. For me, it doesn't make sense to remove something deferred when not executing the world, but maybe some people have use cases for that?

EDIT

Turns out #21 raised a really good point. If deferred removal is done only when ticking, then resources might leak (exemple with WebGL object allocated in systems). Command buffers should then be exposed to users outside of systems as well! The good thing is that it shouldn't be hard to implement

FECS / ECSTRA naming confusion

See both in docs. Guessing there was a name change and didn't do a full sweep.

Add `Removed()`, `Added()`, and `Modified()` query selectors

Instead of creating "reactive queries" that sort entities based on added/removed components, I think I will modify the Query class to process queries with extra selectors:

• Added() → query only process the entity when it's the first tick the component is added
• Removed() → query only process the entity when the componet has been removed at this tick
• Modified() → query only process the entity when the componet has been modified at this tick

Should I use this library or Ecsy for a new project?

It seems that the Ecsy repo is dead at this point whereas this library is being updated regularly. On the other hand, Ecsy already has a decent number of features as well as bindings to many other libraries and dev tools. I'm working on an experimental game that will probably requiring swapping out large sections of the codebase in the future since there's certain features of my project that I'm still unsure on how they will work or if they will work. So I'm looking for a library that will provide maximum architectural flexibility but I don't need it to have tons of features. I realize that neither project has reached a stable release, but how complete would you say this library is compared to Ecsy? Thanks!

Regarding Test Coverage

Recently I've been working on an ecsy-three type project in my free time and there are some economic changes that would be needed in this library to improve overall support.

I was trying to add coverage to ava (in this project) but was not able to set it up as I'm far more familiar with jest/mocha. Would you accept a PR for replacing ava? If you intend to stick with ava, do you have suggestions for coverage with typescript?

V0.0.1

• Deferred removal and deferred addition?
  • We could use command buffers to schedule when to perform those
• Deferred addition?
• StateComponent?
• CJS / UMD
• CI
• System Group tests
• Webpack / Rollup integration test
• System tests

System Init Method Equivalent

Is there an init method equivalent for System?

Feature: Renderer System for Three.js

• Renderer system should go in a Rendering group, i.e., post-update
• Renderer should be able to render to one or more views.
• Views can be a subregions of framebuffer, or a totally different context

Time / Name components

It appears you are treating entity name and time as a special case. I've found having a global "singleton" entity with a TimeConponent advantageous as systems can conditional manipulate time given events. Same with the createEntity(name) is possibly better suited to a NameComponent{name:string}. It makes things like stats generation much easier if there is no special case and the system is generic as possible.

Feature: automatic benchmark

The library should be created with a Node.JS benchmark that could also be used as a profiler to ensure the speed is never going down (except when accepted).

Add API for batch modification of entity

Right now, it's a bit "slow" to add / remove component. Adding / Removing a bunch of components will trigger multiple archetype transfer.
It would be great to have a batch addition / removal without creating temporary allocations when possible. It might be tricky to do.

Add typescript examples

Refactor: Prop shouldnt need to be instanciated

For JS users, it's quite annoying to do:

Properties: {
  prop: new MyProperty()
};

When it could only be MyProperty(). This change is small but makes sense.

benchmark on jsbench

Hi, I talked to you on reddit the other day about the benchmarks. I put your benchmark code from here to jsbench.

I ran into a few problems:

• The benchmark uses whatever version of your library is on NPM. For example, the registerComponent on World doesn't exist, it's named register instead. If you've made any significant changes since, this would influence the result greatly.
• I don't know if I did your library justice, because I had to re-write the bench code from the TS API to the JS API, and I may have made a mistake along the way.

I hope you find this useful. Feel free to close this 😃

Feature: automatically increase `maxComponentType`

When the max number of component type is reached, the world shouldn't crash but should re-compute All ids. Obviously, it's not the best case for performance, but people should be aware that declaring the good count is better.