Code example from documentation?

Options
The documentation states "It is extremely inefficient to assign a PhotonView and ID for every bullet that your weapon fires, instead keep track of your fire bullets via the player or weapon’s PhotonView"

Is there a code example of this in any of the tutorials/examples? I'm curious as to how to handle this situation as it describes- thanks.

Comments

  • Shibli
    Options
    I'd like to see one too
  • Another example where I think some code would be useful is from the Photon performance tips on this site- they say to "Call service regularly" with this quote " Make sure that service is called despite loading or the connection might suffer and be closed"

    It says to make calls to LoadBalancingPeer.Service- So do we call that in Update() from the players? or?

    Is there a code example somewhere of how to do this as it sounds important-

    Performance tips link https://doc.photonengine.com/en-us/realtime/current/reference/performance-tips
  • Hi @mdotstrange,

    please note that 'Realtime' and 'PUN' are two different products. If you are using PUN you don't have to worry about calling Service() because this is automatically done. If you are using Realtime however you have to call Service() on your own. A good interval therefore is 10 to 20 times per second. If you don't call Service() when using the Realtime SDK, no network progress is made. This is described here.

    Hi @Shibli, too.

    About the original question: there is no code example. I'm honestly not sure what is meant at all. The only thing I can imagine is, that having a lot of PhotonViews in the scene might cause also a lot of network messages and traffic, which you want to avoid. Especially for the bullet example instantiating an object for each fired shot might also end up in bad performance because instantiating objects is very expensive. So the other thing I can think of is, that you should use Object Pooling for those kinds of objects and use RPCs or events to fire a bullet from an object pool. This would also avoid assigning a PhotonView component and a certain ID.

    Hope that helps.
  • Thank you for the reply and for the information- I'm glad I don't have to worry about that Service() stuff :)

    Regarding the first question- I see, So if we are already pooling our projectiles we use an RPC like "ProjectileFired" and then another on "ProjectileHit" - something like that instead of adding a view to it? Thank you.

  • So if we are already pooling our projectiles we use an RPC like "ProjectileFired" and then another on "ProjectileHit" - something like that instead of adding a view to it?


    I can't give a definite answer to this because this is based on how you want to handle it but this basically works. Since you want to use pooling you also want to have 'physical' projectiles, don't you? Another option here is to simply use Raycasting whenever a client fires his weapon which wouldn't require object pooling at all.

    A simple example for better understanding: whenever a client fires his weapons you can use a RPC to notify each other client about the shot. The local client uses the RPC to share some additional information as well for example an unique ID for the projectile he fired so that everybody can identify the object later when it's put back into the pool. You can get the ID by using PhotonNetwork.AllocateViewID(); for example. If so please make sure to use PhotonNetwork.UnAllocateViewID(int id); on the local client when you put the object back into the pool to free the used ID. This RPC can also contain further information about the position and the direction the shot was fired if this is necessary.

    You now have to decide who controls the Physics Simulation and have multiple options. One would be that the MasterClient checks the collision detection of all projectiles. Another would be that the owner of each projectile do this. Whoever detects a collision can use a separate RPC to inform the other clients so that each client can put the object back into the pool and the 'owner' can un-allocate the ID. You maybe need a third RPC or a separate event to notify the client you probably got hit.

    Hope you get the idea and this helps somehow. If you have further questions please feel free to ask.
  • Thank you for the informative reply- it seems I have a bit more thinking to do about my setup- thank you.