Come le idee prendono il volo: la linea di produzione di Star Citizen

[Sceiren]

Traduttore: SilentHunter



Saluti concittadini di Star Citizen,

Come avrete sentito, lo sviluppo delle navi di Star Citizen ha recentemente subito un aggiornamento, pertanto le attività sono state spostate dal nostro studio Austin al nostro studio di Santa Monica per essere più vicini a Chris Roberts. Praticamente qui a Santa Monica l’ultimo mese l’abbiamo passato sempre imbarcati (per così dire). Abbiamo fatto il piano globale di sviluppo di tutte le navi per il prossimo anno. Quando diciamo globale, facciamo sul serio! Chris Smith e Josh Coons stanno ancora costruendo navi in Austin, mentre il team di Fonderia 42 in Manchester utilizzerà questo stesso processo per creare le navi necessarie per Squadron 42. Abbiamo pensato che questo mese rappresenta una grande opportunità per aggiornare la comunità sull’attuale stato di sviluppo di tutte le navi, utilizzando la pipeline (un grafo) per aiutare a spiegare le varie fasi di sviluppo delle navi, il significato di ciascuno stato e la loro importanza.



Prima di andare approfondire il processo di sviluppo delle navi e della pipeline, vorremmo prendere un momento per spiegare alcune modifiche che avrete notato in recenti patch su alcune delle Aurora più vecchie e le navi serie Hornet che sono già nel vostro Hangar. Se avete acquistato una delle varianti per queste navi avrete notato che con l’ultima patch sembrano un po’ diverse. Nell’ultimo mese gli sviluppatori hanno lavorato a stretto contato con i membri del team di Ingegneria di Santa Monica di introdurre a code driven variant system (… traduco in maniera libera: dividono le navi in moduli e quei moduli che possono essere condivisi da più navi li raggruppano in un’unica entità. In questo modo l’aggiornamento di un modulo si rifletterà automaticamente su tutte le navi che lo utilizzano).

La standardizzazione dei moduli che compongono le navi consente di risparmiare non solo il tempo necessario per implementare delle varianti, ma soprattutto di risparmiare una notevole quantità di tempo nella manutenzione delle navi e nella correzione dei bug. Ad esempio il 300, della serie Aurora, e la Hornet condividono la stessa cabina di guida con tutte le varianti della loro serie; con il vecchio sistema questi erano tutti moduli differenti. Questo significa che per aggiornare l'interno della cabina di guida della Aurora avremmo dovuto apportare le stesse modifiche anche sulla Aurora LN, LX, MR, ES, CL, per cui un singolo cambiamento avrebbe dovuto esser fatto 5 volte prima di averlo disponibile in tutte le navi. Con il nuovo sistema il codice gestisce le navi più come pezzi di Lego, allegando tutti i bit insieme. Ciò ci permette di cambiare un modulo alla volta e fare in modo che le modifiche possano essere utilizzate in tutte le varianti, purché queste condividano il modulo modificato. Questo non solo apporterà un enorme risparmio di tempo nel fare, nell’impostare, nell'aggiornare le navi, ma ci permette anche di ridurre drasticamente la quantità di bug che potremmo involontariamente creare e il tempo necessario per risolvere i problemi che emergono.

Per iniziare a descrivere questo pseudo “State of the Union” sulle navi, probabilmente è meglio parlare un po’ della Pipeline stessa, così com’è disposta nell'immagine qui sopra, che rappresenta il nostro ultimo processo. Il processo si suddivide in tre fasi principali che vi abbiamo descritto anche nella “public facing releases”. Le tre fasi principali sono i seguenti:

Concept Ready
È la fase durante la quale condividiamo un concetto finalizzato e approvato per la comunità. In questa fase abbiamo già esaminato ed approvato l’idea a valle di un’analisi approfondita del design funzionale. Un recente esempio è la Reclaimer.

Hangar Ready
In questa fase le navi sono già pronte a entrare nell'hangar di tutti coloro che l’hanno acquistata.  A questo punto il modello è per lo più finalizzato e le animazioni associate ai personaggi sono complete. Se per una nave sono previste delle varianti, il nostro obiettivo è di avere contemporaneamente pronte per l’Hangar anche le varianti. Un recente esempio di ciò sono le Costellations.
 
Dogfight Ready
Le navi in questa fase sono pronte per poter essere utilizzate in Arena Commander e, successivamente, nell’Universo Persistente. Rispetto alla fase precedente abbiamo perfezionato i loro LOD, abbiamo completato l’installazione di tutti gli “Stati” dei loro danni, degli  effetti visivi e audio, l'illuminazione finale, ecc. Un recente esempio di questo è la M50.

Ora ci accingiamo a farvi fare un viaggio attraverso la complessità di ogni fase del processo di raggiungimento di ogni traguardo. Tenetevi i cappelli e andiamo!

Concept Ready

Il percorso da compiere per un nuovo concetto di nave è certamente tra i più lunghi e autenticamente creativi. Si parte individuando un ruolo all'interno dell'universo di Star Citizen, che vogliamo ricoprire con una nave. Questo viene fatto con la collaborazione di designer, scrittori, produttori, e Chris naturalmente. Le persone coinvolte in questa fase sono generalmente Dan Tracy, Ben Lesnick, David Haddock, Chris Roberts, e Travis Day. Una volta definito il ruolo della nave, stabiliamo quale dei costruttori del nostro universo sarebbe il più adatto a produrre questa nave, sulla base delle capacità necessarie. Contemporaneamente i nostri scrittori genereranno descrizioni della nave di alto livello per Chris, da scegliere o perfezionare. Al termine di questo processo iniziale di design avremo approvato le caratteristiche tecniche, la funzione e il nome. Una volta che il modello base è stato approvato da Chris utilizzeremo un processo analogo per definire le varianti al modello base della nave.

Concept di alto livello


Schizzi iniziali del Vanduul Scythe

A questo punto selezioniamo il concept artist, sia interno che esterno, a seconda di chi è più qualificato e della disponibilità ad affrontare il concetto di questa nave. Una volta selezionato, gli forniamo tutti i materiali e le idee generate nella precedente fase e stabiliamo un incontro per discutere la documentazione, le idee, la destinazione d’uso, per dar modo di chiedere informazioni e proporre a braccio alcune indicazioni iniziali. Dopo quella riunione l'artista avrà tutte le informazioni necessarie a iniziare il processo di creazione di rapide bozze per mostrare quanto è stato detto e le idee generali di progettazione. Il concept artist consegnerà indietro a volte anche più di 16 diverse bozze per Chris, affinché le revisioni e fornisca un feedback e delle direttive. Una volta che Chris ha selezionato le bozze migliori e ha fornito un feedback su di loro, si procederà attraverso questo processo iterativo finché non si arriverà a un dettagliato disegno finale.

Prima interpretazione 3D


Mustang 3D concept

Per continuare il processo, il concept artist si sposterà nell’ambito dei progetti in 3D utilizzando programmi come Modo o Maya. Essi traducono gli schizzi 2D in modelli 3D che, pur non così dettagliati o puliti come i modelli di gioco finale, riportano la nave in 3 dimensioni in modo da poter iniziare ad affrontare i dettagli tecnici e logistici. Come tutti sapete, le nostre navi sono progettate per essere molto funzionali ed è in questa fase che la funzionalità prende il centro della scena. I nostri tecnici progettisti, modellatori 3D e animatori tecnici sono tutti coinvolti in questa fase per lavorare con il concept artist e inserire dettagli come, per es., l’operatività del carrello di atterraggio, la modalità di arresto della nave, dove collocare i propulsori in maniera da ottimizzare le caratteristiche di volo, dove posizionare la cabina di guida, la distanza delle superfici di controllo, la location dell’engineering bay, la zona notte, il posizionamento delle armi, ecc; a questo punto abbiamo la certezza che le dimensioni, il layout e il design concepiti potranno certamente funzionare una volta che avremo iniziato a costruire in-game la nave 3D in 3DS Max, ad animare in Maya, e in ultima analisi, l'importazione e la configurazione del CryEngine.


L’Hobbins Hole

Aneddoto divertente su questa fase: durante la fase di concept per il Mustang, fatto da David Hobbins, abbiamo scoperto che le unità di misura che aveva usato non erano quelle in uso per i modellisti in 3ds max da utilizzare per la sua installazione su Maya. Questo significava che quando il pilota ha tentato di entrare nella cabina di guida la porta era troppo piccola per adattarsi al personaggio, così si ritrovarono bloccati nel foro dietro la cabina di guida in cui si trova l'ascensore. Da questo episodio nell’ufficio è nato il termine "The Hobbins Hole".

Una volta che tutto è stato finalizzato, ovvero sono stati sottoscritti dagli artisti, dai designer e dagli animatori, il progetto è presentato a Chris per la revisione e l'approvazione finale. Una volta ricevute tutte le risposte, si completerà questa fase riproducendo degli shots in diverse in situazioni e da angolazioni diverse, che mostrano l’atterraggio, il volo nello spazio, il combattimento, assieme a qualsiasi funzionalità peculiare, come l'artiglio sul Reclaimer. A questo punto si presenta alla comunità il lavoro svolto, come di recente abbiamo fatto con la Reclaimer e portiamo la nave alla fase di Hangar Ready (pronto).

Hangar Ready


L'M50 nell’Asteroid Hangar

Quando una nave è Hangar Ready, cominciamo a coinvolgere molte più persone nel processo di creazione della nave, dal momento che la complessità aumenta, si cerca di semplificare il più possibile parallelizzando (unendo) gli sforzi. Al termine della fase di “Concept ready”, il primo passo è generalmente fatto in parallelo ( to the final Concept renders is the “Slice and Dice” proposal and “white boxing” where our Technical Artists and Technical Designers will import the concept model and) e iniziano a identificare le parti principali della nave che vogliamo si danneggino e possano essere distrutti indipendentemente dagli altri (and fleshing out how it will work). Puoi vedere un esempio con la Cutlass.

Questa fase è importante per comprendere come modellizzare la nave, dal momento che le navi, indipendentemente da quel che sembrano, sono in realtà composte da tutti i loro moduli funzionali, collegati tra loro da codice a runtime. Una volta completato questo passaggio possiamo quindi parallelizzare l’ Art work, la progettazione tecnica e l’implementazione, in modo da risparmiare tempo.

Utilizzando la tecnica dello “slice and dice” e della “white box” il team di progettazione è in grado di portare avanti la creazione dei file di implementazione del veicolo, nei quali definiamo il codice di gioco per le attrezzature della nave, l’equipaggiamento che la nave avrà di default e la configurazione delle posizioni del propulsore per testare la meccanica di volo e la rivisitazione della plancia affinché sia pronta al dogfighting. Nel frattempo la squadra degli artisti può quindi procedere con la creazione della nave in 3DS Max per ciascuno dei diversi moduli che compongono la nave e configurare la “gerarchia” come previsto dalla White Box. Generalmente gli artisti utilizzano il modello iniziale del concept come si farebbe con uno stampo per la produzione di gioielli, attorno al quale costruire il nuovo asset di gioco intorno/sopra il concept model, che rimuovono quando hanno completano i moduli finali di gioco, fin quando tutto ciò è fatto ciò che rimane è la geometria finale di gioco.

Una volta che la geometria di base è completata e la gerarchia è correttamente impostata, il team di animazione inizia a lavorare sulle animazioni dei personaggi e del veicolo, mentre gli artisti continuano ad aggiungere dettagli e appigli di supporto per collimare con quel che i tecnici progettisti hanno installato sul white box model, affinché nei file di implementazione risultino correttamente collocati all’interno del modello creato dall'artista. Da lì completeranno la mappatura UV, il texturing, il setting del materiale, la configurazione degli strati di fusione per usura, ecc. Una volta completato tutto ciò, il modello sarà inviato a Chris Roberts per la revisione e il feedback. Da qui in poi il Modeler 3D seguirà un processo di iterazione basato sui feedback di Chris, fino all'approvazione finale, supportando Animatori e designer per qualsiasi necessità o sui cambiamenti che possono ancora essere richiesti.

Ultimo ma non meno importante il modello e le animazioni saranno verificati contemporaneamente ad un artista di illuminazione per impostare l'illuminazione interna ed esterna della nave e un sound designer che farà in modo che tutti gli effetti sonori per la nave, le animazioni dei personaggi, ecc, siano integrate affinché la nave possa prendere vita. Quando tutte queste attività sono state completate e abbiamo una nave che sentiamo pronta per la fase di Hangar Ready,  la sottoponiamo a Chris Roberts per la sua ultima revisione. Dopo aver applicato i suoi feedback e ottenuta la sua approvazione finale, allora integriamo la nave nella successiva patch che rilasciamo alla comunità e a Shazaam e in questo modo è rilasciata una nuova nave Hangar Reday.

Dogfight Ready


Cutlass damage state breakup

Questa fase di sviluppo della nave è senza dubbio quella tecnicamente più complessa, ma è sicuramente la fase che coinvolge il maggior numero di persone e richiede la più stretta comunicazione e la collaborazione tra tutte le discipline di sviluppo a causa della complessità, all’interazione tra le navi e dei loro sistemi. Se si guarda il documento “Ship Pipeline” in questo post si può vedere che questa è la fase nella quale è stato creato il maggior grado di parallelismo, reso possibile anche grazie ai cambiamenti che abbiamo fatto nella prima parte della Pipeline che qui iniziano a pagare i dividendi (immagino si riferisca ai soldi che noi sborsiamo ))))). Grazie alla tecnica dello “slice and dice” e della white box, tramite la quale abbiamo suddiviso la nave in tutti i suoi moduli durante la fase di hangar stage, ora i singoli artisti possono lavorare sulla creazione degli stati di danno su ciascuno di quei moduli allo stesso tempo, poiché ciascuno di loro è un modello separato collocato all’interno della gerarchia della nave. Once they’ve completed this they will move on to baking out LODs for each of these pieces.

Per gli stati dei danni, in particolare, abbiamo sviluppato anche un nuovo sistema di collaborazione tra gli ingegneri, gli artisti Tech e il nostro team di effetti visivi. Se vi ricordate alcuni dei più vecchi “behind the scenes” video con Forrest, abbiamo utilizzato degli artisti VFX per creare effetti and go through setting them up on the model and in XML to trigger the effects to play. With our new system the artists that are actually making the damage states can actually place in helpers on the model themselves, localizzato esattamente dove vogliono che l’effetto visivo si manifesti. Sulla base del nome che danno all’helper il codice eseguirà automaticamente l'effetto che hanno scelto nella posizione specificata. Questo permette agli artisti di collocare gli effetti visivi dove l’hanno immaginati e modellizati, mentre gli artisti VFX possono concentrarsi esclusivamente sullo sviluppo di una vasta libreria di effetti di danno da utilizzare, consentendo nel contempo di ridurre il tempo da dedicare alla realizzazione tecnica.


Cutlass Panoramica Stato danno

Contemporaneamente il nostro team di Interfaccia Utenteinizierà ad impostare i vari elementi HUD e la strumentazione che avevano concepito e creato per la nave durante la fase di modellazione, perfezionandoli in modo da armonizzarli con qualsiasi feedback e richiesta di modifica di Chris Roberts. Questo è un processo molto iterativo e stiamo ancora sviluppando tecnologia per supportare correttamente tutti i creative diegetic displays che il nostro artista UI Zane Bien concepisce per adattarsi alla visione di Chris 'per l'HUD in Star Citizen.

Infine la squadra “VFX & animazione” creerà eventuali effetti personalizzati e animazioni richieste per la nave non ancora sviluppati in una delle precedenti fasi. A seguire la squadra audio farà in modo che ogni singola animazione, ogni singolo effetto, elemento HUD, praticamente ogni cosa abbia un SFX associato che porti la nave a vita. Tutto ciò è finalizzato all'attuazione di tutti gli stati di danno, alle statistiche dei veicoli, ai file di implementazione, alle armi e al thruster configuration balance fino quando non saranno soddisfatti dei loro risultati.
Chris è coinvolto ad ogni passo e in ogni fase, ma è soprattutto nella fase di Dogfight Ready che Chris effettua la sua revisione finale e da un suo definitivo feedback sulla nave prima che venga rilasciata al pubblico. I feedback di Chris sulla nave saranno integrati nella successiva patch, prima che vada in diretta al pubblico, mentre noi tutti assistiamo come i genitori ansiosi per vedere come le nostre patch si comportano in diretta e come la nostra nave viene rilasciata nelle mani della comunità.

Portare le navi in Arena Commander...



Questo è quanto su questa dissertazione sulla pipeline e sul processo che usiamo per sviluppare navi qui a Cloud Imperium Games! Posso onestamente dire che una delle cose più importanti per me è di poter lavorare a questo progetto in piena libertà. Ciò che rende tutto questo possibile è la “libertà creativa”, senza un editore, e la libertà di poter condividere il nostro processo di sviluppo con tutta la comunità. Avere la possibilità di mostrare a tutti il processo di sviluppo in questo tipo di "kimono aperto" è molto liberatorio e divertente per tutti noi qui a Cloud Imperium e speriamo che tutti voi piaccia ascoltare tutto ciò quanto a noi piace condividerlo. Grazie a tutta la comunità, a tutti coloro i quali hanno sostenuto questo progetto e hanno contribuito a generare questa unique creative development relationship! See you all in the ‘verse!

In Fede,
Travis Day
Producer – Star Citizen

Attuale Stato delle navi (al 24/10/2014)
Questa tabelal mostra la prossima fase prevista per ogni nave nella nostra tabella di marcia. Notate che non tutte le navi sono in sviluppo; alcune devono ancora essere annunciate e non sono incluse! (ed altre, come le prossime della Wave4, non sono ancora entrate nella scaletta).