Dentro de la infraestructura de red multijugador de Survival Kids

Este verano, Survival Kids se lanzó como un lanzamiento del día uno para Nintendo Switch™ 2. El juego fue construido completamente en Unity 6, marcando el primer proyecto de desarrollo de extremo a extremo de Unity, trabajando en estrecha colaboración con el socio editor KONAMI.

Desarrollar para una nueva plataforma en el Día 1 es un gran desafío, pero el pequeño equipo interno que construyó este proyecto incluía desarrolladores de Unity experimentados, muchos de los cuales han estado trabajando en Unity y en juegos durante décadas. Este blog es parte de una serie en curso que profundiza en cómo se hizo el juego, cómo este trabajo alimentó el compromiso de Unity con verificación de producción, además de lecciones que otros desarrolladores de juegos de Unity pueden tomar y aplicar a sus propios proyectos.

Esta es la primera entrega de una serie en curso detrás de las escenas que profundiza en las lecciones del equipo al trabajar en Survival Kids.

Nintendo Switch es una marca registrada de Nintendo.

Survival Kids fue construido por un equipo muy pequeño dentro de Unity. El grupo central era de aproximadamente 10 desarrolladores de diversas disciplinas (artistas, ingenieros y diseñadores). En nuestro punto máximo, éramos alrededor de 20 a medida que personas de otros equipos de Unity se unieron. Por ejemplo, Steven, nuestro ingeniero de renderizado, trabajó mucho con nosotros, pero no siempre estuvo en el proyecto.

Como equipo pequeño, teníamos algunas ventajas, sin embargo. Los ingenieros eran muy experimentados: la mayoría de nosotros hemos estado escribiendo juegos durante unos 20 años, principalmente en el espacio AAA, así que hemos aprendido muchas lecciones y hemos cometido muchos errores. Y, por supuesto, somos realmente experimentados en Unity porque la mayoría de nosotros hemos estado aquí durante algún tiempo.

Algunos de nosotros también hemos trabajado en proyectos de clientes como parte de equipos de soporte de Unity como Servicios Profesionales/Soluciones Aceleradas, ahora Producciones de Unity Studio. Asesoramos a los clientes sobre cómo optimizar sus proyectos e incluso nos integramos con equipos de proyectos para trabajar junto a ellos y ayudar a resolver sus difíciles problemas técnicos, así que estamos bastante familiarizados con los errores que los estudios suelen cometer y cómo solucionarlos. Al trabajar en Survival Kids, pudimos arquitectar el proyecto y ponerlo en el camino correcto desde el principio porque sabíamos dónde estarían todas las trampas, y eso nos ahorró mucho tiempo y recursos.

Hoy, quiero profundizar en la arquitectura de red del juego. Usamos Unity para impulsar la red multijugador, y Survival Kids ofrece a los jugadores varias formas diferentes de jugar el juego, todo desde la misma base de red. Así que profundicemos en cómo se unió esto, y con suerte algo de esto puede ayudarte en tus proyectos también.

Survival Kids se puede jugar de varias maneras: un jugador, cooperativo local y en línea con amigos. En la Nintendo Switch™ 2, los jugadores también pueden usar GameShare para transmitir el video a otra Nintendo Switch 2 o incluso a una Switch original, y luego jugar en modo multijugador con alguien en la TV o un dispositivo, lo cual es realmente genial.

Queríamos que nuestra configuración impulsara todo eso y otras combinaciones. Por ejemplo, podrías tener dos jugadores jugando en pantalla dividida en una televisión que está conectada a otros dos jugadores jugando en pantalla dividida en otra TV, así que cuatro jugadores usando dos dispositivos. Esa flexibilidad era algo que realmente queríamos diseñar en la arquitectura para permitir jugar de muchas maneras diferentes.

Para hacer esto, decidimos usar Netcode for Entities. Una vez que presentamos el concepto de Survival Kids a KONAMI, pasamos directamente a la creación de prototipos para encontrar la diversión en nuestro juego multijugador. Usamos un proyecto existente como punto de partida, uno que había escrito previamente como prueba de concepto de cómo podríamos usar Netcode for Entities como una red de backend, y luego escribir una capa de GameObject encima para aprovechar Prefabs y animaciones. No todos en el equipo tenían experiencia trabajando con Entities, así que decidimos usar GameObjects y MonoBehaviour juntos.

También queríamos mantener la lógica del juego en GameObjects y MonoBehaviours porque hacen que sea muy fácil prototipar; esta configuración te permite juntar cosas y escribir scripts y descargar scripts de internet o usar paquetes de Asset Store para prototipar. Queríamos esa rápida iteración y libertad, pero también nos gustaba que Netcode for Entities nos proporcionara una capa de red eficiente. Ya lo había usado en algunos proyectos de clientes y proyectos de investigación personal, así que sabía que su nivel de calidad podría impulsar el nivel de juego que queríamos.

Cuando comenzamos, hace unos tres años, Netcode for GameObjects existía, pero aún le faltaban algunas de las características que queríamos, especialmente la predicción del lado del cliente. Con la predicción del lado del cliente, si hay un retraso entre el servidor y el cliente, el cliente predice lo que el servidor va a hacer y lo hace instantáneamente, así que los controles de los jugadores se sienten responsivos incluso cuando hay retraso. No tienes que esperar a que el servidor te diga que un jugador se ha movido o lo que sea; ya lo estás haciendo. Eso es algo que Netcode for Entities tuvo desde el principio.

Para prototipar, básicamente tomamos un proyecto que ya teníamos y nos lanzamos. Comenzamos con cosas simples: recoger objetos, talar árboles, y gradualmente comenzamos a desarrollar lo que sería parte de la jugabilidad. Todavía estábamos prototipando, así que no nos preocupamos demasiado por la calidad del código. Estábamos tratando de encontrar la diversión y mirando nuestros pilares del juego, incluyendo "supervivencia para todos." Queríamos un juego de supervivencia, pero no queríamos que fuera super difícil o punitivo; estábamos tratando de destilar lo que realmente es divertido y emocionante sobre este género.

Nos preguntamos: ¿Qué les encanta a las personas sobre la elaboración y la recolección de recursos? ¿Qué no les importa? Eso nos ayudó a definir cómo los jugadores obtienen recursos, cómo los mueven de un lugar a otro, cómo hacen la elaboración. Descubrimos todo eso prototipando e iterando bastante rápido usando GameObjects y MonoBehaviours.

Porque comenzamos desde esa pequeña demostración de prueba de concepto, pudimos conectarnos por dirección de internet, desde el principio. Era posible conectarse usando una IP de computadora, pero también usamos el servicio de Relay de Unity, que te permite alojar un juego en un servidor Relay en la nube. Con Relay, cualquiera puede unirse a ese juego usando un código de unión, y las personas pueden conectarse desde casa o la oficina sin una VPN o IP conocida. Eso significaba que podíamos entrar en un ritmo de pruebas de juego semanales; y las estábamos haciendo en el trabajo y en nuestras redes domésticas, lo que nos permitió probar nuestra arquitectura de red junto con la jugabilidad con todo tipo de diferentes velocidades de conexión. Al final, mantuvimos Relay en producción.

Intentamos mantenernos lo más cerca posible de los paquetes publicados públicamente. Si encontrábamos un error en uno de los paquetes, lo identificábamos, llevábamos el paquete localmente y tratábamos de solucionarlo. A veces íbamos a Slack después y enviábamos un mensaje al equipo de Netcode de Unity para explicar el problema y nuestra solución para que pudieran tomar eso y hacer los PR; y a veces conseguirlo en la versión final. No estábamos involucrados en la solución necesariamente, pero al trabajar en un entorno de producción, encontramos algunos problemas que ellos aún no habían encontrado (aunque a veces ya tenían una mejor solución que la que se nos había ocurrido, o nos decían que lo estábamos usando mal).

Debido a que desarrollamos de esta manera, de forma remota a través de Relay, no añadimos un modo fuera de línea hasta más tarde, cerca del lanzamiento. El modo fuera de línea no abre ningún socket de red, y utiliza algo llamado un controlador en proceso. Efectivamente se comporta como si fuera una red, con un servidor y un cliente, pero se ejecutan en el mismo proceso y se comunican entre sí. En lugar de enviarlo a través de la red, lo envían directamente al cliente. Se llama una conexión en proceso, y es muy rápida porque no tienes que esperar a que los bytes reales viajen a través de la red, pero pasa por todo el mismo flujo que nuestro juego.

Trabajando de esta manera, no necesitábamos codificar una versión diferente – esta es nuestra modalidad para un solo jugador y nuestra modalidad multijugador. Un jugador y fuera de línea siguen siendo un juego en red, solo que no usamos la red – todo sucede internamente.

Esto básicamente significaba que teníamos una arquitectura de código que podíamos usar en todas partes. El costo de eso, sin embargo, es que cuando estás alojando o en un solo jugador, estás simulando el servidor y el cliente, creando un desafío de rendimiento para ejecutar ambos al mismo tiempo. Con servidores dedicados, un servidor podría irse y vivir en una granja de servidores en algún lugar, así que todo lo que necesitas es lo que se llama el cliente, que hace que todo se vea bien y responda a lo que el servidor está comunicando. Pero en un solo jugador, ya que estamos simulando, el juego tiene que hacer ambas cosas y no puede simplemente estar en un servidor dedicado en algún lugar.

Eso terminó siendo uno de nuestros mayores desafíos de rendimiento, optimizando para que el servidor y el cliente pudieran estar en el mismo juego, en el mismo fotograma, y aún así alcanzar nuestro objetivo de 60 fotogramas por segundo a una buena resolución. Ese objetivo era realmente importante para nosotros.

Consulta las otras entregas de nuestra serie de blogs para profundizar en Survival Kids producción:
- "Consejos de gráficos y renderizado de Survival Kids"
- "Diseño de niveles y flujos de trabajo de terreno en Survival Kids"

Estén atentos para la cuarta y última publicación de la serie, parte 2 de nuestra historia multijugador, que profundiza en cómo desarrollamos esta arquitectura de red para habilitar el juego en pantalla dividida y GameShare en Nintendo Switch 2.

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