Large Amount of Networked Objects

Options
In the application I'm working on we have a couple of huge hierarchies. Each of the objects in these hierarchies are gameobjects that the players should be able to interact with (move, grab,...) over the network. For now each of these objects has a Photon View that keeps track of a Photon Transform View and a custom script that holds some information about the object. However, some of these hierarchies are so big that we exceed the MAX_VIEW_IDS defined in the PhotonNetwork class. This is not necessarily a problem because we can just change this value but since that is never recommended, I'd like to know if there is an alternative to this situation.

One solution that came to mind was to place a script on the root of the hierarchy that would keep track of all its children and their data, minimizing the amount of Photon Views to 1 per hierarchy. Since the child objects in question remain kinetic unless a player interacts with them, we would only send this data when one of their values has changed. However, this would mean that the root script would have containers containing the information of both the local children and the remote children and constantly loop over these large containers to check for changes. Additionally, since these children do not have a Photon View, ownership will have to be handled in some other way.

I'd like to know what the common practices are when handling a large amount of networked objects. How does using lots of Photon Views compare against using 1 single Photon View that sends all the data? How would I go about this most effectively?

Comments

  • Hi @NicoS,

    I guess you are already on the right way by using just one PhotonView per hierarchy instead of a number which exceeds the limitation made in the PhotonNetwork class. So I think you should follow this approach.

    However, this would mean that the root script would have containers containing the information of both the local children and the remote children and constantly loop over these large containers to check for changes. Additionally, since these children do not have a Photon View, ownership will have to be handled in some other way.


    Basically the parent object needs to have a list of all of his child objects. Having an unique identifier for each of the child objects would be a good idea as well. Each of the child objects could also have a property, which describes the current owner of the object (should be the one who is currently controlling it), i.e. 'non', 'client_1', etc. To interact with an object, a client basically have to request its ownership which works similar to the functionality given by the PhotonView component. In this case you would have to set the previously mentioned property. If you are the 'owner' of the objects, you can start moving it around. To synchronize this movement, you would have to send custom events, which can be done by using PhotonNetwork.RaiseEvent. When using this, you would have to use the previuosly mentioned unique identifier as well. After sending the identifier and the new position of the object, the OnEvent handler of the parent object gets called. This object can then update the certain child object accordingly. When finished interacting with the object, the client would have to send a third event to 'reset the owner' of this child object.

    In conclusion you would have three events, like the following:

    - RequestOwnership (unique identifier, new owner)
    - UpdateObject (unique identifier, new position [and rotation if necessary])
    - ResetOwnership (unique identifier)

    Since you have multiple hierarchies, you would have to add an unique identifier for them as well and might have to add another object (some kind of an hierarchy manager), too, which processes the OnEvent callback handler (might be optional).
  • NicoS
    Options
    Hi Christian_Simon

    Thank you for your response, it was immensely helpful to get me started. I've managed to set up the root hierarchy to handle all information of child objects and communicate any changes through the network. However, currently I'm using OnPhotonSerializeView to update the values of changed objects, but since only 1 player can be the owner of the root object, this means that only that player gets to send their changes even though the other players are interacting with child objects of that root object.

    You mentioned using RaiseEvent to instead transfer ownership and update objects but I'm wondering how well RaiseEvent will perform. Some of these updates such as changes to object transform should be sent as fast as possible. Can RaiseEvent be used effectively to continuously send updates?
  • Can RaiseEvent be used effectively to continuously send updates?


    Yes.