You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What problem does this solve or what need does it fill?
In games with multiple independent in-game worlds (something like different dimensions, different levels etc.), there seems to be no good way to separate these worlds, if you want to simulate each world independently at the same time but still need some interaction between the worlds.
Consider for example a multiplayer game with multiple dimensions. You would want to simulate all these dimensions at the same time on the server, ideally in parallel on multiple threads, since they are independent, yet you also need to have things that are shared between the dimensions, for example networking, list of online players, chat, etc.
Analogous situasions could also arise in singleplayer games. For example want to have a split-screen game, where each side of the screen contains a different world, room, dimension, level, etc, but you want both sides to be playable independently with maybe a few specific interactions between them (for example a racing game where every player races on their own independent track, but times and score are on a shared leaderboard). In such a case input handling, rendering, textures, and maybe a few game specific variables would need to be shared, yet otherwise the separate sides of the screen should be independent.
What solution would you like?
I do not have the appropriate knowledge of Bevy ECS design, to suggest a technically sound solution. However, one approach might be to have a concept of subworlds in the ECS, so each subworld could have its own systems, resources and entities, which would operate independently from other subworlds, but would also have access to entites and resources in the global world as needed (for rendering, input, networking, sharing textures, shared game state etc). All the subworlds could then be scheduled to run in parallel. This would also make it really easy to ensure entites in subwrolds do not accidentally interact.
What alternative(s) have you considered?
As far as I know there are currently two possible alternatives:
Option one would be to run multiple apps at the same time. This would solve the parallelization and independence problems, however any shared state between worlds would be hard to implement, especially stuff like textures, rendering contexts, windows and shared network connections.
Option two would be to run a single app and implement separate worlds with something like a component with a world id.
This makes shared state trivial, however, making the worlds independent would be quite a bit of extra work, because every relevant system would now have to be built to filter and proces entites per world. This is especially troublesome if you want to integrate external plugins like rapier physics, which assumes that all components are in the same physical space. I have no idea if running systems for different world in parallel could be achieved in this case, given that in most cases, different worlds would probably have the same component types in them, so building queries that only target a single world seems impossible. (I suppose with a small, fixed number of worlds you could define a marker component for each world, however this approach falls appart as soon as the number of worlds is variable. This would also not work for systems from external libraries).
The text was updated successfully, but these errors were encountered:
Yea, the subworld RFC is probably what you're looking for.
There hasn't been too much progress with it lately, however, we'd appreciate more contribution/discussion for it :)
What problem does this solve or what need does it fill?
In games with multiple independent in-game worlds (something like different dimensions, different levels etc.), there seems to be no good way to separate these worlds, if you want to simulate each world independently at the same time but still need some interaction between the worlds.
Consider for example a multiplayer game with multiple dimensions. You would want to simulate all these dimensions at the same time on the server, ideally in parallel on multiple threads, since they are independent, yet you also need to have things that are shared between the dimensions, for example networking, list of online players, chat, etc.
Analogous situasions could also arise in singleplayer games. For example want to have a split-screen game, where each side of the screen contains a different world, room, dimension, level, etc, but you want both sides to be playable independently with maybe a few specific interactions between them (for example a racing game where every player races on their own independent track, but times and score are on a shared leaderboard). In such a case input handling, rendering, textures, and maybe a few game specific variables would need to be shared, yet otherwise the separate sides of the screen should be independent.
What solution would you like?
I do not have the appropriate knowledge of Bevy ECS design, to suggest a technically sound solution. However, one approach might be to have a concept of subworlds in the ECS, so each subworld could have its own systems, resources and entities, which would operate independently from other subworlds, but would also have access to entites and resources in the global world as needed (for rendering, input, networking, sharing textures, shared game state etc). All the subworlds could then be scheduled to run in parallel. This would also make it really easy to ensure entites in subwrolds do not accidentally interact.
What alternative(s) have you considered?
As far as I know there are currently two possible alternatives:
Option one would be to run multiple apps at the same time. This would solve the parallelization and independence problems, however any shared state between worlds would be hard to implement, especially stuff like textures, rendering contexts, windows and shared network connections.
Option two would be to run a single app and implement separate worlds with something like a component with a world id.
This makes shared state trivial, however, making the worlds independent would be quite a bit of extra work, because every relevant system would now have to be built to filter and proces entites per world. This is especially troublesome if you want to integrate external plugins like rapier physics, which assumes that all components are in the same physical space. I have no idea if running systems for different world in parallel could be achieved in this case, given that in most cases, different worlds would probably have the same component types in them, so building queries that only target a single world seems impossible. (I suppose with a small, fixed number of worlds you could define a marker component for each world, however this approach falls appart as soon as the number of worlds is variable. This would also not work for systems from external libraries).
The text was updated successfully, but these errors were encountered: