¡Mejora el Rendimiento de Tus Juegos WebGL Unity!

Hola a todos, mi nombre es Florin, y hoy hablaré sobre cómo mejorar el rendimiento de tus juegos de WebGL Unity. Un poco sobre mí. Soy ingeniero de producto en Crazy Games, también soy desarrollador de juegos. Puedes ver un par de los juegos que he creado aquí. Principalmente trabajo con Unity, pero también tengo algunos juegos simples en vanilla JS.

En Crazy Games somos una de las plataformas de juegos más grandes, tenemos más de 5000 juegos, trabajamos con más de 700 desarrolladores y también tenemos 20 millones de jugadores únicos. Así que sí, comencemos con los problemas web de Unity que puedes encontrar al construir para la web. Está el tamaño del paquete, que afecta la rapidez con la que se carga tu juego, el uso de memoria, la RAM que básicamente usa tu juego cuando se ejecuta, y el rendimiento en tiempo de ejecución. ¿Y por qué es importante mantener bajo el uso de memoria en tiempo de ejecución? Bueno, en el navegador, Unity utiliza un heap de memoria para almacenar los datos del juego. Y digamos que cargas una nueva escena, se necesitan cargar nuevas texturas, el navegador puede tener que aumentar el tamaño del heap. Y si un navegador no puede asignar más memoria para aumentar el tamaño del heap, obtendrás este feo popup que simplemente bloquea tu juego.

Sobre el rendimiento del código, no hablaré de eso aquí, así que Oz ya dio una excelente presentación sobre ello, se llama Detect and Avoid Common Performance and Memory Issues in Unity WebGL y animo a todos a que la vean. Sobre Brotli y jZip, estos dos son dos formatos de compresión diferentes para la compilación en Unity. En primer lugar, nunca lanzan compilaciones sin comprimir porque ocupan alrededor de 11MB, el jZip, el predeterminado, ocupa un poco más de espacio que el Brotli, por lo que generalmente recomendamos a los desarrolladores que elijan el Brotli, porque puedes ver la diferencia, puede ser bastante pequeña en un proyecto vacío, pero cuando tu juego se hace más grande, esta diferencia solo se hará más grande. Así que sí, generalmente quédate con el Brotli, aunque toma un poco más de tiempo para comprimir, pero vale la pena.

Sobre el soporte de excepciones, cuando construyes un juego para la web, puedes elegir el soporte sin excepciones esto es más eficiente, pero ya no puedes usar try-catch en tu código. Si sabes que tienes que usar try-catch en algún lugar, elige solo las excepciones lanzadas explícitamente que creo que también es el predeterminado. Y generalmente, deberías evitar las completas, excepto si estás depurando el juego, porque afectará negativamente el tamaño del paquete y el rendimiento de tu juego. También me gustaría hablar sobre el formato de compresión de texturas, que puedes elegir. Dext es el predeterminado y este es mejor para los navegadores de escritorio. También está ASTC que es mejor para navegadores móviles y algunos Chromebooks. Y si eliges el formato de compresión adecuado, las texturas no tienen que ser descomprimidas en memoria y el juego usará menos memoria en tiempo de ejecución. Puedes ver aquí en este pequeño snapshot de memoria, tenemos una compilación con seis texturas, todas bastante grandes, y si se descomprimen en memoria, ocuparán alrededor de 75 megabytes. Si permanecen comprimidas, ocupan alrededor de 10 megabytes. Así que básicamente lograste ahorrar alrededor de 65 megabytes de memoria en tiempo de ejecución, eso es bastante en un dispositivo móvil. Intentamos experimentar esto también con un par de nuestros juegos. Lamentablemente, solo obtuvimos algunas mejoras insignificantes en la tasa de carga y el tiempo de carga. Y cómo lo hicimos, tenemos dos compilaciones separadas, y cargamos la DXT en todas las plataformas o cargamos inteligentemente esta para probar en la plataforma necesaria. Y como dijimos, no obtuvimos mejoras considerables, pero aún así, si tienes, por ejemplo, un juego que lanzas solo para dispositivos móviles, considera usar este, por ejemplo. O puedes consultar la documentación de Unity sobre cómo cargar dos compilaciones separadas, como hicimos con este experimento.

Sobre las opciones de textura. Así que presta atención al tamaño máximo aquí, porque deberías mantener esto lo más bajo posible en WebGL para reducir el tamaño final de la compilación. Si lo reduces, esto también reducirá el tamaño de la textura en la compilación final. También puedes considerar usar compresión crunch, ayudará a disminuir también el tamaño del paquete, pero solo funciona para estos dos formatos de compresión de texturas, DXT y ATCM. Puede tomar un poco más de tiempo construir el juego porque el tiempo de compresión se incrementará, pero la descompresión es bastante rápida cuando inicias el juego.

Sobre los modelos, en caso de que hayas habilitado este, ten en cuenta que ahora el modelo necesita mantenerse en el uso de memoria en tiempo de ejecución, por lo que es mejor mantenerlo desactivado, creo que por defecto también está desactivado. Y también verifica si puedes aumentar la compresión de malla a alta, por ejemplo, porque puedes tener, digamos, una montaña en la distancia que no necesita ser de alta calidad.

Sobre el audio, si eliges memoria comprimida, eso suele ser bueno para el audio de fondo. Reduce el uso de memoria en tiempo de ejecución, y los audios de fondo suelen ser algunos bucles de música que ocupan bastante memoria. Pero esto puede reducir un poco la latencia y causar una reproducción de audio imprecisa. Descomprimir y cargar, es mejor para efectos de audio porque puedes mantenerlos descomprimidos en memoria. Usualmente no ocupan mucho espacio, pero necesitan ser precisos cuando se reproducen. También considera bajar la calidad del audio de fondo, porque esto puede reducir considerablemente el tamaño del audio en la compilación final. Nuestra herramienta de optimización que puedes obtener en GitHub, o Unity Asset Store, y también viene en nuestro SDK, te ofrece todas estas pestañas, te ayudarán a optimizar tus activos. También ofrece analizadores de registros de compilación. Para aquellos que no lo saben, Unity generalmente genera un registro de compilación cuando construyes un proyecto, y es un archivo de texto feo, un archivo de registro, pero esta herramienta lo embellecerá un poco y te mostrará de una manera más legible todos los activos. Y puedes tener una vista final de todos los activos que terminaron en tu compilación final. Sobre Asset bundles y otros símbolos, considera usarlos porque ayudan a disminuir el tamaño de carga inicial. Cómo funcionan, básicamente extraen las texturas, por ejemplo audio, algunos objetos en un archivo separado que se carga solo cuando es necesario. Y puedes hacerlo con Asset Bundles que es de bajo nivel, simplemente obtienes el archivo y extraes los activos de él, pero Unity ahora tiene un paquete Addressables que se construye sobre Asset Bundles y es mucho más fácil de usar. Puedes ver aquí un ejemplo de un juego que usa Addressables y el tamaño inicial de la compilación para la carpeta de compilación es de alrededor de 17 megabytes. La carpeta StreamingAssets se cargará más tarde cuando sea necesario, es de alrededor de 16 megabytes. Así que el desarrollador logró ahorrar alrededor de 16 megabytes de la carga inicial del juego.

No puedo terminar esta presentación sin hablar un poco sobre la herramienta integrada Profiler que creo que todos deberían usar para detectar los problemas de rendimiento y los problemas de memoria. Pero para problemas de memoria, si quieres una visión un poco más detallada, hay un nuevo paquete de Unity llamado Memory Profiler tool. Te ayudará a capturar instantáneas de tu juego en ejecución, también puede conectarse directamente a WebGL, y luego te ayuda a analizar las texturas, por ejemplo, del audio en la memoria de tiempo de ejecución.

Así que, eso fue todo de mi parte, gracias por escucharlo, y no dudes en consultar nuestra documentación donde tenemos más consejos para Unity. Y también puedes contactarnos en developerrelations at crazygames.com.