How best to go about implementing component dormancy in Iris?

Development Programming & Scripting Multiplayer & Networking
, ,
1

Hello,

We want to have a high number of networked AI character actors in our game (1500+). Each of these AI is composed of over 20 components, most of which have replicated state. To help with perf our strategy is going to consist of turning components “on” and “off” based on based on some LOD heuristic. When turning a component off I initially thought we could just stop replicating the component (AActorComponent::SetIsReplicated(false)) but there’s an issue with that approach:

  1. UFooComponent is attached to an actor and is set to replicate
  2. Server game logic sets replicated property UFooComponent::Bar to true and that value replicates to all clients
  3. UFooComponent is set to no longer replicate which results in the associated instance protocol, fragments and state buffers to getting cleaned up
  4. Server game logic sets replicated property UFooComponent::Bar to false
  5. UFooComponent is set to replicate which then creates a new instance protocol, fragments, state buffers etc
  6. Since the default value of UFooComponent::Bar is false, the server doesn’t replicate that value to the clients and the clients are now out of sync

…due to this issue, instead of turning replication off I’d like to essentially pause replication by making the component dormant. UObjectReplicationBridge::SetObjectWantsToBeDormant has an ensure to make sure only root objects (actors) have their dormancy change. Any advice here?

Thanks,

Nick

2

Hi,

There’s unfortunately not an ideal way to go about this, as we usually do not replicate partial state for actors and their components. Generally, Iris relies on relevancy and push-model to make sure clients are only being sent the info they need.

You can use SetReplicatedComponentNetCondition to change the components’ replication conditions as needed. By creating net groups and using the COND_NetGroup condition, you could filter components depending on their “LOD.” However, this may require a lot of different groups that components are frequently switching between, which could have a performance impact on the server. It’s hard to say what this impact might be like, as this isn’t something we’ve tested ourselves.

Another approach to consider would be proxying this data through separate actors (or possibly UObjects via Iris factories). This would allow for more control at a likely smaller performance cost, although it would require more handling in your project code to route the data between the components and these proxy actors.

Thanks,

Alex