Confusion with worlds, as a concept

I'm aware the title is not very descriptive, but I'm having a hard time understanding the need, uses, and concept itself of worlds within DOTS.

I've read the documentation and googled about the topic. I'm aware that different worlds have independent sets of systems, and independent entity managers. I've also read that an ideal use of worlds would be to have a "data world", and a "presentation world", and be able to update them at different times/rates. But I'm only left with more questions:

1. What would be some real use cases for having several worlds? In what way would they make life more convenient, either development-wise or performance-wise?
   
2. In the "data world & presentation world" scenario, how would the two worlds exchange information?
3. In the "data world & presentation world" scenario, how would the two worlds stay in sync? How would they maintain coherence, and how would they signal each other that it's the other worlds "turn" to run their update loop?

I appreciate any guidance you can provide. Thank you.

 

So far I wasn't convinced about using different worlds for data and presentation.

3 use cases I see for different worlds are:

1. Client/Server world (as NetCode does)
2. Simulate stuff in a non-destructive way (like an IA planning ahead the opponent's step, or to preview a projectile trajectory).
3. Mini-games inside another game (like a computer puzzle in a sci-fi adventure game), as I can easily see this become a mess to debug if everything was in the same world.

But, well, following this thread to see others' perspectives.

 

The additional worlds could be used for data preparation, for example in streaming. You add a new world to read some data create entities and when everything is done you transfer entities from one manager to another.
Also, some parts of the game that do not have an impact on gameplay could be on another world. A simplistic example would be a chat in a multiplayer game.
I guess input recording for a replay could be done in a separate world. Then it would be easy to save a replay just save a state of this world. The same thing with some checkpoints, just save state to another world and going back to this checkpoint is easy, just load this world and you are done.

 

Entities streaming (this is how Unity does sub-scenes streaming - through the streaming world). Saving\Loading game\state (this is how we using that).
Edit: Ah beaten didn't refreshed the page

 

I appreciate all the replies. Thank you all.

From what I've gathered and what you've all said, I understand that worlds are more of an organization/grouping device, not unlike system groups, archetypes, etc. but don't offer (yet?) any specific functionality besides having their own "isolated" entity managers. Am I correct?

Finally, do you know of any specific example of inter-world communication or multi-world sync? I imagine the worlds can signal each other and exchange data in some way, but I don't know of any "meta-manager" for handling all this. Or any way to handle it, really.

Thanks again.

 

You can think inversely that this is the only benefit you get. (technically at code level I think that is all what different world is)

But then you can now understand the benefit of multiple worlds by thinking what limitations you have when working with only 1 entity manager. The manager is named a manager because when the data pipeline is "in doubt" it should contact this strictly one singleton thing to resolve problems. Those data to resolve problems are like dependencies (should we sync or can we still parallel), various version numbers scattered throughout, ongoing web of job handles, the count of entities ... they are all computed and collected in the single manager. I think other data "spilled out" from the chunk like shared component data are considered owned by the manager.

Now you have multiple managers you also have a new copies of those things and it does not have to care about the state of the other managers. e.g. if you take time to migrate read-heavy entity data to world 2 then maybe changed version of the chunks of that world may never bump up and in turn speed up other operations in that world that designed to skip work when nothing changed. (dunno if it will actually worth multiple worlds or not but just theoretical example) It looks less like pure organizational feature this way.

Though we may have yet to found truly "meta" (the gaming term) thing that calls for multiple worlds to solve because the lib is still far from finish. Currently it seems to be the prepare vs. using now kind of pattern as others said.. Which I think more than organizational since the preparing world need truly 0 care about presenting world. (Using the same world but different archetype is arguably separated enough chunk-wise, but can't deny that they all lived in the same manager and few line of code can connect them up. They are still kinda more next to each other physically/technically than different worlds)

 

I am also kinda perplexed by the "multiple worlds" thing. I can see now from your comments how it can make sense. But I have some questions..

I am so far having everything in the same World, even tho some things are completely disconnected. But I don't have a problem with it. Should we strive to disconnect worlds as much as possible?

Does 2 separate EntityManagers means that querying, for example, will be faster?

What is the price of "transferring"? Is that a copy (in which case I assume it would be expensive) or just a pointer shuffle?

Edit, more questions: If it's a pointer shuffle, then I guess chunks (of entities with the same archetype) don't get "merged", but remain separate, but now belong to the same world?

How do you manage systems in different worlds? I guess we'll need to make custom bootstrappers for each World?

 

I do not know the cost but I guess transfering from one to another should just transfer ownership of chunks if you transfer whole archetypes. Copy will be more expensive but still saving a checkpoint data in OOP would be harder to do and much slower.

 

I would like to know a bit more about this subject too.

 

Thx @Joachim_Ante for more in depth explanations and clarifications regarding worlds.

 

FT10 SSF2XJR1 when? :3c

 

if you can create lightweight smaller worlds and know ahead of time which ones to update, you can do a lot of things. For example, your game mechanics could possibly rely on physical multiple worlds where the player jumps or interacts between them. Or if you have a rewind time mechanic, you could in theory have a second world that simply is recording the states of the main gameplay world and only swaps out for the main world when you rewind time. Or you can create replays/Overwatch's play of the game without tampering the main world, making entity management a breeze - ie nothing needs to be managed, just let the world update or pause and just resume when the play of the game is done.

That being said in my experience performance of multiple worlds is unfortunately not very good at the moment because since performance is currently limited by the number of systems you're running even if they're not doing anything. A system that does lightweight workloads or even just early outs still takes up frame time, so if you have one world with lots of systems and another world with lots of systems, trying to update them both even if they don't have any workloads can destroy performance. So you have to be super extra cautious about update ordering and the number of systems going in a frame.

Also multiple worlds thanks the entity conversion system for game objects is a freaking nightmare, in part because it uses this whacky singleton world if not overriden prior. It also has some special editor handling that I've had issues with, so I don't know if Unity actually wants you to be using it like that?
And there's no way to say "if you create an entity in one world, also put it into the other world" if you're looking for that. You need to create whacky tags and your own system, or controller, to copy them. Basically it can only put gameobject conversions into one world, and you have to hook in prior to loading those gameobjects or scene. You really should roll your own conversion system if you go this route to avoid massive confusion and headaches. Depending on your goals, your mileage may vary.