El High Level API (API de Alto Nivel)
Configurando un proyecto Multijugador desde el principio

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 networking (redes) es que el código para LocalClients y RemoteClientes sea el mismo, para que los desarrolladores solo tengan 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 networking (redes), los objetos también deben ser “spawned (generados)” para estar activos en la red. Esto solamente se puede hacer en el servidor y causa que los objetos sean creados en los clientes conectados. Una vez los objetos estén generados, el Spawning System (sistema de generación) utiliza una administración del ciclo de vida del objeto distribuido y principios de sincronización de estados.

Para más detalles ver Spawning.

Jugadores, Jugadores Locales y Autoridad

En el sistema de redes, los objetos jugador son especial. Hay un objeto jugador asociado con cada persona jugando el juego, y los commands son enrutados a ese objeto. Una persona no puede invocar un command en un objeto jugador de otra persona - solamente en él mismo. Por lo que hay un concepto de “mi” objeto jugador. Cuando el jugador se agrega y hay una asociación 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 “hasAuthority” en el NetworkBehaviour que puede ser utilizado para decir si un objeto tiene autoridad. Por lo que objetos no jugadores tienen autoridad en el servidor, y objetos jugador con localPlayerAuthority configurado tienen autoridad en el cliente de su dueño.

Autoridad de Cliente para Objetos no jugadores

Comenzando con el lanzamiento de Unity 5.2, es posible tener la autoridad de cliente sobre objetos no jugador. Hay dos maneras para hacer esto. Una es generar el objeto utilizando NetworkServer.SpawnWithClientAuthority y pase la conexión de red del cliente para tomar propiedad. 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 clientes, la propiedad hasAuthority todavía será false. Los objetos no-jugador con autoridad de cliente pueden enviar commands, tal como los jugadores pueden. Estos commands son ejecutados 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.
  • hasAuthority - 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.

El High Level API (API de Alto Nivel)
Configurando un proyecto Multijugador desde el principio