Search Unity

  1. We are migrating the Unity Forums to Unity Discussions. On July 12, the Unity Forums will become read-only. On July 15, Unity Discussions will become read-only until July 18, when the new design and the migrated forum contents will go live. Read our full announcement for more information and let us know if you have any questions.

Best way to handle high shoot speed

Discussion in 'Multiplayer' started by llavigne, Feb 9, 2008.

  1. llavigne

    llavigne

    Joined:
    Dec 27, 2007
    Posts:
    977
    What is the best way to manage network game with lots of raycast bullets and lots of rockets fired by all players?

    I am thinking all collision should be done locally without any RPC, even if a bullet doesn't belong to the client and that only change-of-state which affect players (and NPC) are synchronized via RPC.
     
  2. KlaRo115

    KlaRo115

    Joined:
    Feb 24, 2006
    Posts:
    675
  3. JohnGalt

    JohnGalt

    Joined:
    Nov 27, 2007
    Posts:
    85
    Gaston, how do you destroy your rockets so that new players don't ever see them?
     
  4. larus

    larus

    Unity Technologies

    Joined:
    Oct 12, 2007
    Posts:
    281
    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.
     
  5. llavigne

    llavigne

    Joined:
    Dec 27, 2007
    Posts:
    977
    Thanks!

    I was sifting through your c# class which handles rigids sync, can you explain why the 100ms delay ?
    I have trouble wrapping my head around this past and present conundrum.

    Also would it make sense to have a dynamic delay which depends on the ping to clients?

    [I rewrote history and edited your name out]
     
  6. larus

    larus

    Unity Technologies

    Joined:
    Oct 12, 2007
    Posts:
    281
    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.
     
  7. llavigne

    llavigne

    Joined:
    Dec 27, 2007
    Posts:
    977
    I see, it's like blurring temporal noise.

    This delay has an obvious cascading effect on player physics colliding with each other. The players cars colliding comes to mind (re: Unite). How is it typically handled?

    You mentioned papers on this, do you have any links ?
     
  8. larus

    larus

    Unity Technologies

    Joined:
    Oct 12, 2007
    Posts:
    281
    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.
     
  9. llavigne

    llavigne

    Joined:
    Dec 27, 2007
    Posts:
    977
    This is very useful, thanks.

    I know Unity networking does compression and from what I understand of the networked rigidbody c# class you do some interpolation via scripting, will you make this along with lag compensation and prediction accessible through the API?
     
  10. spawrks

    spawrks

    Joined:
    Nov 16, 2007
    Posts:
    89
    also...

    instead of the 100ms buffer, couldn't you just alter the time speed? more lag = slower , but then nothing is out of sync?
     
  11. larus

    larus

    Unity Technologies

    Joined:
    Oct 12, 2007
    Posts:
    281
    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.
     
  12. thylaxene

    thylaxene

    Joined:
    Oct 10, 2005
    Posts:
    716
    That's what I basically did with TurretWars MP.

    At the moment it seems to work fine and I haven't noticed any serious delays or cheating... well not enough for me to start worrying about prediction at least or handing it all over to the server. But with that said, turretwars isn't HL2! :wink:

    Cheers.