Syncing players only within area

If I were to have a large game world and only wanted to sync one player with the other when within a distance of each other how would I do it? I was thinking it would be in the rpcmode setting, but... doesn't seem like it.

Also, I've been using rpc calls in code to do everything including syncing a players position. Is this a good practice or should it be done some other way? From what I understand all networking is done through rpc calls, unity just has some special features to use them without writing code for simplicity. Is this correct?

Also, if there were multiple scenes that I wanted a server to control all at once (including the physics and movements of AI etc) how could this be done?

Thanks for any help you can provide.

 

In the current version of Unity (2.0.2), this is pretty hard to do. What I did for TRaceON was creating my own "network layer" on top of Unity's networking, with my own NetworkManager and NetworkAccess classes which I use to register players according to their context. Then, I put my RPCs through those classes and basically, instead of doing RPCMode.All or RPCMode.Others, I loop through the lists of NetworkPlayers that I'm keeping and send the messages directly to them, using RPC(..., networkPlayer, ...).

It was a bit tricky to set up, but now it works as designed. This is possible because - as you've said: Unity does everything via RPCs in the end (at least as far as I know). So you can do your own "Network.Instantiate" without using Network.Instantiate, and you can also do your own network synchronization, if you have to.

However, I think it's quite possible that Unity will soon provide something similar (more fine-grained control on who gets what) "out-of-the-box", simply because this is what I feel is currently the most significant limitation in Unity's networking implementation, and usually, Unity does not limit ;-)

Concerning controlling multiple scenes: I also do that in TRaceON, and the approach is simply loading all scenes on the server, and using "DontDestroyOnLoad" to make them "persistent". You need a smooth design for all the management stuff that's involved with that, but it can be done.

Oh: and of course you make your life much easier when you offset the scenes ;-) (I have the first scene at y = -10000, the second one at y = -9000 and so on).

If we get together at least some 10 or 20 people (or more), we could actually try this "in practice". One thing I have also implemented in TRaceON is that different groups playing in the same level but in different "game sessions" don't interfere with each other. So, you can have 2 game sessions A and B in level one, and maybe 3 game sessions in level two, all taking place simultanuously without people from game session A seeing anybody from game session B, and also (more important, and a little more involved to implement) not colliding with anything from session B ;-)

Sunny regards,
Jashan

 

I'm not near the level where I could write my own networking level yet... so would something like below work, or am I way off track?

Would it be possible to have transmissions in each zone have a specific group then disable or enable sending and receiving as necessary using SetRecievingEnabled? If so is there any way to batch turn off all receiving from all players in all groups then just turn on specific groups? I've been reading through the documentation and it sounds like each player for each group has to be shut off separately. Is there a way to shut off all groups for all players then turn on just the specific groups for all players?

 

As I understand Unities Networking there is a destinct difference between State Synchronization (e.g. Unreliable, Reliable Delta Compressed) and RPCs. At least when using Unreliable Synchronization the Update-States are not resent, when lost in traffic.
An RPC call is always resent. So doing synchronization of Player Positions with RPCs can lead to undesirable effects on bad network connections. When an RPC call is dropped and resent, all other packets are put on halt. This is because often it is necessary that they arrive in order.
Though I don't know if this is only for the group the NetworkView is in, or all networking groups.

SetReceivingEnabled is a local filter (as I understood). So it does not reduce traffic. Maybe a bit of CPU work, because the State-Updates don't have to be processed, but thats negeligable.

In your case I would suggest what jashan did. Build your own Network-Update Loop (a CoRoutine with an infinite loop that halts for 1/updateRate seconds after each iteration) and decide on a player by player basis, which RPC-Calls need to be made.