Optimizing Deep Rock Galactic Survivor for mobile

¿Qué se necesita para llevar un juego complejo de PC a los jugadores de dispositivos móviles? Juegos de Funday Roca Profunda Galáctica: Sobreviviente Combina un sistema de juego de disparos frenético con los enanos, las clases, las armas y las mecánicas de excavación de Deep Rock Galactic . El reto para la empresa de desarrollo Piktiv consistía en gestionar miles de enemigos y componentes ambientales simulados simultáneamente, manteniendo al mismo tiempo una velocidad de fotogramas estable en un hardware con una fracción del presupuesto de GPU, CPU y memoria.

Para ofrecer esa experiencia en dispositivos móviles fue necesario reelaborar los sistemas cuyo coste aumenta en función del número de enemigos: búsqueda de rutas, consultas físicas, renderizado de enemigos, cálculo de daños y renderizado del entorno. El equipo también tuvo que adaptar el juego a un iPad de 3 GB, ser compatible con una amplia gama de dispositivos, desde los buques insignia actuales hasta hardware Android de hace años, y mantener una fusión unidireccional con una rama PC que aún estaba en desarrollo activo.

Hablamos con el gerente de ingeniería Marcus Ekelund y el ingeniero principal Fredrik Åkerblom sobre la portabilidad. Roca Profunda Galáctica: Sobreviviente en el ámbito móvil, sus soluciones personalizadas y cómo optimizaron el rendimiento en un panorama de dispositivos fragmentado.

¿Cuáles eran sus principales objetivos técnicos al desarrollar la versión para móviles?

Fredrik Åkerblom: Muchos de los objetivos técnicos que teníamos de antemano eran simplemente: ¿Podemos hacer que esto funcione en dispositivos móviles? ¿Y a qué cantidad de dispositivos podemos llegar? Si nos fijamos en los productos de Apple , no existe un nivel de detalle muy amplio al que se pueda realizar el envío. Está lo más moderno, luego una categoría un poco más amplia que incluye mucho de lo que está disponible actualmente, y luego está todo lo demás. Quieres alcanzar al menos esa categoría intermedia.

Uno de los problemas recurrentes para nosotros era que todos esos dispositivos tienen 4 GB de RAM, excepto un iPad que tiene 3 GB. Así pues, ese se convirtió en un objetivo técnico fundamental: ¿Podemos hacer que funcione en este iPad sin que se bloquee? Teníamos aproximadamente 1.850 MB para trabajar, y si superábamos ese límite, se acababa el juego. Gran parte del trabajo inicial consistió simplemente en optimizar la memoria RAM, y después de eso pudimos analizar con más detalle el rendimiento real del juego en diversas plataformas. Por otro lado, Android cuenta actualmente con unos 9.000 dispositivos diferentes, por lo que garantizar que todo funcione correctamente es todo un arte.

¿Cuáles fueron los mayores cuellos de botella de rendimiento con los que te encontraste al pasar del hardware de PC al hardware móvil, y cómo los superaste?

FÅ: Hubo algunos sistemas centrales que realmente destacaron, y fueron aquellos con miles de objetos activos: Los valores de daño, los proyectiles, el mundo en sí y los enemigos animados en 3D .

Los textos de daño, por ejemplo, eran originalmente un GameObject creado con TextMesh Pro . Pero cuando tienes mil enemigos en pantalla y les lanzas una granada, ahora todos ellos deben mostrar un número de daño. El cuello de botella reside en la generación de la malla de texto: Que la fuente convierta tu cadena de texto en algo visual.

Al final, utilizamos un sistema de partículas Unity estándar con una hoja de sprites con los números del 0 al 9.

ME: Otro ejemplo fue la búsqueda de rutas de todos los enemigos, que utilizó el sistema NavMesh integrado en PC. También contamos con el apoyo de un equipo de ingenieros de Unity , y uno de ellos comenzó a trabajar en una solución que utilizaba la navegación por campos de flujo. Otro ingeniero creó una solución basada en árboles KD para optimizar y eliminar gran parte de las consultas de física.

FÅ: Con la representación de enemigos, tenemos algo así como mil renderizadores de malla con piel en la pantalla al mismo tiempo, y eso realmente no funciona. Resulta que prácticamente todos estos enemigos tienen una sola animación, así que en realidad no necesitamos compatibilidad con múltiples animaciones.

En cambio, este sistema utiliza una técnica en la que cada fotograma clave de la animación se integra en una textura. Recorremos cada fotograma de esa manera, y luego todos ellos son animados por vértices mediante un sombreador en la GPU, por lo que prácticamente no hay coste de CPU.

Reducirlo a una única malla estática y una textura supuso una gran mejora, y también permite hacer cosas como la instanciación de GPU , ya que técnicamente todas son la misma malla con el mismo material.

¿Cómo funcionan internamente los campos de flujo y los árboles KD, y qué reemplazaron?

FÅ: El campo de flujo es una inversión de dónde reside el costo para la búsqueda de rutas. Normalmente, cuando tienes 20 o 30 agentes buscando rutas a través de un entorno, creas una malla de ese entorno y cada agente es responsable de su propia búsqueda de rutas. Cuando tienes miles de ellos, eso se convierte en un cuello de botella bastante grande, porque el coste tiende a aumentar en proporción al número de agentes.

Se crea una cuadrícula que abarca todo el nivel, se empieza por el objetivo deseado y todas las casillas que lo rodean dibujan una flecha que apunta hacia ese objetivo. Da un paso hacia afuera, apunta las flechas de nuevo hacia el objeto más cercano que ya tenga una flecha, y continúa hasta que hayas cubierto todo el campo. En lugar de tener un coste por agente, se basa en el tamaño del área dentro de la cual se desea realizar la búsqueda de rutas.

También puedes limitarlo aún más. Calculamos en función de la ubicación de los enemigos, por lo que creamos un cuadro delimitador que contiene a todos los enemigos más al jugador, y solo actualizamos el espacio dentro de ese cuadro.

Para las consultas espaciales, utilizamos un árbol KD. Si tienes una habitación grande y trazas una línea por el centro, de repente la has dividido en dos espacios. Se crea una estructura de árbol que se puede consultar con bastante facilidad: Aquí tienes un punto y un radio, dame lo que haya ahí.

Eso podría reemplazar muchas de las consultas de física más complejas, como cuando una granada ha explotado aquí y necesito encontrar a todos los enemigos en este círculo. No estoy seguro de que al final haya sido la solución perfecta, porque el árbol de KD tiene que regenerarse mucho: los enemigos están en constante movimiento, por lo que el árbol de KD tiene que reconstruirse con frecuencia.

¿Cómo abordaste las pruebas y los ajustes en los diferentes dispositivos móviles?

FÅ: Una de las primeras cosas que hicimos fue determinar qué dispositivo debía funcionar correctamente con el juego: un dispositivo de gama bastante baja en el que queríamos al menos 30 fps.

Hemos creado un sistema automático de medición del rendimiento en el que podemos configurar una serie de escenarios. Realizamos un total de seis escenarios en Roca Profunda Galáctica: Sobreviviente . Podemos diseñar el juego específicamente en este modo de medición, y tan pronto como se inicie en un dispositivo, entrará en un bioma y ejecutará esos seis escenarios.

Una opción podría ser partir de una base en la que el jugador permanece quieto, y luego generamos mil enemigos que se mueven hacia él, o bien generamos 500 enemigos y lo equipamos con todas esas armas y disparamos automáticamente en todas direcciones. Eso nos da una idea general de lo que está sucediendo, y medimos la CPU, la GPU, la memoria, prácticamente todo lo que podemos medir. Lo analizamos en todos los biomas para poder comprobar si alguno presenta problemas de rendimiento específicos.

Unity Profiler fue una de nuestras principales herramientas para las auditorías de rendimiento de la CPU, sobre todo al principio, cuando buscábamos las soluciones más sencillas y las mayores mejoras.

¿Cómo ayudó Addressables a gestionar el contenido y el consumo de memoria en dispositivos móviles?

FÅ: Las Addressables fueron una parte importante para alcanzar el límite de memoria de 3 GB en el iPad. En general, desde el principio abordamos los temas que nos parecieron más sencillos. Por ejemplo, en los diferentes biomas nunca estás en más de un bioma a la vez, así que puedes desplegar todos esos recursos gráficos y configuraciones.

Los Addressables introducen un comportamiento asíncrono en algo que antes era completamente síncrono, y reconstruir un sistema completo para que sea asíncrono puede suponer un gran desafío arquitectónico, dependiendo del juego. Pero en este caso, era la opción adecuada para nosotros.

¿Qué indicadores de rendimiento ha utilizado para medir el éxito de la versión móvil?

FÅ: La mayoría de nuestros objetivos estaban relacionados con el rendimiento: En estos modelos queremos alcanzar los 30 fps, en estos modelos insignia esperamos 60 fps.

En Roca Profunda Galáctica: Sobreviviente Cada vez que matas un insecto, aparecen un montón de cubos azules brillantes que puedes recoger para subir de nivel. Uno de nuestros escenarios de medición automática generó alrededor de 4.000 de esas mediciones en 10 segundos, lo que supuso un grave problema de rendimiento desde el principio. Tras realizar esa optimización inicial, ya no era posible medirlo.

La optimización del movimiento y la física de los enemigos también aumentó significativamente el rendimiento mínimo de FPS. Eso se convirtió en campos de flujo, así como en una larga cadena de trabajos de Burst (de 10 o 15 dependencias) responsables de mover a todos los enemigos, todo fuera del sistema físico habitual.

Este juego genera sus niveles de forma procedural, por lo que la planta baja y todas las paredes se construyen a partir de objetos individuales. Dado que disponemos de una cámara cenital con el mismo ángulo en todo momento, podemos calcular fácilmente el área donde podemos ver los objetos, reunirlos todos y enviarlos al motor de renderizado mediante nuestros propios comandos de dibujo por lotes. Supuso una gran mejora tanto para la GPU como para la CPU, ya que enviar todas esas llamadas de dibujo individualmente suponía un coste bastante elevado para la CPU.

¿Cuál es tu mejor consejo para los desarrolladores que buscan adaptar su juego de PC a dispositivos móviles?

ME: No se trata tanto de encontrar la solución mágica, sino siempre de la colaboración entre diferentes sistemas.

FÅ: El coste de transferir datos entre los distintos componentes empieza a ser muy elevado cuando se procesan miles de entidades en cada fotograma. Si puedes gestionar tus datos de forma que todos estén en contenedores nativos y utilices esos mismos contenedores nativos durante todo el proceso, puedes obtener grandes beneficios.

ME: Otra conclusión que se puede extraer de este proyecto: Imagina que tienes un juego y, una vez terminado, te das cuenta de que probablemente deberías haberlo desarrollado utilizando ECS para Unity o cualquiera de los sistemas de la pila de tecnología orientada a datos (DOTS) . No es necesario que conviertas por completo todo tu juego y lo reescribas. Solo estamos utilizando el compilador Burst y muchos de los tipos de datos nativos.

Roca Profunda Galáctica: Sobreviviente Está disponible en Steam, en Xbox , en la App Store y en Google Play . Consulta más historias de desarrolladores de Unity en el Unity y el centro de recursos de Unity.