Understanding disconnect and dynamic objects

Hi all,

I'm hoping someone can point me in the right direction?

As the player creating a new room and starting a new game, I guess in Photon speak I take on the attribute of master client, right? Then as part of the level creation I want to dynamically create some content using Network.Instantiate. (or Network.getViewID {something like that} and using an RPC).

Creating a dynamic object this way makes me the photonView.isMine=true Now if the player that performed the instantiate of these level based objects what happens if that player drops? Do the objects drop too? Is there a way to migrate the objects to another player? Is there a way to support these objects on the server if I run my own photon server (not the cloud)? Is any of the management to do this built in or do I need to write my own code to detect when the owner of the level/scene objects is gone, and then do something to take ownership as another player?

Thanks for any feedback you can provide.


  • The master client can create scene objects (PhotonNetwork.InstantiateSceneObject) - these persist if that master client drops. The new master client then becomes the owner of them.
  • ahh, InstantiateSceneObject, I didn't know of that one. Excellent I'll check it out. Thank you.
  • Scruffles wrote:
    The master client can create scene objects (PhotonNetwork.InstantiateSceneObject) - these persist if that master client drops. The new master client then becomes the owner of them.

    I need some help.

    My game design has players moving between levels. Some players can be in different levels at different times. I'm trying to optimize things so no one player is consumed with a lot of extra work. I was hoping to have a my per level scene objects such as AI bots controlled by an actual player in that level. For example, At startup the master client is in level 1 with 9 other players. I have another 10 players in level 2. Each level has AI. I was hoping to have player 1 control the AI in level 1 and player 11 control the AI in level 2. Then if player 11 leaves the level to level 3, now player 12 takes over the AI for level 2. As player 11 is the first player to enter level 3 he'd take on any AI in level 3, etc..

    I don't think there's any way to do this shy of each level maybe being a room and instead of the player loading a new level they actually join/create a new room? Is this doable? I think it is when using Photon for an MMOPG? I'm not doing an MMO, but I do want to support 60-100 players and therefore need a lot of extra optimization and a way to limit how much I need to send over the network. It's unlikely I'll have more than 20-30 in any one level at a time.

    However if I do this then could I still send certain types of events between players in different rooms? For example ingame chat is a simple one, but also things like status updates such as your base is under attack get back quick, or game over, you won/lost, etc...

    What code, samples, docs can I look at that will point me in the right direction?


  • In my opinion, it would make sense to get you up to speed with Photon Server coding and hosting. It looks like you will have to work around several design decisions we made for the Cloud, making it more complex and fragile than useful. PUN, being a layer on top of out LoadBalancing API, add some convenience but also some bandwidth baggage and takes away some control.

    That said:
    Photon Unity Networking has scene objects and your clients can even instantiate those at runtime. The Master Client can control and add them.
    Alternatively you can send commands like RPCs to all clients modifying a bunch of Game Objects which don't have their own PhotonViews each (but are identified some other way).
    Keep in mind: If the master client leaves the room exactly when some AI action should be done, this won't happen. The new master must take over the complete state and calculate the same action as next, jumping in where the other left. More than one master might leave in about the same time.

    Chat across room borders is not yet possible. Messages never leave a room.

    The benefit of the MMO application (which we're not running in the Cloud) is that it doesn't have rooms. Instead, we just use channels and users can subscribe and submit to more than a single one. On the other hand, this can be dauntingly complex.

    I would propose you take a look at the plain LoadBalancing API of the Unity Client SDK and at the Server SDK. Your dream game will benefit from going the extra mile of doing a custom server.
  • Thanks again Tobias, you always have the answer :-). I started looking at some of the MMO docs last night. I'll start to look at the load balancing too. I was trying to push this next level of sophistication off to my next project which is my dream game, but I might have to bight the bullet on that early.
  • :)

    I guess it's best to start with the LoadBalancing app, Game Server and Rooms especially. Even if you jumped right into the MMO app, you would use Operations, Responses and Events too. Adding something to a Room is a good first step. Rooms use fibers / channels and messages, so they prepare you for using them yourself like MMO does.

    I'm not entirely sure if this is up to date with Photon 3.2 but it should help anyways:

    If anything is inexplicable, please ask. In best case, our server guys update the docs,
  • Scruffles wrote:
    The master client can create scene objects (PhotonNetwork.InstantiateSceneObject) - these persist if that master client drops. The new master client then becomes the owner of them.

    Today I use PhotonNetwork.AllocateViewID(); to get a viewID, then I manually instantiate the object which gives me more control such as adjusting the location which can be different for the object if a player joins the game late. Therefore, I want to know if there is a way to manually create a scene object this way instead of using InstantiateSceneObject? Other than viewID, what else do I need to set in the photonView object to make it into a sceneobject, or do I have to use InstantiateSceneObject?


  • Sorry, I didn't notice the question. For some reason it looked like a summary of what you're now doing successfully.

    The "trick" to make a scene object is not it's viewID but the actor ID used to send it's instantiation event. Internally, an instantiation (much like RPCs) is an "event" in Photon. The server is told to cache the event for players joining later on. More or less by default, events are cached for the player and deleted when it leaves but Photon also can store events for the room and keep them.
    This is hidden in NetworkingPeer.SendInstantiate(..., isGlobalObject). When isGlobalObject is true, the resulting event it put into the room's event cache instead of your user's cache.
    I now wanted to write that RPCs are also stored for the player who causes them but found that's not true. Currently, PUN will store any buffered RPC in the room's cache, which already makes your manual instantiation stay in cache even if the sending player leaves.

    I assume the objects you manually instantiate do observe a script with OnPhotonSerializeVie()? If so, you could use that to hide the object on instantiation until the first update is received and applied.
    In this case, it's a drawback that cached events won't get updated (with current positions, e.g.) so you should hide the instantiated object until a update is received.
  • Thanks Tobias,

    That's actually a quite simple approach, to use the packet update of photonview to toggle the object being visible, then I can use the buffered instantiatesceneobject normally, and I don't need to do anything funky other than toggle the renderer on and set the initial position based on the renderer not being on. It's simple and will meet all my needs, I like it. Thanks. Sometimes it's just good to have a sounding board.

    For what its worth, I did get all the other issues resolved where I now have just one large level and I'm moving the active part of the level to global 0,0,0 and everything else away. It's actually working really well. I'll definitely look more into the MMO code and some other techniques for handling larger environments, but probably as part of my next project. I think (still need to stress test) my current design will be "good-enough" for now. Thanks again for all the help.