Enable World Swapping about bevy HOT 5 OPEN

World swapping seems a very counter intuitive and a bad idea to me if you apply it to the whole world. it would make much more sense to me to limit it to some kind of subworld.

As we move to more things "as entity", like windows, gamepads, input devices, ... this feels less and less a good idea

from bevy.

World swapping seems a very counter intuitive and a bad idea to me if you apply it to the whole world.

Can you elaborate? I realize that 'one world' is the common sense right now, but honestly it's quite simple and straightforward. Putting sub-worlds inside a world seems more of an ECS anti-pattern than having actually separate worlds (for the use-cases where it makes sense).

it would make much more sense to me to limit it to some kind of subworld.

Implementing subworlds of any kind is, as far as I know, not even on anyone's roadmap. World-swapping works today with basically trivial code changes.

As we move to more things "as entity", like windows, gamepads, input devices, ... this feels less and less a good idea

The interface between external devices and Bevy worlds is very small, especially compared to the typical volume of code in an application. I don't see these as real blockers, just inconveniences that can be handled with modest effort.

from bevy.

First, I see why this is appealing, and it would be cool. Know that I'm on board for allowing world swapping (the simple "change active world that we are currently running app logic on") . In effect, we already do.

But I'm very opposed to "supporting" (as in, changing how we do things or constraining ourselves in order to make it a first class experience) the "swapping worlds as scenes" pattern.

A World (as we all know) is a "container of all of the things required to make an app function". The proposal (as I interpret it) is to allow someone to create a new World, fill it with entities, and then transfer everything required by all Bevy Engine plugins and 3rd party plugins to function without breaking anything. That "set of things" is undefined. We'd essentially be creating a new "thing" people need to remember to support: ensuring the data is registered in a way that it is transferred. And then ensuring that it is built in a way that it can be transferred (ex: entity references don't break).

Also notably, porting any piece of architecture to being "entity backed" (ex: Assets as Entities, Schedules as Entities, etc) introduces a new set of "porting problems".

I guarantee the TODO list in this issue is not exhaustive. We would forever be identifying new issues upstream (and in 3rd party crates). And we would forever feel the need to tie our hands behind our backs to avoid nasty porting issues (for example, avoiding the use of Entity ids in core systems, which is the opposite direction that Bevy is currently headed in).

This is a path we could take. But we would be sacrificing a lot to make it happen. Instead I think we should be investing in things like allocation reuse (ex: allocate tables of entities on separate threads that can be directly and cheaply merged into the main World storage), world partitions / subworlds, etc.

from bevy.

Know that I'm on board for allowing world swapping (the simple "change active world that we are currently running app logic on")

As I understand it, this is what my worldswapping implementation does. I'm not actually sure what you mean by the "swapping worlds as scenes" pattern.. More comments below...

A World (as we all know) is a "container of all of the things required to make an app function".

This is not quite the case, and it's why I thought world swapping could be achieved in the first place. A world does not A) contain the state of the event loop, B) include a render world inside it (this is not super important for world swapping, but it's true anyway).

The proposal (as I interpret it) is to allow someone to create a new World, fill it with entities, and then transfer everything required by all Bevy Engine plugins and 3rd party plugins to function without breaking anything. That "set of things" is undefined. We'd essentially be creating a new "thing" people need to remember to support: ensuring the data is registered in a way that it is transferred. And then ensuring that it is built in a way that it can be transferred (ex: entity references don't break).

World-swapping as implemented is actually creating an entirely new App and extracting its main world and render subapp. When swapping worlds, only transfer those resources/entities that are device-locked (windows, input devices). 99% of normal plugins don't need to care about this, and I explicitly don't intend to support more than the bare minimum of resource/entity synchronization.

I guarantee the TODO list in this issue is not exhaustive. We would forever be identifying new issues upstream (and in 3rd party crates). And we would forever feel the need to tie our hands behind our backs to avoid nasty porting issues (for example, avoiding the use of Entity ids in core systems, which is the opposite direction that Bevy is currently headed in).

I feel like this exaggerates the cost to support this in Bevy. Can you give an example of a feature that would cause nasty porting issues? Bevy is old enough, and the landscape of what goes into a game engine's design is established enough, that it should be possible to come up with an example if one exists (not trying to be rude, it's just I consider this a major UX improvement and don't want to back down without a clear reason).

Instead I think we should be investing in things like allocation reuse (ex: allocate tables of entities on separate threads that can be directly and cheaply merged into the main World storage), world partitions / subworlds, etc.

From my point of view as a user, these items aren't even on anyone's dev roadmap (as far as I know), which means the state of things is unlikely to improve any time soon (if ever). And to be clear, I personally don't have the time or motivation to invest 1+ months in a big ECS project.

from bevy.

Would sub-worlds be fully self contained? Could an entity exist in multiple worlds simultaneously, or only one at a time? The former would be good for replication and render worlds, but data leakage could be a problem as well.

from bevy.