filtering network updates to specific clients

Quadgnim

In my design I'll have a lot of players potentially in different levels at different times. They will be able to come and go between levels at will. In an attempt to optimize minimal network traffic I'm trying to only send sync and RPC updates to other players in the same level therefore I'm doing:

setsendingenabled (prev_level, false);
setreceivingenabled(prev_level, false);
setlevelprefix(new_level);
setsendingenabled (new_level, true);
setreceivingenabled(new_level, true);

from a coding perspective all this seems to be working, but in practice I'm getting an error that an rpc was
received for levelprefix 1 but I'm in level prefix 2 (or vice versa)

Anyone have an idea why this is happening?

I also heard/read somewhere that Photon has specific support for not sending network updates based on distance. How is that done, and can I use it or something similar to isolate networking between levels, but still allow players to navigate between levels?

I should also mention that for the player I'm performing DontDestroyOnLoad, so my player persists between levels.

Any ideas?

Thanks,

Larry

Tobias

The level prefix is not keeping your clients from sending messages to all others in the same room.
With the newer PUN 1.18 version, we implemented Groups in a new way. They could basically define 254 groups per room and separate players into distinct levels (interest groups). However, as the server executes all player's messages serially per room (basically single threaded but using a pool), the server might become a bottleneck, depending on the player count.
We didn't implement many usecases for this new feature yet and found it can be a source of problems: Messages for a group won't cache, so Instantiate and RPCs won't work in groups. If something is sent in a group, clients who didn't "subscribe" to that group, won't get the message at all. This might look like missing messages.

In best case, you use multiple rooms and switch between those. Will there be a lot of level changing?

The position-based interest management is done in a separate server logic project, called MMO Framework. It's very different from what PUN offers and not run in the Photon Cloud. It's built for seamless world MMOs but more a framework to build your own game on top. So don't expect a Hero Engine or similar.
Also, it uses the "plain" Photon API, meaning: No Photon Views and automatic Game Object sync.

You can find it with samples in the Server SDK.
http://www.exitgames.com/download

Quadgnim

Thanks Tobias.

Based on all of the above, can we spend some time chatting about rooms and setendingenabled / setreceivingenabled, along with photonView.group? Should I be able to filter not receiving data to a particular client?

For example when a player starts in level 1 I:

1. setsendingenabled ( .... , false); for all potential groups (except 0)
2. Setsendingenabled ( 0, true);
3. Setreceivingenabled (0, true);
4. setsendingenabled (spawnlevel, true);
5. setreceivingenabled (spawnlevel, true);
6. photonView.group = spawnlevel;
7. photonView.group = spawnlevel;

Then when a player switches to a new level I

1. setsendingenabled (oldlevel, false);
2. setreceivingenabled ( oldlevel, false);
3. setsendingenabled (newlevel, true);
4. setreceivingenabled ( newlevel, true);
5. setlevelprefix (newlevel);
6. photonView.group = newlevel;

Conceptually should this provide filtering of network commands to just specific clients that are all in the same level? If so does this seem like an ok way to go about it, and if not should I consider another approach?

You had asked how many levels I'd have. It could be 10-20 levels and players will be continuously bouncing between them. I could have all players in 1 level but that's highly unlikely. I'm looking to have approx 4 teams of 15 players each so it could be 60 players in a single campaign, but maybe 10 in any given level at a time. Sometimes more, perhaps upto 30 (worst case could be all 60). If possible I'd even want to increase the number of teams and perhaps the size of teams. To do this I wanted to limit network updates to just the current level a client is in, and when I need to reach everyone I could temporarily switch to group=0 and maybe levelprefix=0. I'm wondering if I can do all this and just leave level prefix = 1 for everything?

If you want more detail on the game I'd be happy to provide it, even in a private thread if necessary.

Any thoughts, feedback, suggestions are greatly appreciated.

Thanks,

Larry

Tobias

The concept is sound and should work in principle.
There are a few corners and things to keep in mind:

These are a lot of players and if they ever end up in the same place, this could break your connections due to flooding. The server currently just passes along any amount of data but can't skip what's unimportant or reduce send rates or anything. Test the "all in one place" scenario early on with as many clients as possible!

PhotonNetwork.Instantiate and buffered RPCs will always be "cached" and sent "to all". You can't "hide" those from any player in the same room, so you need to keep them low (best: none).

Send as much unreliable as possible. Unreliable data does not need an ACK, can skip some updates (if a new one arrives before the older ones) and never repeats. It's better for frequent synchronization messages.

I don't think you need to use setSendingEnabled, actually. Anything a client sends usually should reach the server. Exception: You switch to a new level and keep a GO that should be muted.
SetReceivingEnabled is what defines what's interesting for your client. Anything that's not enabled this way will not be received and effectively limits what your client receives.
The SetReceivingEnabled API is currently done Unity-alike but Photon is a bit more powerful. We could add a method to remove the "old" interests and set new ones in one step. This is also a "per client" setting actually, so you only set it per area change.

Group 0 is always visible. You can't remove that from your interest groups. Workaround: use groups 1 and up.

Just found out: So far, we don't support synchronized changing of the group of a PV (PhotonView). So if you change the PV's group, remote group values will stay what they were on instantiate. Better ignore this by using group 0 initially. Shouldn't be a loss, cause the server can filter incoming interest groups and sending might always be "active".

LevelPrefix: If you don't change it, then don't set it either. It's a variable we skip as default value, so this saves a bit of traffic.

Having 20 levels will still leave you some interest group IDs for team chat or similar.


I hope this helps.

ctalmeida

Hi Tobias

Looking for implementing interest management using photonview group number.

What is the limit of the group number? I am looking on a map that may have 2,500 areas.

I just did a test, created 2 players with group zero on the instantiate,

PhotonNetwork.Instantiate("PlayerController", mySpawnSpot.transform.position, mySpawnSpot.transform.rotation, 0);

then sent RPC on both and worked fine, then I changed player number 2 photonview group to 1. Player with group = 0 send RPCs but the player 2 does not get the message. You said above that group 0 always send messages to all. Is that correct?

Then what I read in this post is that I should be using SetReceivingEnabled? Should I not change photonview.group at all and just let all on zero and just use SetReceivingEnabled when a player move to a different group?

Thanks

Carlos

ctalmeida

Hi Tobias

Sorry writing again.
I got the PUN PLUS on the Unity store and install the new PUN version, the problem where my player on group 1 would not receive RPC from player on group zero disappear, is working now. Then now the SetReceivingEnabled makes sense.

My question stays.

What is the limit of the group number? I am looking on a map that may have 2,500 areas.

Thanks

Carlos

vadim

Hi Carlos
Tobias wrote above:

They could basically define 254 groups per room

Looks like much less than you need.