I’m thinking about making a machine gun in a non-authoritative networked multiplayer game with the built-in networking, with a simple implementation where when the client fires he instantiates a bullet locally, then sends an RPC to the other clients to locally instantiate a dummy bullet with the same heading (in other words, I’m not going to use Network.Instantiate). Only the firing client’s bullet will calculate damage.
What would the ramifications be if I created a setup like this, and the machine gun had a fire rate of say, 20 per second (20 RPC’s to locally instantiate an object per second)?
I’ve actually implemented both an RPC and non-rpc shooting method for a game which can have up to 20 shots per second for guns. Although RPC’s sound like a good idea since you are guaranteed to get the exact result in order on client machines, if any of your clients have any type of packet loss you can start to experience really strange delays and other problems with the RPC calls. I originally had all of my input for my current game being sent 10 times a second to the server via RPC’s however if I injected even a 1% packet loss into the network, a gradual build of buffered RPC’s happened thus delaying the call of newer RPC’s further and further.
My solution is simply to have each client send their local players data to either the server or all other players and have each client control the bullets locally from this data. This data would be something like: position, aimDirection, velocity, isFiring, etc… Although the position, rotation and number of shots of the firing is not precise in this setup, you will never have an issue with RPC’s building up over time. As you said in your post, only the client is calculating damage so you could easily send damage RPC’s only when another player is hit by a bullet which is significantly less often than when each client fires a bullet.
Ahh I see. So when you say “gradual build up of buffered RPCs”, were you buffering the RPC’s that instantiated local bullets for everyone? Or by buffer do you literally mean like a backed-up queue of RPC’s waiting to be delivered?
And could you solve this by putting all the bullet-spawning RPC’s in their own group, and periodically calling RemoveRPCsInGroup() on the server?
The problem is that all RPC’s are guaranteed to be delivered in order even with packet loss, so if a client does experience some packet loss, RPC packets will have to wait until previous ones have gone through in order for themselves to get through, which could cause some build up if the client has high packet loss rate and you are consistently sending 20 RPC’s per second. RPC in general should really only be used events or messages which only happen periodically, not for state synchronization.
My question to you would be, why do you need to set firing bullets as an RPC and not just synchronize the state of the character in game firing these bullets and just have a bool value which says if he is currently firing or not.
Probably because I’m lazy and like doing everything with RPC’s 
I’m trying to think how I would handle a semi-automatic gun with OnSerializeNetworkView and an isFiring boolean, but a semi-automatic weapon with a fire rate of 5 per second or so, I could probably get away with using RPC’s with, the only one I really need to worry about is the full auto probably, no?
I’m new to unity programing, But couldn’t you send a RPC with a Start/Stop value attached for automatic weapons, So you send a RPC when you start shooting and one when you stop, Wouldn’t the reduce the RPC’s sent per second? I don’t know what the effect’s of a lag in this case would be, But just an idea.
yes, you can do that. it’s what I do.