Entrevista: Red Faction (Parte II)

El problema es que lo que es apreciable por el jugador normal es un objeto en movimiento basado en lo que está pasando en el juego en un momento en particular. Hacer un agujero en la pared que está frente a ti es un problema completamente diferente a un edificio de dos plantas que se está derrumbando sobre si mismo. Tenemos que manejar ambos, y todo lo que hay entremedio, sin que el juego se ralentice o sin que el jugador se salga de la ficción que hemos creado. Como resultado tenemos diferentes sistemas que miden el rendimiento del motor y cambian los detalles en tiempo real para mantenerlo, mientras hacen que el juego luzca lo mejor posible. Básicamente nos acercamos a lo real tanto como sea posible.

Nos pasamos más de la mitad del tiempo ajustando opciones para que la destrucción tuviese el resultado adecuado. Durante la mayor parte nos mantuvimos lo más cerca posible a la realidad, principalmente para que las cosas reaccionaran tal y como el jugador esperaba, pero la norma era "esto es un juego, la diversión está por encima de la corrección". El ejemplo más claro es el martillo. Ni siquiera el hombre más fuerte del mundo podría agujerear una pared o enviar a un enemigo varios metros más allá de un golpe, pero eso no importa porque nos parece bien y es divertido. Si insistiéramos en el realismo, el jugador se pasaría media hora intentando hacer un pequeño agujero en una pared (o, probablemente, lo dejaría tras varios golpes porque es aburrido).

Una de mis frases favoritas en el desarrollo de un juego es "no hacemos simulaciones, hacemos videojuegos". Normalmente se usa para animar a un programador joven que intenta hacer las cosas demasiado complejas con un nuevo pedacito de código. Un corolario es "la percepción lo es todo". Pasando a RFG, el juego se salta esta regla - para que una simulación como la nuestra parezca realista hay que hacer una simulación real. No hay más remedio. Pero como en muchas otras cosas del desarrollo, nuestro modelo de físicas es una aproximación de la realidad. Los arquitectos usando lo que llaman el análisis de matrices de elementos finitos para examinar las fuerzas que actúan en una estructura compleja. Es muy formal y caro, pero en el fondo inútil para un juego. Así que hicimos una aproximación que no en el fondo no es tan real. Lo que era importante era conseguir que los objetos volasen y chocasen de forma creíble. Es mejor tener un juego que no una simulación totalmente realista que tarde media en renderizar un único frame.

Y sí, hay algunos truquitos para hacer cosas que sean más atractivas. Por ejemplo, la naturaleza del sistema es tal que nos permite de forma fácil colocar un plano 3D a través de una estructura y romperla en esa superficie. Si te fijas en grandes edificios que se derrumban, de vez en cuando verás un "roto2 en la mitad inferior. Ese es el pequeño toque que añadimos. La tecnología del juego es definitivamente parte de ciencia y parte de arte. De todas formas diría que estamos sorprendidos de lo poco que tuvimos que hacer eso. La cantidad de físicas emergentes que obtenías simplemente dejando funcionar al núcleo del sistema era impresionante.

Esa respuesta es simple: ¡es realmente difícil! No sólo hay que dedicar mucho tiempo en crear la tecnología (nótese el ciclo de cinco años necesario para crear RFG), sino que también crea problemas en todas las disciplinas del juego. La gente de render tiene que poner más cosas en pantalla y que luzca bien, la gente de IA y los diseñadores tienen que tener en cuenta que el nivel cambia constantemente, los técnicos de sonido deben crear más efectos para más interacciones y si además quieres tener multijugador debes encontrar la forma de sincronizarlo todo. Eso sin mencionar la memoria y potencia de proceso que consume. No es algo que puedas poner en el último momento en un juego, es algo que debes planear desde el principio.

Apostaría a que muchos desarrolladores lo han intentado, para poco después huir asustados. El problema con un sistema como este es que toca absolutamente todo lo demás del juego. Hace el rendering tremendamente más difícil. Hace el diseño de niveles extremadamente difícil. Hace que el uso de memoria incluso para las estructuras más simples sea mucho mayor. Así que tienes un sistema comerecursos de destrucción como el nuestro, mejor que te prepares para poder pagarlo con mucho esfuerzo y sacrificio. Tienes que enfocar el juego hacia la propia destrucción, sino el precio a pagar es demasiado alto. A mi me da la sensación de que la mayoría de juegos apuntan hacia algo totalmente diferente.

Fue una de nuestras prioridades. Desde el principio sabíamos que sería multiplataforma, pese a que al desarrollo del hardware de PS3 todavía le faltaban varios años. Una vez lo tuvimos y el juego funcionaba en ambas consolas fuimos cuidadosos hasta el final del proyecto. Incluso evitamos hacer ciertas optimizaciones si solo eran aplicables en una plataforma. Para mantener nuestra salud mental intentamos que los núcleos fuesen lo más cercanos posible, ero con las SPUs tuvimos que idear muchas soluciones a medida por razones de rendimiento. Para la destrucción tuve que eliminar físicamente funcionalidades y código de Havok para hacer sitio a nuestro sistema en una de las SPUs. Dado lo mucho que forzamos ambos sistemas todavía me resulta sorprendente que consiguiésemos que las dos fuesen virtualmente idénticas, realmente necesitó muchísimo trabajo por parte de todo el equipo.

Hablando en general, nos gusta mantener el desarrollo de ambas plataformas en paralelo. Realmente no puedes permitirte que una de las dos quede detrás, porque entonces se hace difícil hacer predicciones sobre el rendimiento general y las características. Lo cual afecta entonces a los materiales que puedes crear, lo que después afecta al calendario, luego en el presupuesto, etc. Es especialmente crítico que la tecnología mantenga ambos sistemas en línea y proporcione herramientas sofisticadas para que los creadores de contenido no tengan que hacer el trabajo N veces (donde N es el número de plataformas).

Sobre el hardware en concreto, el multiproceso en 360 y PS3 es significativamente diferente. Llegados a cierto punto, simplemente debes dividir grandes piezas de código para tratar con esto de forma eficiente. Para nosotros las dos grandes áreas son las físicas y el motor de render. Ambas tienen frameworks de alto nivel multiplataforma, pero cuando llegas a zonas donde el rendimiento es capital, se dividen en código específico para cada plataforma. Por suerte, el volumen que representa este tipo de código en el resultado global es relativamente pequeño.