I have been diving into Unity3d multiplayer again. Whilst previous attempts I was using a socket server I had ignored the simplicity of the Peer to Peer networking that Unity can do to make life much easier to prototype things.
The way this works is that unity3d provide a broker a.k.a a Master Server which acts as a lobby to allow a network game to show up and a client to connect to it. Once that connection is established through some very simple properties and through the use of RPC (Remote Procedure Calls) you are able to make things happen on each client.
For a more robust MMO solution there are things like Photon however to get into what it means to create a distributed system its worth just using the basics to start.
I am not going to go over the lobby essentials as that is in various other network tutorials but just wanted to share the simplicity of the network synchronisation.
When each person gets their version of the unity scene for the game the one that initiated the network connection is regarded as the server all the others that connect are clients, but they are all running the same code.
This is where some confusion comes in, but Network.isServer is a property that helps you decide on whose the boss.
Any of the clients or server is able to create an object with a special version of “Instantiate”. This is used to create an instance of a fully functioning object (or prefab) in a scene. If that prefab is bestowed with the special component Network View is is then able to be created with Network.Instantiate. The component is at the bottom of this picture. How the data flows and which property to inspect is configurable.
What that does is make the object appear on the creating client, but it also messages all the other clients(and server) to create the same prefab (as they are running the same code anyway). Each of these objects is able to have a property or set of properties to then keep updating. Typically this is something like the objects position and orientation (transform). If the owner of the object changes where it is, the changes are rippled to each of the other clients without any further effort. Magic.
This helps provide some interesting design choices in the distribution of responsibility. I was building a generic playing card deck and I started with each client being responsible for instantiating their cards as that is how it feels it should work. However it quickly became more obvious that the one client (i.e. the Server) should be in control of the deck. This sounds obvious, but maybe it is isn’t always the case. The Server instantiates all cards and those ripple to all clients (including itself). Ownership of the cards for the game is then maintained by my own collections, despite the attraction of .isMine property on objects. Now other objects and types of interaction will be better distributed more equally. Either way you end up having to send other messages back and forth. Whilst unity3d will keep track of transforms your have other data to send and synchronise.
Once an object has a network instance you can call functions on scripts on those objects wherever they are on which ever client using networkView.RPC().
This lets you specify the function name to call the values to send and more interestingly an RPC mode. This means that you can call the function on all networks instances or every other network instance other than this one clients version etc.
Functions are made available on the script with a simple extra tag in c# (works in .js in a similar way)
[RPC]
void setvalue( int myval) {
cardval = myval;
}
}
So before you know it you have state synchronised objects across a network and you can concentrate on what and why they exists. It is certainly somewhere to start if you are not used to these sort of distributed problems.
Leave a Reply