How to stop following/rendering remote game object when using interest groups

Options
Hi!

I am developing a PoC with "One big world" that is meant to have many (100-200) players who can interact. The world has various architectural rooms (all one Unity scene and all one Photon Room). I call the architectural rooms "Areas". The interest groups are set up by attaching colliders to the areas, so when a player moves into a new area, they adjust their interest groups accordingly.

All of that is working fine with PhotonTransformView and PhotonVoice, with one hitch: When a player leaves an area, he is till visible to the other players in that area at the place where he left the area (usually a doorway). Since the player is no longer in the interest group, using IPunObservable callbacks doesn't work. I have tried to send messages via RPC calls but having issues with that approach. Before I debug further, wondering if there is a better solution?

Also wondering, when I do get the info that the player has left the area, is the best practice to SetActive (false) on that gameobject, or is there another technique for making that player disappear until they rejoin the area.

Thanks

Answers

  • Tobias
    Options
    Sorry but .. we can not support this case really. PUN and PhotonTransformView won't scale to 100 players in a room, no matter what.

    About the actual question: When a character leaves the Interest Group, there is no notification for that. You could possibly come up with one but by default, you simply don't get updates from groups that are not subscribed.

    Maybe you disable or destroy (this is up to you / your needs) characters, which move close to the border of Interest Groups (based on position). And enable them when they are a few steps inside a group's area.
  • Thank you.

    I ended up figuring it out -- I had not realized that RPCs were affected by interest groups. Now I do the following when a player leaves an area

    - Send RPC call ("LeavingArea") to current area interest group
    - Unsubscribe from that area's group and voice group
    - Change transmission group and voice group to new area
    - Send RPC call ("EnteringArea") to new area interest group
    - Subscribe to new area's group and voice group

    After all that, the player leaving the area correctly notifies those players still in the area that they are leaving, and correctly notifies them again when they come back.

    On the other players, I change 2 properties on the leaving player: set scale to 0 and set renderer to disabled; and do the opposite when the player comes back.

    Note that this does not help the leaving player toggle visibility correctly. He also has to mark as invisible all the players in the area he left, and mark as visible all the players in the area he enters. This is achieved by calling "SetPlayerProperties" every time a player changes an area, and storing the results in a hashtable.

    That way, when the moving player changes rooms, they know which other players to disable (the ones in the area they just left) and which players to enable (the ones in the area they just entered).

    Wanted to document that in case it's helpful for others! However, the larger answer is a bit disappointing: even with heavy interest management, we can't have 100-200 players in a Room. I wonder what alternatives exist...



  • Tobias
    Options
    If you call SetCustomProperties when a player leaves/joins an area, the other players get this as update. Means: You can skip sending the surplus "enter" and "leave" messages. To maximize the number of players a room can support, you want to minimize the data everyone sends.

    To approach a game for 100 or more players, you need to learn a little about the restrictions which keep everyone from supporting that. The way you approach it, makes clear you don't know/care much about the networking itself. Aside from bandwidth, there are implications for the costs and performance. Also, static interest groups (based on areas) won't cut it when some area in your scene is so interesting that everyone goes there...

    Gaffer on Games is a blog with a lot of background info, in case you want to catch up.