ownership, viewIDs and more

Ownership of a networkview?
well after viewing like a gazillion posts I found one with a reply from the network guy at unity that states that the server/client that the networkviewID is allocated from is the "owning" server/client (would be nice to have in the documentation if its true).
My question is then: Does Network.AllocateViewID() propergate this to the server and other clients so that other clients or servers would not allocate the same ID later on? (I presume that everybody is connected to a server for this to be correct).


Another question is if a client is the owner of a networkview that observes a script (OnNetworkSerialize(.....)). Since the client only knows of the server, he will transmit the data only to the server.
Would you then have to create another networkview with the server as the owner to transmit the data to all the other clients? or will the server, since it knows it is a server (network.InitializeServer(...)), propergate the data to all connected clients?

hmm.... think I have some more questions, but it seems like I have forgotten em.

 

Isn't it? Well, anyways, yeah - the owner is the one that has allocated the ViewID.

Yes. In a "peer-to-peer setup" there is still one of the clients acting as server. And, AFAIK, every connected machine has its own range of ViewIDs so that there can't be collisions. I think in the case that a client runs out of ViewIDs, it could probably ask for me on the server ... but that's just a guess. This *may* be documented in Raknet (I think Unity uses the ViewID concept from the original Raknet library).

Note sure, maybe the client is part of the ViewID which would also avoid collisions. I think that's actually more likely. Maybe Larus can clear this up?

The server will transparently pass that information on to the other clients (unless that was switched off via NetworkView.SetScope or Network.SetSendingEnabled - I'm hoping that NetworkView.SetScope only effecting NetworkView-Synchronization and not RPCs is a bug and not "by design"; SetSendingEnabled works "per group" of which you have 32).

 

Another question, but it's about the same concepts so i'll put it here...

As i understand it, a NetworkView observing a script will automatically send when you call Serialize(var) if the NetworkView owns the object and receive on that same call when it doesn't.

Is it possible to transfer ownership of objects to another instance? That is, a client calls Network.Instantiate() and therefore is the owner of instances of that object, so its serialize calls control where it is and the server's serialize reads it out. Is it now possible to make the server the owner of instances of that object at a later time? So after this event the server's calls to serialize will send and the original owner will receive just like any other clients.

Oh i forgot to mention that i've tried setting NetworkView.owner, but it's read-only.

 

I think that answered your question ;-)

What you'd usually do is different: You send an RPC to the server asking to instantiate an object (with all the info the server needs to know). Server checks "is that possible?" and if so, instantiates the object.

 

Yeah, that was my backup plan. The difference is of course that in that case the server is in charge all along. So i guess it's not possible to transfer ownership then?

I do think that in this case the NetworkView implementation has traded off some valuable versatility for simplicity. I would like to be able to decide when to send and when to receive, but i'm forced to work around the issue. Still, in my case it's luckily not a big problem. I just wanted to know that i'm not overlooking anything.

 

Not that I would know about it.

That's true - using the built-in synchronization is probably a little less versatile. However, you're free to use RPCs for your synchronization - and doing so gives you all the versatility you're asking for. Of course, that comes at the price of being less simple ;-)

 

Who owns what is controlled by the NetworkViewID allocated and assigned to the NetworkView and not the networkview's owner property.

I have not tested it, but it would be reasonable to assume that if you allocate a new ViewID and assign it to the networkview observing the object you can change who owns what and when (well its actually how I use it, but Ive not tested if you can switch).

You would still have to syncronize these viewID's between the parties though i.e. in a RPC.
It is probably not a viable solution if they need to switch "ownership" alot either.


//Perlohmann

 

In a peer to peer game where you want to mimic client / server and have a single owner, you setup one machine as a game observer, you place in the code for that particular startup routine to have it create all of the objects, then when a person joins the game, the only network view ID they should actually end up owning is their player, other than that, all game objects are owned by the observer.

IF (startedAsServer) THEN instansiate everything.
IF (startedAsClient) ASK server for everything.
FYI make sure that the server is robust and can handle the calculation of everything for those objects. In a Peer to Peer your asking the load to be handled by each client that created its objects before broadcast.

Think about Command and Conquer for a moment, that is a 4 - 8 player peer to peer game. Now, each player creates there own object and sends out the message to the other players that the object is getting created, all the other machines do is create an echo of that object but control nothing about it, they all rely on the machine that created it to broadcast to the network of players everything there is to know about the object.

In the event of a disconnection of the player, they detect the disconnection and some player in the queue of players is assigned the master of those objects and the objects owner is switched.

One good point you bring up is switching the ownerID of a particular object. I have not messed with this using Unity's implimentation of Rakknet, so if this is possible, someone else can chime in and say how.