multiple contexts
Closed this issue · 3 comments
Hello.
I want to use the ECS concept described in your articles in my indie game.
But there are some questions I can not solve by myself and asking for your help.
I want to divide the whole game logic into contexts (Svelto.Context) with the maximum encapsulation.
Each context will have its own EnginesRoot.
For example, the context of the quests logic, the context of a player control, the context of the enemies control, the context of the UI control, the context of data working, etc.
But there is a little problem.
I do not see the possibility of achieving the full encapsulation.
For example, quests can turn off enemy spawn in the course of their work because that would not interfere with the player.
But to do this, I need an access to the context of the enemies from the context of the quests. And it breaks the encapsulation and is impossible in the current logic because the contexts use different EnginesRoot.
Or, it will be needed an access to the context of the player from the context of the enemies in order to know about the target to attack.
Could you advise the correct way to exchange data between Context with different EnginesRoot?
We considered an option with a variety of Context and one basic EngineRoot for all entities.
But we didn’t like this option for a number of reasons.
I will be very grateful for your advice and help!
yes it's tricky. Even my team never fully exploited this theory, mainly because there are some tools missing that I need to implement.
First one is to have hierarchical engines roots, so that you can share engines and entities between specialized engines root. This one is tricky, I need to get it right otherwise it would defeat the whole point.
The second one is a formal way to let EnginesRoots communicate between each other. The communication between engines roots cannot be done through entities (unless I implement the hierarchical engines root). Atm you can do this using observers or even sequencers, but I have much better ways in mind.
I think encapsulated engines roots work well with GUIs, which usually interact with services and not other elements, although some times they can interact with other GUIs, but this is another problem that I roughly explained here: https://github.com/sebas77/Svelto.ECS/wiki/Svelto.ECS-and-GUI. However if they need to change data of not gui entities, it gets tricky too. In my Svelto example I solve GUI engines -> Not GUI engines communication through observers and sequencers. Again this can be improved in future as my observers are not really Svelto.ECS integrated although I designed them to work with it.
Take in account that you already achieve code encapsulation with engines alone. Engines roots encapsulation is more about separating entities data. The 1 EnginesRoot code encapsulation already allows you to avoid crazy dependency injections (which is usually the root of the spaghetti code, together with the use of Singletons) , while the multiple EnginesRoots encapsulation allows to encapsulate data, as entities will not be shared between EnginesRoot. This is actually something quite powerful, as without this, not exploiting the fact that entities data is actually global is just a formality (which I give through guidelines in my articles).
So I am all for multiples engines root and multiple contexts, but it's just a theory even for me. I need to work on it more, but before it the refactoring of DispatchOnSet and DispatchOnChange has a higher priority at the moment.
ok thanks for the information
ok, any thought/suggestion?