¿Por qué es tan difícil construir un juego multijugador y qué podemos hacer para solucionarlo para todos?

Hola a todos, soy Asad Nehman. Voy a hablar sobre por qué es tan difícil crear juegos multijugador y qué podemos hacer para facilitarlo. Un poco de lo que quiero decir. Soy un desarrollador. Hago cosas. Específicamente, me gusta crear herramientas para desarrolladores y lo he estado haciendo durante más de 10 años. También fundé una empresa de IDE en línea en el pasado. También me gusta jugar juegos multijugador con mis amigos. Así que naturalmente me gusta hacer juegos multijugador. Digamos que quiero hacer un juego multijugador. Comencemos con el juego multijugador más simple y veamos qué desafíos enfrentamos. Lo primero que probablemente quieras hacer es obtener un juego de un solo jugador base, que luego convertirás en un juego multijugador. Este juego base probablemente tendrá un bucle de juego con él, y las partes multijugador pueden ser agregar más jugadores y alguna lógica al respecto, algunas competiciones y cosas así. Y lo primero que probablemente harías para convertir esto en un juego multijugador es agregar un backend a él. Y en el contexto de los juegos web, esto suele ser un servidor Node.js con algún tipo de framework de web socket como Socket.io. Entonces, probablemente quieras manejar las conexiones de los jugadores y almacenar esos jugadores en una matriz global dentro de tu aplicación Node.js, y de esta manera todos los jugadores pueden conectarse entre sí utilizando este backend de web socket, y esto funciona. Pero pronto te das cuenta de que también necesitas tener algún concepto de Salas en tu juego, en tu servidor. Entonces, lo que harían las Salas es asignar algún código de sala a algunos jugadores y lo que esto te permite hacer es conectar a cada jugador y a sus amigos entre sí. Entonces, todos los jugadores en todos tus juegos no están en la misma sala. Están en sus propias salas y las salas pueden comenzar y terminar en sus propios tiempos dependiendo de cuándo comiencen sus juegos. Así que suena como que estos dos jugadores están en sus propias salas y estos dos jugadores están en sus propias salas y solo pueden comunicarse dentro de sus propias salas. No pueden comunicarse con los jugadores de otras salas. Bastante simple. Y sí. Pueden usar este código de sala como un identificador de canal único a través del cual pueden comunicarse entre sí. La comunicación puede ser el estado del jugador y la posición del jugador, puntuaciones, todas esas cosas. Ahora, necesitas... Una vez que introduces los códigos de sala, necesitas una forma de compartir estos códigos de sala con otros jugadores. Esto puede ser algún tipo de interfaz de lobby que necesitas crear. La interfaz de lobby puede ser que el anfitrión inicie el juego, comparta el código de sala, enlace de sala, código QR con otros jugadores, y ese código QR o enlace de sala tendrá el ID de la sala incrustado en él, y cuando el otro jugador abra esta URL, se conectará automáticamente a la misma sala, y de esta manera pueden comunicarse entre sí. También necesitas alguna forma, alguna interfaz de usuario para permitir a los jugadores elegir sus avatares, sus colores, sus nombres, para tener alguna personalización, y para que puedan diferenciarse

entre los jugadores. Sí, y una vez que tienes eso, creas tu juego. Tu juego es esencialmente, transmites el estado del juego a los jugadores, y los jugadores transmiten su propio estado a los demás jugadores, y tu trabajo como creador de juegos es combinar esos estados, actualizaciones, y consumirlos, guardarlos localmente. Por ejemplo, un jugador puede moverse y compartir la posición al servidor WebSocket, y los otros jugadores pueden leer esa posición y actualizar al jugador en su propia pantalla, y viceversa. Entonces, básicamente lo que estás haciendo es mantener estas variables globales propias, que deseas sincronizar entre todos los jugadores. Y la mayor parte del código de red involucrado sería asegurarse de que estos estados estén sincronizados. Una vez que tienes eso, tienes un juego simple. Ahora, no puedes simplemente compartir este juego sin desplegarlo en algún lugar. Para desplegarlo, necesitas algún lugar para alojar este juego. Esto puede ser una instancia de AWS EC2, lo cual recomendaría. Puedes usar algún servicio como Vercel, Netlify, y lo que pueden hacer es alojar tu juego, escalar tu juego a nivel global, tener múltiples instancias ejecutándose de tu juego basado en el tráfico que llega a tu juego y una vez que eso sucede, te das cuenta del problema principal aquí.

El problema es que tus servidores están aislados. Supongamos que estoy conectado al servidor A aquí y uso algún código de sala para conectarme al servidor y comparto ese código de sala con mi otro amigo que está conectado al servidor B. Y ellos intentan usar el mismo código de sala pero no me ven. Eso se debe a que el servidor A y B no están interconectados entre sí. Por lo tanto, el estado que mantienen, bueno, los estados de las salas, la lista de salas que mantienen, no es la misma porque se ejecutan en un proceso completamente separado en todo el mundo. Y para resolver esto, lo que necesitas es básicamente conectarlos a una base de datos central, tal vez. Supongamos que los conectas a una base de datos. Redis es una buena opción para hacer esto. Entonces, Redis puede actuar como el backend del backend, que luego almacena todas las salas, los estados y las listas de jugadores y todo. Y todos estos servidores simplemente se sincronizan con esa base de datos central, Redis en este caso. Pero también necesitas desplegar este par de servidor y base de datos en todo el mundo porque tus usuarios pueden conectarse desde lejos y no deberían experimentar retraso en su juego. Entonces, lo que quieres es desplegar servidores cerca de ellos y también quieres desplegar la réplica de la base de datos cerca de ellos. Así que no ven retraso. Comienzas desarrollando un juego, pero ahora estás gestionando tu clúster y bases de datos. Eso no es lo que quieres hacer. Y cada desarrollador de juegos se enfrenta a una versión de esto al hacer juegos multijugador. Eso es mucho trabajo duplicado. No quieren gestionar todos estos servidores. Solo quieren hacer el juego. Afortunadamente, hay algunas alternativas mejores que simplemente escribir tu propio servidor. Por ejemplo, Unity tiene Photon o netcode para objetos de juego. Hay servicios como Hathora, Revit, Snapser que alojan un servidor de juegos para ti. Entonces, solo les das el código del servidor y ellos lo alojan por ti. También puedes usar Firebase como backend para juegos. Esto puede ser útil para juegos simples, juegos no arcade y juegos de fiesta. Estas opciones son geniales. Al menos son mejores que lo que hablamos antes. Pero aún así, tienes que escribir un montón de código no relacionado con el juego y código de servidor backend. También debemos hablar sobre otro código no relacionado con el juego que probablemente necesitarás hacer. Que es averiguar las conexiones punto a punto.

Las conexiones punto a punto. Por lo tanto, los mensajes no se envían a un servidor, en su lugar se envían directamente al otro jugador, lo que reduce la latencia para ti. Esto es absolutamente necesario para juegos de ritmo rápido. Probablemente también quieras agregar soporte para Gamepad para que los jugadores puedan jugar localmente, en pantalla dividida o en la televisión. También querrás hacer algún tipo de predicción del lado del cliente para los movimientos de los jugadores. Porque mientras se envía esta actualización, por ejemplo, para una posición a ese jugador, ese jugador no debería quedarse atascado en el espacio. Debería ver alguna forma de predicción sucediendo. Entonces, el jugador se mueve suavemente al siguiente paso. Entonces, hablamos con algunos estudios de juegos sobre su opinión sobre lo que proporciona la infraestructura actual y cómo se sienten al respecto. Y vimos un patrón común de que están gastando mucho tiempo y dinero en hacer estos juegos multijugador. Y sí, no debería ser así. Debería ser así. Entonces, repensemos cómo sería si no tuvieras que lidiar con ningún código no relacionado con el juego en tus juegos. Eso significaría simplemente no escribir ningún código de servidor en absoluto. Y sí, tampoco quieres escribir tu propio sistema de lobby y interfaces de usuario y gestionar perfiles de jugadores y todas esas cosas. ¿Qué tal si solo llamas a una función y te da la lista de jugadores en esta sala actual y simplemente comienza un juego con esa lista de jugadores? Y no tienes que preocuparte por todas las conexiones del lobby, los códigos QR, el estado de la sala, qué estado de la sala quieres sincronizar. Es solo una variable global a la que puedes establecer y obtener y se sincronizará automáticamente entre todos los jugadores en esta sala, por lo que no tienes que preocuparte por cómo obtener este estado del dispositivo A al dispositivo B. Por ejemplo, establezco el estado PUNTUACIÓN3 en el dispositivo A en el jugador A, y luego puedo intentar obtener la puntuación en otro dispositivo y obtener el estado actualizado aquí. Esa es la premisa detrás del marco llamado Playroom en el que estoy trabajando. Sí, veamos cómo funciona. Entonces, primero que nada, para usar Playroom lo que quieres hacer es instalar playroom-get y después de hacer eso llamas a esta función init() que llamamos insertCoin. Esto le dice a Playroom que comience, esto le dice a Playroom que inicie el sistema de lobby para que muestre la interfaz de lobby y desde allí maneja automáticamente toda la creación, unión, perfiles de jugadores y que los jugadores elijan sus propios colores y avatares y todas esas cosas. ¿Cómo? Veamos. Entonces, cuando llamas a insertCoin, el jugador ve esta interfaz de pantalla completa que llamamos la interfaz de lobby y los jugadores pueden, como dije, elegir sus avatares y colores y todo y también pueden invitar a otros jugadores para que puedan compartir el enlace a tu juego con esa URL única o simplemente el otro jugador puede escanear este código QR para unirse a la misma sala. Y el siguiente paso que quieres hacer es escribir una lógica de juego para que los jugadores se unan al juego y abandonen el juego. Entonces, por ejemplo, cuando un jugador se une al juego probablemente quieras agregar algún sprite para ellos en la escena y cuando se van quieres eliminar ese sprite de la escena. Y eso es unirse y abandonar el juego. La otra cosa que quieres manejar es el estado del juego en sí. Entonces, digamos que quieres tomar alguna entrada, hacer algún cálculo y actualizar la posición del jugador y una vez que hagas eso, los otros jugadores verán automáticamente esa nueva posición y actualizarán la posición del jugador.

En tu pantalla. Y esto sucede automáticamente. Solo tienes que configurar y obtener posiciones de las funciones de Playroom y esto es válido para las posiciones de los jugadores, la entrada, la salud, la puntuación, quién es el ganador, las clasificaciones y todas esas cosas. Y nuevamente, nunca escribiste ningún código de servidor para esto, solo instalas esto con npm e inicias en Playroom y luego estás configurando y obteniendo el estado. Eso es todo. Entonces, ¿cómo funciona esto detrás de escena? Supongo que el mayor secreto aquí es Cloud Play y DurableObjects. Cloud Play tiene nodos adicionales en todo el mundo y probablemente también tenga nodos adicionales dentro de tu ISP. Por lo general, estos están a unos 50 ms de distancia en términos de latencia. Y la otra cosa es DurableObjects, que es como un sistema de almacenamiento que Cloud Play proporciona y que te permite tener un almacenamiento consistente y de baja latencia en cualquier parte del mundo. Sí, eso es como el backend de Playroom.

Y repasemos el ciclo de vida de un rol. Cuando el primer jugador inicia un juego y el juego llama a insertCoin, lo que hace Playroom es mostrar la interfaz de CRM para el lobby y el perfil y todo. Y detrás de escena, Playroom crea una nueva sala para ellos y se conectan a esta sala. Y cuando comparten esta URL única con otros jugadores, ellos también se unen a la misma sala. Y luego, cuando el anfitrión hace clic en iniciar, simplemente se guarda la sala. Y Playroom gestiona el estado.

Y eso no es todo lo que hace Playroom. Playroom también proporciona una conexión secundaria para ti. Entonces, Playroom mantiene dos tipos de conexiones para ti. Uno es el socket TCP del que hablamos, que es confiable y pasa por los servidores de Playroom. Y tienen una latencia de 80 a 150 ms. El otro tipo de conexión es la conexión UDP o WebRTC que Playroom mantiene entre los jugadores. Entonces, en estas conexiones no se involucra ningún servidor de Playroom. Y estas utilizan WebRTC y son inherentemente no confiables. Eso significa que tu estado puede que no siempre llegue al otro extremo. Pero para algunos tipos de estados, esto está bien. Por ejemplo, para las posiciones de los jugadores, esto está bien porque probablemente estarás enviando la posición del jugador nuevamente en unos pocos milisegundos. Entonces, si te pierdes uno, no importa. Simplemente...

Si intentas enviar las posiciones de los jugadores utilizando websockets, lo que sucederá es que habrá un efecto de enlace de números allí arriba. Donde recibirán un montón de posiciones y los jugadores se quedarán atascados y avanzarán rápidamente. Y eso no es lo que quieres. Pero Playroom te permite decidir qué tipo de estado quieres enviar a través de qué tipo de conexión. Y para cada estado establecido, puedes decidir si quieres enviarlo a través de websockets o WebRTC. De lo contrario, Playroom decidirá por sí mismo en función de la calidad de la conexión y todas esas cosas. Compartimos Playroom con un grupo de desarrolladores de juegos y los comentarios iniciales han sido excelentes. Supongo que el enfoque de Playroom es hacer el SDK de múltiples capas más simple posible y el enfoque es que los desarrolladores de juegos no escriban ningún código que no esté relacionado con el juego. Y sí, los comentarios han sido buenos. Eso es todo de mi parte. Muchas gracias. Puedes obtener más información sobre Playroom y unirte a Playroom.com. También puedes seguirme en Twitter o escanear este código QR para seguirme en Twitter. Muchas gracias.