(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.)
Puede habilitar la sincronización de estado para una vista de red determinada eligiendo Reliable Delta Compressed o Unreliable desde el menú desplegable State Synchronization. A continuación, debe elegir qué tipo de datos se sincronizarán mediante la propiedad Observed.
Unity puede sincronizar componentes Transform, Animation, Rigidbody y MonoBehaviour.
Transforms se serializan almacenando la posición, la rotación y la escala. La información sobre los padres no se transfiere a través de la red.
Animation serializa cada estado de animación en ejecución, es decir, el tiempo, el peso, la velocidad y las propiedades habilitadas.
Rigidbody serializa la posición, la rotación, la velocidad y la velocidad angular.
Scripts (MonoBehaviours) llaman a la función OnSerializeNetworkView().
Los Network Views actualmente soportan dos niveles de realibilidad Reliable Delta Compressed y Unreliable.
Ambos tienen sus ventajas y desventajas, y los detalles específicos del juego determinarán cuál es el mejor para usar.
Para obtener información adicional sobre cómo minimizar el ancho de banda, lea la página Minimizar el ancho de banda.
El modo Reliable Delta Compressed comparará automáticamente los datos que el cliente recibió por última vez con el estado actual. Si no se han modificado datos desde la última actualización, no se enviarán datos. Sin embargo, los datos serán comparados en base a la propiedad. Por ejemplo, si la posición del transform ha cambiado pero su rotación no tiene entonces sólo la posición será enviada a través de la red. El ancho de banda se guarda transmitiendo sólo los datos modificados.
Unity también asegurará que cada paquete UDP llegue de forma confiable reenviándolo hasta que se determine el recibo. Esto significa que si se abandona un paquete, los paquetes enviados posteriormente no se aplicarán hasta que se reenvíe y reciba el paquete eliminado. Hasta entonces, todos los paquetes posteriores se mantendrán esperando en un búfer.
En el modo Unreliable, Unity enviará paquetes sin comprobar que se han recibido. Esto significa que no sabe qué información se ha recibido y por lo que no es seguro enviar sólo los datos modificados - todo el estado se enviará con cada actualización.
La Network layer utiliza UDP, que es un protocolo no confiable, no ordenado, pero puede utilizarse para enviar paquetes ordenados de forma fiable, al igual que TCP. Para ello, Unity utiliza internamente ACKs y NACKs para controlar la transmisión de paquetes, asegurando que no se eliminen paquetes. La desventaja de usar paquetes confiables ordenados es que si un paquete se cae o se retrasa, todo se detiene hasta que el paquete ha llegado con seguridad. Esto puede provocar retrasos en la transmisión cuando hay retrasos significativos en la red.
La transmisión Unreliable (no fiable) es útil cuando se sabe que los datos cambiarán cada frame de todos modos. Por ejemplo, en un juego de carreras, prácticamente se puede confiar en que el coche del jugador siempre está en movimiento, por lo que los efectos de un paquete perdido pronto se fijará en el siguiente.
En general, debe utilizar el envío no fiable, donde las actualizaciones rápidas y frecuentes son más importantes que los paquetes perdidos. Por el contrario, cuando los datos no cambian con tanta frecuencia, puede utilizar reliable delta compression (compresión delta confiable) para ahorrar ancho de banda.
Cuando el servidor tiene autoridad total, los clientes sólo cambian el estado del juego según las actualizaciones que reciben del servidor. Un problema con esto es que el retraso introducido por la espera para que el servidor responda puede afectar el juego. Por ejemplo, cuando un jugador presiona una tecla para avanzar, no se moverán hasta que el estado actualizado sea recibido del servidor. Este retraso depende de la latencia de la conexión, por lo que cuanto peor sea la conexión, menos veloz será el sistema de control.
Una posible solución a esto es Client-side Prediction , que significa que el cliente predice la actualización de movimiento esperada desde el servidor usando aproximadamente el mismo modelo interno. Así que el jugador responde inmediatamente a la entrada pero el servidor ve su posición desde la última actualización. Cuando la actualización de estado llega finalmente desde el servidor, el cliente comparará lo que predijo con lo que realmente sucedió. Esto puede ser diferente porque el servidor puede saber más acerca del entorno en torno al player, el cliente sólo sabe lo que necesita saber. Los errores en la predicción se corrigen a medida que suceden y si se corrigen continuamente, el resultado será más suave y menos perceptible.
Es posible aplicar el principio básico de la predicción del lado del cliente a los opositores del jugador. Extrapolation es el proceso de almacenar los últimos valores conocidos de posición, velocidad y dirección para un oponente y usarlos para predecir dónde debería estar en el futuro inmediato. Cuando la próxima actualización de estado llega finalmente con la posición correcta, el estado del cliente se actualizará con la información exacta, lo que puede hacer que el personaje salte de repente si la predicción era mala. En juegos FPS el comportamiento de los jugadores puede ser muy errático por lo que este tipo de predicción ha limitado el éxito. Si el retraso es lo suficientemente alto el oponente saltará severamente a medida que se acumulan los errores de predicción.
Interpolation se puede usar cuando los paquetes se caen en el camino hacia el cliente. Esto normalmente haría que el movimiento del NPC se detuviera y luego saltara a la posición más nueva cuando finalmente llegue el nuevo paquete. Retardando el estado del mundo en un tiempo determinado (como 100 ms) e interpolando entre la última posición conocida y la nueva, el movimiento entre estos dos puntos, donde se soltaron los paquetes, será suave.