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

Networking with Lerping positions

Discussion in 'Multiplayer' started by jackywaiholeung, Oct 16, 2020.

  1. jackywaiholeung

    jackywaiholeung

    Joined:
    Oct 16, 2020
    Posts:
    4
    Hiya,

    I've been learning Unity and websocket programming myself in my spare time so I'm quite new to all of this.

    I've been writing LAN multiplayer game which is authoritative based using a custom UDP messaging framework; I've a few issues which I'm not sure what is the correct approach to take. With authoritative games both the client and the server runs the same logic to process inputs from the clients and they derive the character's position.

    After some much needed unit testing I found out that the way I lerp the character's position causes the simulation on the client and server have different end positions due to calculating the new position based on the character's current position rather than the end position of the lerp. So depending on when the server receives the next input the position of that client's character would appear to overshoot on the server side.

    Now if on the client side I ignore the inputs until the character reaches its target lerp position then the input controls will feel less responsive and movement may look less smooth like when the character turns around.

    Any ideas on how I can address this?
     
  2. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    If you're having the client and server independently determine the position of the player, I wouldn't call that an authoritative approach. Authoritative would be the client sends the server the inputs, the server calculates the movement, then the server syncs the client the new position which the client then interpolates movement to based on its previous known position. Unfortunately that will produce significant felt input lag for the player, which is fine for some games but unacceptable for others.

    If unacceptable, what you probably will want is what is called client side prediction. This is where the client moves the player immediately with the inputs, anticipating where the server will place the player, and will reconcile with the updated positioning from the server if the client's predicted position is off (possibly by more than some threshold value). Its one of the more complicated position syncing topics, there's been several good threads on it with comments from people more knowledgeable than I on how to do this specific technique correctly.
     
  3. jackywaiholeung

    jackywaiholeung

    Joined:
    Oct 16, 2020
    Posts:
    4
    Yea I mean client prediction, but my calculated positions are different due to when inputs are processed. I'm kinda looking at this part of authoritative gaming first.

    Any links to these topics? Or recommend any particular topics to read?
     
  4. jackywaiholeung

    jackywaiholeung

    Joined:
    Oct 16, 2020
    Posts:
    4
    I haven't got this implemented yet but from what I have read this is something I could aim for:
    • Make the movement deterministic; so server and client can derive the same position using the same inputs.
      • Use fixed update to support the deterministic design pattern.
      • Keep the movement's distance relatively small, so it animates within the server tick rate (e.g.: 10 ticks per sec, so move a 10th of 1 metre); this creates a balance of:
        • Having more responsive controls.
        • We don't need to process every input from the client on a frame by frame basis, we only process a new input after the character completes its movement; so this reduces the likelihood of breaking the deterministic pattern and reduce the amount of processing.
     
    Last edited: Oct 26, 2020
  5. qbvbsite

    qbvbsite

    Joined:
    Feb 19, 2013
    Posts:
    83
    Hey,
    I just when through this exercise and the above post about client-side prediction is correct.

    Here are a few short articles I should helpful:
    https://www.gabrielgambetta.com/client-side-prediction-server-reconciliation.html
    https://developer.valvesoftware.com...rver_In-game_Protocol_Design_and_Optimization
    https://gafferongames.com/post/deterministic_lockstep/

    Here is a code example of it along with its thread on unity:
    https://github.com/GenaSG/UnityUnetMovement/blob/master/Scripts/NetworkMovement.cs
    https://forum.unity.com/threads/une...nt-side-prediction-and-reconciliation.349929/

    I few points that really helped me specifically with smooth client-side prediction :
    • Update position in FixedUpdate using MovePosition (or equivalent) and not transform.position. This makes sure colliders work correctly, inputs are processed over a fixed time period (key for server movements), and gives a smooth experience (assuming everything is in sync, aka camera, prediction, reconciliation)
    • Don't use Lerp for player movement (At Least For 2D), personally, I found it helped only when there was another underlying issue and once that issue was fixed the Lerp looked worst than just using MovePosition(position).
    • For Client-Side Prediction make sure that the server processes inputs in the exactly same way to make replay easier and position drift to a minimum. My 2D game movement was pretty easy as it's not a 3D simulation and the huge win for me was not using Time.delta when moving the player on the server. I instead used a determined value (since inputs only run on a fixed update I knew the exact amount of time between inputs). Once this was implemented my client-side / server positions were near perfect
    Hope that helps and I'm happy to answer any questions
     
    Last edited: Oct 29, 2020