14 min read

(For more resources related to this topic, see here.)

Multiplayer is everywhere. It’s a staple of AAA games and small-budget indie offerings alike. Multiplayer games tap into our most basic human desires. Whether it be teaming up with strangers to survive a zombie apocalypse, or showing off your skills in a round of “Capture the Flag” on your favorite map, no artificial intelligence in the world comes close to the feeling of playing with a living, breathing, and thinking human being.

Unity3D has a sizable number of third-party networking middleware aimed at developing multiplayer games, and is arguably one of the easiest platforms to prototype multiplayer games.

The first networking system most people encounter in Unity is the built-in Unity Networking API . This API simplifies a great many tasks in writing networked code by providing a framework for networked objects rather than just sending messages. This works by providing a NetworkView component, which can serialize object state and call functions across the network.

Additionally, Unity provides a Master server, which essentially lets players search among all public servers to find a game to join, and can also help players in connecting to each other from behind private networks.

In this article, we will cover:

  • Introducing multiplayer
  • Introducing UDP communication
  • Setting up your own Master server for testing
  • What a NetworkView is
  • Serializing object state
  • Calling RPCs
  • Starting servers and connecting to them
  • Using the Master server API to register servers and browse available hosts
  • Setting up a dedicated server model
  • Loading networked levels
  • Creating a Pong clone using Unity networking

Introducing multiplayer games

Before we get started on the details of communication over the Internet, what exactly does multiplayer entail in a game?

As far as most players are concerned, in a multiplayer game they are sharing the same experience with other players. It looks and feels like they are playing the same game. In reality, they aren’t. Each player is playing a separate game, each with its own game state. Trying to ensure that all players are playing the exact same game is prohibitively expensive. Instead, games attempt to synchronize just enough information to give the illusion of a shared experience.

Games are almost ubiquitously built around a client-server architecture, where each client connects to a single server. The server is the main hub of the game, ideally the machine for processing the game state, although at the very least it can serve as a simple “middleman” for messages between clients. Each client represents an instance of the game running on a computer. In some cases the server might also have a client, for instance some games allow you to host a game without starting up an external server program.

While an MMO ( Massively Multiplayer Online ) might directly connect to one of these servers, many games do not have prior knowledge of the server IPs. For example, FPS games often let players host their own servers. In order to show the user a list of servers they can connect to, games usually employ another server, known as the “Master Server” or alternatively the “Lobby server”. This server’s sole purpose is to keep track of game servers which are currently running, and report a list of these to clients. Game servers connect to the Master server in order to announce their presence publicly, and game clients query the Master server to get an updated list of game servers currently running.

Alternatively, this Master server sometimes does not keep track of servers at all. Sometimes games employ “matchmaking”, where players connect to the Lobby server and list their criteria for a game. The server places this player in a “bucket” based on their criteria, and whenever a bucket is full enough to start a game, a host is chosen from these players and that client starts up a server in the background, which the other players connect to. This way, the player does not have to browse servers manually and can instead simply tell the game what they want to play.

Introducing UDP communication

The built-in Unity networking is built upon RakNet . RakNet uses UDP communication for efficiency.

UDP ( User Datagram Protocols ) is a simple way to send messages to another computer. These messages are largely unchecked, beyond a simple checksum to ensure that the message has not been corrupted. Because of this, messages are not guaranteed to arrive, nor are they guaranteed to only arrive once (occasionally a single message can be delivered twice or more), or even in any particular order. TCP, on the other hand, guarantees each message to be received just once, and in the exact order they were sent, although this can result in increased latency (messages must be resent several times if they fail to reach the target, and messages must be buffered when received, in order to be processed in the exact order they were sent).

To solve this, a reliability layer must be built on top of UDP. This is known as rUDP ( reliable UDP ). Messages can be sent unreliably (they may not arrive, or may arrive more than once), or reliably (they are guaranteed to arrive, only once per message, and in the correct order). If a reliable message was not received or was corrupt, the original sender has to resend the message. Additionally, messages will be stored rather than immediately processed if they are not in order. For example, if you receive messages 1, 2, and 4, your program will not be able to handle those messages until message 3 arrives.

Allowing unreliable or reliable switching on a per-message basis affords better overall performance. Messages, such as player position, are better suited to unreliable messages (if one fails to arrive, another one will arrive soon anyway), whereas damage messages must be reliable (you never want to accidentally drop a damage message, and having them arrive in the same order they were sent reduces race conditions).

In Unity, you can serialize the state of an object (for example, you might serialize the position and health of a unit) either reliably or unreliably (unreliable is usually preferred). All other messages are sent reliably.

Setting up the Master Server

Although Unity provide their own default Master Server and Facilitator (which is connected automatically if you do not specify your own), it is not recommended to use this for production. We’ll be using our own Master Server, so you know how to connect to one you’ve hosted yourself.

Firstly, go to the following page:

http://unity3d.com/master-server/

We’re going to download two of the listed server components: the Master Server and the Facilitator as shown in the following screenshot:

The servers are provided in full source, zipped. If you are on Windows using Visual Studio Express, open up the Visual Studio .sln solution and compile in the Release mode. Navigate to the Release folder and run the EXE (MasterServer.exe or Facilitator.exe). If you are on a Mac, you can either use the included XCode project, or simply run the Makefile (the Makefile works under both Linux and Mac OS X).

The Master Server, as previously mentioned, enables our game to show a server lobby to players. The Facilitator is used to help clients connect to each other by performing an operation known as NAT punch-through . NAT is used when multiple computers are part of the same network, and all use the same public IP address. NAT will essentially translate public and private IPs, but in order for one machine to connect to another, NAT punch-through is necessary. You can read more about it here:

http://www.raknet.net/raknet/manual/natpunchthrough.html

The default port for the Master Server is 23466, and for the Facilitator is 50005. You’ll need these later in order to configure Unity to connect to the local Master Server and Facilitator instead of the default Unity-hosted servers.

Now that we’ve set up our own servers, let’s take a look at the Unity Networking API itself.

NetworkViews and state serialization

In Unity, game objects that need to be networked have a NetworkView component. The NetworkView component handles communication over the network, and even helps make networked state serialization easier. It can automatically serialize the state of a Transform, Rigidbody, or Animation component, or in one of your own scripts you can write a custom serialization function.

When attached to a game object, NetworkView will generate a NetworkViewID for NetworkView. This ID serves to uniquely identify a NetworkView across the network. An object can be saved as part of a scene with NetworkView attached (this can be used for game managers, chat boxes, and so on), or it can be saved in the project as a prefab and spawned later via Network.Instantiate (this is used to generate player objects, bullets, and so on). Network.Instantiate is the multiplayer equivalent to GameObject.Instantiate —it sends a message over the network to other clients so that all clients spawn the object. It also assigns a network ID to the object, which is used to identify the object across multiple clients (the same object will have the same network ID on every client).

A prefab is a template for a game object (such as the player object). You can use the Instantiate methods to create a copy of the template in the scene.

Spawned network game objects can also be destroyed via Network.Destroy. It is the multiplayer counterpart of GameObject.Destroy. It sends a message to all clients so that they all destroy the object. It also deletes any RPC messages associated with that object.

NetworkView has a single component that it will serialize. This can be a Transform, a Rigidbody, an Animation, or one of your own components that has an OnSerializeNetworkView function. Serialized values can either be sent with the ReliableDeltaCompressed option, where values are always sent reliably and compressed to include only changes since the last update, or they can be sent with the Unreliable option, where values are not sent reliably and always include the full values (not the change since the last update, since that would be impossible to predict over UDP). Each method has its own advantages and disadvantages. If data is constantly changing, such as player position in a first person shooter, in general Unreliable is preferred to reduce latency. If data does not often change, use the ReliableDeltaCompressed option to reduce bandwidth (as only changes will be serialized).

NetworkView can also call methods across the network via Remote Procedure Calls ( RPC ). RPCs are always completely reliable in Unity Networking, although some networking libraries allow you to send unreliable RPCs, such as uLink or TNet.

Writing a custom state serializer

While initially a game might simply serialize Transform or Rigidbody for testing, eventually it is often necessary to write a custom serialization function. This is a surprisingly easy task.

Here is a script that sends an object’s position over the network:

using UnityEngine;
using System.Collections;

public class ExampleUnityNetworkSerializePosition : MonoBehaviour
{
  public void OnSerializeNetworkView( BitStream stream, 
NetworkMessageInfo info )
  {
    // we are currently writing information to the network
    if( stream.isWriting )
    {
      // send the object's position
      Vector3 position = transform.position;
      stream.Serialize( ref position );
    }
    // we are currently reading information from the network
    else
    {
      // read the first vector3 and store it in 'position'
      Vector3 position = Vector3.zero;
      stream.Serialize( ref position );
    
      // set the object's position to the value we were sent
      transform.position = position;
    }
  }
}

Most of the work is done with BitStream. This is used to check if NetworkView is currently writing the state, or if it is reading the state from the network. Depending on whether it is reading or writing, stream.Serialize behaves differently. If NetworkView is writing, the value will be sent over the network. However, if NetworkView is reading, the value will be read from the network and saved in the referenced variable (thus the ref keyword, which passes Vector3 by reference rather than value).

Using RPCs

RPCs are useful for single, self-contained messages that need to be sent, such as a character firing a gun, or a player saying something in chat.

In Unity, RPCs are methods marked with the [RPC] attribute. This can be called by name via networkView.RPC( “methodName”, … ). For example, the following script prints to the console on all machines when the space key is pressed.

using UnityEngine;
using System.Collections;

public class ExampleUnityNetworkCallRPC : MonoBehavior
{
  void Update()
  {
    // important – make sure not to run if this 
networkView is notours
    if( !networkView.isMine )
      return;

    // if space key is pressed, call RPC for everybody
    if( Input.GetKeyDown( KeyCode.Space ) )
      networkView.RPC( "testRPC", RPCMode.All );
  }

  [RPC]
  void testRPC( NetworkMessageInfo info )
  {
    // log the IP address of the machine that called this RPC
    Debug.Log( "Test RPC called from " + info.sender.ipAddress );
  }
}

Also note the use of NetworkView.isMine to determine ownership of an object. All scripts will run 100 percent of the time regardless of whether your machine owns the object or not, so you have to be careful to avoid letting some logic run on remote machines; for example, player input code should only run on the machine that owns the object.

RPCs can either be sent to a number of players at once, or to a specific player. You can either pass an RPCMode to specify which group of players to receive the message, or a specific NetworkPlayer to send the message to. You can also specify any number of parameters to be passed to the RPC method.

RPCMode includes the following entries:

  • All (the RPC is called for everyone)
  • AllBuffered (the RPC is called for everyone, and then buffered for when new players connect, until the object is destroyed)
  • Others (the RPC is called for everyone except the sender)
  • OthersBuffered (the RPC is called for everyone except the sender, and then buffered for when new players connect, until the object is destroyed)
  • Server (the RPC is sent to the host machine)

Initializing a server

The first thing you will want to set up is hosting games and joining games. To initialize a server on the local machine, call Network.InitializeServer.

This method takes three parameters: the number of allowed incoming connections, the port to listen on, and whether to use NAT punch-through. The following script initializes a server on port 25000 which allows 8 clients to connect:

using UnityEngine;
using System.Collections;

public class ExampleUnityNetworkInitializeServer : MonoBehavior
{
  void OnGUI()
  {
    if( GUILayout.Button( "Launch Server" ) )
    {
      LaunchServer();
    }
  }
  
  // launch the server
  void LaunchServer()
  {
    // Start a server that enables NAT punchthrough,
    // listens on port 25000,
    // and allows 8 clients to connect
    Network.InitializeServer( 8, 25005, true );
  }

  // called when the server has been initialized
  void OnServerInitialized()
  {
    Debug.Log( "Server initialized" );
  }
}

You can also optionally enable an incoming password (useful for private games) by setting Network.incomingPassword to a password string of the player’s choice, and initializing a general-purpose security layer by calling Network.InitializeSecurity(). Both of these should be set up before actually initializing the server.

Connecting to a server

To connect to a server you know the IP address of, you can call Network.Connect.

The following script allows the player to enter an IP, a port, and an optional password and attempts to connect to the server:

using UnityEngine;
using System.Collections;

public class ExampleUnityNetworkingConnectToServer : MonoBehavior
{
  private string ip = "";
  private string port = "";
  private string password = "";

  void OnGUI()
  {
    GUILayout.Label( "IP Address" );
    ip = GUILayout.TextField( ip, GUILayout.Width( 200f ) );

    GUILayout.Label( "Port" );
    port = GUILayout.TextField( port, GUILayout.Width( 50f ) );

    GUILayout.Label( "Password (optional)" );
    password = GUILayout.PasswordField( password, '*',
GUILayout.Width( 200f ) );

    if( GUILayout.Button( "Connect" ) )
    {
      int portNum = 25005;

      // failed to parse port number – a more ideal solution is 
tolimit input to numbers only, a number of examples can 
befound on the Unity forums
      if( !int.TryParse( port, out portNum ) )
      {
        Debug.LogWarning( "Given port is not a number" );
      }
      // try to initiate a direct connection to the server
      else
      {
        Network.Connect( ip, portNum, password );
      }
    }
  }

  void OnConnectedToServer()
  {
    Debug.Log( "Connected to server!" );
  }

  void OnFailedToConnect( NetworkConnectionError error )
  {
    Debug.Log( "Failed to connect to server: " +error.ToString() );
  }

}

Connecting to the Master Server

While we could just allow the player to enter IP addresses to connect to servers (and many games do, such as Minecraft), it’s much more convenient to allow the player to browse a list of public servers. This is what the Master Server is for.

Now that you can start up a server and connect to it, let’s take a look at how to connect to the Master Server you downloaded earlier. First, make sure both the Master Server and Facilitator are running. I will assume you are running them on your local machine (IP is 127.0.0.1), but of course you can run these on a different computer and use that machine’s IP address. Keep in mind, if you want the Master Server publicly accessible, it must be installed on a machine with a public IP address (it cannot be in a private network).

Let’s configure Unity to use our Master Server rather than the Unity-hosted test server. The following script configures the Master Server and Facilitator to connect to a given IP (by default 127.0.0.1):

using UnityEngine;
using System.Collections;

public class ExampleUnityNetworkingConnectToMasterServer : MonoBehaviour
{
  // Assuming Master Server and Facilitator are on the same machine
  public string MasterServerIP = "127.0.0.1";

  void Awake()
  {
    // set the IP and port of the Master Server to connect to
    MasterServer.ipAddress = MasterServerIP;
    MasterServer.port = 23466;

    // set the IP and port of the Facilitator to connect to
    Network.natFacilitatorIP = MasterServerIP;
    Network.natFacilitatorPort = 50005;
  }
}
Packt

LEAVE A REPLY

Please enter your comment!
Please enter your name here