Number of NetworkBehaviour objects - What is too much? (Bandwidth Optimization)

Hey,

let's start with a basic assumption:

The less networked objects (NetworkBehaviours) are used within a scene, the less network bandwidth is consumed.

• Is this assumption true? If so, under which conditions?
  
• How significant is the actual number of NetworkBehaviours, independent from the synched data they include? Independent from the data means that we still have the same amount of SyncVars, Commands and ClientRPCs, but a different architecture respectively a different number of networked objects.
  
• Do empty NetworkBehaviours (without data) have an impact on bandwidth consumption?
  
• To which extent is it reasonable to reduce the number of NetworkBehaviours in order to optimize network bandwidth consumption?

Unfortunately, the official UNET docs do not provide much help and information on best practices regarding efficient UNET game architectures. In addition, everything would be so much easier if we had a way to exactly measure bandwidth consumption. Then we could at least compare different code architectures in terms of network bandwidth consumption. Anyway, it would be better to know how to do it properly right from the start.


A simple example:
Let's say we have a game scenario with multiple players and each player is able to cast different spells.

Design Choice A:
We could make each spell a NetworkBehaviour with it's own Commands and ClientRPCs. As a result, we have some quite modular code, but also a lot of networked objects in the scene (one for each spell and maybe also for each player).

Design Choice B:
We could change the code architecture to have a single NetworkBehaviour script for each player. This script handles all the Commands and ClientRPC and then calls functions in other scripts for the spells which do not need to be networked objects. So we have significantly less networked objects in the scene. On the downside, we might need a few more parameters in order to identify the casted spells.

So, these are just 2 design variants with different code architectures.
Is there a significant difference between those variants, especially in terms of bandwidth?

What are general hints and best practices in order to create efficient network architectures with UNET, especially in terms of bandwidth consumption?

Any help is much appreciated.

 

Hi,
+1 to all these questions.

For design choice, I took the second way : One networkbehaviour per client.
My game is a fast shooter. A player can spawn "spells" like a grenade.
I have a weaponController component attached to my root player object. This controller will spawn the grenade, grab all the targets/damages infos after it exploded, then send the result to all player if isServer.

I prefer this over one networkbehaviour per object, because I think I just don't trust this part of unity, especially about optimization.
It's also easier to debug/modify because I had to write the logic myself, and have now a (little) better understanding of networking.

I'm waiting for my game to be finished to learn how to use a sniffer and make extensive tests about networking optimization.

Meanwhile I saw a little tool in unity you might be already aware of : the profiler window.
http://forum.unity3d.com/threads/networkclient-manage-connection.396816/

Not directly an answer to your questions but it can give an idea :
A NetworkServer/Client connection will not consume bandwith if you send no messages, event if it's started and listening to something.
So, following this logic, an empty or disabled NetworkBehaviour should not use bandwith.

I also extremely interested in more of any kind of informations / protips about networking.

 

I'm an absolute beginner, but as far as I understand from the docs, a NetworkBehavior has to have dirty bits to cause bandwith usage. So if your SyncVars aren't changing, nothing should be sent.

 

I'd say B. Look at the MOBA example project that was posted a while ago, it does exactly this.

 

Thanks for your input. The example indeed provides a nice reference for design B.