Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple independent worlds in the same game #2412

Closed
FeldrinH opened this issue Jun 29, 2021 · 3 comments
Closed

Multiple independent worlds in the same game #2412

FeldrinH opened this issue Jun 29, 2021 · 3 comments
Labels
A-ECS Entities, components, systems, and events C-Feature A new feature, making something new possible

Comments

@FeldrinH
Copy link

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).

@FeldrinH FeldrinH added C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Jun 29, 2021
@MinerSebas
Copy link
Contributor

I think you might be interested in the Subworld RFC: bevyengine/rfcs#16

@NathanSWard
Copy link
Contributor

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 :)

@FeldrinH
Copy link
Author

I was not aware the RFC repo existed. The subworld RFC does indeed seem to be very similar to my proposoal. Closing this in favor of the RFC.

@alice-i-cecile alice-i-cecile added A-ECS Entities, components, systems, and events and removed S-Needs-Triage This issue needs to be labelled labels Jul 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ECS Entities, components, systems, and events C-Feature A new feature, making something new possible
Projects
None yet
Development

No branches or pull requests

4 participants