Construyendo Westeros para dispositivos móviles en Juego de Tronos: Fuego de dragón

Para Warner Bros. Para Games Boston, llevar el mundo de Westeros a los dispositivos móviles requería algo más que adaptar una franquicia muy querida. Con La Casa del Dragón como su fundamento, Game of Thrones: Fuego de dragón Combina estrategia multijugador a gran escala y combates con dragones en una experiencia gratuita diseñada para dispositivos móviles modernos.

Los jugadores asumen el papel de un descendiente valyrio encargado de incubar, criar y comandar dragones, mientras compiten con miles de otros jugadores por el control del Trono de Hierro. Para hacer realidad esa fantasía, fue necesario encontrar un equilibrio entre gráficos de alta calidad, rendimiento escalable y sistemas multijugador en tiempo real compatibles con una amplia gama de dispositivos.

Hablamos con Ara Yessayan, director técnico, y Taia Lee, artista técnica avanzada, sobre la creación de dragones para dispositivos móviles, el soporte para juegos de estrategia a gran escala y el uso de Unity para dar vida al mundo de Poniente.

¿Cuáles fueron sus principales objetivos y limitaciones para la experiencia de la primera sesión del jugador?

Ara Yessayan: En la primera sesión, queremos mantener al jugador entretenido y evitar cualquier tiempo de inactividad que pueda interrumpir su inmersión. Es importante introducir gradualmente los conceptos básicos de nuestro juego y la historia que tenemos que contar en el mundo de "La Casa del Dragón".

¿Qué estrategias has utilizado para minimizar los tiempos de carga tanto para los jugadores nuevos como para los que regresan, y en qué se diferencian estas experiencias?

AY: En una instalación nueva, el objetivo es requerir la menor cantidad de datos posible por adelantado. Hemos explorado técnicas para reducir la cantidad de datos que necesitamos descargar o cargar en la memoria antes de que los jugadores accedan al inicio de nuestra experiencia, así como el uso de transiciones como oportunidades para cubrir parte de esas cargas. Para un jugador que regresa, necesitamos más datos para completar su estado de jugador y ubicarlo en el lugar correcto en el mapa. Si bien la premisa es similar (minimizar el tiempo de espera de los datos), las técnicas se centran más en los costos de deserialización y en formas estratégicas de requerir menos recursos iniciales.

¿Cómo identificaste los principales cuellos de botella en el tiempo de carga durante el desarrollo?

SÍ: Para abordar los tiempos de carga, utilizamos varios enfoques. Para tener una idea general de dónde se encontraban nuestros cuellos de botella, configuramos eventos de perfilado personalizados para cada etapa de nuestro proceso de carga, que se escribieron en un archivo CSV. Agregamos los valores de varias sesiones para identificar qué etapas eran los puntos críticos. También transformamos estos datos en eventos de seguimiento de Chrome y seguimientos de OpenTelemetry para poder visualizar mejor cómo se cargaban las etapas en paralelo.

A partir de ahí, nos centramos en una etapa específica. El módulo de CPU de Unity Profiler nos proporcionó una visión más profunda del código ineficiente que podíamos optimizar. En algunos casos, grabar varios perfiles y utilizar el Analizador de perfiles de Unity nos ayudó a evaluar cómo el ajuste de algunos valores de carga mejoraba (o degradaba) los tiempos de carga.

El analizador de rendimiento de la CPU resultó muy útil a la hora de explorar fotogramas con grandes interrupciones, investigando las causas de las caídas en la velocidad de fotogramas y ayudándonos a encontrar mejores técnicas.

Más allá de la carga, el módulo de renderizado nos ayudó a analizar las ineficiencias en el renderizado una vez que estábamos dentro del juego, y RenderDoc fue otra herramienta que utilizamos cuando necesitábamos realizar un análisis más profundo sobre un problema de tiempo de ejecución.

Finalmente, para que las sesiones pudieran continuar, teníamos que asegurarnos de que nuestro consumo de memoria se mantuviera bajo control. Mediante instantáneas del Generador de perfiles de memoria , identificamos cargas innecesarias de recursos y objetos, especialmente en las zonas del mapa y las marchas, lo que a su vez redujo los requisitos de carga para acceder al juego.

¿Cómo utilizaste el analizador de memoria de Unity para analizar el uso de memoria del paquete de recursos, incluyendo la detección de duplicados y la verificación de la descarga de recursos? ¿Podrías compartir un ejemplo concreto?

Taia Lee: Normalmente utilizamos el analizador de memoria para identificar casos en los que los recursos se cargan en puntos inesperados del juego y permanecen en la memoria. Por ejemplo, esto puede ocurrir cuando una textura se utiliza en varios lugares pero reside en un único paquete, lo que provoca que se cargue todo el paquete cuando solo se necesita esa textura.

Esta es otra razón por la que nuestro objetivo es crear paquetes compartidos específicos para evitar esto. Esta herramienta también resulta útil para detectar los mayores problemas de memoria, especialmente aquellos de los que quizás no éramos conscientes o que son más importantes de lo esperado.

¿Cuáles fueron los problemas de rendimiento más inesperados con los que te encontraste al principio, en particular los relacionados con la entrega de contenido y el rendimiento del juego?

SÍ: Una de las sorpresas fue la cantidad de memoria necesaria para cargar los datos del archivo de mapas que indicaban el diseño del mapa. En Game of Thrones: Fuego de dragón Los jugadores utilizan sus ejércitos y dragones para capturar territorios (casillas) en el mapa. Estas opciones ayudan al jugador a reunir recursos y a limitar a dónde puede enviar sus ejércitos, basándose en el requisito de que él u otro miembro de su facción posea una casilla adyacente.

Sabíamos que necesitábamos dividir los datos del mapa en fragmentos para cargar el contenido. Los datos eran necesarios para que el juego comprendiera qué había en cada coordenada, especialmente teniendo en cuenta los datos adicionales que necesitábamos almacenar para los nodos que abarcan varias casillas. La carga de todas las estructuras asociadas a un mapa de 2000×4000 consumió suficiente memoria como para provocar el bloqueo de algunos dispositivos.

A medida que avanzábamos con las mejoras y optimizaciones para cargar solo las partes relevantes del mapa en lugar del mapa completo, este trabajo redujo significativamente los tiempos de carga para nuestros jugadores recurrentes.

Otra técnica que utilizamos para optimizar aún más el mapa consistió en reemplazar los GameObjects que representaban el terreno en el mapa con la representación directa de las mallas. Esto nos permitió evitar los costes de memoria que supone instanciar esos GameObjects. Combinar esto con la carga estratégica de solo las mallas y los modelos necesarios para el área circundante mejoró tanto el rendimiento de entrada al mapa como el de desplazamiento.

¿Cómo se decide qué contenido debe estar disponible en el lanzamiento y qué se puede transmitir o cargar posteriormente?

SÍ: El primer paso consiste en identificar qué necesitamos para la experiencia de usuario inicial (FTUE, por sus siglas en inglés) antes de que los jugadores entren en la fase multijugador de nuestro juego. Esto nos da la oportunidad de descargar cualquier dato que los jugadores utilicen cuando accedan al juego completo.

Existen otros tipos de contenido relacionados con operaciones en vivo o funciones de fase avanzada que también se pueden descargar más adelante en el proceso. Queremos asegurarnos de que los jugadores puedan disfrutar del juego en cuanto se encuentren con un sistema.

En futuras cargas, se trata de encontrar un equilibrio entre cargar elementos por adelantado (lo que puede aumentar el tiempo de carga) y lo que cargamos de forma asíncrona (lo que podría activar un indicador de carga antes de acceder a una pantalla o área). Continuamos trabajando en esta área para encontrar la mejor experiencia de usuario posible.

¿Cómo estructuraste y automatizaste tu proceso de creación de paquetes de recursos para equilibrar el tamaño de la descarga, el uso de la memoria y la flexibilidad en tiempo de ejecución?

TL: Por lo general, nuestro objetivo es que nuestros paquetes de recursos no superen los 8 MB, con algunas excepciones que dependen de los casos de uso y de los recursos necesarios en un paquete. Esto nos llevó a estructurar los paquetes de manera que los recursos que se utilizan habitualmente juntos durante la ejecución estén disponibles al mismo tiempo.

Por el contrario, evitamos los paquetes extremadamente grandes en los que solo se utiliza una parte de los activos. Disponemos de paquetes organizados por área del juego, característica o tipos de recursos compartidos. Por ejemplo, tenemos diferentes biomas en nuestro mapa y cada bioma tiene elementos separados que se adaptan a esa ubicación específica.

No necesitamos agrupar las montañas nevadas del norte con las montañas desérticas del sur. Sin embargo, algunas mallas y texturas se comparten entre biomas, por lo que esos recursos se incluyen en un paquete compartido.

Se trata de un equilibrio que requiere comprender cómo se utilizan los recursos a lo largo del juego para mantener un rendimiento óptimo. Como ocurre con cualquier juego en directo, se trata de un proceso continuo que debemos revisar y reorganizar a medida que se añaden más funciones.

SÍ: Antes del lanzamiento de Addressables, desarrollamos internamente un conjunto de herramientas para ayudarnos a abordar muchos de los problemas que Addressables ahora resuelve. Algunas de esas herramientas internas potencian nuestra capacidad para comprender la composición de nuestros paquetes y permiten técnicas avanzadas para descargar parches y actualizarlos (a esto lo llamamos "Parcheo Binario").

¿Qué inconvenientes o desafíos ha encontrado al trabajar con paquetes de activos y cómo los ha abordado?

TL: El mayor desafío al que nos enfrentamos es que el tamaño de los paquetes de recursos puede aumentar drásticamente si alguien edita un prefab existente o agrega muchos recursos nuevos sin darse cuenta del impacto potencial en el tamaño y la organización del paquete.

Hemos tenido casos en los que los paquetes aumentaban en más de 5 MB a la vez sin que la gente lo supiera, y en el peor de los casos, esto hizo que nuestro archivo .aab superara nuestro límite de tamaño para el envío a la tienda. Desde entonces, hemos añadido alertas a nuestro proceso de compilación para detectar estos casos y hemos ayudado a los desarrolladores a comprender mejor cuándo sus cambios podrían aumentar el tamaño de los paquetes de forma inesperada.

¿Cómo se gestionan las dependencias de los recursos para evitar descargas redundantes y un uso innecesario de la memoria?

TL: En nuestra herramienta interna de gestión de paquetes de activos, podemos observar activos duplicados en diferentes paquetes. En general, no queremos ver muchos recursos duplicados, especialmente los de mayor tamaño, por lo que añadimos esos recursos directamente a un paquete en lugar de permitir que se incluyan como dependencia desde varios paquetes. Tenemos que asegurarnos de que se añada a un paquete que pueda utilizarse en varios lugares, pero normalmente creamos un paquete compartido aparte.

¿Qué técnicas has utilizado para reducir los picos de uso de la CPU o los retrasos causados ​​por la deserialización de recursos durante el inicio de la aplicación?

SÍ: Una de las técnicas que utilizamos para nuestros datos de diseño consiste en usar el formato Protocol Buffers (Protobuf) para el almacenamiento en lugar del formato JSON habitual. Protobuf (el formato binario utilizado por gRPC) ofrece un almacenamiento más compacto y una deserialización más rápida.

Al utilizar un archivo de esquema estructurado asociado, podemos cargar datos en la memoria mucho más rápido sin analizar el contenido de las cadenas JSON ni tokenizar su estructura. Exploramos otras opciones como BSON y Odin Serializer para almacenar y deserializar datos de forma más eficiente, pero la posibilidad de usar gRPC para comunicarnos con nuestros servidores de manera más eficiente hizo que fuera la opción correcta para nosotros.

La gestión eficaz de los hilos de ejecución también es fundamental. Identifica qué tareas puedes trasladar fuera del hilo principal de Unity para que puedas centrarte en cargar los recursos y las escenas en el único lugar donde puedes realizar ese trabajo.

¿Cómo se optimizan el tamaño de las compilaciones y los procesos de implementación para garantizar actualizaciones de contenido y parches más rápidas?

SÍ: Utilizamos varias técnicas. Ante todo, nos centramos en lograr el equilibrio adecuado entre los recursos necesarios integrados en el binario del juego y aquellos que podemos descargar posteriormente. Nuestro juego incluye un tutorial que se completa en pocos minutos, lo que nos permite descargar recursos adicionales según sea necesario sin interrumpir a los jugadores en su primer inicio de sesión.

Aprovechar la función Play Asset Delivery de Android también nos ha ayudado a disponer de más recursos desde el principio. Comenzamos a integrar tablas de datos dinámicos seleccionadas en el cliente del juego, con la expectativa de que parte de esa información estaría desactualizada. Al descargar únicamente las tablas que habían cambiado, redujimos el tiempo de carga.

A partir de ahí, implementamos nuestra técnica de parcheo binario, que nos permite descargar diferencias binarias más reducidas y parchear los archivos modificados en lugar de descargar directamente la nueva versión. También podemos usar esto con paquetes de recursos, actualizando el contenido del juego según sea necesario para los nuevos eventos en vivo.

Mirando hacia atrás, ¿cuál fue el cambio más significativo que implementaste para mejorar los tiempos de carga para los jugadores?

SÍ: La respuesta sencilla es asegurarse de que los jugadores carguen solo lo que necesitan. Antes del lanzamiento preliminar, identificamos el mapa como uno de los principales cuellos de botella en los tiempos de carga. En aquel momento, el juego cargaba todos los recursos del mapa por adelantado antes de que comenzáramos nuestras optimizaciones para mostrar solo las regiones alrededor de la base del jugador.

Identificar lo que necesitábamos e implementar técnicas para cargar el resto de forma asíncrona posteriormente eliminó varios segundos de tiempo de carga incluso en dispositivos de gama alta. Nuestro equipo cumplió con la misión de mejorar los tiempos de carga para los jugadores y nos encaminó hacia una mejor experiencia de usuario, y no puedo agradecerles lo suficiente por su arduo trabajo.

Para obtener más información sobre proyectos realizados con Unity, visite la página de Recursos .