¡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 Unity WebGL. Pero primero, permítanme contarles un poco sobre mí. Soy un ingeniero de productos en Crazy Games y también soy desarrollador de juegos. Pueden ver algunos de los juegos que he creado aquí. Principalmente trabajo con Unity, pero también tengo algunos juegos simples en JavaScript puro.

En Crazy Games, somos una de las plataformas de juegos más grandes, con más de 5000 juegos. Trabajamos con más de 700 desarrolladores y tenemos más de 20 millones de jugadores únicos. Ahora, hablemos de los problemas comunes en Unity web que puedes encontrar al crear juegos para la web. Estos problemas incluyen el tamaño del paquete, que afecta la velocidad de carga del juego, el uso de memoria y el rendimiento en tiempo de ejecución.

¿Por qué es importante mantener bajo el uso de memoria en tiempo de ejecución? Bueno, en el navegador, Unity utiliza un montón de memoria para almacenar los datos del juego. Si cargas una nueva escena, se deben cargar nuevas texturas y es posible que el navegador tenga que aumentar el tamaño del montón de memoria. Si el navegador no puede asignar más memoria para aumentar el tamaño del montón, aparecerá una molesta ventana emergente que hará que tu juego se bloquee.

No hablaré sobre el rendimiento del código aquí, ya que Oz ya dio una excelente presentación al respecto. Se llama Detectar y Evitar Problemas Comunes de Rendimiento y Memoria en Unity WebGL, y animo a todos a verla. En cuanto a Brotli y jZip, estos son dos formatos de compresión diferentes para la compilación en Unity. Nunca lances compilaciones sin comprimir, ya que ocupan alrededor de 11 MB. jZip, el formato predeterminado, ocupa un poco más de espacio que Brotli, por eso generalmente recomendamos a los desarrolladores que elijan Brotli, porque la diferencia puede ser pequeña en un proyecto vacío, pero a medida que tu juego crezca, esa diferencia solo aumentará. Así que, por lo general, es mejor elegir Brotli, aunque tarde un poco más en comprimir, vale la pena.

En cuanto al soporte de excepciones, al compilar un juego para la web, puedes elegir el soporte de no excepciones, que es más eficiente en términos de rendimiento, pero ya no podrás usar try-catch en tu código. Si sabes que necesitas usar try-catch en algún lugar, elige solo las excepciones que se lanzan explícitamente, que también es la opción predeterminada. Por lo general, debes evitar las excepciones completas, a menos que estés depurando el juego, ya que afectarán 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. El formato DXT es el predeterminado y es mejor para los navegadores de escritorio. También está ASTC, que es mejor para los navegadores móviles y algunos Chromebooks. Si eliges el formato de compresión adecuado, las texturas no tendrán que descomprimirse en memoria y el juego utilizará menos memoria en tiempo de ejecución. En esta captura de memoria pequeña, puedes ver que tenemos una compilación con seis texturas, todas bastante grandes. Si se descomprimen en memoria, ocuparán alrededor de 75 megabytes. Si se mantienen comprimidas, ocuparán alrededor de 10 megabytes. Básicamente, lograste ahorrar alrededor de 65 megabytes de memoria en tiempo de ejecución, lo cual es bastante considerable en un dispositivo móvil.

Hemos intentado experimentar con esto en algunos de nuestros juegos. Desafortunadamente, solo obtuvimos algunas mejoras de velocidad de carga y tiempo de carga insignificantes. Lo que hicimos fue tener dos compilaciones separadas y cargamos la versión DXT en todas las plataformas, o cargamos inteligentemente esta versión para probar en la plataforma necesaria. Como dije, no obtuvimos mejoras considerables, pero aún así, si tienes, por ejemplo, un juego que solo lanzas para dispositivos móviles, considera usar esta opción. O puedes consultar la documentación de Unity sobre cómo cargar dos compilaciones separadas, como hicimos en este experimento.

Sobre las opciones de textura. Así que presta atención al tamaño máximo aquí, porque debes mantenerlo lo más bajo posible en WebGL para reducir el tamaño final de la compilación. Si lo reduces, también reducirás el tamaño de la textura en la compilación final. También puedes considerar el uso de la compresión crunch, que ayudará a reducir el tamaño del paquete, pero solo funciona para estos dos formatos de compresión de textura, DXT y ATCM. Puede llevar un poco más de tiempo compilar el juego debido al aumento del tiempo de compresión, pero la descompresión es bastante rápida cuando se inicia el juego.

Sobre los modelos, en caso de que hayas habilitado esto, ten en cuenta que ahora el modelo debe 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. También verifica si puedes aumentar la compresión de malla a alta calidad, por ejemplo, porque es posible que tengas, digamos, una montaña en la distancia que no necesita ser de alta calidad.

Sobre el audio, si eliges la 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 bucles de música que ocupan bastante memoria. Pero esto puede reducir un poco la latencia y causar una reproducción de audio imprecisa. La descompresión y carga es mejor para los efectos de audio porque puedes mantenerlos descomprimidos en memoria. Por lo general, no ocupan mucho espacio, pero deben ser precisos cuando se reproducen. También considera reducir la calidad del audio de fondo, ya que 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 en Unity Asset Store, y también viene en nuestro SDK, te ofrece todas estas pestañas que te ayudarán a optimizar tus activos. También ofrece analizadores de registros de compilación. Para aquellos que no lo sepan, Unity generalmente genera un registro de compilación cuando se compila un proyecto, y es un archivo de registro feo y textual, pero esta herramienta lo embellecerá un poco y te mostrará de una manera más legible todos los activos. Y puedes echar un vistazo final a todos los activos que terminaron en tu compilación final. Sobre los Asset Bundles y otros símbolos, considera usarlos porque ayudan a reducir el tamaño de carga inicial. Cómo funcionan, básicamente extraen las texturas, por ejemplo, el audio, algunos objetos en un archivo separado que se carga solo cuando se necesita. Y puedes hacerlo con Asset Bundles, que es de bajo nivel, solo tienes que buscar el archivo y extraer los activos de él, pero Unity ahora tiene un paquete llamado Addressables que se basa en Asset Bundles y es mucho más fácil de usar. Aquí puedes ver un ejemplo de un juego que utiliza Addressables y el tamaño de compilación inicial para la carpeta de compilación es de alrededor de 17 megabytes. La carpeta StreamingAssets se cargará más tarde cuando sea necesario, tiene alrededor de 16 megabytes. Por lo tanto, el desarrollador logró ahorrar alrededor de 16 megabytes en 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 los problemas de memoria, si deseas una descripción general 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, el audio, en la memoria en tiempo de ejecución. Eso fue todo de mi parte, gracias por escucharlo y no dudes en consultar nuestra documentación donde tenemos más consejos para Unity. También puedes contactarnos en developerrelations at crazygames.com. Esperamos ver tus juegos en crazygames.com. ¡Adiós!