Best way to handle high shoot speed

Ho, no need to refer directly to me I think there are quite a few active forum users now which have tangoed with networking and can offer insights to it.

That is the right idea I think. For example, there is no need to have 7 clients and 1 server run the same raycast (possibly with different results if everything is not 100% identical). If your client controls his own players movements, then just making the client do the raycast and all calculations himself is fine. The effect of the action (muzzle flare, particle effects where the hit lands etc) can be synchronized over the network. To prevent cheating, making the server verify calculations might be a good idea. Of course authoritative server is always the better cheat defence. Then the server does all the raycasts, etc and tells the clients what happened.

Rockets could be network instantiated in the usual manner. If you are brave, one party might be the authority on the rockets effect. All parties then individually instantiate the rocket, but the rocket itself is not network synchronized. The effect is only determined by the originator or the server.

If you have many rockets in the air, and are worried about new clients not seeing them, there are a number of ways to tackle that. One is a simple 3-4 second delay before the client becomes active. Then the network has a chance to get started and hopefully all temporary objects like rockets which fired before the client connected, are destroyed. I believe a small delay (a couple of seconds) is a good idea to have in the beginning anyway. Sometimes networked object behave erratically right at the beginning milliseconds as they are instantiated and receive up to date state. Another is a sort of rockets-in-the-air-state structure. This is sent by the server to the client when he connects and he's not allowed to become active before its processed. This structure would contain all active rockets so the client can re-create them. You probably don't need to maintain this structure continuously but just populate it when new clients arrive. The rockets are not RPC buffered, and thus you don't need to worry about constantly adding and removing from the buffer. I'm sure there are also other ways to deal with this.

 

Its to smooth out the playback. When something happens on the owner of an object, it is sent over the network and played back by the other parties. This playback is not smooth, packets might arrive with varying latency and jitter. To smooth out the playback they are all buffered and played back with 100 ms delay, so some packets are delayed more than others, depending on the variation in latency.

It makes some sense, but the ping value can vary, and it might not be a good idea to have differing playback delays on different clients. I think this value should be universal across all clients and all objects, but you might vary it if everybody has good connection speeds. So if no one has a ping below 40, then set the delay to 60 ms (50% higher than lowest ping).

The thing is that when packets arrive later than the buffer delay, then you get stuttering objects.

 

I think the typical way is a system in place which buffers the world state and can decide what is supposed to happen based on timestamps. The server could keep track of where everything is/was and when collisions are to occur, the server will verify the collision using matching timestamps of the objects. The client will see external objects with a 100 ms delay so he can't be trusted to make a 100% fair decision, but if he buffered the state he could do it (although he can't be trusted because of cheating).

Client side prediction can be used to predict where he external objects are supposed to be. Then you don't actually blindly deploy the 100 ms delayed updates, but predict where the object is supposed to be, based on previous movement. Then compare where he was 100 ms ago with the state update. Then make corrections if needed (if they don't match approximately). If the prediction works perfectly then everyone sees exactly the same thing.

If you don't use physics then it might be simpler to predict with 100% accuracy. You might have an algorithm for movement or something and you know exactly how it behaves, even a bit into the future (perfect determinism).

For simpler games you might not want to go through all this hazzle, this is quite complicated. Its mainly needed for fast games (like FPS's and racing games), where you want everything to be as perfect as possible. You can also accept that there is a delay (whatever value you choose), and all client don't see 100% the same thing.

I don't remember what I meant, and I couldn't find much of use by checking my links. Half-Life 2 by Valve used something similar to what I mentioned above if I recall correctly. More on that here.

 

Sorry for the late reply. For now, interpolation, prediction, etc are "roll your own" cases where you do this yourself manually in scripts. This might be unpractical/cumbersome to generalize as what you really need to do can vary game by game but maybe some common case can be found. So the answer is something along the lines of: probably not but if it feels right, maybe.

I don't think that would work so easily, it would be an unusual method. Basically you would want the entire game to move with an specific lower time scale so that updates (over the network or local) would be deployed with a delay higher than the latency? Wouldn't that look bad, feel unnatural? Guess it depends on what kind of game you are doing.