Multiplayer Hub: Developer Basics Part Two

11.15.21

Welcome to the Multiplayer Hub, where Improbable experts share their knowledge on multiplayer development, deployment and LiveOps.

This is Part 2 of a series that will help you get started creating your first multiplayer game, you can find links to the previous parts at the end of the article.

We’ll introduce common, essential concepts that every developer needs to know — and help you understand how they can affect your game. This part talks about network protocols and round-trip time (RTT).

Network protocols

When you develop your multiplayer game, we recommend that you use a low-latency, loss-tolerating network protocol such as UDP (user datagram protocol) or KCP .

These protocols are more favourable than a connection-oriented protocol such as TCP (transmission control protocol) which is prone to latency issues and packet loss, and can seriously impact the performance of your game.

Read more about UDP, KCP and TCP:

RTT is the amount of time between a player’s action and the reaction the player experiences in the game, and usually includes the following:

  • A player's keystroke and processing time on their gaming device (the action)
  • Network latency between game server (server) and game client (client)
  • Server computation of changes to the game world state
  • Client processing of the server's changes to the game world state
  • Client rendering of the changes on the player's device (the reaction).
Multiplayer Hub - Round Trip Time Diagram

You should consider that the following issues can impact RTT:

  • Packet loss and delay. A 100% stable connection for all players is unlikely. Packet loss and packet delay are common problems in fast-paced multiplayer games.

  • Input lag. In the round trip between client and server diagram shown above (Image 1), the RTT is 250ms. At this rate a player receives four updates a second from the server, which is inadequate for a fast-paced game. However, you can address these issues by using the following methods, which we’ll discuss in detail in the next post:

  • Create server and client buffering
  • Reduce input lag
  • Influence the player's perception of input lag
  • Compensate for input lag

More solutions. More possibilities.

Explore all IMS solutions