Search Unity

Networking concepts (Source, Quake) questions

Discussion in 'Multiplayer' started by OatmealOgre, Oct 3, 2019.

  1. OatmealOgre

    OatmealOgre

    Joined:
    Oct 3, 2019
    Posts:
    1
    Hi,

    I've been reading into some concepts about networking and some questions arose.
    Specifically I've been reading the following articles:
    https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
    https://fabiensanglard.net/quake3/network.php

    1. First and foremost are there source code examples implementing these solutions?

    2. How do you implement a tick rate in Unity and how do you send data at a different rate than the tick rate?

    3. What is a reasonable number of data messages to send per second?

    4. When calculating how long ago something happened on the server or the client should you use half the round-trip time (aka ping) or is there a way to calculate the one-way delay?
     
  2. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    I'm not aware of an existing network solution which implements this snapshots at a set tick rate approach. Though you could build that on top of most any low level networking API I would think.

    1) No idea

    2) Unity isn't well set up for that, because Unity separates the main game loop from the physics update loop. Even setting them both to the same rate doesn't guarantee they will be called at the same rate. Unity is designed to sacrifice calls to Update in favor of almost anything else which needs to run (physics, garbage collection, etc).

    3) The number of messages you can send per second depends on the size of the messages. But the actual sending of the messages is probably less resource intensive than the processing involved in creating the message, or the processing involved in acting on a received message.

    4) I wouldn't worry much about how long ago something occurred on the server, and instead establish a baseline of what the server reports its clock as in a received message. Compare the received server clock to your own clock and calculate an offset. Then whenever you receive a message you calculate its offset, and compare the new offset to your baseline offset to tell how far off in time from the baseline the received packet is.
     
    MrsPiggy likes this.