Red de pantalla dividida y GameShare en Survival Kids

Este verano, Unity lanzó su primer juego, creado en estrecha colaboración con el socio editor KONAMI. Survival Kids es una actualización llena de diversión del clásico juego para niños que se lanzó como título de día uno para Nintendo Switch™ 2.

El juego fue construido completamente en Unity 6, por lo que el equipo de desarrollo estaba trabajando con un nuevo software para lanzar el juego en una nueva plataforma, un gran desafío. Además, el juego se puede disfrutar en una variedad de configuraciones de red, por lo que el pequeño equipo de Unity que trabajaba en el proyecto tuvo que construir una arquitectura multijugador robusta que soportara estas opciones.

Consulta la primera entrega de la historia de redes multijugador para Survival Kids, donde compartimos cómo se unieron los fundamentos detrás de la arquitectura de red del juego. Esta publicación amplía esta base para mostrar cómo el equipo construyó la pantalla dividida y las capacidades de GameShare de Nintendo Switch 2.

Nintendo Switch es una marca registrada de Nintendo.

Después de haber resuelto muchos de los problemas en la arquitectura de red del juego, comenzamos a pensar en cómo íbamos a hacer la pantalla dividida, que no se proporciona de forma predeterminada en Netcode for Entities. Este fue un desafío diferente. Con la pantalla dividida, tiene que haber más de un jugador, pero esos jugadores pertenecen a un cliente.

Netcode for Entities asume que hay un jugador por cliente; si hay un juego separado, con una consola separada conectándose a él, entonces tiene un jugador. Cuando eso cambia y hay en realidad dos o tres jugadores, no hay forma de enviar la entrada para cada jugador individual. Tienen que ser enviados como uno.

Efectivamente creamos un jugador de entrada virtual que nadie puede ver. Es totalmente invisible, pero recoge toda la entrada de todos los jugadores locales, hasta cuatro de ellos (aunque al final no hicimos pantalla dividida para cuatro jugadores). Gestiona toda la entrada que llega y luego envía toda esa entrada al servidor cada cuadro.

En el juego, los jugadores no gestionan su propia entrada. El jugador de entrada virtual imaginario les dice cuál es la entrada para un cuadro. Anteriormente, Netcode for Entities asume que un jugador es responsable de obtener su entrada y usar su entrada para hacer todo su movimiento, pero aquí hay este otro jugador que no hace ningún movimiento pero sostiene toda la entrada para todo lo demás.

La pantalla dividida fue el principal desafío desde el punto de vista de la red. Para evitar tener un problema de múltiples cámaras, comenzamos teniendo un segundo jugador que corría mientras la cámara se quedaba con el primer jugador. Eso se juntó bastante rápido, pero luego encontramos otros problemas, como ¿cómo configurar una segunda cámara? ¿Cómo mantener una cámara a la izquierda de la pantalla y la otra a la derecha de la pantalla? También tuvimos que resolver problemas de interfaz de usuario, porque hay bastante interfaz de usuario que solo un jugador puede ver. Por ejemplo, si un jugador está frente a un tronco, vería un pequeño botón de aviso que dice: "Oye, presiona X para recoger este tronco", pero por supuesto no quieres que el otro jugador lo vea.

Tuvimos que averiguar cómo ocultar la interfaz de usuario para que si el otro jugador está cerca, no la vea. Usamos capas para eso, pero nuestra solución estaba más relacionada con la interfaz de usuario que con la red. Habíamos decidido que, en última instancia, queríamos bloquear el juego a dos jugadores en pantalla dividida para una mejor experiencia de juego; incluso si está en una pantalla grande, solo puede haber dos jugadores locales. Podríamos hacer cuatro en una pantalla dividida internamente, y mantuvimos eso durante bastante tiempo porque era una gran manera de probar el rendimiento, ya que cada jugador agrega un poco más de procesamiento, un poco más de renderizado, otro jugador para simular.

Una de las características durante el desarrollo para Nintendo Switch 2 es GameShare. Estás enviando efectivamente un video a otra consola; realmente, es solo pantalla dividida desde una perspectiva de red, excepto que el sistema envía una cámara a otra consola en lugar de renderizarla en una pantalla.

Nuestra pantalla dividida para cuatro jugadores fue la base de cómo abordamos el modo GameShare. Podríamos conectar tantos jugadores como quisiéramos siempre que el rendimiento esté bien y podamos transmitir video a esa consola. La razón principal por la que no queríamos hacer pantalla dividida para cuatro jugadores era solo por el tamaño de la pantalla, realmente. A menos que tengas un televisor enorme, es realmente difícil ver las ventanas; pero si tienes tu propia consola, el video puede transmitirse a esa.

Nos esforzamos mucho por diferenciarnos de nuestro modo de pantalla dividida para dos jugadores para poder soportar un tercer jugador extra en GameShare. Puedes tener un anfitrión y dos invitados mientras ofreces a los jugadores una gran experiencia y un rendimiento fluido. No estábamos dispuestos a bajar nuestros estándares en eso, pero aún así pudimos usar la arquitectura de pantalla dividida para potenciar GameShare.

Una característica realmente útil que añadimos fue un comando de depuración. Tenemos un menú de desarrollo, así que puedes presionar un botón, llamar al menú y luego escribir comandos en él. Esto fue útil porque nos permitió ejecutar un montón de cosas de depuración; todo está compilado fuera del juego final, así que, por supuesto, nadie podría hacer eso en el juego final que la gente compra y juega. Pero uno de los modos que teníamos en pantalla dividida era que podías duplicar al jugador principal; esto te permitía tener una pantalla dividida donde un controlador controla a ambos jugadores. Era una gran manera de probar la pantalla dividida sin necesidad de tener un montón de controladores alrededor, y esto facilitó las pruebas.

La configuración de pantalla dividida también ejecutaba efectivamente todo el código de red normal que hicimos. Dado que los jugadores estaban separados entre sí, el servidor enviaría información para mostrar cómo funciona el juego en línea. Pero también es posible probar si el código funcionaba en modo multijugador sin conectar a un jugador a otro cliente, iniciando el modo de pantalla dividida con otro controlador en el Editor para jugar allí. No hay necesidad de hacer una nueva compilación ya que es posible probar el código en pantalla dividida como un proxy para un juego en línea normal.

Había otras dos herramientas de Unity que encontramos realmente útiles, aunque no las usamos hasta justo al final del proyecto. Unity 6 incluye nuevas herramientas de Modo de Juego Multijugador, que nos permite probar sin una compilación de jugador separada.

Al abrir el Editor, toma más de una hora hacer una compilación limpia de jugador porque hay tanto arte y otra información, así que probar el código con un jugador remoto significa esperar al menos ese tiempo. No es particularmente bueno para iterar. Pero el Modo de Juego Multijugador te permite efectivamente abrir otra ventana, como otra versión virtual del Editor, y conectarte de esa manera.

Netcode for Entities también tiene herramientas de Modo de Juego para simular malas conexiones de red. Puedes especificar y simular un nivel específico de ping; digamos, un ping de 300 milisegundos, un viaje de ida y vuelta realmente horrible para simular cómo sería jugar con un amigo que conectó su teléfono a su laptop en un aeropuerto y se conectó al juego de esa manera. Luego puedes probar eso en el Editor para averiguar cuán retrasado o inestable es. A veces eso no funciona en una conexión de red que está perdiendo datos y perdiendo paquetes, y pudimos simular eso fácilmente.

Esta prueba sucedía todo el tiempo. Durante un tiempo, tuvimos una regla que nadie podía jugar en el Editor con el simulador apagado; todos tenían que jugar con algún tipo de retraso simulado, ya que ninguno de nuestros jugadores iba a jugar en una conexión perfecta. De esa manera, nunca podríamos engañarnos a nosotros mismos creyendo que una conexión de banda ancha de oficina de alta velocidad era representativa.

Al final, todas estas pruebas valieron la pena: pudimos ofrecer un juego fluido y eficiente a 60 fps en redes y configuraciones multijugador realmente diferentes. Desde el lanzamiento del juego hace unas semanas, hemos visto a los jugadores continuar participando en línea a través de Lobby y Relay, disfrutando de una experiencia de juego fluida y robusta, independientemente de las condiciones de su red doméstica.

Consulta las otras entregas de nuestra serie de blogs sobre Survival Kids producción:
- "Consejos sobre gráficos y renderizado de Survival Kids"
- "Diseño de niveles y flujos de trabajo de terreno en Survival Kids"
- "Dentro de la infraestructura de red multijugador de Survival Kids"

Para aprender más sobre proyectos hechos con Unity, visita la página de Recursos.