InstantiateSceneObject

Options
Hi All,

I'm a newbie so please bear with me, Im making a Dungeon Crawler which will be multiplayer so I am trying to use Photon to assist. I believe I need to create all my game blocks (walls/doors etc...) as SceneObjects as they are created at runtime.

This is fine and works for the masterclient the problem is I don't understand how the other clients should create the objects, they do get sent to the clients when they join but the state of the objects are wrong and its missing all the details of the objects i.e. if a player opens a door (via an RPC) even though they are buffered when the next player joins it does not show that the door was opened (seems a bit intermittent) I also have script attached to the objects like a door which gives it all its properties isLocked which do not seem to get set/populated on the client.

Basically how should non master clients create/handle sceneobjects created by the master?

Comments

  • Tobias
    Options
    You can apply PhotonViews in the scene when you create the level. You don't HAVE to instantiate everything at runtime. Just saying.

    To save the state of a GameObject, you should use a Custom Room Property. Those are a Hashtable of key-values and you can have a key per door plus the (bool) value if it's open. Any player can modify this. The last one to call room.SetCustomProperties() with a door's state will set it.

    Of course, you need a script to react to custom property changes. There is a callback you can implement:
    void OnPhotonCustomRoomPropertiesChanged(Hashtable propertiesThatChanged)

    Check the changed keys and apply updated values.
    All values are available to joining players via room.customProperties.
  • Thanks Tobias,

    I think I am miss understanding how I should be creating object. Like I said before I'm creating a dungeon crawler which is multiplayer so every object in my dungeon has to update over the network because switch can disable/enable walls or doors can be open/closed etc...

    I read the level data from a file which is converted to Hex and then a GameObject all at runtime so I have prefabs which have a PhotonView attached to them so they can serialize their data over the network should they need to be updated.

    I've now hit the problem that it seems I have too many scene objects yet i'm only just getting started I've not even added NPCs or Items which will also need to be scene objects.

    'Exception: AllocateViewID() failed. Room (user 0) is out of 'scene' viewIDs. It seems all available are in use.'

    *EDIT*

    I've now found I can increase the limit but Im sure I must be doing this wrong to hit the standard limit :)
  • Tobias
    Options
    PhotonViews are not effective for thousands of GameObjects and if you run out of IDs, you are likely to have too many such IDs.
    Each Instantiate is a message which you send to all players. This is totally overkill if the clients have the hex file to re-create the exact same level anyways!

    In in tile based game you can easily skip the PhotonViews for anything that's not moving anyways. The tile is the ID. If it's a door, it has a default state. When this state changes, set a property {"xy" = (bool)true}. x and y are the coordinates. Together they should be unique. This way, you don't have to replicate the level via network Instantiate AND you only store props for things that changed from default. This is leaner.
  • Thanks tobias

    So I've changed everything back to being local and have a rpc call on a leveldata manager which finds and updates the gameobject locally with a action, this works fine while both players are in the room but even with buffered messages they don't seem to sync up correctly for a newly joined player so I want to look at the room properties like you advised, is there any good examples of people using this?
  • Tobias
    Options
    Sadly, there is no great demo for that yet. I wanted to write one these days as I have to explain it anyways. The thing is, I spent the day with Windows 8 exports in various versions of Unity, etc.

    I will try tomorrow. Otherwise. the Round Timer script is using one room prop and the Pickup Demo uses properties, too.