Digital Foundry vs. Respawn: l'intervista su Titanfall

Quando abbiamo avviato l'azienda e cercato di capire quale gioco fare, non avevamo un ufficio e nemmeno i computer. Ci siamo praticamente accovacciati sul pavimento degli uffici dove siamo adesso (di cui non avevamo ancora un contratto di locazione) abbiamo portato delle sedie pieghevoli e ci siamo seduti in cerchio. Eravamo nemmeno trenta o quaranta e abbiamo trascorso parecchi giorni a discutere del gioco che volevamo fare, di quelli che avevamo fatto ma non ci erano piaciuti e del perché, o di quali avremmo voluto fare. Una volta avuto a disposizione un ufficio, i computer e un'infrastruttura Perforce ci siamo messi a pensare a un sacco di prototipi di sviluppo, in particolare su come arrivare a un diverso concetto di mobilità in un FPS. La nostra esperienza era sempre stata piuttosto limitata al concetto di realismo assoluto e per trovare qualcosa di diverso dovevamo tornare ai tempi di Unreal, Doom, Tribes o Quake III Arena....

Niente rocket jump, niente combinazioni di movimento particolari, niente di niente. La realtà attuale del movimento in un gioco è assolutamente piatta e infatti gli FPS sono diventati per la stragrande maggioranza monodimensionali.

Già. Sai, quando uscirono Counter-Strike e Rainbow Six furono pubblicati nello stesso periodo ed entrambi divennero molto popolari per come rendevano un certo genere di gameplay accessibile all'utente medio rispetto agli sparatutto multiplayer precedenti come Quake o Unreal. Si trattava di giochi in cui era necessario avere una coordinazione occhio-mano pazzesca nel coniugare movimento e mira per prevalere sugli avversari. Con CS gli utenti accettavano la possibilità di morire per un headshot per una raffica di AK-47 o M9 e quindi iniziò il trend di far diventare il gameplay il più realistico e autentico possibile.

Si trattava di una soluzione ideale per favorire la transizione degli sparatutto da PC a console ed uno dei motivi che ci ha portato a concepire da zero un gioco di fantascienza che ci ha portato in cui il giocatore può eseguire doppi salti e correre sui muri con robot giganteschi. Ovviamente dovevamo trovare un modo di rendere convincente la spiegazione su come tutto questo potesse essere possibile, quindi il contesto fantascientifico è stato del tutto funzionale a questo condizionamento.

Un sacco di materiale fuori di testa ma non posso dirti altro perchè probabilmente ricicleremo alcune idee per un altro gioco. Molti concetti sono stati abbandonati già nello sviluppo iniziale mentre altri verso la fine, in ogni caso non ci tratteniamo troppo a lungo su soluzioni di lavoro che non crediamo potranno funzionare. Spesso in passato ci siamo trovati a cestinare idee valide, e altrettanto spesso a metterle da parte e trovare il tempo di realizzarle come si deve. Lo sviluppo di Titanfall è sicuramente stata una di queste occasioni.

L'idea è che quando stai facendo uno sparatutto in prima persona e hai una campagna singleplayer e una componente multiplayer devi essere davvero bravo a dividere tempo e risorse in entrambi i settori. Abbiamo solo circa 70 sviluppatori e abbiamo quindi dovuto mettere in comune tutte le nostre risorse in un'unica soluzione. Abbiamo avuto ragazzi che sono stati davvero bravi a realizzare la parte singleplayer nella sua presentazione, mentre altri molto portati al gameplay singleplayer e multiplayer così abbiamo deciso di mettere insieme lo sviluppo e la trama di entrambi. Fondamentalmente il giocatore sarà chiamato a giocare eventi separati di una trama più grande mettendo insieme tante piccole storie.

No, ogni livello della campagna singleplayer è una porzione a sè stante dell'intera trama e racconta quella specifica parte della storia.

In teoria si, tramite DLC o patch è possibile espandere l'ambientazione e la trama andando oltre quello che abbiamo fatto nel gioco completo. Volendo, avremo la possibilità di contestualizzare meglio quello che succede con la storia che stiamo raccontando.

Abbiamo valutato un sacco di motori: alcuni noti e altri meno: alla fine abbiamo scelto il Source Engine perchè un sacco dei nostri designer volevano sviluppare la base del gameplay su un engine collaudato su numerosi elementi già presenti nell'engine stesso da lungo tempo e che potevamo già usare liberamente. Per esempio, ci siamo trovati ad apprezzare alcune soluzioni di Team Fortress chiedendoci se avremmo potuto evolverle e vedere cosa ne sarebbe venuto fuori se fossimo riusciti ad adattarle alle nostre esigenze.

Non proprio, anzi: a questo punto dello sviluppo mi da quasi fastidio dire che si tratta del Source Engine.

Esatto. Voglio dire, abbiamo sostituito quasi tutto: un nuovo motore di rendering, codice audio, codice di rete, sistema di immissione dati per il gamepad. Alcuni elementi dell'engine sono stati soltanto migliorati, ma numerosi cambiamenti sono stati molto invasivi come il nostro editor di livelli, il sistema d'illuminazione, il modo in cui le normal map sono compilate. Si tratta del Source ma non certo la versione usata Portal 2 o tantomeno Half-Life 2 nel 2004.

L'aspetto che ci ha intrigato del Source Engine quando ci abbiamo messo sopra le mani era la sua flessibilità, un elemento evidente da quello che Valve ha fatto con Portal 2. Si tratta di un motore DX9 pensato per un utilizzo a thread singolo usato in maniera perfetta per le necessità di Portal. Non riesce a renderizzare grosse quantità di asset video a schermo in quando il thread principale non può gestire molti elementi contemporaneamente. Per adattarlo alle nostre necessità abbiamo dovuto quindi svolgere un enorme lavoro di rielaborazione: non abbiamo scelto questo motore perché ci avrebbe permesso fin da subito di viaggiare a 60FPS al secondo, ma perché avremmo trascorso due anni a piegarlo alle nostre esigenze di prestazioni.

Il Source nella sua incarnazione versione originale non sarebbe riuscito a renderizzare la quantità di dati di Titanfall com'è oggi. Se prendessimo l'engine come lo abbiamo licenziato inizialmente non riuscirebbe a far superare all'attuale build di Titanfall il limite di dieci fotogrammi al secondo, anzi probabilmente non riuscirebbe nemmeno a terminare il caricamento del gioco. Per arrivare alla performance attuale abbiamo dovuto affrontare una sfida terribile sotto il profilo dell'ingegneria del software che ci ha costretto a impegnare tutti i nostri ingegneri nella creazione del back-end mentre i designer stavano ideando la struttura di base del gioco. Questo approccio è stato necessario per evitare di fermare i programmatori alla realizzazione dei tool di sviluppo lasciando i designer a girarsi i pollici. Nel nostro team sono presenti solo una dozzina di programmatori, quindi un team piuttosto piccolo per il lavoro che sono stati in grado di svolgere.

Fondamentalmente l'abbiamo riscritto da zero, come se avessimo dovuto passare da un motore per Xbox 360 a PS3: Dalle DX9 a 32 bit siamo passati alle DX11 a 64, riscrivendo le routine di Lightmap e il sistema d'illuminazione. Non si tratta d'illuminazione in tempo reale a tutto spiano ma è sicuramente una soluzione realizzata per soddisfare le nostre necessità. Non ci servono soluzioni tecniche fantasmagoriche solo per il gusto di introdurle nel gioco, quindi abbiamo implementato solo quello che ci serviva. L'obiettivo finale era sempre stato quello di ottenere la miglior performance possibile senza penalizzare le risorse da dedicare a design, gameplay e mettere in condizione i nostri artisti di rendere il gioco il più bello possibile.

Esatto, io stesso perdo ancora molte ore nei test di latenza.

[Risate] Non si può mai sapere quando i problemi possono presentarsi, che si tratti di codice, applicazioni o dati: anche un paio di frame d'animazione ripetuti o un salto nel rendering o qualsiasi altra cosa possono sbucare dal nulla in qualsiasi momento. Vogliamo essere sicuri che nulla possa alterare il fluire dell'immagine in gioco nel momento in cui il giocatore compie un'azione.

Non è vero.

Il nostro ingegnere di rete John Shiring ha scritto un articolo molto interessante per il nostro sito per dare a tutti la possibilità di capire come funziona il Cloud. A seconda della necessità in una particolare regione geografica, farà partire alcune machine virtuali su cui girerà il nostro codice server che potremo aggiornare a nostro piacimento.

No, non siamo arrivati a tanto: tecnicamente sarebbe stato possible avere lo stesso codice binario per tutte le piattaforme, ma avremmo dovuto lavorare veramente duro per arrivarci. Non credo che questo accadrà ma questo non conta visto che possiamo attivare 100.000 server PC, 200.000 Xbox One...

Esatto, l'IA è tutta server-side, anche buona parte della fisica, ma non tutta, alcuni elementi sono in locale.

Certo, per forza. Anche connettendosi a un server in ascolto sulla stessa macchina su cui si sta giocando è presente un minimo di latenza e senza la predizione ogni gioco sarebbe condizionato da un ammontare variabile di lag percepita. La predizione dell'azione a schermo esiste a prescindere e questo vale anche per Titanfall.

Assolutamente si. L'esperienza sarà più solida per tutti visto che in un'architettura P2P un giocatore ha zero lag mentre le prestazioni degli altri dipendono dalla sua posizione geografica. Se questi vive in North Dakota, tutti dovranno arrivare in North Dakota con quello che ne consegue in tempi di risposta per chi si connette da zone remote degli Stati Uniti: la stessa cosa vale ovviamente per il resto del pianeta.

Si, è più equo nel non favorire nessuno in termini di latenza, più performante e riduce un sacco di mal di testa con gruppi e matchmaking: niente più paranoie con NAT, migrazioni dell'host durante la partita e così via. Questa soluzione ha anche il vantaggio di liberare risorse della CPU che ospita il gioco. Non molti sanno che nella realizzazione della porzione multiplayer di un'infrastruttura host-client non puoi spingerti oltre l'85-90% delle risorse necessarie a far girare puramente il gioco in locale. Questo perché chiunque, in ogni momento, può diventare il servente della sessione di gioco occupando quel 10-15% di risorse disponibili. Nell'infrastruttura client/server ogni singola istanza di gioco può sfruttare al massimo tutte le risorse di sistema quindi questa limitazione non si pone.

Ci sono vari tipi di implementazioni: il ragdoll dei giocatori colpiti è gestito localmente in quanto non ha un impatto sul gameplay come invece succede per gli elementi fisici che lo hanno e quindi devono essere gestiti lato server. In pratica, se sparate a un Titano con un lanciarazzi e si staccano alcuni pezzi, l'effetto è solo estetico e quindi calcolato dalla console dell'utente in locale.

Il bello del Source è che ha alle spalle almeno una decina d'anni di materiale e soluzioni di sviluppo e questo vale anche per tutto il codice audio ereditato dalle esperienze precedenti. C'è talmente tanta roba che abbiamo finito per scartarne la stragrande maggioranza: come per la parte grafica ci siamo limitati ad usare quello che ci serviva veramente. Visto che non abbiamo usato tecniche audio HDR (High Dinamic Range) è stato come lavorare in LDR in quanto abbiamo limitato l'ampiezza del suono che l'utente può sentire, ma il risultato finale è stato ugualmente eccellente. Il nostro ingegnere del suono in precedenza ha lavorato su Battlefield e Medal of Honor, quindi ha le idee piuttosto chiare su come far suonare bene un gioco esigente come il nostro.

. È fantastica: abbiamo fatto giocare il maggior numero possibile di tester in quanto abbiamo un sacco di dev kit e nessuno ha notato differenze evidenti in termini di poligoni, texture ed effetti tra la versione Xbox One e quella PC. Sono perfettamente identiche. Sulla performance stiamo invece ancora lavorando fino a quando il gioco non sarà pronto: voglio dire, la console ancora non esiste nella sua forma definitiva così come gli strumenti di sviluppo e, ovviamente, il nostro codice. Abbiamo ancora ampie possibilità di ottimizzazione.

La nostra idea è quella di uscire nella primavera del 2014, ma non siamo sicuri se questa sarà la finestra di lancio definitiva o meno. Un sacco di concorrenti usciranno sul mercato prima di noi e questo ci permetterà di prendercela relativamente comoda nelle fasi finali dello sviluppo. Ci sarebbe piaciuto uscire in contemporanea con il lancio della console perché c'è un certo orgoglio nel farlo in concomitanza con un hardware tanto importante, ma non abbiamo avuto modo di farlo per problemi di attività già schedulate che ci hanno impedito di arrivare in simultanea al lancio.

Poco, oltre al fatto che la conversione è stata affidata a un altro team.

Non possiamo parlarne... [risate]. Posso dirti che il team che ci sta lavorando è composto da gente in gamba e sta facendo un ottimo lavoro anche se non abbiamo il controllo diretto del progetto di conversione: stiamo lavorando in collaborazione con loro gestendo il codice condiviso tramite Perforce. Siamo comunque abbastanza fiduciosi sul risultato finale visto che non si tratterà di un gioco completamente diverso dalla versione Xbox One/PC ma della stessa esperienza di gameplay proposta scendendo al giusto compromesso sul fronte tecnico.

Vedremo come si comporterà il gioco nella sua incarnazione finale: il frame rate sarà comunque sempre la nostra priorità.