What should be the motivation for creating separate ECS “Worlds”? Looking at the World.cs class, I’m not really seeing anything obvious that indicates why there should be several different worlds
Is it just a question of allowing you to better group systems together, so that you can then do something like this?
public void DoSomething()
{
// Update all systems of world 1
foreach(ScriptBehaviourManager m in myWorld1)
{
m.Update();
}
// THEN update all systems of world 2
foreach (ScriptBehaviourManager m in myWorld2)
{
m.Update();
}
}
There are actually multiple cases where you might want to create multiple worlds.
Think about a server that runs multiple world instances on the same machine, or a multiplayer game that wants to run both server and client on the same process for debugging, or a system that stores worlds as snapshots to be able to query the previous state, etc.
The use cases are multiple, and it is all about flexibility for us. Allowing to run parallel isolated worlds, while still retaining very efficient ways to move entities between them, is a goal to allow game devs to cover today’s and tomorrow’s needs.
i guess an example off the top of my head would be if you wanted to simulate different types of physics to different degrees of accuracy, potentially changing the accuracy weighting at runtime. You could do stuff like have one world as a “rendering” world, and multiple “simulation” worlds where they just execute specific systems and physics (so one that handles fluid simulation, one that handles pathing etc etc).
@GabrieleUnity Translating this over to MMO/persistent game world terms, does that imply that going forward I can execute a single headless Unity instance for a particular zone of my game and spawn new zone instances by creating a new world? If so this might reduce the overhead of running multiple headless instances for each instance of an in-game zone.
Old, but I would like to add. Imagine if you want one more complete copy (or just a subset of) of the thing you are using with 0 problem, the code that worked will still work. (As long as you didn’t touch static in your system design, that’s where multiple worlds broke)
I have multiple systems working together. One that loads a file (can only hold 1 open file), a system to edit it (work on system that opens the file) , and save the file.
Now I would like to implement a function that iterate and analyze through multiple files to paste some data in the currently open file. I don’t have to implement a function to handle multiple files, I can just make a new world while inside the current world and create the same set of systems for it. Tell the system to work and grab the data out, then dispose that “worker world”. (Or work on everything required inside using (World w = new World("Worker")) { ... } scope. )
As far as I understand you can run worlds on specific threads or at least it is a planned feature. In which case, if you need to create a lot of entities but don’t want to load the main thread I was told that you could create them in another world and transfer them to the main one and save main thread time (if transferring is cheap). But I need a confirmation on that.
It’d be great if Worlds can run on separate threads, right now I have two main Worlds - one World that helps render / communicate with Unity, and another World that handles all the game logic, which doesn’t use anything from UnityEngine. My game is turn-based, so by design I’m already forced to manually update the logic world (phases/systems need to loop until turn is resolved).
Would there be problems if I tried to put the logic world on its own separate thread? Is there anything inherent in the ECS design that demands access to the main thread? I assumed something like EntityManager and Jobs might break the whole thing (though I’m not using any Jobs yet).
edit: Just read Joachim’s reply, will need to look into ExclusiveEntityTransaction…