Note: UNet is deprecated, and will be removed from Unity in the future. A new system is under development. For more information and next steps see this blog post. |
The Network ManagerA Networking component that manages the network state of a project. More info
See in Glossary offers a built-in simple player spawning feature, however you may want to customize the player spawning process - for example to assign a colour to each new player spawned.
To do this you need to override the default behaviour of the Network Manager with your own script.
When the Network Manager adds a player, it also instantiates a GameObjectThe fundamental object in Unity scenes, which can represent characters, props, scenery, cameras, waypoints, and more. A GameObject’s functionality is defined by the Components attached to it. More info
See in Glossary from the Player PrefabAn asset type that allows you to store a GameObject complete with components and properties. The prefab acts as a template from which you can create new object instances in the scene. More info
See in Glossary and associates it with the connection. To do this, the Network Manager calls NetworkServer.AddPlayerForConnection. You can modify this behaviour by overriding NetworkManager.OnServerAddPlayer. The default implementation of OnServerAddPlayer
instantiates a new player instance from the player Prefab and calls NetworkServer.AddPlayerForConnection to spawn the new player instance. Your custom implementation of OnServerAddPlayer
must also call NetworkServer.AddPlayerForConnection
, but you are free to perform any other initialization you require in that method too.
The example below customizes the color of a player. First, add the color script to the player prefab:
using UnityEngine;
using UnityEngine.Networking;
class Player : NetworkBehaviour
{
[SyncVar]
public Color color;
}
Next, create a NetworkManager to handle spawning.
using UnityEngine;
using UnityEngine.Networking;
public class MyNetworkManager : NetworkManager
{
public override void OnServerAddPlayer(NetworkConnection conn, short playerControllerId)
{
GameObject player = (GameObject)Instantiate(playerPrefab, Vector3.zero, Quaternion.identity);
player.GetComponent<Player>().color = Color.red;
NetworkServer.AddPlayerForConnection(conn, player, playerControllerId);
}
}
The function NetworkServer.AddPlayerForConnection
does not have to be called from within OnServerAddPlayer
. As long as the correct connection object and playerControllerId
are passed in, it can be called after OnServerAddPlayer
has returned. This allows asynchronous steps to happen in between, such as loading player data from a remote data source.
Although in most multiplayer games, you typically want one player for each client, the HLAPIAbbreviation of High Level API
See in Glossary treats players and clients as separate concepts.This is because, in some situations (for example, if you have multiple controllers connected to a console system), you might need multiple player GameObjects for a single connection. When there are multiple players on one connection, you should use the playerControllerId
property to tell them apart. This identifier is scoped to the connection, so that it maps to the ID of the controller associated with the player on that client.
The system automatically spawns the player GameObject passed to NetworkServer.AddPlayerForConnection
on the server, so you don’t need to call NetworkServer.Spawn for the player. Once a player is ready, the active networked GameObjects (that is, GameObjects with an associated NetworkIdentityA Networking component that allows you to assign an identity to your GameObject for the network to recognise it as a Local Player GameObject or a Server Only GameObject. More info
See in Glossary) in the SceneA Scene contains the environments and menus of your game. Think of each unique Scene file as a unique level. In each Scene, you place your environments, obstacles, and decorations, essentially designing and building your game in pieces. More info
See in Glossary spawn on the player’s client. All networked GameObjects in the game are created on that client with their latest state, so they are in sync with the other participants of the game.
You don’t need to use playerPrefab on the NetworkManager
to create player GameObjects. You could use different methods of creating different players.
In addition to players, client connections also have a “ready” state. The host sends clients that are ready information about spawned GameObjects and state synchronization updates; clients which are not ready are not sent these updates. When a client initially connects to a server, it is not ready. While in this non-ready state, the client can do things that don’t require real-time interactions with the game state on the server, such as loading Scenes, allowing the player to choose an avatarAn interface for retargeting animation from one rig to another. More info
See in Glossary, or fill in log-in boxes. Once a client has completed all its pre-game work, and all its Assets are loaded, it can call ClientScene.Ready to enter the “ready” state. The simple example above demonstrates implementation of ready states; because adding a player with NetworkServer.AddPlayerForConnection
also puts the client into the ready state if it is not already in that state.
Clients can send and receive network messages without being ready, which also means they can do so without having an active player GameObject. So a client at a menu or selection screen can connect to the game and interact with it, even though they have no player GameObject. See documentation on Network messages for more details about sending messages without using commands and RPC calls.
To replace the player GameObject for a connection, use NetworkServer.ReplacePlayerForConnection. This is useful for restricting the commands that players can issue at certain times, such as in a pre-game lobby screen. This function takes the same arguments as AddPlayerForConnection
, but allows there to already be a player for that connection. The old player GameObject does not have to be destroyed. The NetworkLobbyManager uses this technique to switch from the NetworkLobbyPlayer GameObject to a gameplay player GameObject when all the players in the lobby are ready.
You can also use ReplacePlayerForConnection
to respawn a player after their GameObject is destroyed. In some cases it is better to just disable a GameObject and reset its game attributes on respawn. The following code sample demonstrates how to actually replace the destroyed GameObject with a new GameObject:
class GameManager
{
public void PlayerWasKilled(Player player)
{
var conn = player.connectionToClient;
var newPlayer = Instantiate<GameObject>(playerPrefab);
Destroy(player.gameObject);
NetworkServer.ReplacePlayerForConnection(conn, newPlayer, 0);
}
}
If the player GameObject for a connection is destroyed, then that client cannot execute Commands. They can, however, still send network messages.
To use ReplacePlayerForConnection
you must have the NetworkConnection GameObject for the player’s client to establish the relationship between the GameObject and the client. This is usually the property connectionToClient on the NetworkBehaviour class, but if the old player has already been destroyed, then that might not be readily available.
To find the connection, there are some lists available. If using the NetworkLobbyManager
, then the lobby players are available in lobbySlots. The NetworkServer also has lists of connections and localConnections.
When you visit any website, it may store or retrieve information on your browser, mostly in the form of cookies. This information might be about you, your preferences or your device and is mostly used to make the site work as you expect it to. The information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Click on the different category headings to find out more and change our default settings. However, blocking some types of cookies may impact your experience of the site and the services we are able to offer.
More information
These cookies enable the website to provide enhanced functionality and personalisation. They may be set by us or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising. Some 3rd party video providers do not allow video views without targeting cookies. If you are experiencing difficulty viewing a video, you will need to set your cookie preferences for targeting to yes if you wish to view videos from these providers. Unity does not control this.
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.