Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Thoughts on dealing with latency in a tennis multiplayer game...

Discussion in 'Multiplayer' started by LK84, Jan 18, 2017.

  1. LK84

    LK84

    Joined:
    Aug 10, 2015
    Posts:
    9
    Hi there, actually I'm not working on a tennis game, but my issues are pretty similar, so using the tennis example is easier for me to explain to you.
    What is bothering me most is how to deal with latency. I haven't coded anything yet concerning latency. I first intend to deal with the issues on a theoratival basis and hopefully get some advice from people with more experience in this field.
    I've tried to summarize my thought process in the picture I've provided (made in Paint within a few minutes :eek:). The numbering is arbitrary and only shows the order in the time series (I know there are wa more time steps/frame in between).
    Here the host serves( =in a tennis sense ;)) and due to latency the ball on the clients side will always be a little bit behind the ball on the host side (compare red/black to yellow on the top). I think I could tackle that problem by lerping towards the position of the ball of the host. But I can't use the position value directly from the server since there would be still the latency issue. So I need to lerp the ball position on the client against some predicted position (calculated on the client too) based on the impulse from the collision with the racket (which is provided from the server). Is this even possible to get "future" physic results? I hope it is comprehensible what I'm trying to explain.
    Why I need this lerping (at least I think I need it) can be seen by looking at the red and black ball in position 6. This is now the tennis ball seen on the host side. Since there is latency when receiving input from the client hitting the ball I think I can't prevent the ball going through the racket a little bit (red). But if the ball arrives at the same time on the client side as on the host side it won't be at least smaller compared to no lerping at all (black) since the ball would arrive later on the racket on the client side hence leading to a later reaction by the client player.
    I'm also confused on how I should deal with the ball (make it a scene object (switch authorities), calulate racket impact locally or on server). Right now I feel all this is a little bit over my head!. Hope someone has some ideas. If I need to explain better let me know:) tennisMultiplayer.jpg
     
  2. Zullar

    Zullar

    Joined:
    May 21, 2013
    Posts:
    651
    That's tricky. I'm not sure the best way but I have some ideas.

    When network syncing the ball I would definitely send position & velocity information and then locally perform physics in-between network updates.

    If (somehow) you locally calculated the racket hit which reverses the ball's velocity then it would never go past the racket.

    You could try timestamps. Since a game like this will be deterministic (i.e. if you know the balls position and velocity and spin then you'll know it's future position forever since you can locally perform physics on each client) you could try time stamping events. This should allow both server & client to see the exact same thing.
    i.e.
    -10.0sec: client begins swing (sends network message to server showing swing has begun) begins performing animation locally
    -10.0sec + latency: server receives message /w timestamp. server knows action actually began at 10.0sec and adjusts the racket position accordingly (i.e. skips forward animation by 0.2sec. may glitch if you aren't careful).
    -10.5sec: client & server both see racket impact ball at the exact same time (ball does not go through the racket). locally on each client the impact physics are performed and the balls trajectory adjusted.
    -10.5sec: server sends a ball trajectory correction w/ timestamp.
    -10.5sec+latency: client receives trajectory correction (*should* have no effect...). Client goes back in time and places ball back at old position at 10.5sec, then performs physics to catch the ball up to the current time at 10.5sec+latency (all within 1 frame). This also means you'll have to write your own physics because I'm not sure if this is supported..
     
    Khena_B and LK84 like this.
  3. LK84

    LK84

    Joined:
    Aug 10, 2015
    Posts:
    9
    Thank you very much for your feedback and ideas. Gonna need to digest it first. But using timestamps is definitely a good idea. The only problem I see so far is that the racket is controlled by the user through swipe Input: As faster as the user swipes over the touch screen, the harder the ball gets hit (and even a miss is possible).
     
  4. imgodot

    imgodot

    Joined:
    Nov 29, 2013
    Posts:
    212
    I'm not sure if Photon TrueSync might be applicable, or desirable, to you.
    I've only played around with it for a few minutes, but it seems interesting.
    It has its own deterministic physics and works as a lockstep framework.
    Both of those features might simplify some of what you're trying to do.
     
    LK84 likes this.
  5. LK84

    LK84

    Joined:
    Aug 10, 2015
    Posts:
    9
    Thanks, Photon TrueSync definitely sounds promising. I'll give it a try
     
  6. LK84

    LK84

    Joined:
    Aug 10, 2015
    Posts:
    9
    If anyone cares: I ended up using Photon TrueSync and it is really perfect for that kind of problem. Especially when you are changing your singleplayer game into a multiplayer game it's way faster. I might make a tutorial for future references
     
  7. imgodot

    imgodot

    Joined:
    Nov 29, 2013
    Posts:
    212
    LK84,
    Please do make a tutorial.
    With the product being so new, it would be very helpful I'm sure.
    -- Paul
     
  8. onrdrop

    onrdrop

    Joined:
    Jan 20, 2016
    Posts:
    1
    My Kingdom for a tutorial :)