El plugin multijugador del Construct 2
El diseño general de un juego multijugador en Construct 2 se ve algo así.
Flujo de un juego multijugador
El ciclo de vida de un juego multijugador irá algo como esto:
1. Conectar al servidor de señalización e iniciar sesión.
2. Unirse a una sala
3. Otros clientes pueden unirse y dejar el juego mientras este corre.
4. Los datos de objetos y otros mensajes como el chat son intercambiador con otros clientes.
5. Eventualmente el juego termina, todos dejan la sala, y quizás buscan por una nueva (de nuevo al paso 2).
Nótese que el juego termina si el host se desconecta. Ellos están actuando como el servidor del juego, así que si se desconecta entonces el juego ya no puede correr. Esta es una razón para considerar correr el juego en un host dedicado en un servidor central, particularmente para juegos grandes con muchos jugadores. Sin embargo no hace diferencia para juegos de dos jugadores - el juego terminaría de todos modos si el otro jugador se marcha.
El plugin multijugador tiene características cubriendo las fases de señalización (pasos 1 y 2), así como las características de la 'sala' cubriendo el juego en sí mismo, cosas como desencadenadores para cuando un cliente se une o se marcha, mensajes recibidos, etc.
Resumen del Diseño
Se pretende que los juegos se diseñen con un tipo de objeto representando ambos los objetos controlados por los jugadores y todos los otros jugadores en el juego. entonces el mismo objeto es usado equitativamente por todos en el juego, incluyéndote a ti (e incluso siendo el host), es recomendable nombrar a este objeto Cliente (Peer), debido a lo que representa. Si tienes jugadores compuestos de múltiples objetos, como un arma y cuerpo separados, crea un objeto Cliente básico y pon en un contenedor los otros objetos. Esto asegura que los jugadores son creados y destruidos como un todo, y que sus objetos relacionados se recogen automáticamente en eventos con el objeto base, así que puedes tratar al objeto base como representante de todo el jugador.
Ambos, el host y los clientes están corriendo el mismo proyecto. Esto significa que tu proyecto debe poder manejar eventos para ambos el host, que tiene la versión autoritaria del juego, y los clientes, que están viendo una versión retrasada y sólo pueden enviar sus entradas. La vía más conveniente para manejar esto es tener dos grupos dedicados al Host y al Peer, y poder activar únicamente el apropiado luego de unirse a una sala y determinar cuándo te conviertes en host.
La acción Sync object del objeto multijugador es la vía fundamental para indicar que quieres enviar datos acerca de objetos sobre la red. Esto le dice al host que envíe la información acerca de estos objetos a los clientes, y les dice que esperen a recibir información acerca de esos objetos. El motor multijugador automáticamente crea y destruye objetos que representan clientes cuando estos se unen y se marchan (la acción Sync object también puede ser usada por otros objetos que no representan clientes, pero son usados comúnmente por ellos).
Cada cliente tiene una ID de Cliente asignada por el servidor de señalización. Esto es una cadena con una corta secuencia de caracteres aleatorios para identificarlos por separado. Los IDs de los clientes son generalmente usados para poder referirse consistentemente al mismo jugador incluso si su alias cambia. La ID de cliente necesita ser guardada en una variable de forma que sepas a que cliente está representado determinado objeto. Cuando un objeto de un cliente es creado en el motor, la expresión Multiplayer.PeerID es puesta a su ID de cliente, de forma que puede ser guardada en su variable de instancia. Debido a que controlas tu propio objeto de cliente, podrías fácilmente determinarlo al probar si su variable de instancia es igual a Multiplayer.MyID, y luego modificando sólo esa instancia.
Modos de Confiabilidad
La última cosa para mencionar es que hay 3 formas de transmitir datos. Éstos intercambian confiabilidad por rendimiento.
El modo más confiable es Ordenado confiable (Reliable ordered), éste envía un mensaje que es rastreado: Si es dejado por la red, será re-enviado hasta que verifique que ha llegado a su destino. Incluso ordena mensajes, de forma que se garantice que lleguen en el mismo orden al que fueron enviados. Esto es útil, pero no es el más rápido: si un mensaje es dejado y sostenido, mantendrá todos los mensajes siguientes hasta que ese mensaje logre pasar. Lo que también significa que los mensajes individuales puede tomar múltiplos de la latencia para llegar ya que debe esperar al menos tiempo de ida y vuelta para saber si el mensaje llegó. Esto es generalmente sólo es recomendable para mensajes de baja frecuencia y poca importancia como los mensajes de conversación (chat).
El siguiente más rápido es el Confiable desordenado (Reliable unordered). Éste envía un mensaje que es rastreado, y será re-enviado hasta que se verifique que ha llegado a su destino. Sin embargo, los mensajes pueden llegar en cualquier orden. Esto previene que un sólo mensaje sea mantenido retrasando todos los mensajes siguientes - Puede simplemente llegar tarde, después de mensajes que originalmente fueron enviados después. Sin embargo, mensajes individuales todavía pueden tomar múltiplos de la latencia para llegar. Esto es recomendable para eventos de juego que deben llegar pero no están relacionados con otros, como abrir una puerta o una explosión.
El modo más rápido es Poco fiable (Unreliable). Esto envía un sólo mensaje y se olvida de él. Si es dejado, el mensaje simplemente nunca llegará a su destino. Puede que incluso llegue en un orden distinto a la secuencia en la que originalmente estaba, y puede que posiblemente llegue duplicado. Generalmente es más recomendable para mensajes regulares, donde es más importante que el mensaje llegue tan pronto como sea posible que si llega en absoluto. Si es dejado, será seguido rápidamente por el siguiente mensaje con nuevos datos, así que no importa. Nótese que el motor internamente utiliza este modo para objetos sincronizador con interpolación construida y características de compensación, así que no intentes replicar esa funcionalidad con este modo.
¡Listo para empezar!
A pesar que el plugin multijugador de Construct 2 maneja muchos detalles técnicos por ti como la predicción de entradas y conectividad, todavía es muy importante conocer la teoría para poder tomar las decisiones correctas acerca de qué datos son enviados a dónde con precisión y que modo de confiabilidad. Con suerte este tutorial te ha dado una visión general suficiente para empezar a diseñar tu primer juego multijugador con un buen entendimiento de qué está ocurriendo detrás de las escenas, y que necesitar hacer en Construct 2 para sacar el mayor provecho de sus características. A pesar que este tutorial se ha centrado en la teoría, los siguientes tutoriales cubrirán como abordar problemas como la predicción de entradas y la compensación del lag en la práctica usando características específicas del plugin multijugador.
¡Si estás listo para aprender más, continua con Multiplayer tutorial 2: chat room!