This question is for a world partition level in a multiplayer game setup. The specific question is, what is the suggested way to track actor states between server, where all actors are always loaded, and on clients in a distant region where actors are currently unloaded.
Here is a scenario:
You have a huge map, lets say the size of a Fortnite map. You are playing and in a region that is far away there is a massive explosion that is supposed to hide actors. The explosion can affect any actors in the area, including bps and static meshes. (I assume that replicating all actors is not a viable solution) The explosion happens on the server, the affected actors get hidden, but their client counterparts are unloaded via world partition logic, so the client side explosion can’t access them. If I store the list of affected actor references in a repNotify array on the server, the array’s references will not get resolved to client counterparts because they are unloaded and they don’t exist. One solution I saw mentioned online is to create a custom bp helper actor that will be spatially loaded and will have an instance in each wp grid. Upon entering a zone, the helper actor will load setting off logic that will wait for actors to load and check if the actor references in the array get resolved client references.
As you can imagine, this setup could be cumbersome with many edge cases. Which brings me to my question, is there a more elegant solution for this problem that can be implemented using bp logic, or is it something that needs to be handled in cpp?
Thank you in advance!
Richard G.
Hi,
In a situation like this, the most common, straightforward way these actors would be handled is to have them all replicate. If an actor has some gameplay-critical state that needs to stay synchronized between the server and clients, that actor and its relevant properties should be marked as replicated. This ensures that clients receive the latest state for these actors (including if they’ve been destroyed) when loading into a new part of the map or when joining a match in progress.
Having a large number of replicated actors can come with a high performance cost on the server, so for actors placed in the level, these should also be marked as initially dormant. This allows the replication system to skip considering these actors for replication, so they don’t incur any performance cost until they’re woken up and their properties are changed. This is how Fortnite handles all of its destructible actors placed throughout the map.
You can find more info on using dormancy here: https://dev.epicgames.com/community/learning/tutorials/K8vY/unreal-engine-optimizing-server-performance-with-net-dormancy
Also, do some of these affected actors need to simulate physics? If so, I can reach out to a colleague to get more info on how physics actors tend to be handled across the server/clients.
Thanks,
Alex
I don’t think we can use net dormancy as most of the actors are not replicated and some (like static mesh actors) can’t be replicated. But this is great information that we can utilize in other cases. Thanks
Hi,
You’re welcome! If you do need to sync the state of objects between the client and server and making them replicated is not an option, then you will likely need some replicated proxy actor to manage this, like you previously mentioned.
Thanks,
Alex