Multiplayer question regarding Bandwidth Profiles

0 favourites
  • 6 posts
From the Asset Store
The official Scirra Multiplayer Signalling Server for helping peers find and connect to each other
  • The multiplayer plugin has 2 bandwidth profiles - 30 Hz updates w/ an 80ms buffer for games played over the Internet, and 60 Hz updates with a 40ms buffer for games played over LAN. I have 3 questions:

    1. What is the buffer actually for? (The manual doesn't explain this)

    I learned recently from the developer of a multiplayer game that feels incredibly responsive (w/o any client input prediction), that his game only sends 20 updates per second (vs the MP plugins 30), with his server receiving and processing updates immediately (which happens every 50 ms).

    2. Does this mean that his game is essentially using a Bandwidth Profile of "20 Hz updates w/ a 50ms buffer"?

    3. If so, would this be recommended if it gives my game a better feel? I have chosen not to use client input prediction, due to the issues that come with it, but I still want my game to feel fairly responsive on the clients side. What would the implications be of decreasing the buffer from 80ms to 50ms, and reducing the updates from 30 to 20? I've tested the change and it feels okay, but on a larger data transfer scale, what does this mean?

    Thanks in advance!

  • I'm still wondering about question 1.

    Does anyone know what the Multiplayer Buffer is?

  • It is for interpolation for smoothing out jitter and/or packet loss.

    https://www.scirra.com/tutorials/892/mu ... pts/page-6

    Roughly speaking you can think of it as the engine having 80ms worth of artificial latency - all peers under 80ms will percieve the same level of responsiveness from the host, and the player/host ideally won't notice any network lag unless the actual ping (or time between updates) becomes greater than 80ms.

  • It is for interpolation for smoothing out jitter and/or packet loss.

    https://www.scirra.com/tutorials/892/mu ... pts/page-6

    Roughly speaking you can think of it as the engine having 80ms worth of artificial latency - all peers under 80ms will percieve the same level of responsiveness from the host, and the player/host ideally won't notice any network lag unless the actual ping (or time between updates) becomes greater than 80ms.

    oosyrag

    Thanks for the help! But question... I'm not using client input prediction for various reasons, if I don't want any artificial latency what's the harm in putting this buffer to 0ms? I've tested it with simulated latency and it seems a lot more responsive (the delay between key press and client side movement is reduced greatly).

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Honestly if you understand the implications and know what you are doing, there shouldn't be any harm. Although it is pretty standard and common among netcode implementations to have some sort of buffer, for the aforementioned smoothing out of latency issues for a more consistent experience for peers at low latency levels.

    It will seem more responsive under good conditions, but any intermittent packet loss or jitter will be more pronounced when it does occur.

  • Thanks for sharing your knowledge I plan on using an additional Player object for each Peer, and interpolating client side to the correct position. This should fix those jitter problems, while still making the game feel fairly responsive.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)