Client Server System Variants and beyond

Unity Engine
,
1

This Client Server System Variants feature is the feature I most wanted now. Currently I have asset store asset that is not support dots netcode. It’s extremely annoying that every time there’s new update, I need to maintain and change the system to update at client/server world make it support dots netcode properly. So I would like to have Client Server System Variants that works similar like current Ghost Component Variants but now it’s on system that now u can change any system at package without require to modify package anymore.

Beyond that, I would also like to request to show all the client and server systems at editor before enter play mode that at System Window not only u can check it but also able to disable the system that’s not using that it become config saves into disk persistently that it becomes something similar like GhostAuthoringInspectionComponent authoring baker that u can configure ghost prefab and save into disk. Furthermore the system windows also able to show all Baking System before enter play mode too. To make it even further, it’s really nice to be able to show client and server world entities at Entities Hierarchy windows before enter play mode

2

Hey optimise! It’s possible to disable a system from your own system, so I’d recommend you simply do that. No “system variant” API needed.

This is more of a feature request for Entities. The problem is that systems are added by code contracts, so having a secondary file-based filter may not align perfectly with any conditional code used to create systems.

I’d recommend writing this yourself to begin with.

I agree and like this suggestion. Those worlds obviously don’t exist at that point, so it has some feasibility issues, but it seems desirable as a long term debugging goal. I’ll add it to the backlog, thank you for the feedback.

1 Like
3

What I actually mean is when the asset store ecs package has been written that has no support for client / server world meaning that it will just go to default world which is not the expected behavior when u need to use it at dots netcode project. So I need this “system variant” API to make it able to override the system to run it at client or server only world that basically work very similar like Ghost Component Variants without require to modify asset store ecs package.

Actually this is very similar like how GhostAuthoringInspectionComponent works that u write Ghost Component Variants API to override it but u can use GhostAuthoringInspectionComponent to make the final decision that GhostAuthoringInspectionComponent has highest authority to decide which Ghost Component Variant should apply. This concept applies to System Windows that System Windows has the highest authority to decide which system to enable/disable and even better u can drag the system up and down to override the final system ordering.

4

I was going to ask clarification because I thought we didn’t answer to your question. This now make more sense given the sentence you wrote.
This has been a long topic of discussion how to achieve that (seamless multiplayer support). There are a lot of caveats and pattern that you use when you write MP in first place that aren’t required for single player in general. First are the flow and message handling (that you usually don’t have) other specific component or query needs (that again you usually don’t have) among other more simple issue like: how to schedule the system in the right place (we have the similar problem with Physics).

Even supposing that we can have a System Variant API, how are you going you use it? It is just to inject the system in another group ? Or you need to use different queries? or handle some other cases internally?

Asking because In the latter, you need to rewrite the system anyway, so at that point… just modify the package code directly and that it seems more a natural choice.

5

Currently I will just use it to override system at default world to Server world then I already get it working since I just want the particular systems to run at server world only and client side no need to run the system.

Moving forward, when official working on better support for single player and multiplayer switching use case at same game build will need to implement much better holistic solution for it. If I understand correctly currently there’s custom bootstrap but u will need write lengthy boilerplate code which has some complexity just to setup specific system to run at client / server / local and u will need to change code and recompile every time u want to change system setup. And also I dun think it’s good idea to create and dispose bootstrap just to switch between local and multiplayer which I believe it’s how dots netcode has been designed currently that I believe not just it’s really slow to create and dispose boostrap because of current bootstrap path is still not upgrade to fully burst unmanaged land yet and also memory fragmentation every time u create and dispose bootstrap which is really bad. I think to tackle this problem firstly is to implement system config that can save into disk to make it much easier to change system setup without require to recompile code. Then change the default netcode boostrap setup to make local, client and server word stay at memory persistently without require to keep creating and disposing world anymore that now u just need to disable local world when need to switch to multiplayer.

6

System configuration as scriptable object (or similar) has been discussed in Entities as a topic (among other solutions).
I do agree that would be better to have this data driven all these:

  • World in which execute
  • Group in which execute
  • Relative ordering
    Among other stuff.

If you need to write your self which system in which group and world need to run, the answer is yes, it is quite cumbersome to write (we had that before too, and this is why we added WorldFilter). But that would not solve the groups problem (and creation order dependencies too).

Bootstrapping is an heavy operation, I agree. But happen only when you create/dispose world. That is not that often. There are way worst fragmentation and memory waste in other area. Not to mention, may of these allocation are in chunk (so not small allocations).

Bootstrapping cannot be completely unmanaged, because of the existence of the SystemGroup (that are managed) and other little things. Apart that, it is also great that it is not, because this way you can use other machinery (like scriptable, configs, etc) that would be impossible to use otherwise in burst land.
But the process could be technically two step (one managed, one un-managed, burstable) but it is a lengthy process to the get there.

But this is really up to you… You can already do that if you really want. There is nothing preventing you to create all the worlds you want and not disposing them (when you are in game, if we are speaking about edit mode is another story).

The problem though are becoming bigger then the benefits of not disposing them:

  • Scene loading become problematic (because of the way sub-scene works)
  • How do you ensure the world state is actually re-usable all the time? Are you sure you don’t have anything in memory, cached, or something in your systems that is not properly reset ? It is dramatically hard and time consuming tracking these things.

Disposing world give you a very clean state you can rely and start from and ensure consistency. As soon as you are start keeping stuff alive, apart also potential memory consumption, the risks are bugs because of non-reset state or inconsistent world state.

If we could ensure that Systems has no state (or all the state is properly reset) but still keep them alive (so the memory is not de-allocated) and all the entity data is properly destroyed then we the world creation can be lighter:

  • Systems are re-used
  • Only the entity data storage need to be re-created (and the system associate entities as well).

That requires a lot of changes in Entities that I hardly seen happening in the short term.