A multiplayer level has 100+ replicated actors — players, projectiles, pickups, and static decorations — with dozens of players connected. The dedicated server is CPU-bound on its networking loop: every tick it recomputes per-connection relevancy and diffs every actor's replicated properties, and bandwidth to each client is saturated. Most actors rarely change, and many are far from any given player. Describe how you would bring the per-tick networking cost down. Requirements: distant and irrelevant actors stop consuming send work for a given client; rarely-changing actors are not reconsidered every tick; only the properties a client actually needs are sent; and the approach must keep scaling as actor and player counts grow.

Problem statement

A level with 100+ replicated actors and dozens of players. The server burns too much CPU on the net loop: every tick it computes relevancy per connection and diffs every actor's properties.

Solution components

1. Relevancy and distance culling

• NetCullDistanceSquared — an actor stops replicating to clients outside the radius. The baseline defense against sending everything to everyone.
• Do not overuse bAlwaysRelevant — it disables culling.

2. Update frequency

• NetUpdateFrequency sets how often an actor is considered for replication. A static prop is fine at 1–2 Hz; a player pawn needs 30–60 Hz.
• MinNetUpdateFrequency together with adaptive net update frequency lowers updates while an actor is unchanging.

3. Dormancy

• Static or idle actors are set to DORM_DormantAll. The server skips them in the net loop until FlushNetDormancy is called.

4. Conditional property replication

• DOREPLIFETIME_CONDITION restricts a property — for example COND_OwnerOnly for private data, COND_SkipOwner for owner-predicted state. Fewer properties means less diffing work.

5. Replication Graph

• At scale this replaces the per-actor relevancy loop. Actors are placed into spatial nodes (grid spatialization), and per-connection lists are gathered from the nodes instead of a full scan.

Data flow

Server: state change
   → actor in Replication Graph node (or per-actor loop)
   → relevancy / distance / dormancy culling
   → property diff filtered by DOREPLIFETIME_CONDITION
   → packet to connection
Client: apply properties → OnRep callback

Trade-offs

• A low NetUpdateFrequency saves CPU but adds jitter to fast actors.
• Dormancy is free for static actors, but a forgotten FlushNetDormancy causes desync.
• The Replication Graph scales best but needs node-setup code and is harder to debug.