Network interest management: replicate the relevant world to each client

Decide what each connection needs

Interest management selects the objects or data relevant to each client. The authoritative world can remain much larger than any client's replicated view. Rules may use distance, ownership, teams or match membership. Mirror documents these alternatives, while Unreal evaluates actor relevancy per connection. Camera visibility alone is insufficient: an offscreen projectile or audible enemy can still affect the player. [1][2]

Treat membership changes as a lifecycle

Entering the relevant set requires enough initial state to create a usable client representation. Later deltas must refer to a baseline that client actually possesses. Leaving requires a defined hide or despawn operation; it does not necessarily delete the authoritative object. Unity's network visibility explicitly controls client spawning, despawning and object traffic. [3]

On re-entry, establish fresh state and reject delayed updates belonging to an obsolete object incarnation. Separate persistent identity from a recycled runtime handle. An object's attached equipment and other dependencies also need coherent visibility, or the client receives references it cannot resolve.

Worked example: payload savings and boundary churn

Consider an illustrative server with 1000 dynamic objects. Sending 64 payload bytes per object at 20 updates per second costs 1000 * 64 * 20 = 1280000 bytes per second for one client. If that client needs 80 objects, the same model costs 80 * 64 * 20 = 102400 bytes per second. These are payload calculations, excluding headers, compression, initial state and retransmissions.

For ordinary distance-based membership, suppose objects enter within 100 meters but remain until beyond 120 meters. This hysteresis reduces repeated spawning near a boundary. It also retains extra objects; choose the margin from movement speed, update cadence and entry cost. Apply information permissions before this spatial convenience rule, so a wider exit radius never reveals a forbidden opponent.

Build and measure the relevance pipeline

Start with explicit always-relevant, owner-only and spatial categories. Use a spatial index to produce candidates, then apply the full rules. Update membership when players move, teams change or objects spawn. A delayed rebuild needs a conservative margin or an immediate path for urgent changes.

Log relevant-object counts, evaluation time, initial-state bytes, steady traffic and entry/exit frequency. Test teleports, spectator cameras, crowded entrances and rapidly changing ownership. Inspect what a client actually receives, including fields on otherwise relevant objects; object membership does not automatically filter private fields.

Understand the limits

Interest management trades server bookkeeping and lifecycle complexity for selective transmission. Dense encounters can still make almost everything locally relevant. Sending hidden information and later removing it cannot erase what a modified client already learned. Keep authorization rules explicit, and budget sudden visibility expansions as well as average traffic. Correct membership does not guarantee timely delivery or smooth motion; those require separate networking policies.

Sources

• [1] Interest Management — Mirror Networking contributors.
• [2] Actor Relevancy — Epic Games, Unreal Engine documentation.
• [3] Object Visibility — Unity Technologies, Netcode for GameObjects documentation.