Bethesda y el Gamebryo – Creation Engine

Y con el Fallout 76 la bola explotó. El motor gráfico de hace 20 años que ha sufrido una clara dejadez por parte de la compañía que más ha venido usándolo parece que ya ha dejado de pasar el corte a la hora de seguir metiéndolo con calzador en nuevos juegos. Ahora, a Bethesda solo le queda o cambiar de motor gráfico por uno actual más moderno, o arreglar de una vez todas las rarezas, bugs y limitaciones del Gamebryo o Creation Engine si lo quiere seguir utilizando. Pero, ¿qué problemas tiene exactamente este motor gráfico? ¿Cuáles son las causas de que sigamos viendo tras 20 años los mismos bugs y las mismas limitaciones? ¿De dónde vienen muchas de estas limitaciones?

Viajando 20 años atrás en el tiempo, nos encontramos con un motor gráfico llamado NetImmerse. Este motor gráfico fue creado inicialmente para juegos online tipo MMO un poco al estilo del famoso World of Warcraft. Este motor gráfico poco después fue cambiado de nombre a Gamebryo, aunque el motor gráfico seguía siendo el mismo. De hecho, si tienes instalado algún juego actual de Bethesda como el Skyrim puedes ver que en el directorio del juego se siguen haciendo uso de formatos de archivo .NIF o NetImmerse File. Bethesda cogió ese motor gráfico para MMO y lo trató de adaptar a juegos offline de un jugador, y de paso le volvió a cambiar de nombre a Creation Engine. Pero la adaptación la dejó a medias, como otras cosas que iremos viendo que he separado en tres subapartados.

Jugabilidad general

¿Alguna vez te has preguntado cómo es posible que en otros juegos de mundo abierto como el Assassin’s creed Unity haya cientos de NPCs (Personajes no jugables) en la calle pero en los juegos de Bethesda no? Pues viene de la base MMO y de la mala adaptación a juegos de un jugador. En el Gamebryo – Creation Engine todos los jugadores tienen exactamente los mismos atributos, sean jugables o no. Esto hace que cualquier NPC, por simple que sea, tenga cosas como su propio inventario exactamente igual que el personaje principal. Esto provoca que el impacto en los recursos del sistema por cada NPC sea mucho mayor en este motor gráfico que en cualquier otro motor gráfico moderno de hoy en día.

Los NPCs y objetos también son en los juegos de Bethesda bastante más propensos a quedarse atascados en el escenario o a directamente atravesarlo. Esto es porque el Gamebryo – Creation Engine tiene la habilidad de crear de forma automatizada mapas de colisión del escenario en base al diseño poligonal de este. El problema es que este sistema automatizado conocido como NavMesh está muy lejos de ser perfecto. En condiciones normales, un estudio de videojuegos combinaría esta generación automática de colisiones con la manual, o repasaría manualmente la generación automática. No parece ser el caso de Bethesda, que en muchas ocasiones se ha jactado de hacer juegos enormes con poco personal por tener herramientas automatizadas y aquí está el resultado. Colisiones mal hechas por todas partes. Los milagros no existen, y si el resto de estudios utiliza mucho más personal para sus juegos es por algo. Y Bethesda no tiene herramientas especialmente automatizadas que el resto de estudios que hacen juegos de mundo abierto no tengan. Es simplemente recortar gastos.

De aquella época se han seguido heredando otras dos cosas que tienen que ver con la creación y gestión del mapeado del videojuego. Este motor gráfico tiene una herramienta de modelado de terreno muy limitada, que no permite hacer paisajes como cuevas o acantilados sin meterlos como un modelado aparte incrustado en el mapeado, con el consumo de recursos extra que ello supone. Del tema de cuevas, está también la forma que tiene el Gamebryo – Creation Engine de gestionar la carga de terreno a medida que vas viajando por el mapeado. Este motor gráfico tiene una carga basada en celdas. Esto quiere decir que todo está compartimentado y si tú por ejemplo, estando en el exterior quieres entrar en una cueva, no vas a poder tener una transición fluída entre ambos entornos como estamos acostumbrados en otros motores gráficos modernos. Este motor descarga de memoria la «celda» del exterior y carga la «celda» de la cueva en memoria, obligándote a abir una puerta para entrar a una cueva y tener un tiempo de carga. Lo mismo si quieres por ejemplo entrar a una casa o salir de ella. La casa es una celda que hay que cargar y descargar. Este motor gráfico no entiende el concepto de ir cargando cosas al vuelo según te mueves, y esto es algo que en Bethesda tampoco se han preocupado de arreglar.

Gráficos

Continuando con otros temas técnicos, ¿alguna vez jugando al Skyrim te has encontrado con momentos en los que las sombras del entorno u otros personajes te parpadeaban? Eso es porque Bethesda ha rehecho (o más bien intentado rehacer, porque el resultado final…) varias veces el motor de renderizado que utiliza para el Gamebryo – Creation Engine pero dejó cosas a medio hacer, y bugs como ese existen porque sigue habiendo cosas que no se terminaron en ese proceso de reescritura. Y a Bethesda le da igual. Este motor de renderizado que Bethesda ha intentado rehacer en más de una ocasión sigue siendo deficiente en otros apartados que impactan directamente en el rendimiento gráfico que se puede conseguir. En este caso me voy a referir a dos técnicas fundamentales para el ahorro de recursos, que los desarrolladores de otros motores gráficos ya fueron perfeccionando a lo largo de los años, pero que aquí siguen funcionando fatal. Son el Frustum Culling y el Occlussion Culling.

El Frustum Culling es una técnica que explicada de forma sencilla se entiende fácil. Se basa en decirle al renderizador que dibuje solo lo que cabe dentro de la pantalla. La lógica te dice que sería absurdo gastar recursos en dibujar algo que está fuera de la pantalla si luego no se va a ver. En su día era famoso el Unreal Engine 3 en juegos como el Mass Effect porque cuando girabas una esquina veías cómo las cosas del borde de la pantalla hacia la que girabas la esquina te aparecían por arte de magia. Esto poco a poco se fue perfeccionando y ya no es un problema. En el Gamebryo – Creation Engine sí sigue siendo un problema ya que o no se usa bien, o no se usa casi nada y por eso estos juegos tienen unos gráficos de mierda en relación a los recursos que pide.

El Occlussion Culling sigue un poco en la línea de lo anterior. Una vez que has identificado qué cabe en la pantalla, ahora identificas qué se va a acabar viendo dentro de lo que hay en la pantalla. Seguramente te hayas encontrado con videojuegos en los que te pones a mirar a una pared y ves que en ese momento la tasa de fotogramas por segundo se dispara. Eso es porque se está haciendo Occlussion Culling. Da igual lo que haya detrás de la pared, como si es una mega ciudad llena de detalle y de gente, que no lo vas a ver porque tienes una pared delante y no tiene setido renderizar la ciudad que hay detrás de la pared si solo vas a ver esa pared. Pero ahora te digo, coge el fallout 4, vete a Diamond City a algún sitio en donde notes que el rendimiento es bajo y mira hacia una pared. El rendimiento sigue siendo bajo, ¿verdad? Eso es porque la ciudad de detrás de la pared se sigue dibujando aunque no se vea. Y a Bethesda le da igual. Es cierto que se han dado casos de compañías dibujando intencionadamente cosas que no se ven para desviar el rendimiento a su interés, como en su día comentaba aquí con el Crysis 2. Pero en este caso es simple dejadez o ineptitud.

Las dos técnicas anteriores probablemente se vean perjudicadas por el mal uso (o casi nulo) de una herramienta que ya tiene el Gamebryo – Creation Engine llamada Occlussion planes. Esta herramienta es conceptualmente una barrera que la colocas en el modelado del mapa y lo que hay detrás del Oclussion Plane no se renderiza. Pero son tantas las situaciones que he tenido de mirar a una pared y seguir teniendo un rendimiento lamentable, que dudo que Bethesda lo esté usando de forma efectiva. Aparte para juegos con un mapeado grande, es absurdo tener que colocar muros a mano para decidir qué se ve, qué no se ve y desde dónde se ve o no se ve. Es por esto por lo que los motores gráficos modernos tienen la inteligencia suficiente como para saber por sí mismos si algo está siendo tapado por otra cosa y no dibujarla. O si algo no entra dentro de la pantalla y no dibujarlo. No considero como moderno al Gamebryo – Creation Engine. No al menos en su estado actual.

Si ya en exteriores el juego se ve mal, en interiores la cosa empeora bastante. Este motor gráfico no es capaz de generar sombras para objetos que estén en interiores. A mi personalmente esto me produce como una falta de profundidad o de tridimensionalidad en los interiores que hace que queden especialmente feos. Bethesda dice que ha reescrito el motor de renderizado varias veces y sin embargo, limitaciones como esta han existido en todos los juegos de Bethesda desde el Morrowind hasta el Fallout 76. Curiosas reescrituras que hacen en esta compañía. A veces a Bethesda le da por intentar disimular esta limitación poniendo debajo de algunos objetos una textura coloreada como imitando a una sombra o poniendo un halo oscuro semitransparente en la base del objeto. Pero esto no funciona bien con la iluminación dinámica porque esas soluciones son estáticas. Tampoco funciona bien con objetos que se puedan mover.

Tal vez no te hayas percatado de algo que es un poco más dificil de notar, pero que a la gente que lo nota les molesta muchísimo. Por mucho que tú bloquees la sincronización vertical de los juegos de Bethesda a 60fps (tasa de refresco bastante habitual en un monitor), vas a seguir notando pequeños tirones. Esto es porque el Gamebryo – Creation Engine internamente actualiza muchas de sus operaciones 64 veces por segundo y esta es una cifra que no es fácil de sincronizar con una tasa de 60 fotogramas por segundo. Tienes un desfase que se traduce en pequeños tirones cada más o menos un segundo. ¿Se podría arreglar? Sí, pero a Bethesda le da igual.

Físicas

Pasemos a las famosas físicas de los juegos de Bethesda. Objetos con vida propia, personajes que reciben un golpe y rebotan a kilómetros de altura…

Bethesda utiliza un motor de físicas bastante famoso conocido como Havok. Te aseguro que el problema no está en el motor de físicas en sí y que hay muchos juegos de renombre utilizando este motor que son conocidos por sus grandes capacidades de físicas que no tienen estos bugs, como los Half Life o el Zelda Breath of the Wild. El problema es en la implementación a medias que ha hecho Bethesda en el Gamebryo – Creation Engine y el no haberse molestado en solucionar limitaciones de este motor que pueden chocar con el uso de un motor de físicas potente. El Gamebryo – Creation Engine es un motor que solo permite un input hacia los objetos presentes en el juego y es el del propio jugador hacia el personaje que está controlando. Por esto, cosas como vehículos no son posibles y Bethesda suele recurrir a chapuzas como convertir a tu personaje en un modelado de personaje + caballo todo junto, en hacer ascensores que no se mueven sino que son las texturas de la pared las que se deslizan, trenes que en realidad son un NPC con cabeza gigante en forma de vagón…

Pero de las físicas en conctreto y de la posibilidad del motor de físicas de fallar también está relacionado con esto. Imagina esta escena. Tú manejando al personaje coges una lata del entorno por ejemplo. Esa lata la lanzas a un cubo de basura. Aquí tenemos un problema y es que el cubo de basura está recibiendo un input de algo que no es el jugador. La probabilidad del que el motor gráfico no sepa qué hacer en esta escena es muy alta y es alta por tanto la probabilidad de que el Gamebryo – Creation Engine le diga al Havok que simule físicas inverosímiles. Como resultado, probablemente acabarás teniendo un cubo de basura con vida propia.

Otra peculiaridad de las físicas tal y como están implementadas actualmente en el Gamebryo – Creation Engine, es que el resultado de sus cálculos siguen estando ligados a la tasa de fotogramas por segundo. Es por esto por lo que Bethesda es tan reticente a desbloquear la tasa de fotogramas por segundo en sus juegos pasado un límite. Como sucedía en otros motores antiguos, cuantos más FPS, más rápidas actuarán las físicas y si la tasa de FPS es demasiado alta, el juego se vuelve loco. Casi todos los motores gráficos tienen esto solucionado. Y digo casi porque Bethesda sigue ligando la tasa de FPS a las físicas, al contrario que el resto de la industia, que ya arregló esto hace años.

¿Es el problema realmente del Gamebryo?

El Gamebryo de hace 20 años en sí no tiene por qué ser el problema de todo esto. Hay otros juegos hechos con este motor que no tienen tantos problemas, pero es que tampoco tienen las capas extra de Bethesda a medio hacer. Muchos motores gráficos actuales también tienen sus raíces en otros motores más antiguos pero esas compañías se han ido preocupando de mejorar, reescribir, corregir, modernizar… No es el caso de Bethesda. Esta compañía ha ido metiendo cosas a medio hacer encima de otras cosas a medio hacer funcionando todo sobre un motor con limitaciones sin corregir. Y al final el grado de medio hacer y de sin corregir de este motor gráfico es terrible. Y a Bethesda le da igual.

Que a Bethesda le da igual es algo que he repetido varias veces porque el consumidor también tiene la culpa de que a Bethesda le haya acabado dando igual. 20 años con los mismos bugs y cuando decías algo siempre había alguien que te contestaba «De qué te quejas, si ya sabes cómo son los juegos de Bethesda» o «Si tanto te molesta, espera un poco que seguro que sacan un mod para arreglarlo». Estos argumentos son basura, primero porque se justifica a una compañía a seguir sacando cosas sin terminar y segundo porque es Bethesda la que me está cobrando un dinero por sus juegos, no los modders. Es trabajo de Bethesda hacer un juego con los mínimos bugs posibles y no de los modders. Es trabajo de Bethesda hacer un juego con menús adaptados a la plataforma en la que salga y no de los modders. Es trabajo de Bethesda hacer un juego con unos gráficos que no te den ganas de vomitar y no de los modders.

Pero, Bethesda se ha acostumbrado a que la gente le ría las gracias con los bugs que hasta lo usan como chiste en sus conferencias y claro, para qué cambiar. Claro que al final a Bethesda le va a dar igual todo. Si así haces los juegos más rápido y barato y la gente te los va a comprar igual… Curioso me parece que la gente haya tardado 20 años y haya sido con el Fallout 76 que por fin los usuarios se han dado cuenta de todo esto.