Hemos creado un mundo, AVA, relativamente pequeño. O eso pensamos nosotros. De momento, para cubrir las necesidades de la narrativa de la versión demo. Inicialmente eran 4km cuadrados aproximadamente. Pero hemos tenido que dejarlo en solo 2km cuadrados. Suficiente para explorar, perderse y recorrerlo en unos cuantos minutos.
En AVA hemos recreado un subconjunto de las características del planeta Tierra. Modificadas. Pero siguiendo su espíritu. Desde la atmósfera hasta la flora, pasando por zonas de presiones, zonas climáticas, biomas y diferentes minerales y plantas. Cada uno de ello con sus características dinámicas que evolucionan con el paso del tiempo. Ciclos de día y noche, estaciones y años.
Esto implica muchos pero que muchos actores. La emoción de construirlo y ver cómo funciona nos produce una gran satisfacción. Tanta que se nos olvidó el coste computacional.
Resultado: se atraganta en algunos momentos y situaciones en nuestros equipos de desarrollo. Ahora que ya tenemos la demo lista para que la juguéis, pensamos que quizás era mejor darle una vuelta al rendimiento para evitaros esa sensación. O, al menos, aliviarla.
Y eso es en lo que hemos estado trabajando esta semana.
Hasta esta semana utilizábamos las sombras tal cual. Pensando que al ser un entorno pequeño no era necesario profundizar más. Error. La luz y, por tanto, las sombras están cambiando constantemente por el ciclo día y noche. Y el sistema calculaba eso para todo el mundo y los actores que hay en él, estuvieran o no visibles para el jugador. No hemos cuantificado el dolor que produce, pero si hemos sentido su alivio al cambiar este enfoque.
Es algo obvio. Pero hasta que no lo necesitas, no piensas en ello. Lo que el jugador no ve, requiere luz ni sombras. Por ello, hemos ajustado la distancia de la cámara para que el motor solo calcule aquello que está en ese campo de visión, ahorrándole el resto. Y se nota. También hemos bajado la calidad. Y yo, que soy un poco exquisito con ese tema, no lo he notado.
AVA es un planeta vivo. Eso significa que todos los actores deben actualizarse y evolucionar. Hemos construido una malla hexagonal para facilitar la gestión de ellos. Y uno de las cosas que les afecta es el propio clima, personalizado según el bioma, la estación del año o si es de día o de noche. Un ejemplo es la temperatura. De día hace más calor que de noche. Hicimos varias pruebas y vimos que lo más equilibrado era hacer el cálculo al anochecer y al amanecer. Esto hace que en esos momentos se produzca un pico computacional que el jugador en movimiento percibe.
Dado que tenemos la malla, cada hexágono gestiona a los actores que contiene, y se encarga de solicitar esa info al actor que gestiona el planeta. Es decir, había una petición por cada hexágono y, en esa petición, iba ese objeto actor planeta completo ocupando mucha memoria. Cuando eran pocos actores pasaba desapercibido, pero ahora, se ha explicitado ese problema.
La solución es hacer una petición única al actor planeta y luego trabajar con referencia a dicho objeto. Solo esto ya ha supuesto un ahorro significativo del consumo de memoria y ha hecho que las transiciones día y noche sean fluidas.
Otra vez la malla. En concreto los actores que la componen. Como consecuencia del problema 1, pensamos que lo mismo que las sombras, para qué queríamos tener activos todos los actores del planeta si no intervenían ni en la visión ni en la acción del jugador. Decidimos con el mismo buen criterio solo activar los actores que tuvieran impacto directo en el jugador por cercanía. Los otros siguen evolucionando a nivel lógico pero sin estar activos y sin consumir memoria. Este enfoque nos ha supuesto otro gran ahorro computacional.
Pero, en este caso, el beneficio escondía un problema. ¿En qué momento activar y desactivar?Correcto, al traspasar el límite del hexágono para entrar en él. Y, al hacerlo, se producía el mismo efecto de ralentización que en las transiciones día y noche.
¡Oh, qué casualidad! No solo era el mismo efecto sino también la misma causa porque la información que se requiere para activar/desactivar reside en el actor planeta. Aplicamos la misma solución: dejamos de trabajar con objetos y pasamos a referencias.
¿Quién lo diría? La fruta se convirtió en un problema. Concretamente el exceso de fruta.
Tenemos arboles frutales distribuidos por el mundo. Cada uno de ellos tiene su ciclo vital y genera frutos. Diferentes frutos, características y usos. Mientras el árbol siga viva en edad adulta generará frutos según su ciclo personalizado.
Como en la vida real, si esos frutos no se consumen son un excedente problemático. En nuestro caso porque cada fruto nuevo es un actor nuevo que ocupa memoria y que no libera hasta que alguien lo consuma.
Como tener el planeta lleno de frutos que nadie consume no aporta nada el juego valoramos dos opciones. La primera que los frutos tuvieran su propio ciclo de vida y desaparecieran con el paso del tiempo. La descartamos, porque aunque realista, el juego no obtiene ningún beneficio adicional por ello. De momento.
La segunda es la clásica que todo el mundo conoce. Generar un nuevo fruto si el anterior ha sido consumido.
Optamos por la segunda. ¡Y otro gran aumento de las prestaciones!
Estar resolviendo todas estas cosillas puso sobre la mesa si era el momento de parametrizar la calidad gráfica para facilitar que ordenadores más limitados en recursos pudieran correr con solvencia el juego. Y decidimos que si. Que, de alguna forma, no obligara a tener un pepino para jugar. Utilizar UE ya supone un nivel mínimo, pero nos ha parecido buena idea dar esta facilidad en un momento tan temprano de nuestro proyecto.
Así que hemos introducido un desplegable para elegir entre calidad baja, por defecto y alta.
Ufff. Hemos aprendido muchas cosas. Pero si tuviera que sintetizarlo en algo, ese algo sería no dejarse llevar por el entusiasmo de enriquecer y ampliar el juego con nuevos elementos que hagan más chulo el gameplay sin sopesar el impacto en el rendimiento. En cuanto el juego crezca, el problema de rendimiento aparecerá. Y luego será más doloroso resolverlo. Nuestro caso ha sido el hecho de incorporar sistemas que implicaban la creación de actores. Al ser generativo, el número final exacto de actores en tiempo de juego no lo controlamos, por lo que el trabajar con referencias nos ha resuelto el problema pero nos ha costado más trabajo cambiarlo. Y con UE, hasta que no pruebas, no se sabe muy bien como lo gestionará…
Resumen: Piensa lento, prueba rápido.
Estos cambios los hemos hecho en la versión de juego individual. Y han funcionado muy bien. La semana que viene tenemos que confirmar que estos cambios funcionan igual de bien en la versión multijugador.
Quizás te preguntes si es necesario tanta complejidad para un juego demo. Un mundo simulador de la realidad que acaba matándote por el rendimiento en tu ordenador.
La respuesta es sencilla y breve. Sí.
Para esta demo no hubiera sido necesario. Pero Avademia es un videojuego que va de comprender las matemáticas, que están ocultas en el planeta, descubriéndolas. Porque solo contextualizándolas en un entorno real (aunque sea digital) se puede dotar a su abstracción inherente una aplicación práctica y, por tanto, más comprensible, tanto de su funcionamiento como de su uso.
Pero hay otro elemento adicional. Queremos que la narrativa se genere en función del comportamiento y las decisiones individuales y grupales de los jugadores, generando también nuevo conocimiento a descubrir. Y eso requiere una base sólida. Un entramado como el que hemos creado.
Nos vemos el viernes que viene.
Y recuerda.
Si consideras que lo que te he contado está alineado contigo, tienes tres formas de estar involucrado:
1. Seguir apuntado a esta Bitácora. Te doy las gracias por adelantado.
2. Compartir nuestro proyecto con todo aquel que consideres que le pueda interesar
3. Unirte como fundador al programa Quantum Architects. 100 fundadores con beneficios especiales. Puedes solicitarlo en www.avadlf.com.
Hasta la semana que viene.