NETWORK VIEWS

Network views in uLink are the vehicles used to share data across the network. They allow two kinds of network communication: state synchronization and remote procedure calls. When you have many clients running the same game, each client has a set of objects, which all together make up the game itself. To make two or more clients seem identical, these objects need to be synchronized by sending data over the network. This is called state synchronization. Synchronizing the state of every object in the game would require a massive amount of data, probably too much data to be sent across the network in practice. To address this, uLink's network views are used to specify what data will be shared, and therefore which objects will be synchronized. Each uLinkNetworkView component watches a specific part of an object and makes sure it is synchronized with the object replicas on other clients. More information about state synchronization can be found in the State Synchronization Details manual chapter. There are other network scenarios, like when you want to send out the position of an object or respawn an item for someone to pick up. Because these are one-time, infrequent operations, it does not make sense to synchronize the state of the involved objects. Instead, you use a remote procedure call to tell the clients or server to perform an operation. More information about remote procedure calls can be found in the RPC Details manual chapter.

uLinkNetworkView vs. uLink.NetworkView

The observant reader may have noticed that there is one class named uLinkNetworkView and one class uLink.NetworkView. What is important to know is that there is absolutely no difference between the two. uLinkNetworkView is an alias that is used in Unity when the name uLink.NetworkView would conflict with the existing UnityEngine.NetworkView. If you look in the uLink API listing you will only find uLink.NetworkView. The same argument goes for uLinkNetworkP2P and uLink.NetworkP2P.

NetworkViewID

uLink's network views are identified across the network by uLink.NetworkViewIDs. A uLink.NetworkViewID is basically a unique identifier of an object that all networked machines agree on. It is implemented as a 16 bit number. Each packet that arrives on the client side needs to be delivered to a specific uLinkNetworkView. The uLink.NetworkViewID uniquely identifies to which uLinkNetworkView it belongs. Using the uLink.NetworkViewID, uLink can find the right uLinkNetworkView, unpack the data and finally apply the incoming packet to the uLinkNetworkView's observed object.

Basic usage of the uLinkNetworkView component

In the Unity editor, just drag and drop the script component named uLinkNetworkView to a prefab or a game object. After that, the quickest way to get started is to just set the observed property of the uLinkNetworkView to the transform (position and rotation) of the object. Now your object knows what to synchronize over the network with state synchronization but there is still one thing missing, the uLink.NetworkViewID.

ViewID - automatic or manual

If you use uLink.Network.Instantiate() to create your networked objects at runtime, you do not need to worry about allocating uLink.NetworkViewIDs and assigning them yourself. It will all be done automatically under the hood. This is the recommended way for spawning game objects during a live game. Another good way to get a uLink.NetworkViewID for a game object is to set it manually at design time. It is common to do this for Game Objects that are part of the scene. The uLinkNetworkView component has a property called Manual View ID. Change that from the default 0 to a unique number. It is recommended to use numbers from 1 to 1000 (see uLink.Network.maxManualViewIDs()). Any game object that is listed in the hierarchy view in Unity at design time needs to get a view ID from the game developer in this manual way. Examples of network aware objects that are not dynamically created at runtime are spawning points and chat windows. Network aware game objects that are part of a scene in the Unity editor should always be assigned a unique Manual View ID. If the client and server have different scenes, make sure the objects in both scenes have a uLinkNetworkView component and that the Manual View ID is set to the exact same number for both objects.

Script code accessing the uLinkNetworkView

The easiest way to access the uLinkNetworkView inside a script attached to a game object is to make the script inherit uLink.MonoBehaviour and then the property called networkView can be accessed and used. If you write a script and want to access the network view of another game object there are three easy ways to access the uLinkNetworkView when you know the name of that game object. The last one does not work in Unity 2.6.1 or older.

Multiple NetworkViews per game object

It is possible to have multiple NetworkViews per prefab/game object. We do not recommend this. Instead we recommend using only one NetworkView and whenever there is a need to send and receive the state of several components in a prefab/game object, use the uLink utility script uLinkObservedList (described in the section below). The possibility to have multiple NetworkViews is included in uLink only to make it easier to migrate from a game built with several NetworkViews using Unity's built-in networking. The migration can be done very easily keeping multiple NetworkViews per game object and test the result fast. Later on, it is best to do the actual refactoring into using only one networkView per game object. The motive for using only one NetworkView per game object is that it reduces the risk for bugs. One situation with bug risks is when you call the Destroy() method on a component. Another motive for using only one NetworkView is that it makes the structure of components and code easier to understand and maintain. When using multiple NetworkViews in one game object, the property named State Synchronization should be the same in every uLinkNetworkView if the object is instantiated with uLink.Network.Instantiate(). If State Synchronization differs, uLink will use the setting in the first component for the complete game object.

Using uLinkObservedList

Let's say there is a need to send the state of the game object's transform and also the state of a script component named Score attached to the same game object. The callback uLink.Network.uLink_OnSerializeNetworkView() has been implemented in the Score script. This is how to make this setup work the correct way in uLink:

• Add the script uLinkNetworkView to the prefab for this game object.
• Add the script uLinkObservedList to the prefab for this game object.
• Make sure the observed property of uLinkNetworkView is the uLinkObservedList.
• Set the uLinkObservedList's Size to 2.
• Set the uLinkObservedList's Element 0 to be the transform component.
• Set the uLinkObservedList's Element 1 to be the Score script component.

Done! Now it is possible to instantiate this object using uLink.Network.Instantiate().