Best practice architecture for separating rendering and logic

[icy fable]

So for various reasons, I want to keep my game logic completely separate from how the world is rendered.

In practice, that means that I have a struct World that completely describes the current state, and all external possible state transformations are described by member functions.

Everything is completely discrete, so I don't have to worry about continuous actions, changes over time, or simulations that need updates every tick, etc.

What would be the proper way to now set up the rendering etc on top of this in Bevy? I see basically two possibilities:

• The world exists just for itself as Entity in the ECS that somehow renders everything in it.
• The world somehow has one entity in the ECS for each of its elements, so they all get rendered by Bevy individually. Upon changes of the world, it somehow needs to update/delete/create these components to reflect the current state correctly.

Both seem not very great/best practice to me. The first one basically sidesteps the whole ECS by putting everything in one entity that does everything internally. The second one kind of duplicates state, once in the world, once in the ECS.

Do I overlook a better option to do this? Is there a good example I can look at of some project that already does something similar in a best practice way? Or is Bevy maybe just not the right tool for this kind of game? In that case, what would be better fit for this?

[limber river]

The latter is kinda already done by bevy internally

It uses a separate render world and all entities that can be rendered have their relevant states copied over between frames

Bevy offers a concept called Sub Apps to help this kind of separation, with an extract phase to bring data from one world to the other - might be worth leaning on for your separation

You can also store a bevy World in a component or Resource and manage the sync yourself - I do this in a backend project where the ECS serves as the model in an MVC framework

[icy fable]

Hm, interesting. Would it make sense to manually destroy and recreate all to be rendered entities every frame? I thought that might be very inefficient, but apparently that's what's happening internally anyway in the render world?

Because in that case, all I need is a function that creates all entities from a given game state and then I use this every frame to make sure the correct state is rendered.