Digital Foundry vs. Respawn: entrevista con los creadores de Titanfall

Cuando empezamos la compañía y tratamos de descubrir qué juego queríamos hacer no teníamos ni oficina ni ordenadores. Trabajábamos en el suelo del piso en el que estamos ahora incluso antes de firmar el contrato, y nos llevamos sillas plegables para sentarnos en círculo. Éramos unas treinta o cuarenta personas y había un gran proceso de grupo, hablando de los juegos que nos gustaban, los que nos habían decepcionado y por qué - lo que pensábamos que podía ser genial pero cuyas mecánicas no funcionaban bien. Cuando ya tuvimos una oficina de verdad, ordenadores y Perforce instalado, hicimos muchísimos prototipos. Al principio era sobre tratar de descubrir cómo funcionaba la mobilidad en un FPS. Parecía muy limitada, y queríamos volver quince años atrás, a Quake, Unreal, Doom, Tribes, cosas así...

Ni rocket jumping, ni combos locos... es todo muy plano. Los FPS se han vuelto en su mayoría totalmente unidimensionales.

Sí. Ya sabes, Counter-Strike y Rainbow Six salieron más o menos en el mismo periodo, y ambos fueron muy populares y eran accesibles para el usuario medio. No necesitabas reflejos sobrehumanos, tenías la posibilidad de morir por una bala perdida y la la gente entendía la AK-47 o la M9. Eso empezó la tendencia de hacer las cosas lo más auténticas y realistas posible.

Eso te limita y una de las razones por las que tenemos un juego de ciencia-ficción es porque todos esos prototipos nos llevaron a saltos dobles, a correr por las paredes, a robots gigantes y cosas así, y necesitamos una forma de explicar cómo es posible todo eso en el mundo que estamos creando. No podemos hacer eso con una ambientación actual, así que la ciencia-ficción cumple el propósito de crear un universo propio en el que todo eso sea posible.

Muchas cosas locas. Probablemente no deba hablar mucho de ello. Quizás vuelvan en otro juego o algo. Tratamos de no trabajar demasiado tiempo en algo si no pensamos que va a funcionar. Siempre es doloroso descartar algo, pero a veces debes hacerlo, o guardarlo para más adelante, cuando tengas tiempo de terminarlo de forma adecuada.

La idea era que cuando haces un shooter en primera persona tienes una campaña individual y un multijugador, así que realmente divides tu tiempo y tus recursos. Sólo tenemos unos setenta desarrolladores, así que queríamos destinar todos nuestros recursos a una experiencia. Teníamos gente que era muy buena en la presentación cinemática de la campaña y ese tipo de cosas, y otra que era realmente buena en el núcleo jugable o el multijugador, así que quisimos mezclarlo todo. Básicamente jugarás la historia en orden y no es un nivel por aquí y otro por allí, sino que cada uno explica su propia historia. No es tan lineal como algo dividido en tres actos, sino que cada nivel es una pequeña porción de la imagen general de lo que está ocurriendo.

No, cada nivel en la campaña será como un nivel de un juego individual. Explica su propia historia.

Teóricamente puedes aplicar parches o lo que sea para explicar más historia o sacar a relucir un poco más el universo. La idea es dar algo de contexto a las cosas que ocurren y ayudar a explicar la historia que tenemos.

Evaluamos un montón de motores, tanto los conocidos como los que no lo son tanto.

Sí, lo escogimos porque muchos de nuestros diseñadores querían hacer prototipos jugables desde el primer día y así teníamos diez años de juguetes jugables listos en el motor de todos los juegos de Valve. Podíamos decir 'mira, así lo hicieron en Team Fortress, probémoslo y veamos cómo funciona', y si era bueno hacer nuestra propia versión adaptada a lo que queríamos hacer.

Llegados a este punto odio decir que es el motor Source.

Sí, quiero decir que hemos reemplazado tantas cosas... es un nuevo renderizador, un nuevo código de audio, un código de red totalmente nuevo, nuevo código para el input del gamepad. Hay cosas que tan sólo las hemos mejorado, pero hemos hecho cambios masivos. Tenemos nuestro propio editor de niveles, nuestra propia iluminación, la forma en que se compilan los mapas...

El tema con el motor Source es que cuando lo obtuvimos era en realidad una rama de Portal 2. Tenía DX9, código muy enfocado a un único hilo y la forma en que funcionaba era la más apropiada para Portal. No puede renderizar muchas cosas en pantalla. El hilo principal no puede manejar suficientes trabajos, así que hemos cambiado muchas cosas. No escogimos este motor porque funcionase a 60FPS, lo escogimos sabiendo que dedicaríamos dos años haciendo que fuese realmente rápido, con un equipo de tan sólo doce ingenieros. La verdad es que en realidad es un motor bastante lento para mostrar cosas en pantalla.

Es totalmente nuevo. Es como pasar de un motor de 360 a uno de PS3, o incluso más. Ahora es una aplicación de 64 bits, DX11, hemos reescrito la forma en que se renderizan los mapas de luz y tenemos nuestro propio sistema de iluminación. No es iluminación global en tiempo real para todo, es algo muy personalizado para nuestras necesidades. No solemos añadir características técnicas únicamente por el mero hecho de que existan... nos esforzamos más en el diseño, en la jugabilidad y en dar a nuestros artistas lo que necesitan para hacer que las cosas se vean bien. El mejor rendimiento es nuestro objetivo.

Sí, yo mismo hago muchas pruebas de latencia.

[Ríe] Nunca sabes dónde aparecerán problemas, si en el código, en la aplicación o en los datos. Si hay un par de frames de animación antes de que empiece, como en una recarga, un salto de animación o algo así. Queremos estar seguros de que no pasa nada tan pronto como aprietas el botón.

Eso no es cierto.

Nuestro ingeniero de redes John Shiring escribió un artículo realmente bueno en nuestra web, donde se explican los aspectos básicos sobre cómo funciona. Basándonos en la demanda de cada región enciende máquinas virtuales y tenemos un paquete con todo nuestro código de servidor para actualizar todo lo que necesitemos, lo cual abrirá una instancia.

No, todavía no está terminado. Técnicamente si trabajásemos muy duro podríamos tener el mismo binario para todas las plataformas. No creo que eso ocurra, pero en realidad tampoco importa. Simplemente tendremos 100.000 servidores para PC y 200.000 para Xbox One...

Cierto, toda la IA está en el servidor, las físicas... bueno, algunas de las físicas siguen estando en la parte cliente.

Oh, sí, es necesario. Incluso corriendo un servidor de escucha - ya sabes, jugar en el servidor en el que cargas el juego - en cualquier juego sigue habiendo latencia entre el servidor y el cliente, y sin predicción habría una extraña sensación de desconexión. La predicción estará ahí pase lo que pase.

Desde luego. Es una experiencia más consistente. En un juego alojado por el cliente tienes una persona con lag cero. El resto depende de su ruta hasta él. Si está en Dakota del Norte, todo el mundo va a Dakota del Norte.

Sí. Es más justo. Es más rápido. Reduce quebraderos de cabeza para el matchmaking, no necesitas preocuparte de NAT, de migración de hosts. Libera un poco de tiempo de la CPU. En un juego alojado por el cliente cualquiera puede ser el servidor, con lo cual no puedes asumir que tienes toda la CPU y los recursos disponibles para el cliente. Así que reservas una parte - 10, 15% de tiempo de CPU - por si es el servidor. Ahora que el cliente no debe ejecutar el servidor en ningún momento tenemos disponibles todos esos recursos.

Hay varios tipos. Creo que las ragdolls van por el cliente porque no tienen impacto en la jugabilidad. Si tiene impacto en la jugabilidad queremos que se coordine desde el servidor. Si no, como disparar un cohete a un Titan y que caigan piezas de él, lo hacemos desde el lado del cliente.

La razón de haber escogido el motor Source - diez años de gameplay testado - también implica que hay diez años de legado de código de audio con muchas cosas innecesarias. Es algo increíble, un código que parece spaghetti. Llegamos a un punto en el que para lo que queríamos hacer era más fácil empezar de cero que usar lo que había ahí. No tenemos audio HDR... es algo curioso porque es más audio LDR porque limitas el rango de lo que puedes escuchar, pero - aunque es fantástico - tienes un tiempo concreto para terminar el juego, y tenemos nuestro diseñador de sonido que trabajó anteriormente en Battlefield y Medal of Honor, así que saber cómo conseguir que un juego suene así de bien.

Genial. Tenemos dev kits, un montón de ellos. Tenemos tanta gente trabajando en ella como nos es posible. Ahora mismo no hay efectos de render que no estén en Xbox One y sí en PC o viceversa. El rendimiento es algo en lo que vamos a trabajar sin parar hasta que lancemos el juego. Quiero decir, el hardware aún no está listo, el software tampoco y nuestro software no está terminado. Hay mucho trabajo de optimización por hacer todavía.

Apuntamos a primavera [de 2014]. No se si eso todavía es periodo de lanzamiento o no. Mucha gente publicará sus juegos antes que nosotros, lo cual quizás suavice un poco el proceso de desarrollo. Nos hubiera gustado sacar el juego para el lanzamiento porque hay cierto punto de orgullo al lanzarlo al mismo tiempo que la consola, pero los calendarios... hay ese tipo de cosas.

Nada salvo que que otros se están encargando de hacer el port.

No hablamos sobre el tema [ríe]. Lo que sí puedo decir es que la gente que lo está haciendo es realmente lista y está haciendo un gran trabajo con él. Nosotros estamos bastante desligados de ello. No queremos decirles qué deben hacer pero podemos opinar, lo vemos, sincronizamos nuestros Perforces... no va a ser un juego diferente con otro contenido. El objetivo es tener la misma experiencia jugable.

Veremos qué tal va de rendimiento. El frame-rate es el rey en este sentido.