How to Sync Hundreds of Bullets over network

Hey Guys!
I am currently working on a multiplayer dogfight game, and I have the single player aspect down packed. Converting my game to multiplayer has been a hassle. I just synced player transform today, but bullets and other weaponry proves to be a hassle to start.

I am wondering if I should attach a photonView to each instantiate, but I know thats overhead overkill. I was also thinking about running calculations player side, like ( the player next to me is "shooting" so let me create local bullets with a certain vector3, and translate them ).

Are there any other ideas that can reduce the impact of these bullets? Please, I am stuck.

 

Do your hit calculations client-side only. If the client registers a hit, then send that to the server, and let the server resolve how much damage was done etc.

The server should then notify he player being shot at that they were hit.

You may also want to simulate some random bullet fire on the person being shot at's client. So the player will hear bullets whizzing past etc. But in this case you only need to send this signal once every burst of bullets, or every 10 bullets, as its purely for aesthetical purposes, and lets the player know they are being shot at.

To handle these whizzing bullets, just place a large collider around the plane, so any bullets that hit this collider, send the notification to the other player that they are being shot at.

You can use a more accurate box/compound or mesh collider for the actual plane hits when they receive damage.

 

If you trust your clients, you can send a message to all clients to instantiate the bullets locally.

You can let the clients to do the hit and calculations themselves and ask server to sync the hits, or you could have only the server will calculate hits and damage registration if you want more authority.

 

The tradeoff with that approach is threefold...

a.) If the client knows the target was in their sights, and they definately made a hit, if you let the server determine the hit, it might return that the client was not in their sights, and thus the user will feel short changed.

b.) Feedback from a hit, i.e opponent showing a hit animation or other feedback will only show once the server has confirmed a hit, giving noticable lag which is not very suitable in terms of user experience.

c.) Simulating loads of bullets/hit detections on the server can be a huge strain on the server resources.

 

Its up to him, if he trusts the clients or not.

 

You can never trust the client.

 

lmao! I followed your approach, spawning the bullets locally, and syncing the hits with the player being shot at. There is a shooting bool in the script that is synced over the server, to show that the player is shot at. You guys are the best!

 

You can never trust the client.

Wise AF.

 

Agreed with the above statements about not trusting the client. If anything, you can make a SyncVar Vector3 that contains where the player is aiming...and then Raycast on the server and handle all logic there. The client updates the server with the direction (Vector3) they're aiming. When they press "Shoot" the server casts a Ray in the direction they were aiming (that Vector3 that was mentioned). If it hits something, the server calculates damage and propagates it to clients. Everything is safe and handled server-side...except the player input...a.k.a. aiming.

@Meltdown
A. Do you feel shortchanged in FPS when you know you got a head-shot, but the enemy doesn't go down instantly? Sure...but does it break the game for you? Nope. Also consider the reverse. What if the other target KNEW they weren't in someone else's sights, but they took damage. Would they feel cheated? Yup.

B. Lag is expected by most players in multiplayer games. You further exaggerate the lag by creating windows for cheaters like your suggesting. Also, the "lag" between being shot and being hit is minimal, if not virtually non-existent when it comes to small-scale (4-32 players) shooters.

C. Don't simulate hits (collisions). Bullets should be handled via Ray casting...and just create visual effects for the bullets. One should rarely...if EVER...instantiate ACTUAL bullets. The only time this is common is with slow moving objects like rockets.

 

Agreed +1,

1.) You shouldn't be instantiating objects for the bullets - they should just be a raycast math with a target intersect.
2.) You shouldn't trust the client for any reason. Don't do hit calcs on the client.

If there are physics calculated on hit, like push or apply force, do that on the server and send just the resulting transforms back to the client so that you don't have to worry about it being deterministic across server / clients

 

here is the whole multiplayer implemented you should try this one
https://www.assetstore.unity3d.com/#!/content/81698