Intervista Tecnica: Need for Speed: Hot Pursuit
DF visita i Criterion per un'intervista tecnica.
Need for Speed: Hot Pursuit rappresenta l'inizio di un importante nuovo corso per Criterion. Non si tratta infatti di una semplice versione ottimizzata di Burnout Paradise, poiché il team di sviluppo, oltre ad aver messo a punto un nuovo engine, ha dato vita a un'esperienza di guida completamente nuova, impreziosita da un comparto grafico molto diverso dai precedenti titoli della compagnia. Ciò che ci aspetta è un Need for Speed estremamente classico che tornerà alle origini del franchise e che si attesterà su ottimi standard per grafica e fisica.
La nostra recente chiacchierata con Richard Parr e Alex Fry non ci ha dato solo la possibilità di discutere delle innovazioni tecnologiche che coinvolgono il progetto, ma anche di scoprire interessanti informazioni sul processo di sviluppo. Se volete saperne di più, non vi resta che continuare a leggere...
Abbiamo imparato tantissime cose da Paradise. Una di queste è che quando si crea un gioco dal suo post mortem è possibile trarre moltissimi insegnamenti: ciò che ha funzionato, ciò che è andato male e ciò che poteva essere fatto in maniera migliore. E talvolta, ciò che sarebbe stato possibile migliorare porta a dei grandi cambiamenti.
Quello più grosso che abbiamo apportato riguarda il threading model di questo gioco, ora tutto nuovo. Siamo passati da un dual thread, ovvero quello utilizzato da Paradise, a un single thread e i motivi di questo cambiamento sono molteplici.
Inizialmente volevamo realizzare un gioco a 30Hz che risultasse visivamente straordinario e che fosse caratterizzato da una grande reattività dei comandi. Con un ulteriore render a 30HZ avremmo dovuto fare i conti con dei seri problemi di latenza e così abbiamo fatto una certa scelta. Sarà interessante vedere i risultati della vostra analisi di latenza, crediamo che si riveleranno ottimi.
Crediamo di potere arrivare a 83ms... o al massimo 100ms.
Diciamo che se dovessimo superare i 100ms ne saremmo molto delusi.
Sono abbastanza sicuro che le console non riflettano istantaneamente lo stato del controller. C'è una sorta di processo in background che non rende la cosa istantanea.
Abbiamo cercato di limitare il lag al minimo. E questo è uno dei motivi per cui abbiamo optato per il single thread. Abbiamo provato diversi giochi a 30Hz che sembravano essere dual thread ma avevano molto lag, non si è trattato di esperienze particolarmente positive. Gli sviluppatori non devono aver avuto vita facile nel realizzare cose simili e nel cercare di renderli piacevoli da giocare. Molto tempo fa noi stessi provammo a far girare Need for Speed a 30Hz con un modello dual thread e ci sembrò tutt'altro che godibile. C'era troppo lag.
Bisogna usare il paralellismo, non i thread. Il modo più classico per velocizzare un gioco è quello di proporre un render thread separato. Così facendo la simulazione, la fisica e l'IA si appoggiano tutte al proprio thread, mentre il rendering gira scollegato ma in parallelo, solitamente indietro di un frame. Alcune volte, se scollegato, può renderizzare e aggiornarsi a un rate arbitrario. In Paradise l'abbiamo scollegato in modo che girasse sempre indietro di un frame, restando comunque in parallelo con quello successivo.
Lo è. La latenza diventa un problema meno significativo in quel caso e con essa, visto che non è necessario bufferizzare, un altro beneficio riguarda la memoria.
Quando si bufferizza tra i thread è necessario conservare delle copie di alcuni stati di gioco, oltre a dei dati che gli permettano di funzionare tranquillamente in parallelo. Questo incrementa il carico di lavoro e richiede una grande sincronizzazione. Credo che, considerando sia Paradise che questo gioco, abbiamo conservato circa 20 megabyte di memoria... una cifra notevole, ottenuta semplicemente rimuovendo quel thread e tutto il buffering che comportava. Parte della nostra nuova architettura si basa sul modo in cui i vari moduli di gioco interagiscono tra di loro. Basandoci sulla nostra conoscenza e sulle cose imparate, abbiamo preso le idee di Paradise per poi implementarle in maniera diversa: questo è il nuovo engine.
C'è stato un grande "copia-incolla" dal codice di Paradise per gli aspetti in cui tale codice si dimostrava all'altezza delle nostre attuali aspettative. Che si tratti o meno di un nuovo engine, possiamo definirlo una versione 2.0 dell'engine di Paradise, non un 1.1.
Questo è senz'altro un modo di vedere la cosa.
L'aspetto grafico è sicuramente nuovo.
Mettiamola così. È una nuova architettura impreziosita dalle migliori parti del codice di Paradise. E un perfetto esempio di questo "modus operandi" è Black. Ai tempi prendemmo gran parte del codice della fisica e del rendering di Burnout 3 per inserirlo in Black. Si trattava di un architettura completamente nuova e di un engine completamente inedito, realizzato sfruttando alcuni elementi di Burnout 3. Ed è esattamente la stessa cosa che sta accadendo oggi: non abbiamo riscritto ogni singola linea del codice, anche perché sarebbe una cosa senza senso.
Ogni compagnia sfrutta il meglio di quanto fatto in passato per i propri progetti. Non abbiamo preso l'intera architettura in blocco o l'intero engine, ma ci siamo limitati a sfruttare parti del vecchio codice che è poi stato necessario riformulare affinché si adattassero alla nuova architettura. È una cosa che abbiamo sempre fatto, prenendo pezzi di vecchi progetti, aggiungendone di nuovi e dando così vita ad architetture ed engine molto diversi da quelli precedenti.