Third Party [SOLVED] Photon & synchronizing projectiles: Which method is best?

I'm making a game with slow moving projectiles--around 40 will be on screen at once and according to Photon, it's not a good idea to create too many photonViews.

I have 2 ideas to sync projectiles:

1) Call an RPC on each client to create a projectile and move it somewhere. This is good because it's efficient but lag could make the projectile a bit delayed on the client (not sure how big a deal it is).
Maybe this could be improved by adding a "timestamp" to the RPC and then calculate by what time the projectile should arrive at its destination, so depending on how much it lags, the projectile could move faster.

2) Add the projectile to the photonView of the player that created the projectile and stream their position. This seems like it might be more accurate but less efficient.

Thoughts?

 

Number 1.

You need to handle bullets locally. A thing you can do is to send photon network time with the RPC and then fix what needs to be fixed locally based on when it was the message was sent.

 

BFGame's solution would work but there is an alternative one that can prevent hacking. First, you need an authoritative server. Several networking solutions allow for this such as uLink, Bolt, and my personal favorite, Forge. Instead of detecting bullet collisions on clients, you detect it on the server. This can be done similarly to how BFGames suggested, with an RPC.

You call an RPC to the server which alerts the server to shoot a bullet from your player's gun. Be sure to include important information like who's shooting in the RPC parameters. On the server, the bullet gets simulated and if it hits someone, change their health based on the bullet's damage. Then on the next sync the server hands out, put in the little detail that someone got hit by sending everyone the new health of that player. On the client side, fire a 'dumb' bullet that does nothing except make cool effects.

This is the system many top FPS games use such as Halo and Call of Duty. There are games like Begone that use client side bullet simulation but they can be easily hacked.

 

@jpthek9 I was just reading into Bolt, Forge, and uLink but from what I understand, I'd need to host my own servers, right? I'd have to rent servers and then use Bolt / Forge / uLink for the logic, right?

 

<

This is very correct. Even with Photon Cloud you should only use dummy bullets on all clients expect the master client to prevent as much hacking as possible and not getting multiple hit messages.

 

Most definitely. As far as I know, Photon is the only networking solution that provides a cloud server but Forge has plans to do that as well.

The right choice for you really depends on what you want from your game. I'm pretty sure a game like Begone can be made with Photon Cloud but it's really the epitome of what can be done.

If you want more information on a variety of networking solutions, I go into them a bit here: http://forum.unity3d.com/threads/mu...rkrift-forge-and-playfab.294852/#post-1944975.

@BFGames The master client technique works really well too but it'd be inefficient to use a server as there's already an authority every packet has to go through. For something like that, you can use Unity's standard library which will generate much less lag (and be cheaper).

 

Yes that is the case.

 

This is a game i am working on where we use Photon Cloud. The video is a year old and was before we had any kind of lag compensation.

But you can see we have a LOT of bullets using the local bullets approach. We upgraded the system now, but should give a good insight to how many bullets you can handle if you use them locally. Some of the bullets like the bouncing one is however not possible with our new system as they are hard to sync without a few updates.

 

For updating health and such a few miliseconds is not really a problem. You will still shot bullets as soon as you get the RPC call. You will not wait for the masterservers response.

 

That game looks cool. How did you handle collisions btw?

 

This game is not authoritative, hence we can use Unitys physics. For bullet's raycasts.
Players there are not yours are not having an active rigidbody and are just moved around based on messages sent.

 

I am having an issue with this approach. Although this seems correct on paper (so that clients can instantly see something happening as a response to their input - in this case pushing the fire button) and it works great with client-side prediction and an authoritative serve (I am using Bolt btw) I have the following issue:

-At the moment, I am sending an RPC (called events in Bolt, same principle) to the server and the server creates the projectile. When the server replicates the projectile to all clients, they see it but this means that there is a significant delay from when the player pushes the fire button until they see the projectile. On the plus side since it's the server who creates and owns the projectile, collision detections are happening on the server and results are pushed to the clients (damage RPCs, explosion creations etc.)
-If I am to create some kind of client prediction based on user input (e.g. fire button push), I will need to create a local projectile that is not replicated through the network, but is shown only to the local client (the rest of the clients will see the one the server creates). But here there is a problem. What do I do when the client local projectile hits an enemy? Do I destroy it and show an explosion? What if the server created projectile actually missed the same enemy (it can happen quite easily). Also, on the other hand, if the server projectile actually hits the enemy but the local misses them the local player will see their projectile missing the enemy but the enemy will be destroyed and there will be a (server created) explosion. The only plus side of this is that the projectiles will spawn immediately following user input.

tl:dr:
Server created projectiles may have a big delay appearing to the local user who shoots.
Client created "fake" projectiles (on local player who pushed the fire button) may disagree with authoritative server's collisions and end up showing something different than what is actually happening.

So what is the solution to this? I would love to hear you ideas.

 

I am having the same issue, I sent you a private message!

 

I am also having this same issue, but not with a server auth approach... basically, player 1 moves (x,z) and rotates (y), and can click 'fire'. I am using _photonView.RPC("OnFireWeaponRPC", PhotonTargets.All); This has the local client shooting the weapon right away, then has the clients shooting them when they get the RPC.

The issue is that locally, the shooter sees the bullet hitting his target, while the target has moved on his machine locally, and the bullet misses. So the shooter sees a hit, the target sees a miss.

I do not have a photon view on the projectile, should I? The projectile script essentially says, put a projectile at the players position/rotation (offset by gun muzzle) and shoot forward.

Please help!

 

You could try to use PhotonTargets.AllViaServer. This keeps the local client from executing the RPC earlier, as the messages gets sent back from the server. This will add local lag, which is also not desirable but you have to make do with some form of lag and hide the (wrong) results as good as you can.