Multiple Worlds

I was playing around with ECS to make a turn based, tilemap demo and ran into some confusion when it comes to the worlds and separation of entities.

I keep reading that it is normal to use separate worlds for rendering vs the simulation.

Does this mean I should have two worlds for a basic roguelike project? One world to handle all the logic systems of the player and the monster entities, etc. and one world that manages the tilemap rendering with a completely different set of rendering entities?

That is how I am interpreting it but wanted to make sure going down the correct path. I assume I would have some sort of bridge where once I update the simulation I update entities in the rendering world to initiate the change.

 

from my own experience, I recommend to just use one world for now:

- when I tried, there were missing methods / apis changes related to dynamicbuffers not kept up to date in the entitytransaction part vs entitymanager / commandbuffer apis, and I think the entitytransaction is what make the multiple world really worth it ( to efficiently batch create the entities in the render world)

- If you re learning ECS and prototyping your own code without a very strict architecture, having multiple worlds makes changing your mind / refactoring systems more painful, as you can not have dependencies between systems in different worlds. In my case I'm doing voxel stuff and the frontier between rendering and generating is not well defined yet for me.

So to summarize multiple world is an optimization, and premature optimization is the root of all evil

 

Well, referring to last sentence, I would least expect to hear that In ECS context. Using ECS is like massive optimization. And many aspects can be made quickly in Unity editor with OOP. Hence I don't think this phrase fits anyhow to ECS.

In ECS is good to learn how to write optimal code from beginning.