Is doing RPC.All equivalent to looping through each player and sending it to each of them?

Options
For example if a player isn't close enough to a certain networked objected, he doesn't need to receive the RPC updates. In this case I want to loop through each player, and decide whether they should receive the RPC or not.

Is there anything wrong with this approach?

Best Answer

  • Tobias
    Tobias admin
    Answer ✓
    Options
    It's primarily an issue if you do this on a client.

    With the server's help, a client can send a message to everyone else (e.g.) by sending the data up just 1 time.
    If this client sends the same message to each player individually, it must send the data up X times. X being the number of players-1.
    The client can also compile a list of target actors (I forgot to mention that above) and send the data up 1 time with a list of targets.
    So case a) or c) are best.

    In all cases, the server always has to send said data to all the receivers. So on the server side, it does not really make a difference. However, performance wise, it's good if the server has one message going to multiple clients, too. Serialization is done only once and sending is optimized for lists of targets.

Answers

  • Tobias
    Tobias admin
    edited August 2021
    Options
    The approach is not optimal, as the sender now has to send a lot of individual messages (one per player who should get the RPC).

    For a simplistic interest management, you can use the Interest Groups. You divide the world into groups and players only subscribe to groups to which they are close-by.

    https://doc.photonengine.com/en-US/pun/current/gameplay/interestgroups/


    Using RPCs can be replaced with RaiseEvent, which is not PhotonView related. That may be a benefit, too.

    https://doc.photonengine.com/en-us/pun/v2/gameplay/rpcsandraiseevent
  • Tobias wrote: »
    The approach is not optimal, as the sender now has to send a lot of individual messages (one per player who should get the RPC).

    For a simplistic interest management, you can use the Interest Groups. You divide the world into groups and players only subscribe to groups to which they are close-by.

    https://doc.photonengine.com/en-US/pun/current/gameplay/interestgroups/


    Using RPCs can be replaced with RaiseEvent, which is not PhotonView related. That may be a benefit, too.

    https://doc.photonengine.com/en-us/pun/v2/gameplay/rpcsandraiseevent

    Thanks for the info, good to know about those.

    Regarding this "as the sender now has to send a lot of individual messages" does this still apply in a self hosted dedicated server scenario? Or is it just mainly not optimal in a P2P situation where a player master client needs to send those?
  • Tobias
    Tobias admin
    Answer ✓
    Options
    It's primarily an issue if you do this on a client.

    With the server's help, a client can send a message to everyone else (e.g.) by sending the data up just 1 time.
    If this client sends the same message to each player individually, it must send the data up X times. X being the number of players-1.
    The client can also compile a list of target actors (I forgot to mention that above) and send the data up 1 time with a list of targets.
    So case a) or c) are best.

    In all cases, the server always has to send said data to all the receivers. So on the server side, it does not really make a difference. However, performance wise, it's good if the server has one message going to multiple clients, too. Serialization is done only once and sending is optimized for lists of targets.
  • Tobias wrote: »
    It's primarily an issue if you do this on a client.

    With the server's help, a client can send a message to everyone else (e.g.) by sending the data up just 1 time.
    If this client sends the same message to each player individually, it must send the data up X times. X being the number of players-1.
    The client can also compile a list of target actors (I forgot to mention that above) and send the data up 1 time with a list of targets.
    So case a) or c) are best.

    In all cases, the server always has to send said data to all the receivers. So on the server side, it does not really make a difference. However, performance wise, it's good if the server has one message going to multiple clients, too. Serialization is done only once and sending is optimized for lists of targets.

    Sweet, thank you for the info Tobias!