Photon Realtime Interest Groups for Room Traffic Filtering

Stop broadcasting the whole room to every client

In a single Photon Realtime room, all players receive all state updates by default. For a large map with hundreds of networked objects that is unsustainable. Interest Groups let you keep one logical room while the server filters what each client receives. Assign objects to a group ID and clients subscribe only to the groups they care about. Bandwidth and CPU drop because irrelevant updates never leave the server.

Interest Groups are not a replacement for room segmentation. They are a traffic filter inside a room. The server still tracks everything, but it only forwards events and ownership changes for entities whose group is in the client’s subscription set.

How the filter works

Two operations control the filter.

Publisher side: a networked entity is tagged with a group ID. In Photon Realtime SDKs this is typically a property on the network view or entity, e.g. SetInterestGroup or an InterestGroup field. The server uses that tag to decide which subscribers may receive the entity’s updates.

Subscriber side: a client explicitly joins one or more groups. The client receives RaiseEvent, state sync and ownership messages only for entities whose group is currently joined. Leaving a group stops delivery for that group.

The server enforces the mapping. If a client is not subscribed to group 3, packets generated by entities in group 3 are discarded for that client before serialization.

Worked configuration: zone-based map

Assumption: Photon Realtime with a Unity client. API names vary by SDK version and binding. The pattern below is illustrative, not a tested build.

Room setup. One room hosts the whole map. Zones are encoded as group IDs: Zone A = 1, Zone B = 2, Global chat = 0. Group 0 is often used for room-wide data.

// Publisher: assign an entity to a zone at spawn time
// Run on the master client or server authority that creates the object
var view = networkObject.GetComponent();
// illustrative property name
view.InterestGroup = 1; // Zone A

Clients subscribe to the zone they are in and to global.

// Subscriber: join groups on entry
// Run on the local client after joining the room
// illustrative API names
PhotonNetwork.JoinInterestGroup(0); // global
PhotonNetwork.JoinInterestGroup(1); // current zone

// When the player crosses a zone boundary
PhotonNetwork.LeaveInterestGroup(1);
PhotonNetwork.JoinInterestGroup(2);

Meaningful placeholders: networkObject is the spawned prefab, 1 and 2 are your zone IDs. Required permissions: the client must be connected and in the room; group changes are local and do not require elevated rights.

Expected behavior: after joining group 1, the client receives updates only from entities whose InterestGroup is 1 or 0. Updates from entities in group 2 are not delivered. Changing groups updates the subscription set on the server immediately, so the next tick reflects the new filter.

Risk: forgetting to leave the previous group causes the client to receive two zones simultaneously, increasing bandwidth. Forgetting to join the new group causes pop‑in when objects appear only after the first update is sent.

Verification without inventing logs

Instantiate multiple network objects in the same room with different group IDs. Enable Photon logging on the client and observe which callbacks fire.

Practical check: create three objects, groups 1, 2, 3. Join only group 1. Trigger a state change on each object. Confirm via the client’s event handler that only the group 1 object produces a callback. Then change subscription to group 2 and repeat.

Network logs can be inspected in the Photon Dashboard or via client‑side debug output. Look for the set of incoming event codes per object. The absence of events from unsubscribed groups is the signal the filter is active.

Limits and common mistakes

Over‑segmentation creates pop‑in. If a player moves between groups faster than the server sends a first update, objects appear late. Mitigate by overlapping groups briefly or using a small hysteresis on zone transitions.

Manual transition bugs. Group changes are client‑driven. If the client fails to unsubscribe from a previous group, it continues to receive that group’s traffic. If it fails to subscribe to the new group, it misses updates until the next manual correction. Centralize zone change logic and always pair Leave and Join.

Interest Groups do not replace spatial partitioning. In extremely large open worlds, group IDs are coarse. You still need distance‑based culling or a separate spatial system. Interest Groups reduce traffic within a partition, they do not create the partition.

Group ID range and count are limited by the SDK. Exceeding the supported number of groups per client can silently drop subscriptions. Check the SDK documentation for your binding and version.

Maximum Transmission Unit considerations. The feature helps avoid MTU fragmentation by reducing per‑client packet size, but it does not guarantee packet size. Keep individual events small and avoid bundling many properties into a single RaiseEvent.