Entrevista: Red Faction (Parte I)

Es una relación muy cercana debido a la necesidad. Incluso con todas las herramientas hechas a medida en ocasiones era difícil averiguar por qué algo no funcionaba, debido a la complejidad del motor. De todas formas ellos tenían una herramienta que les daba una idea bastante cercana de cómo funcionaría su creación en el juego final. La herramienta cargaba el edificio y realizaba una serie de pruebas, tanto al estar entero como al destruirse, y daba ciertas mediciones. No era tan simple como un "funciona/falla", ya que gran parte de la ecuación es cómo se usaba en el juego, pero daba un buen punto de partida. Al final había una comunicación entre ambos equipos para que ellos dijeron lo que estaría bien implementar y que luego nosotros lo limitásemos a lo que se podía crear de forma realista.

Este es el clásico problema de desarrollo, y es particularmente difícil cuando estás trabajando con un motor nuevo. Lo cierto es que normalmente no sabes cómo rendirá el motor hasta que no hayas estado desarrollando con él bastante tiempo. Pero debes hacer que los artistas y diseñadores trabajen mientras tanto - ¿cómo lo haces? Bien, ello necesitan tomarse su tiempo para trabajar en sus ideas mientras nosotros terminamos la tecnología. Ningún diseñador de juegos del mundo se sienta y escribe el diseño perfecto en el primer intento. Así que mientras se completa la tecnología y el sistema se va finalizando, los equipos de arte y diseño pueden ir refinando sus ideas.

Más adelante, cuando la tecnología ya es más madura, hay distintas clases importantes de herramientas. Proporcionamos herramientas para que cada elemento de arte pueda ser analizado en el vacío. ¿Cuántos polígonos tiene ese modelo? ¿cuántos materiales diferentes? ¿está bien ajustada la física? ¿cuánta memoria consume? ¿se puede asignar un valor de coste al elemento? En RFG, desarrollamos un sistema de clases para los edificios - iban marcados de "uno" a "cinco" en términos de intensidad. Esta clasificación era un indicador de cuánta complejidad se añadiría a la escena en caso de utilizar el edificio.

Proporcionamos numerosas herramientas de análisis a los diseñadores de niveles en el editor del mundo. En concreto, tienen que ser especialmente cuidadosos con el uso de la memoria y el sistema de streaming. También deben asegurarse de que el número total de objetos esté bajo control (un objeto puede ser una silla, una mesa, algo más grande como un edificio, o algo más inmaterial como un nodo o un punto de navegación para la IA).

Probar el framerate final ingame es quizás lo más importante que podemos hacer. Llegados a este punto tenemos un amplio rango de herramientas. Hay utilidades de análisis a muy bajo nivel para que los programadores vean los hilos y puedan ver por qué el código tarda tanto en ejecutarse. Tenemos herramientas automáticas para sobrevolar por el mundo y recoger datos sobre las áreas con un framerate más pobre. Tenemos una serie de visores ingame que proporcionan a los diseñadores con feedback sobre los elementos más costosos en el juego, desde perspectivas de simulación y rendering. También proporcionamos al equipo de control de calidad con utilidades para reportar el framerate - ellos juegan al juego más que nadie, y por lo tanto son los más cualificados para avisar cuando encuentren una zona problemática.

Lo que la mayoría de juegos entienden por "destrucción" es "destrucción visual" - cosas como texturas que se añaden a la pared, pero esta sigue intacta, o una versión destruida del objeto que entra en escena cuando se inflige suficiente daño. Nuestro objetivo siempre fue obtener la "destrucción física" - que si un edificio tiene unos puntos estructurales principales debería comportarse como tal y el edificio debería derrumbarse si éstos son retirados. Ahí es donde entra en funcionamiento el sistema de estrés. Está evaluando constantemente la estabilidad de los objetos mientras reciben daño. No importa si es un trozo pequeño de una pared o un puente del tamaño de un campo de fútbol, siempre ejecutará la misma simulación para producir resultados consistentes.

El número real se calcula en función de diferentes pasos, para que el proceso puede expandirse en el tiempo. Primero debemos tomar en consideración si hay otros objetos que se apoyen en el objeto que está siendo analizado, y esto puede ser cualquier cosas, desde un tanque enemigo a un puente que conecta dos torres. Después de eso, el código de estrés va del objeto de más arriba al de más abajo, añadiendo la fuerza de la masa superior (así como la masa de los objetos soportados) y lo compara con la resistencia del material en ese punto. Si la fuerza es mayor que la resistencia, el material se rompe, lo que resulta en una sección que queda libre y cae desde la última conexión.

Mientras eso ocurre también debemos mostrar señales visuales y auditivas para hacer saber al jugador que áreas están a punto de romperse. Aparte de hacer el mundo más creíble también sirven como sistema de aviso de que la estructura es inestable y podría se podría derrumbar sobre el jugador si éste no tiene cuidado y sigue ahí durante demasiado tiempo. Este pequeño añadido es lo que diferencia al sistema de una bonita demo técnica a un juego que coloca al jugador en el mundo generándole sensaciones muy reales mientras huye de un edificio que está cayendo a trozos y se encuentra rodeado de runa y polvo.

El resultado final es un mundo que reacciona al jugador de una forma física idéntica a como lo harían objetos en el mundo real - quítale las dos patas de soporte a una torre y ésta caerá, si hay otra al lado destrozará el tejado y hará un agujero en la pared, si dentro hay tropas enemigas éstas se encontrarán ante una pesadilla. Y lo mejor es que el motor reacciona según lo que haga el jugador: él tiene una serie de herramientas, una lista de objetivos a cumplir, y la libertad de crear su propio plan de batalla para tener éxito o fracasar según sus decisiones. Algunos de los momentos más memorables provienen de fallos espectaculares, así que la derrota en vez de ser frustrante anima al jugador a volver y probar algo nuevo.

Utilizamos Havok principalmente para las colisiones entre cuerpos rígidos, la simulación de vehículos, y la generación de rayos. El motor de destrucción fue creado totalmente a medida para estar por encima de Havok, y tuvimos que retocarlo internamente en gran medida (especialmente para PS3, para que funcionase rápido en las SPUs). Es genial trabajar con la gente de Havok, y solían bromear con que protestaban cada que les enviaba un email, porque forzábamos al máximo su código a un nivel que nadie había conseguido, con lo que los bugs que descubrí eran realmente chungos. Juntos pudimos hacer realidad nuestra visión y ellos nos siguen diciendo que están impresionados con lo lejos que fuimos capaces de llegar.

La mejor forma de plantearlo es que Havok es al Geo Mod 2.0 lo que DirectX es al Unreal Engine o al CryEngine. Proporciona alguna funcionalidad básica, pero es en el propio engine donde ocurre todo lo divertido. Ellos te dan multitud de formas de mejorar el núcleo del código (una licencia de Havok te proporciona casi todo el código). Havok es, principalmente, un gran simulador de objetos que te permite jugar con ellos en diferentes puntos de la simulación. El núcleo de la interación que proporciona el sistema de destrucción es un wrapper que nos permite recibir notificaciones de Havok con cosas como "X colisiona con Y a tal velocidad" y responder a ello en diferentes estadios de la simulación. Lo que desarrollamos es un modelo que nos permitía tomar un objeto muy complejo, como un edificio entero, mirar cuándo ocurrían las colisiones, modificar los objetos existentes y crear algunos objetos nuevos. Así que cuando Havok nos dice "X colisiona con Y" nosotros respondemos con "X cambia así, Y cambia así, se crea Z y W vuela en esta dirección". La magia del sistema de destrucción es que toda la lógica interna que nos permite tomar todas estas decisiones desde entras muy simples.

Un segundo punto nada trivial es que hay que asegurarse de no sobrecargar a Havok. De forma interna, el sistema de destrucción es capaz de modelar y procesar edificios con una gran complejidad. Pero si dejas que corra una simulación de tanta fidelidad, es muy fácil encontrarte ante una situación en la que estás dándole al hardware de la consola más trabajo del que es capaz de realizar. Pasamos mucho tiempo balanceando detalle extremo con lo que el hardware es razonablemente capaz de hacer.