Projectile online or offline?

Options
Hi all, this is my first project using PUN and it's my first post !

I feel excited using Photon, and no doubt it's a powerful tool, but I feel a bit confused due to a lack of information about the basic flows involved in different multiplayer game needs. However I know you can't always follow tracks and a good developer should be able to find his own way, that's what I'm trying to do ;P (don't hesitate to share good links with me ;P)

I would like your opinion about the logic you would use for having a slow projectile spawned from a player with a totally predictable trajectory (spawns from a known position with a known angle with a known force).
It seems to me there are 3 ways of accomplishing that:

- Instantiate the projectile with Photon.Instantiate and observe its transforms (like you would do for players moves in a fps).
- Instantiate the projectile with Photon.Instantiate and send RPC to all with shoot parameters (angle and force) and let each client update the projectile's state locally.
- Directly send RPC to all clients with shoot parameters and let each client instantiate (the unity way) update the projectile's state locally.

Comments

  • By reading this thread: viewtopic.php?f=17&t=5788
    I did try the first option (everything server-side) but since it also requires to smooth projectile's positions over time, to avoid jitter effect, I'm not having the exact same landing spot, I mean the projectile isn't touching objects at the exact same place. And that's a big issue for a game like mine…

    Should I rely on RPC calls ?
  • vadim
    Options
    Are other objects synchronized precisely enough to hit same place even if projectiles are perfectly synchronized?
    Is that 'big issue' is visual only? I guess you run hit logic only on one of clients, so other clients states updated even visually object hit in wrong place.
    Btw, what do you meant by 'everything server-side'?

    3rd option looks like most appropriate for objects with fully predictable trajectory. When spawning projectiles in RPC of other clients, use same PhotonNetwork.time for trajectory start as on shooting client. Or network delay may cause significant difference in trajectories.
  • Yes, it seems the Unity physics simulation is reliable and do not use randomness so 2 identical shots will bounce and land in the exact same spot.
    The issue would be visual only but player A will declare he has touched player B while player B will see a missed shot.
    Yes, it logic runs from the player who fires a projectile, in fact all players will receive the collision event but only one client will send a win message to others.

    By "server-side" I was thinking of instantiating projectiles with photon, observing projectiles transforms through photonview. The problem is it also involves predication to get smooth projectile moves when packets are lost or delayed (it would also involve high data traffic on photon network).

    Yes, I did use the 3rd option by sending RPC with AllViaServer mode. I was thinking this mode would force each client to get the same shooting parameters. Am I wrong?
    Your tip with PhotonNetwork.time sounds interesting but I don't get how to use it. Would it just be a reliable server time defined in the future for all client to shoot at the same time? If yes what's the difference with the AllViaServer RPC's mode?

    Thanks for your support!
  • vadim
    Options
    Yes, I did use the 3rd option by sending RPC with AllViaServer mode. I was thinking this mode would force each client to get the same shooting parameters. Am I wrong?
    Obviously, shooting parameters would be exactly the same no matter which RPC mode you chose. Receivers just get what sender sent. But at different times. That's why I advised you send shooting time as well and calculate trajectory on all clients with same formula and same parameters. I supposed that you have 'time passed form shooting' in your formula which should be (PhotonNetwork.time - t0) where t0 is PhotonNetwork.time on shooting client at shooting time.