Il making of di Gears of War: Ultimate Edition - intervista

Ricordo ancora il giorno che l'ho saputo. Sono stato chiamato nell'ufficio di Mike Rayner (direttore tecnico dello studio), e dopo che la sorpresa e l'eccitazione sono svanite, abbiamo discusso i possibili approcci. In pratica le opzioni erano tre: partire dall'originale, dall'ultima versione di Unreal Engine 3 o passare a UE4.

La nostra filosofia è stata di mantenere il codice giocabile nel corso dello sviluppo, quindi sentivamo che per raggiungere i nostri obiettivi e assicurarci di giocare più spesso possibile, il miglior punto di partenza era il codice originale. Dalla prospettiva dei contenuti, le cose avrebbero funzionato fin dal primo giorno. Il nostro team ha lavorato molto con la tecnologia Unreal, ma a quel tempo avevamo poca familiarità con il codice di gameplay di Gears. Abbiamo discusso l'approccio come team, visitato Epic e discusso con loro, e a parte le sfide insite nel lavorare con strumenti vecchi di 10 anni, abbiamo deciso che quella era la strategia migliore. Ecco come è cominciato il nostro lavoro con il codice originale.

Il problema con le altre opzioni era che tutti i dati dei livelli sarebbero stati difficili da gestire nella transizione, e questo si sarebbe tradotto in un lungo periodo di tempo durante il quale il codice sarebbe stato ingiocabile. Alla fine non avremmo potuto garantire le stesse funzionalità dell'originale, visto che i sistemi che le regolavano sarebbero cambiati. L'unica altra opzione sarebbe stata di ignorare tutto e ricostruire lo scripting da zero, e abbiamo pensato che le possibilità di perdere qualcosa dell'esperienza di gameplay sarebbero state troppo elevate.

Presa la decisione, il nostro team dedicato al motore si è occupato immediatamente di far girare il gioco su Xbox One, mentre quello del gameplay ha dissezionato e appreso tutto ciò che fa funzionare Gears. Questa combinazione ci ha permesso di valutare le aggiunte al gameplay provandole su Xbox One a 60fps negli stadi iniziali dello sviluppo.

Siamo molto felici della decisione presa, ma abbiamo sottovalutato alcune delle sfide che lavorare con un editor così vecchio implica. L'editor di Unreal Engine 3 è stato aggiornato e migliorato molte volte, e avremmo potuto migliorare di molto la nostra efficienza sfruttando queste cose nelle fasi iniziali della produzione. Mantenere il motore e il gameplay originali ci ha permesso di non rifare tutto da zero per ricostruire qualcosa di simile al gameplay del primo Gears, e la nostra versione sarebbe stata fedele all'originale.

Abbiamo cominciato con il codice originale e cambiato e aggiornato in base ai consigli del nostro team di rendering. The Coalition e Microsoft contribuiscono attivamente ad Unreal Engine e capiscono bene come si comportano le diverse funzioni di rendering su Xbox One. Questa conoscenza ci ha permesso di cominciare facendo girare le funzioni di gioco originali su Xbox One, e in seguito abbiamo aggiunto elementi presi dalle ultime versioni dell'UE3 e anche da UE4. La maggior parte delle funzioni dell'editor sono state prese da UE3. Un esempio è Lightmass (il sistema di illuminazione di Unreal Engine), che è passata attraverso numerosi mesi di lavoro per ottenere funzioni che risalgono approssimativamente fino al 2011. Altre funzioni sono state prese più da UE4 o da nostri lavori su UE4, come lo shading basato sulla fisica e miglioramenti specifici per Xbox One quali la gestione della ESRAM. Abbiamo anche sperimentato con il calcolo asincrono per ottimizzare in un modo che non era possibile con UE3.

Abbiamo deciso per campagna a 30fps e multiplayer a 60fps molto presto in base a una scelta di design e non per limitazioni tecniche. L'originale era una vetrina tecnica per Xbox 360, e volevamo fare lo stesso su Xbox One migliorando significativamente la grafica della campagna a 1080p mantenendo un frame-rate a 30fps più stabile di quello dell'originale. È possibile far girare la campagna a 60fps, ma il suo aspetto non è al livello della versione a 30fps.

Come parte della nostra metodologia 'sempre giocabile', abbiamo impostato e mantenuto i budget di rendering monitorando le prestazioni nel gioco. Ciò ci ha permesso, nel corso dello sviluppo, di sapere in che condizioni eravamo dal punto di vista delle prestazioni con tutti i contenuti originali, e monitorare e aggiornare man mano che ogni mappa veniva rifatta. Ogni giorno eseguivamo test di gioco automatici e manuali su ogni mappa in sviluppo attivo. Per la GPU, nello specifico, abbiamo puntato a un valore tra 8ms e 12ms su una mappa multiplayer con il solo personaggio del giocatore attivo, in modo da avere margine per fluttuazioni dovute a sparatorie, granate e altro.

Ci sono state molte sfide di rendering nel corso dello sviluppo, ma spesso abbiamo avuto limiti dal lato CPU a causa del numero di oggetti aggiunti, e abbiamo dovuto utilizzare degli strumenti per unire le geometrie e distribuire il lavoro su più core. È stato fatto molto duro lavoro per rendere solide le prestazioni della GPU, e questo comprende il riscrivere quasi tutti gli effetti post-process del gioco, massimizzando l'utilizzo della banda di memoria con la ESRAM e molte altre ottimizzazioni.

Una domanda divertente, e avrai una descrizione direttamente dallo sviluppatore principale del nostro sistema di gestione della ESRAM.

Inizialmente abbiamo messo solo i buffer di colore/profondità nella ESRAM visto che siamo forward-rendered, e molti buffer (colore/profondità) si inseriscono bene nella ESRAM a 1080p: l'incremento nelle prestazioni è stato enorme. Più avanti nel progetto abbiamo esaminato nuovamente l'utilizzo della ESRAM per ottenere prestazioni migliori. Dall'analisi si può vedere che solo certi passaggi e risorse danno dei benefici all'interno della ESRAM visto che in molti casi non eravamo limitati dai ROP.

Abbiamo aggiunto un allocatore per la ESRAM che usa la memoria virtuale per mappare pagine di 64k alla ESRAM/DRAM. Abbiamo aggiunto la gestione del ciclo di vita delle risorse che vogliamo all'interno della ESRAM in modo che al termine del loro utilizzo le pagine fisice tornino disponibili per altre risorse. Profondità e colore possono essere compressi su Xbox One, e abbiamo notato che in alcuni casi dividerli tra DRAM ed ESRAM può risultare utile in quanto ciò libera della memoria ESRAM per risorse più importanti.

Il nuovo allocatore è stata una bella vittoria per noi in termini di prestazioni, specialmente durante i passaggi relativi alle ombre, le cui operazioni di lettura e scrittura della profondità vengono eseguite nella ESRAM. Usando un approccio 'ingenuo' e mettendo tutto nella ESRAM si può sicuramente raggiungere il limite di 32MB, specialmente con un renderer differito. Nel nostro caso non è stato un problema e abbiamo avuto la possibilità di usare i motori DMA per spostare le risorse quando in caso avessimo avuto bisogno di più spazio.

Utilizziamo la gestione dell'audio disponibile su Xbox One, e la buona notizia è che non abbiamo mai visto l'audio come collo di bottiglia della CPU, e le cose hanno semplicemente funzionato. Visto l'incremento a 7.1, il numero di suoni gestiti è aumentato enormemente, e la compressione via hardware è molto utile.

Certo! Usiamo Lightmass per l'illuminazione, e abbiamo cominciato con la versione del 2006. Abbiamo effettuato due integrazioni principali, una pre portare il sistema in pari con quello del 2009 e un'altra per portarlo al 2011. Questo lavoro ha volte è stato portato avanti gradualmente per assicurarci che tutto funzionasse prima di passare al livello successivo. La prima integrazione ci ha fornito l'illuminazione globale, che da sola rappresenta un grosso passo in avanti dal punto di vista grafico. Successivamente abbiamo inserito il supporto per l'illuminazione speculare e permesso agli oggetti dinamici di ricevere e proiettare ombre integrate correttamente con lo scenario. Il nostro shading basato sulla fisica deriva dal metodo di UE4.

Il modello d'illuminazione è stato cambiato per usare il rendering basato sulla fisica di UE4, Lambert per la diffusione con Schlick Fresnel e distribuzione GGX. Le normal map possono essere trattate opzionalmente con il mapping Toksvig. Mantenere il modello dell'UE4 ha reso le cose molto intuitive per gli artisti che hanno familiarità con quel modello.

Tutta l'illuminazione è ora in pieno spazio lineare HDR. Il post-processing è stato totalmente riscritto per funzionare nello spazio lineare HDR ed esegue regolazione dinamica dell'esposizione, radianza fisicamente corretta, effetto di sporcatura della lente, profondità di campo bokeh, motion blur, vignettatura, correzione della gamma, gradienti del colore tramite 3D LUT e FXAA. Il multiplayer omette motion blur e profondità di campo, e impiega 1.1ms con tutti gli altri effetti abilitati. Per quanto riguarda l'occlusione ambientale, il metodo SSAO è basato sull'oscuramento volumetrico con passaggi separati per dilatazione e sfocatura.

Abbiamo usato il formato RGB101111 a 32-bit invece dell'FP16x4. Quest'ultimo non ci dava differenze qualitative percepibili, quindi abbiamo mantenuto il formato a 32-bit che ha anche aiutato nell'utilizzo della ESRAM.

Risponderò da un punto di vista tecnico, delle funzioni che abbiamo inserito per migliorare l'esperienza. Peder, il nostro lead designer, avrebbe più feedback sulle scelte di design. Volevamo fornire server dedicati e controlli reattivi (frame-rate veloce, rilevamento delle collisioni dal lato client) e un frame-rate stabile.

Volevamo anche essere sicuri che il matchmaking e l'esperienza multiplayer fossero quanto più aggiornati e solidi possibile. Ciò significa aggiungere supporto per cose come squadre e playlist, e la possibilità di interagire e comunicare con la community. La Ultimate Edition si affida anche a molti più servizi esterni dei precedenti Gears of War. L'obiettivo per il matchmaking era di mettere i giocatori in una partita il più velocemente possibile, e nella miglior sessione possibile. Abbiamo aggiunto il matchmaking legato all'abilità, introducendo il sistema di leveling (simile a quello di Gears 3), e in generale lavorato a stretto contatto con i ragazzi della piattaforma per assicurarci che l'esperienza multiplayer fosse la migliore. Una delle cose che ci ha permesso di riuscirci sono state le numerose sessioni di gioco di prova, sia interne che esterne, che hanno accompagnato lo sviluppo del progetto.

Abbiamo aggiornato in alcuni modi il nucleo del co-op per migliorare l'ingresso in una partita in corso, ma gli elementi più visibili sono il migliore FOV dello split-screen e tutti i miglioramenti del versus che si applicano anche al co-op.

La versione breve è che abbiamo cominciato con l'originale, assicurandoci di sostituire qualsiasi cosa a parte le collisioni, migliorando poi il tutto con illuminazione, effetti ed elementi supplementari. A parte che per le collisioni, abbiamo ricreato completamente i livelli.

Dal punto di vista tecnico abbiamo dovuto fare alcune cose per supportare questo lavoro. Prima di tutto abbiamo costruito un grosso database di tutti gli oggetti di Gears e dei livelli a cui sono relativi. Questo ha aiutato il team artistico a pianificare la creazione degli elementi. Il nostro team degli strumenti ha poi analizzato ulteriormente gli oggetti e determinato l'uniformità dello scaling in modo da darci un'idea di quanti elementi aggiuntivi avrebbero dovuto venire realizzati per mantenere costante la densità di texel. Il team di sviluppo originale è stato molto creativo ed efficiente nel riutilizzare i vari elementi, ma c'erano dei compromessi grafici che non abbiamo reputato accettabili per il 2015.

Un'altra cosa che abbiamo fatto all'inizio è stata bloccare tutte le collisioni in modo da non poterle modificare per sbaglio. A volte è facile spostare qualcosa per errore, così ci siamo premuniti. Il grosso dell lavoro tecnico è venuto dal collaborare con i team artistici in ogni fase dello sviluppo grafico per assicurarci che le funzioni necessarie a ogni livello funzionassero e che le prestazioni su ogni mappa fossero quelle volute. Abbiamo ottimizzato e aggiunto funzioni in ciascuno dei 18 mesi di sviluppo, e questo a volte ha complicato la vita del team artistico. Un capace team di artisti tecnici di The Coalition e Splash Damage ha aiutato a bilanciare questi problemi.

Per gli scenari, il nostro budget iniziale era destinato a rimpiazzare le texture. Per i vertici l'incremento di poligoni è molto leggero, perché i nostri artisti hanno scoperto che potevano ricostruire i modelli migliorandoli sensibilmente con un incremento del numero di poligoni tra il 10% e il 30%. Per le texture, ne abbiamo il doppio e a risoluzione superiore, con un utilizzo della memoria tra quattro e sedici volte superiore. Le aggiunte maggiori stanno nel rimpiazzo degli elementi di base e nelle fasi di miglioramento che hanno visto l'aggiunta di altri oggetti. Infine, l'ottimizzazione è stata fatta raggruppando assieme degli oggetti simili per un rendering più veloce. Alcuni personaggi, come il Corpser, vantano un numero doppio di vertici e texture.

I dati relativi alle animazioni dei personaggi sono stati mantenuti così com'erano per preservare l'esperienza di gameplay. I modelli dei personaggi, i loro scheletri e le animazioni secondarie sono stati migliorati. Ad esempio l'armatura e la pelle dei personaggi sono state bilanciate più adeguatamente in modo da non estendere troppo l'armatura e animare le cinture dei personaggi nella campagna. Inoltre è possibile avere otto ossa per vertice invece delle quattro originali.

Nella fase concettuale abbiamo valutato il necessario per inserire uno switch come quello di Halo Combat Evolved Anniversary Edition. Non volevamo utilizzare troppa memoria per ospitare la versione Xbox 360 del gioco né allungare i tempi di caricamento, quindi questa funzione è stata rimossa in fase di pre-produzione. Ciò ci ha portato a discutere dell'inserimento di un filtro cromatico o di un'approssimazione dell'aspetto originale con una risoluzione più bassa. Alla fine, però, abbiamo pensato che sarebbe stato meglio concentrare tutti gli sforzi nel migliorare l'aspetto del gioco il più possibile.

Artisti e level designer hanno avuto la possibilità di reimmaginare l'lluminazione nel modo che credevano adeguato, purché i livelli non compromettessero le prestazioni. Ciò ha permesso di migliorare alcuni aspetti come quello da te menzionato, nonché delle funzioni della luce che fanno illuminare le texture in alcune aree, ad esempio attorno a un fuoco.

In pratica è lo stesso codice. Il team Xbox converte il gioco e gli eseguibili PPC in eseguibili nativi x64, li abbina agli assets originali e all'emulatore in un normale gioco per Xbox One, e lo pubblica.

Stiamo ancora lavorando sodo per ottimizzare. Le DirectX 12 ci danno un controllo migliore sul carico della CPU, limitando l'ingombro del driver. Alcune risorse sono state messe a disposizione del gioco, e stiamo anche inserendo dove possibile delle ottimizzazioni da UE4. Sul fronte della GPU, abbiamo convertito la SSAO per sfruttare il calcolo asincrono e stiamo esplorando la possibilità di usare lo stesso espediente per altre funzioni, come l'MSAA.

Ci siamo impegnati parecchio per rendere la versione Windows 10 una vetrina da mostrare a 4K. Geometrie e texture sono state ridisegnate pensando ai 4K in modo da far scalare la fedeltà visiva insieme all'hardware. Pensiamo di togliere il limite al frame-rate e inserire un benchmark interno. Per l'anti-aliasing, supporteremo MSAA e FXAA.

Anche se non abbiamo limitato la scalabilità verso il basso, è importante assicurare che le prestazioni siano buone, con almeno 30fps su una serie di hardware. Supporteremo molte risoluzioni e opzioni grafiche per fare in modo che i giocatori possano calibrare al meglio la configurazione per il loro sistema.