Q: ape seems to be (at least currently) mono world?

[jcorbin]

Due to things like World.prototype.registerComponent mutating the given klass.prototype, makes it not appealing to work with multiple worlds.

What's your thoughts on how to do that sort of multi-world/shard/chunk thing?

[fritzy]

Component and Entity types are currently world specific for optimization reasons, but it wouldn't affect the API to change it (WorldEntity might need to change the TypeScript definition a bit). I'm certainly open to making it easier to use entities and components in more than one world. What use-case do you have in mind?

[jcorbin]

A couple of current use cases I have in mind:

• independent/unsynchronized simulation regions, e.g. not ticking everything all the time
• independent spatial regions, without affording for that internally with an additional coordinate or "plane" tag

Speaking of spatial sharding, what's your take on an index for collision detection?

[fritzy]

That makes a lot of sense. I'll make it a priority. I think I can do it without a 2.0, but it might need to be API breaking. We'll see! I'll keep you in the loop.

[fritzy]

Components can now be registered to multiple worlds in the portability branch.
I'll start thinking about the ability to copy and move entities between worlds in the future.

[jcorbin]

Fantastic, for an update on where I'm at, am currently pursuing "what if I just used DOM elements literally as an ECS, what with data attributes, CSS variables, quereySelectorAll, and such"; you can see a working demo here: https://jspit.vercel.app/domgeon.html

fwiw, my approach to FOV / lighting does provide a potential use case for copy/moving between between worlds:

• there is the objective world ( in domgeon terms the "solid tile plane" ); it serves as the source of truth, where movement and interaction happens
• the lighting simulation gets calculated in the objective world ( by (re)computing --light CSS variables using a modified shadowcasting algorithm )
• but we don't draw the objective world, rather what we do is copy in-FOV tiles out of the objective world, into a subjective plane, after first clearing any copied light values from the prior round
• I plan to later use this same approach for AI, so that they also only see their own subjective copy of the world, sensed through LOS/FOV observations

Now, currently for domgeon, this is all just so much div.grid div.plane div.tile elements; how would I map it onto a more formalized ECS, not sure.

And a parting thought: copying between ECSes seems to me just a lighter weight version of (de)serialzing, which ECSes are supposed to afford quite well in general; not sure what ape-ecs's current story is around loading/saving tho?

[fritzy]

You can run getObject on a world, entity, or component. The results can be used as the definition in createEntity/createEntities.