Newbye Question - Mechanical machine setup


Hello, I'm just discovering PUN, and I have to admit that I have some difficulties to understand how it work.

I've watched some tutorials (and for sure the official one) but them did not helped me.

In practice, I have an electric trolley that should be managed by multiple users.

This trolley is composed by several parts: the body (root), and some movable child gameobjects: levers, buttons, and the wheels, that move/rotate with some scripts components attached on the root.

This trolley should be engaged by the 1st one that press the spacebar on the keyboard, and released after a few seconds.

I would'nt have any issues to manage it with a single user, but I'm confused how to do that for multiple users.

I've obviosly added a "Photon View" and "Photon Transform View" components to the root of the trolley, to send it's position/rotation to other clients, but:

1) does any movable child gameobject should have its own "Photon View" and "Photon Transform View" components? When I push a button on the trolley, for example, and the button move in another position (because I've pressed it), do I have to say to all other clients that this button is moving?

2) TransferOwnership().... This is a lot confusing to me. I understand that someone should send to the others client the position/rotation of the gameobject, but wich one? All of them at the same time? So, should I call TransferOwnership() from the root to the lowest child each time some user engage the trolley?

Many thanks for your help!


  • Tobias

    You should be OK with one PhotonView which observes all components that belong to the trolley.

    One client is on control and can actually move/affect the trolley, while everyone else gets updates from this client and just applies those (maybe smoothing out from update to update).

    You could transfer ownership (actually "control") to any of the users. It only makes sense when someone is using the trolley for a longer time. The benefit is that this client can just place the trolley any way needed (immediately) and the others get an update about that (with a delay).

    I would actually use Fusion for this by now. In Host Mode (with a server), one instance of Unity is authoritative of the state of everything. All clients just receive this state (and are seeing about the same).

    Unless the pressing of a button is a core event in your app, don't send a button's analog position (press state). It's enough to send the state that a button is now pressed. Any client which didn't show the button pressed yet, can either show it pressed now, or even play an animation that it is being pressed...

  • Many thanks Tobias!

    I'd really like to use Fusion, but I think that 1st I should try to learn PUN, before to move to the next step :)

    Actually I'm using PhotonView + PhotonTransformView just to send the position/rotation of the trolley, and I'm sincronizing every other occasional event like small movements, or color change, on nested GameObjects (the button that is pressed, the led that light up, etc) through RPC calls

    It seem to me that in this way I can just transfer the ownership for the position/rotation of the trolley, and all the others RPC calls don't need to take the ownership to work (and there's less Internet traffic too).

    Do you agree?

    P.S. I'm experiencing a quite weird problem, for my application that randomly get stuck

    Do you think that a good Internet connection is necessary, ormaybe my issue come from another side (not Photon) ?

  • Tobias

    I don't think PUN should be a first step. Using RPCs a lot is actually discouraged in Fusion, for example. Their timing can't be guaranteed and most of the synchronization you need, can be achieved with networked state instead. Once you get the hang of that, it's actually simpler.

    The shared mode in Fusion is also a simple initial step. You don't have to sync input. Players just move whatever they control and Fusion syncs it...

    For your case and PUN, yes, you could use RPCs but I think if you effectively serialize the state of the complete game object, you don't have to send costly RPCs instead. Include the data in a custom OnPhotonSerializeView method or use properties (if they change really rarely).

    See Synchronization and State for some more thoughts on this.