Muchos de los puntos aquà mencionados ya se han tomado en cuenta en blogs anteriores, quizás hay algunos pocos a tomar en cuenta que son nuevos. La falta de memoria es la causa principal de que muchos juegos salgan disparados en móviles, generalmente esto ocurre por una falta de previsión y por desconocimiento de las capacidades del dispositivo.
Conocer cómo funciona la memoria en nuestro juego es algo muy difÃcil ya que es algo bastante cambiante, sobretodo si son juegos que cargan las escenas progresivamente, también es muy posible que al haber un aumento desmedido de enemigos, balas o partÃculas puede disparar un exceso de memoria, particularmente esto se hace muy difÃcil si exportas tu juego para WebGL.
Unity nos da algunas pistas con el profiler, en el apartado de memoria, en el puedes ver en qué apartados gastas mas memoria.
Evita la generación procedural en WebGL.
En dispositivos móviles como en webGl, la memoria es limitada, cargar elementos nuevos durante la existencia de una escena puede hacer que se agote rápidamente, ahora, nosotros no necesitamos que estos elementos estén en pantalla constantemente, por lo que lo logico seria destruir los elementos que no necesitamos. Perdón, ¿dije destruir?
Destruir no es muy buena idea, es mejor desactivar y trasladar al punto de la escena que necesitamos, esto aunque es más complejo permite mantenerlo en memoria, irónicamente liberar memoria cuesta memoria.
Haz escenas limitadas en espacio y carga.
Cuando somos novatos y queremos hacer juegos, tendemos a caer en el error de hacer escenas sandbox de mundo abierto, pero esto a la larga se traduce en un dolor de cabeza tremendo, la jerarquÃa se hace muy grande, más inmanejable, perdemos control de los diferentes assets, nos llenamos de texturas, materiales que no necesitamos, nuestro proyecto crece sin control.
En cambio cuando las escenas son más limitadas, puedes ver fácilmente que puede ser combinado, como hacer la escena mas tematica y poderse enfocar en los detalles que le dan más vida a la escena y por tanto mantener la memoria controlada.
Usa el tipo de dato necesario para el calculo necesario.
Si necesitas mucha precisión puedes elegir un dato tipo double en ves de float, en vez de elegir 3 o 4 datos flotantes para algún vector, es mejor usar un Vector3 o un Vector4 o si no existe mejor crear el tipo de dato a la medida, esto hará que en la memoria caché están ordenados contiguamente en vez de disperso.
Si por el contrario estás usando un array de booleanos, considera usar bytes como un array, esto es muy común en algoritmos como marching cubes, autómata celular y el juego de la vida, algoritmos muy comunes en juegos tipo roguelike.
Entregale la información mascada a la CPU y GPU.
Esto ya lo he repetido en varias ocasiones, aunque la CPU y la GPU está diseñado para cálculos, algunos cálculos se les sale de las manos, si tu ya sabes los resultados de algo o si el resultado es repetitivo, lo mejor es encapsular el resultado en algún tipo de dato, yo personalmente soy un entusiasta de encapsular cosas en texturas, las uso para efectos de olas, viento o influencia de algún tipo.
Descargar la memoria al finalizar las cargas.
Cuando cargas un asset desde la carpeta Resources.Load(); generalmente se nos olvida descargar la memoria con Resources.Unload Asset(); al igual que System.GC.Collect(); en momentos muertos del juego como después de guardar la partida, o en la pantalla de carga o en el menú de pausa donde esos tiempos muertos no afectan el juego.
Cargar texturas según la resolución del dispositivo.
Aunque este tema ya ha sido tratado en el apartado gráfico, este se trata de tener varios assets y cargar alguno dependiendo de la resolución de la pantalla del dispositivo, puede usarse pero yo discrepo de este punto, si vas a usar el mismo juego para una tablet o un móvil yo seleccionarÃa un intermedio entre ambos o directamente escogerÃa la imagen de más baja resolución.
Eliminar vértices en polÃgonos que sean innecesarios.
Este tema ya ha sido tratado en el apartado de gráficos, rediseñar el ciclo de vida de algunos assets; por ejemplo si hay elementos comunes que cargan en varias escenas como el personaje principal, algunos sonidos o texturas comunes, es mejor cargarlos silenciosamente en la pantalla de tÃtulo y cargar el resto de la escena cuando se necesite.
Cada escena debe contener pool de objetos especÃficos.
Aunque un pool de objetos es necesario, tampoco puedes cargar todos los objetos dinámicos en una escena, solo los necesarios, algunos pools de objetos hacen esto automáticamente en la tienda de unity.
Comprimir sonidos en memoria si es necesario.
Si algunos sonidos son de corta duración, comprimirlo supone un gasto al momento de descomprimirlos, asà que a menos que el sonido sea muy grande es mejor mantenerlo descomprimidos.
Este ha sido el final del viaje por ahora, la optimización de juegos tiene su ciencia y aún hay un largo camino, De momento lo dejaré aquà y espero que esta información le haya sido de utilidad, prometo que a medida que descubra nuevas cosas actualizará los blogs de rendimiento.
Hasta pronto.