(Para nuevos proyectos puedes usar el Nuevo Networking System introducido en 5.1. Esta información es para antiguos proyectos usando el sistema antiguo de networking.)
Debido a que la comunicación en red es potencialmente más lenta comparando otros aspectos de un juego, es importante reducirlo a su mínimo. Por lo tanto es importante considerar qué tantos datos se cambian y qué tan frecuente los intercambios toman lugar.
La cantidad del bando de ancha utilizado depende fuertemente en sí usted utiliza el modo de Unreliable o Reliable Delta Compression para sincronizar los datos (el modo se configura del componente Network View).
In Unreliable mode, the whole of the object being synchronized will be transmitted on each iteration of the network update loop. The frequency of this update is determined by the value of Network.sendRate, which is set to 15 updates per second by default. Unreliable mode ensures frequent updates but any dropped or delayed packets will simply be ignored. This is often the best synchronization mode to use when objects change state very frequently and the effect of a missed update is very short-lived. However, you should bear in mind the amount of data that might be sent during each update. For example, synchronizing a Transform involves transmitting nine float values (three Vector3s with three floats each), which equates to 36 Bytes per update. If the server is running with eight clients and using the default update frequency then it will receive 4,320 KBytes/s (8*36*15) or 34.6Kbits/s and transmit 30.2 KBytes/s (8*7*36*15) or 242Kbits/s. You can reduce the bandwidth consumption considerably by lowering the frequency of updates, but the default value of 15 is about right for a game where the action moves quickly.
En el modo Reliable Delta Compressed, se garantiza que los datos se envían de manera fiable y que lleguen en el orden correcto, estos serán buffered hasta que todos los paquetes en secuencia hayan llegado. Aunque esto asegura que los datos transmitidos se reciben correctamente, la espera y re-transmisión tiende a aumentar el uso de banda ancha. No obstante, los datos también son comprimidos delta que significa que solamente las diferencias entre el estado pasado y el actual son transmitidos. Si el estado es exactamente el mismo entonces nada se envía. El beneficio de la delta compresión (compresión delta) por lo tanto depende en qué tanto cambia el estado y en qué propiedades.
Hay un montón de oportunidades para la creatividad en el diseño del juego para que el estado parezca ser el mismo en todos los clientes incluso sin lo es, estrictamente. Un ejemplo de este es dónde las animaciones son sincronizadas. Si un componente de Animation se observa por un Network View entonces sus propiedades serán sincronizadas exactamente, para que los frames de la animación parezcan los mismos en todos los clientes. Aunque esto pueda ser deseable en muchos casos, típicamente será suficiente que el personaje se vea caminando, corriendo, saltando, etc. Las animaciones por lo tanto pueden ser crudamente sincronizadas simplemente enviando un valor entero para denotar qué secuencia de animación hay que reproducir. Esto ahorrará una gran cantidad de ancho de banda comparado a sincronizar todo el componente de Animation.
A menudo no es necesaria mantener el juego perfectamente sincronizado con todos los clientes, por ejemplo, en casos dónde los jugadores están en diferentes áreas del mundo del juego dónde no se encuentran. Esto puede reducir el ancho de banda al igual que la carga en el servidor ya que solamente los clientes que pueden interactuar necesitan mantenerse en sincronización. Este concepto a veces se refiere como Relevant Sets (ie, hay un sub-conjunto del juego completo que es relevante a cualquier cliente en particular en cualquier momento en particular). Sincronizar los clientes según sus conjuntos relevantes se pueden manejar con RPCs, ya que pueden dar un mayor control sobre el destino del estado de actualización.
Cuando cargue niveles, rara vez se necesita preocupar por el ancho de banda que se está utilizando ya que cada cliente puede simplemente esperar hasta que los otros han inicializado el nivel a jugar. La carga de niveles a menudo involucra la transmisión de unos items de data bastante grandes (como imágenes o datos de audio).