Conceptos del Sistema de Red

Servidor y Anfritrión

En el sistema de red de Unity, los juegos tienen un servidor y múltiplos clientes Dónde no hay un servidor dedicado, uno de los clientes juega el rol del servidor - nosotros llamamos este cliente el “anfitrión (Host)”.

El anfitrión es un servidor y un cliente en el mismo proceso. El anfitrión utiliza un tipo especial de cliente llamado LocalClient (cliente local), mientras otros clientes son RemoteClientes (clientes remotos). El LocalClient (cliente local) se comunica al servidor (local) a través de llamadas de función directas y colas de mensajes, ya que está en el mismo proceso. En realidad comparte la escena con el servidor. Los RemoteClientes (clientes remotos) se comunican con el servidor sobre una conexión regular de red.

Una meta del sistema de red es que el código para LocalClients y RemoteClientes es el mismo, entonces los desarrolladores solo tienen que pensar acerca de un tipo de cliente la mayoría de veces.

Instanciar (Instantiate) y generación (Spawn).

En Unity, GameObject.Instantiate crea nuevos game objects de Unity. Pero con el sistema de red, los objetos también deben ser “spawned (generados)” para estar activos en la red. Esto solamente se puede hacer en el servidor y causa los objetos en ser creados en clientes conectados. Una vez los objetos estén generados, el Spawning System (sistema de generación) hace la administración del ciclo de vida del objeto distribuido y la sincronización de estados.

Para más detalles ver Spawning.

Jugadores, Jugadores Locales y Autoridad

En el sistema de red, los objetos del jugador son especiales. Hay un objeto jugador asociado con cada persona jugando el juego, y los comandos son enrutados a ese objeto. Una persona no puede invocar comandos en un objeto jugador de otra persona - solamente en él mismo. Por lo que hay un concepto de “mi” objeto jugador. Cuando el jugador es agregado y hay una asociación hecha con una conexión, cuando un jugador es agregado y la asociación es hecha con una conexión, ese objeto jugador se vuelve un objeto “jugador local” en el cliente de ese jugador. Hay una propiedad isLocalPlayer que es configurada a true, y un callback OnStartLocalPlayer() que es invocado en el objeto en el cliente. El diagrama de abajo muestra dos clientes y sus jugadores locales.

Solamente el objeto jugador que es “suyo” tendrá la flag isLocalPlayer configurada. Esto puede ser utilizado para filtrar procesamiento de input, para manejar anexos de cámara, o hacer otras cosas del lado del cliente que solo deberían ser hechas para su jugador.

En adición a isLocalPlayer, un objeto jugador puede tener su “local authority (autoridad local) ”. Esto significa que el objeto jugador en el cliente de su dueño es responsable para el objeto - este tiene autoridad sobre este. Esto es utilizado más común para controlar movimiento, pero puede ser utilizado para otras cosas también. El componente NetworkTransform entiende esto y va a enviar movimiento del cliente si esté está habilitado. El NetworkIdentity (Identidad de red) tiene una casilla de verificación para configurar LocalPlayerAuthority (Autoridad del jugador local).

Para objetos no jugadores, tal como enemigos, no hay un cliente asociado, por lo que la autoridad reside en el servidor.

Hay una propiedad “isAuthority” en el NetworkBehaviour (comportamiento de red) que puede ser utilizado para decir si un objeto tiene autoridad. Por lo que objetos no jugadores tienen autoridad en el servidor, y objetos jugadores con localPlayerAuthority configurado tienen autoridad en el cliente de su dueño.

Autoridad de Cliente para Objetos no jugadores

Comenzando con el release de Unity 5.2, es posible tener la autoridad de cliente sobre objetos no jugadores. Hay dos maneras para hacer esto. Una vez generar el objeto utilizando NetworkServer.SpawnWithLocalAuthority y pasar la conexión de red del cliente para tomar propiedad, y el otro es utilizar NetworkIdentity.AssignClientAuthority con la conexión de red del cliente para tomar la propiedad.

Asignar autoridad a un cliente causa OnStartAuthority() en ser llamado en NetworkBehaviours en el objeto, y la propiedad hasAuthority será true. En otros clinetes, la propiedad hasAuthority será falsa. Los objetos no-jugadores con autoridad de cliente puede enviar comandos, tal como los jugadores pueden. Estos comandos corren en la instancia del servidor del objeto, no en el jugador asociado con la conexión.

Los objetos no jugadores que tienen autoridad de cliente deben tener LocalPlayerAuthority marcado en su NetworkIdentity.

Este ejemplo de abajo genera un objeto y le asigna autoridad al cliente del jugador en el cual fue generado.

[Command]
void CmdSpawn()
{
    var go = (GameObject)Instantiate(otherPrefab, transform.position + new Vector3(0,1,0), Quaternion.identity);
    NetworkServer.SpawnWithClientAuthority(go, connectionToClient);
}

Propiedades del contexto de la red

Hay propiedades en la clase NetworkBehaviour que le permite a script saber cuál es el contexto de la red de un objeto en red en cualquier momento.

• isServer - true si el objeto está en un servidor (o anfritrión-host) y ha sido generado.
• isClient - true si el objeto está en un cliente, y fue creado por el servidor.
• isLocalPlayer - true si el objeto es un objeto jugador para este cliente.
• isAuthority - true si el objeto es propiedad del proceso local

Estas propiedades pueden ser vistas en la ventana de pre-visualización del objeto en la ventana del Inspector del editor.