Around the Verse: Lo Sviluppo delle Navi – Parte 2

Seconda parte dell’approfondimento dedicato alla catena di sviluppo delle navi: dalla fase di greybox allo stadio “Pronto al Volo”.

AGGIORNAMENTO DAGLI STUDI DI FRANCOFORTE

·        Foundry 42 Francoforte ha compiuto due anni, durante i quali è passata dai sei impiegati iniziali ai 70 attuali.

·        Team delle Armi FPS:

o   È stato terminato il secondo passaggio artistico della Klauss & Werner Arclight 2, della Galant e della Arrowhead.

o   È stato completato il primo passaggio artistico della Kastak Arms Ravager 212 ed il secondo passaggio della Devastator.

o   Il team delle armi delle navi ha completato tutti i razzi ed i lanciamissili di dimensioni 1-3.

o   È stato effettuato il primo passaggio artistico dei cannoni Ballistici della Knight’s Bridge Arms, che utilizzano la nuova tecnologia modulare per l’aggiornamento e la combinazione con altri componenti.

·        Team dell’Illuminazione:

o   Hanno assunto un artista capo dell’illuminazione che lavorerà all’integrazione delle luci negli avamposti modulari ed alle sfide dovute alla generazione procedurale.

§  Ogni ambiente procedurale dispone di diverse risorse sceniche disposte in maniera differente, cosa che andrà ad influenzare anche l’illuminazione.

o   Inoltre, stanno creando delle segnalazioni visive per le stanze principali: zona abitativa, colture idroponiche, officina meccanica, magazzino. Lo scopo è di migliorare ulteriormente l’illuminazione degli ambienti interni.

o   Una volta che avranno finito di elaborare queste informazioni, inseriranno anche il sistema delle luci nel motore modulare, così da conferire anche al primo una certa modularità.

·        Team Artistico Tecnico:

o   Sono stati impegnati nell’ampliamento delle possibilità di personalizzazione dei personaggi.

o   Hanno sviluppato degli strumenti che permetteranno agli animatori di gestire le animazioni di movimento, riducendo così il tempo che sarà loro necessario per svilupparle.

·        Team del Design dei Livelli:

o   Stanno sviluppando il sistema della modularità degli avamposti e delle stazioni spaziali.

o   Inizieranno con le 5 versioni di avamposto che hanno già stabilito.

§  In futuro, aggiungeranno nuovi pattern e strutture, così da ampliare la varietà delle forme degli avamposti che incontreremo nel gioco.

o   Il negozio del “Truck stop” sarà il primo banco di prova del sistema delle stazioni spaziali modulari.

o   Stanno lavorando alla possibilità di personalizzare ulteriormente gli hub delle stazioni spaziali, per incrementare la varietà degli ambienti ed ampliare le combinazioni degli spazi di accesso alle zone delle stazioni.

·        Team del Motore:

o   Hanno terminato la rifattorizzazione della griglia fisica.

o   Il vecchio sistema della griglia del CryPhisics utilizzava una matrice fisica fissa bidimensionale costituita da svariate celle, le quali avevano un’unica, enorme dimensione. Inizialmente hanno provato a lavorarci sopra, ma a causa della scala delle dimensioni di cui necessitavano, hanno deciso di cambiare approccio ed hanno creato una gerarchia fissa di celle 3D annidate di varie dimensioni.

o   Queste modifiche hanno permesso loro di scalare le dimensioni della griglia fisica da oggetti grandi quanto dei sassi, ad interi pianeti.

o   I test iniziali svolti su Crusader mostrarono un’efficienza di gran lunga superiore rispetto al sistema precedente, con una riduzione del numero di entità restituite ad ogni query di quasi un ordine di grandezza, mentre le query stesse erano da 1.2 a 2 volte più veloci, anche se utilizzavano una quantità di memoria leggermente superiore.

o   Evo Herzig si è occupato di sviluppare le funzionalità di base del movimento dell’IA.

o   Il suo lavoro consiste sostanzialmente nel prendere i dati di mocap che sono stati utilizzati per degli scenari fissi e prevedibili, per poi usarli in una varietà di interazioni imprevedibili.

o   Il sistema che ha creato è stato definito “Parametric Blending” e permette all’IA di riprodurre una serie di animazioni in maniera naturale e senza artifici.

§  In breve, il “Parametric Blending” è in grado di destrutturare i singoli frame dei set di movimento estratti dai dati di mocap precedentemente catturati, decidere quali sono necessari per replicare il movimento dei personaggi in una certa situazione e riassemblarli, mischiando elementi provenienti da set di movimento differenti. Così facendo, sono in grado di realizzare delle animazioni fluide e realistiche anche per quei movimenti che non hanno potuto catturare in mocap.

§  Dal punto di vista tecnico, questo sistema funziona indicizzando lo spazio relativo al modello del personaggio di cui bisogna generare l’animazione. Questo spazio viene suddiviso in tanti punti, i quali vengono catalogati e collegati tra loro geometricamente. A ciascuno di questi punti viene assegnata un’animazione ben definita ed il programma lavora in maniera geometrica, verificando che le correlazioni spaziali tra i vari punti siano rispettate e generando così l’animazione voluta. Il tutto viene fatto in maniera completamente automatizzata e senza richiedere l’intervento degli animatori, se non per le operazioni di impostazione dei punti di localizzazione per l’esportazione dei frame delle animazioni mocap.

o   Il video riportato in questa sezione dell’AtV ha mostrato nel dettaglio il principio di funzionamento di questo sistema.

o   Il team del Motore ha anche apportato dei miglioramenti al blending degli oggetti con il terreno, cosa che dovrebbero mostrare a breve.

·        Team di QA:

o   Il nuovo tester Senior del QA, James Stevens, si è unito al team per dare loro una mano a rifinire l’editor dell’equipaggiamento ed a testare il nuovo editor del Sistema Solare, Soled.

·        Team dell’IA:

o   Hanno completato la funzionalità delle missioni di SQ42 e del PU.

o   Stanno migliorando le impostazioni relative agli scenari che coinvolgono più personaggi che interagiscono contemporaneamente tra di loro.

o   Lo strumento della Sussunzione ha visto una serie di miglioramenti relativi alle conversazioni, ed inoltre il team ha iniziato a lavorare alle conversazioni relative alle sotto-attività. Le sotto-attività costituiscono la logica che regolerà il comportamento dell’IA negli scenari in cui saranno presenti più personaggi.

§  In particolare, le sotto-attività sono state progettate in maniera tale da permettere ad ogni IA di continuare a gestire indipendentemente le proprie azioni, così da poter fronteggiare qualsiasi situazione si dovesse verificare senza dover prima necessariamente risolvere la sotto-attività in corso.

o   Hanno completato il primo passaggio di rifattorizzazione della percezione delle astronavi spaziali per permettere all’IA di interfacciarsi con le navi e per controllare il comportamento dell’IA stessa all’interno di queste.

§  Il sistema percettivo dell’IA all’interno delle navi tiene conto sia delle informazioni visive che di quelle uditive.

·        Team delle Cinematiche:

o   Stanno lavorando alle nuove scene per SQ42 e stanno rifinendo quelle già realizzate.

§  Nei prossimi mesi sperano di poter far veder qualche spezzone di quello che stanno facendo, così da far capire quale sia il livello qualitativo a cui stanno puntando, che di base è molto alto.

·        Team dei VFX:

o   Stanno continuando il lavoro relativo agli effetti planetari, cose come gli effetti atmosferici o metereologici, oltre che altri effetti più specifici, relativi a diverse tipologie di risorse che verranno utilizzate dal sistema di dispersione degli oggetti.

·        Team degli Ambienti:

o   Stanno terminando la finalizzazione delle lune, mentre il sistema di distribuzione procedurale delle risorse ha visto notevoli progressi e miglioramenti.

o   Brian Chambers ha detto:” Tutti i pezzi che costituiscono i nostri pianeti e le nostre lune procedurali stanno davvero iniziando a prender forma. Si potrebbe dire che è tutto magnifico”.

SISTEMA DI SVILUPPO DELLE NAVI – PARTE 2: DAL GREYBOX AL “PRONTA AL VOLO”

TLDR

·        La fase artistica finale consiste nell’effettuare una serie di rifiniture aggiuntive, realizzare le funzioni della nave, definire le sensazioni che deve dare e persino assicurarsi che esploda nella maniera giusta.

·        Una delle tecniche preferite dal team di sviluppo consiste nell’utilizzare i POM come decalcomanie per dare l’illusione di una struttura più geometrica anche in quei punti in cui, invece, non ci sono elementi geometrici.

·        Successivamente, si passa alla fase di animazione, che viene descritta come una sorta di “affare di famiglia”.

·        Il funzionamento, le tempistiche, le componenti estetiche ed infine l’interazione con i personaggi sono il passo successivo.

·        Questa parte del processo di sviluppo ricorda ad Elwin quello che faceva da piccolo, quando costruiva e giocava con i pupazzi.

·         A questo punto, il team dei VFX può entrare in azione e fare la sua magia. In questa fase si effettua parecchia R&D e si crea la prima versione delle animazioni uniche della nave, assieme a quelle più tipiche della linea Drake. Infine, si revisiona quanto fatto.

·        Dopo l’iterazione dei feedback ed ulteriori rifiniture, la nave viene validata da CR ed ottimizzata. A questo punto, si può dire che sia pronta per il volo.

·        Il team della UI ama essere coinvolto fin dall’inizio del processo di sviluppo, ma ha le mani legate fino alla fine. Utilizzano grosso modo gli stessi schemi di sistema, ma conferiscono ad ogni nave un aspetto e sensazioni uniche.

·        Lo sviluppo degli effetti audio viene avviato prima sulle navi più grandi, visto che richiedono molto più lavoro delle altre, ma alla fine, tutte le navi meritano di avere la stessa connessione emozionale con i giocatori.

·        Parte del fascino della Herald è dovuto al fatto che sembra possa esplodere in qualsiasi momento.

·        Utilizzano svariati livelli condizionali per produrre una sensazione sonora più organica e consistente e dare ad ogni nave una voce ed un carattere realistici e flessibili.

·        Prendere l’ispirazione per gli effetti audio dalle altre navi Drake non è una semplice questione di copia-incolla.

·        Lo stadio “Pronto al Volo” costituisce l’ultima fase di sviluppo di una nave e prevede la preparazione degli stati di danneggiamento.

·        Gran parte del lavoro in questo ambito si concentra sulla configurazione dei modelli, la modifica dei reticoli grafici e sul conferire a tutto l’aspetto giusto.

·        Una volta terminata la creazione dei modelli dei danni, si passa alla configurazione UV, che è lo step preparatorio all’implementazione degli stati di danneggiamento. Successivamente, devono assicurarsi che le varie parti si rompano nella maniera prevista, devono aggiungere gli effetti relativi alle particelle, alle luci, al fumo, ecc.

·        Quando hanno finalizzato il tutto, si torna a lavorare su quegli aspetti che erano stati soltanto abbozzati o che avevano ancora bisogno di qualche rifinitura. Allo stesso tempo, si bilanciano le statistiche delle armi e della nave in generale, cosa che in genere si fa provandola contro altre navi, fino a quando non si trova il mix giusto.

TRASCRIZIONE COMPLETA

Elwin Bachiller Jr. (EB): L’ultima volta abbiamo parlato degli stadi di whitebox e greybox. Da allora siamo passati alla fase artistica finale ed a quello che definiamo lo stadio “Pronto al Volo”.

Matt Sherman (MS): E si tratta di uno step in cui dobbiamo solo rifinire ulteriormente la nave, non assicurandoci soltanto che sia in grado di volare, ma anche che sia in grado di volare così come vogliamo che faccia. Non si tratta soltanto di assicurarci che possa prendere danni ed esplodere, ma quando succederà, dovrà anche farlo in una maniera fantastica. Dovrà avere il giusto quantitativo di resistenza. I suoi scudi dovranno essere funzionanti e dovranno poter assorbire la giusta quantità di danni. Infine, si tratta di dare i ritocchi finali alla nave stessa.

EB: Sostanzialmente, quello che facciamo è terminare la superficie della nave, per cui decidiamo quali materiali andremo ad utilizzare per ciascun elemento geometrico della nave stessa. Ad esempio, se abbiamo scelto di utilizzare del metallo grezzo o del metallo colorato, ci assicureremo di creare tutte le texture necessarie per ciascun materiale. Una tecnica che sfruttiamo abbastanza consiste nell’utilizzare i POM, che sono le Texture di Mappatura in Parallasse di Occlusione, le quali sostanzialmente sono una sorta di decalcomanie, per conferire alla superficie una serie di elementi geometrici aggiuntivi rispetto a quelli già realmente presenti. In genere, usiamo questo approccio per aggiungere sulla superficie dei rivetti, tagliare le linee delle ali e via dicendo. Insomma, ci permettere di conferire un maggior dettaglio geometrico a quelle zone che non ne possiedono alcuno, per cui la superficie sembrerà avere una geometria più dettagliata di quella reale, il che, a sua volta, ci permetterà di implementare più efficientemente il modello nel motore di gioco. Utilizzerà meno risorse, ma avrà comunque un aspetto fantastico. Alla fine sembra quasi che la nave abbia tonnellate di dettagli, ed è per questo che tale tecnica costituisce una delle fasi di sviluppo che preferiamo di più. Una volta arrivati a questo stadio, dobbiamo iniziare ad aggiungere ulteriori dettagli alla nave per portarla in vita e definire il suo aspetto. Abbiamo un ampio margine di libertà per quanto riguarda la maniera in cui possiamo realizzare questi dettagli, per cui iniziamo a danzare attorno alla nave senza andare ad influenzare in maniera significativa la sua geometria. Inoltre, in questa fase ci assicuriamo di finalizzare anche tutte le animazioni, per le quali ci affidiamo a Jay Brushwood in Texas, il quale le rifinisce e, in caso di necessità, cambia anche la tempistica delle animazioni.

Jay Brushwood (JB): Così ho finalmente l’opportunità di mettere le mani sulla nave ed andare al sodo della questione per quanto riguarda la configurazione dei punti di fulcro, la gerarchia della struttura della nave e così via. Per quanti di voi non sanno cosa sia la gerarchia, si tratta sostanzialmente di una sorta di relazione genitore-figlio. Ad esempio, è un po’ come se la vostra mano fosse figlia del vostro avambraccio, che a sua volta è figlio del vostro braccio. La stessa cosa… Succede sulle navi. Abbiamo ogni genere di strutture di gerarchia in cui vari elementi possono ramificarsi e compiere la propria parte. Ad esempio, nel caso dei carrelli di atterraggio, i piedi delle ruoto sono attaccati alle caviglie del carrello, dietro le quali potrebbero esserci dei pistoni che fanno su e giù per permettere al carrello di ritrarsi completamente. In ogni caso, dopo aver configurato tutto questo, ho l’opportunità di avvantaggiarmi sul lavoro ed occuparmi delle tempistiche delle animazioni. In questa fase aggiungiamo qualche altro elemento estetico correlato alle azioni sovrapposte ed un mare di altri principi di animazione relativi al comportamento dei vari elementi della nave. Ci occupiamo di cose come le animazioni del carrello di atterraggio, la scaletta di ingresso, il movimento di apertura e chiusura dell’abitacolo. Dobbiamo definire tutto ciò che riguarda questo genere di cose, per poi esportare le animazioni nel gioco e, quindi, impostare le interazioni con i personaggi. Cose del tipo: permettere ai personaggi di salire sulla nave, entrare ed uscire dall’abitacolo, aprire i cassetti, i portelloni e via dicendo.

EB: Per quanto mi riguarda, l’intero processo mi ricorda un po’ quello che facevo da piccolo quando costruivo dei pupazzetti. Ho modo di giocatore con il modello, ma è solo quando realizziamo le animazioni che la nave prende vita ed abbiamo l’illusione che i vari pezzi si incastrino tra loro. Questo è anche lo stadio in cui permettiamo al team dei VFX di mettere le mani sulla nave ed iniziare a realizzare i loro effetti per quei componenti che li necessitano, come ad esempio i propulsori.

Mike Snowdon (MS): Allora, la differenza tra gli effetti che vedrete sulla Buccaneer e quelli delle altre navi Drake, dipende essenzialmente dall’aspetto e dalle funzioni di questa nave rispetto alle altre. Suppongo che l’esempio migliore siano i propulsori: lo schema dei colori e lo stile degli effetti dei propulsori della Buccaneer condividono alcune somiglianze come le altre navi Drake. Tuttavia, i propulsori hanno una forma unica e caratteristica di questa nave e, similmente, le loro animazioni sono uniche e specifiche. Questi elementi andranno ad influenzare l’aspetto dei nostri effetti per la Buccaneer rispetto a quelli delle altre navi. Per cui durante la fase di sviluppo dei VFX, avremo… Andremo dal reparto di R&D per abbozzare gli effetti VFX, per poi passare alla prima fase di sviluppo, che costituisce il primo tentativo degli artisti di realizzare degli effetti di qualità, per poi revisionarli, fornire dei feedback e rifinirli ulteriormente. La fase di rifinitura consiste… Una volta che sarà stata terminata ed avremo ricevuto la convalida di Chris Roberts, passeremo alla fase di ottimizzazione, che ricopre un ruolo importante nella rifinitura degli effetti e nella loro implementazione nel gioco.  Arrivati a questo punto, potremo dire di aver completato gli effetti della nave e la potremo considerare come “Pronta al Volo”.

Treavor Wernisch (TW): Il team della UI ama essere coinvolto in tutte le fasi dello sviluppo delle navi, dal graybox al whitebox. Nel complesso, molte navi utilizzano lo stesso stile di UI. Sicuramente ce ne sono alcune che richiedono degli schermi di forme e dimensioni uniche. Stanno arrivando parecchie navi che avranno un design abbastanza unico. Pertanto, prima veniamo a conoscenza di quei design, prima possiamo iniziare a lavorare all’aspetto visivo dei vari componenti, ma nel caso della Buccaneer e di molte altre navi… Parecchie di loro utilizzano lo stesso schema dei sistemi, per cui il team della UI può non essere coinvolto nello sviluppo della nave fino all’ultimissimo momento. Quando si è trattato di lavorare alla Buccaneer, fortunatamente avevamo già introdotto un sistema di sviluppo delle navi ben definito ed oliato, per cui l’implementazione degli schermi è stata effettuata istantaneamente dopo il completamento del modello 3D. Il numero di personalizzazioni che abbiamo dovuto effettuare è stato estremamente ridotto. Vogliamo che, prima o poi, tutte le navi Drake abbiamo una loro estetica e siano in grado di comunicare delle sensazioni peculiari. Vogliamo che avvenga lo stesso anche con le navi Anvil e con tutti gli altri produttori. Ciascuna linea potrebbe avere degli schermi delle stesse dimensioni o con gli stessi rapporti, ed inoltre vogliamo che ciascuna di esse abbia i propri colori ed un linguaggio di forme differente in base al produttore.

Darren Lambourne (DL): Il nostro produttore audio, Nichola Grelk, si occupa delle comunicazioni che avvengono tra il nostro team e gli altri. Possiamo vedere quando le navi più grandi entrano nella fase di sviluppo, per poi allocare del tempo di produzione riservato unicamente a loro. Nel caso delle navi più piccole… Richiedono meno tempo, per cui in questo caso, prima di iniziare a lavorarci solitamente aspettiamo che le navi siano quasi arrivate alla fine del loro processo di sviluppo. Tuttavia, ogni nave necessita di avere lo stesso livello di collegamento emozionale con i giocatori. Ad esempio, nel caso della linea Drake prestiamo grande attenzione alle caratteristiche generali del produttore. Questo avviene tanto con la Herald, quanto con la Caterpillar e tutte le altre navi. Ci occupiamo di definire la loro voce e quali sensazioni dovrebbero comunicare pilotandole. E sono vascelli che differiscono parecchio dalla Buccaneer. La Buccaneer è, per dire, più elegante della Herald. La Herald è una sorta di barattolo attaccato ad un razzo. Voglio dire, deve dare l’impressione di poter esplodere in ogni momento, e ciò fa parte del suo fascino. Deve dare una sensazione abbastanza grezza, è così che dovrebbe essere. Ma sono caratteristiche che possiamo definire soltanto dopo che la nave ha ricevuto tutte le sue decalcomanie ed i suoi dettagli e… Altra roba. Così possiamo decidere sul momento quali suoni dovrebbe avere.

Per fare un rapido esempio, questi sono i propulsori della Herald [riproduce la traccia audio dei propulsori]. Potete proprio sentire il ruggito del motore. Siete attaccati ad un missile. E questa è la nostra Buccaneer [riproduce una traccia più delicata]. È il suono delle navi Drake, già… I propulsori vengono realizzati sovrapponendo svariati strati audio. Questo è uno di quelli, e fornisce un tono molto peculiare con l’aumentare della potenza del propulsore, fino ad arrivare all’accelerazione massima [riproduce un’altra suono in modulazione]. Sentito come il suono cambia e viene modulato fino ad arrivare al massimo e poi tornare al minimo? Sullo sfondo c’è una specie di livello sintetico che fornisce maggiore carattere al suono. Ma questo elemento sintetico è soltanto uno dei tanti che costituiscono il suono composto dei propulsori… Guardate quanti parametri agiscono in tempo reale e sono legati a questo singolo suono. Tutti questi reagiranno in base alle azioni del giocatore, a seconda delle istruzioni che darà ai controlli della nave e modificheranno i picchi, i filtri ed il volume dei vari elementi, conferendo nel complesso una sensazione organica e consistente. Sapete, mentre uno di questi elementi sale di tono con l’aumentare dello stress a cui è sottoposta la nave, un altro effetto che causa un ronzio elettronico potrebbe parallelamente diminuire di intensità e, così facendo, fornire un’interazione con i suoni estremamente naturale. E questo è il modo con cui forniamo a ciascuna nave una propria voce, un carattere flessibile e realistico che si estende persino ai rumori ambientali riprodotti all’interno della nave stessa. Ciascuno di questi suoni possiede una serie di parametri che vengono modulati in tempo reale.

Quello che stiamo facendo consiste nel prendere gli effetti peculiari della linea delle navi Drake ed importarli su una nuova nave, creando al contempo qualcosa di unico e caratteristico di questa nave. Non si tratta di una sorta di kit prefabbricato. Non facciamo un copia/incolla dei suoni di una vecchia nave sulla nuova. Si tratta di prendere le idee implementate nelle altre navi Drake ed importarle nella nuova con una nuova sessione di progettazione del suono dedicata esclusivamente alla Buccaneer, creando al contempo qualcosa di unico.

EB: L’ultima fase del processo di sviluppo artistico costituisce lo stadio “Pronto al Volo”. Durante questa fase non ci concentriamo più sull’aspetto della nave. Lo abbiamo già finalizzato, ma dobbiamo riempire alcuni dei buchi rimasti a livello di gameplay, passaggio obbligatorio prima di poter dichiarare la nave completa. Questo vuol dire che dobbiamo sviluppare gli stati di danneggiamento.

Matthew Intrieri (MI): Io sono coinvolto nello sviluppo di ogni nave. Inizio a lavorare dopo che siamo arrivati alla fase di whitebox, dopo che è stata completata la bozza della nave, ne è stato definito grosso modo il modello ed il design ha già inserito alcune funzionalità. A quel punto entro in gioco io e vado a vedere il design della nave, quanto è stato fatto fino a quel momento, ed inizio a pensare a come poterlo distruggere. Fin dall’inizio ci preoccupiamo di definire come sarà possibile fare a pezzi la nave. Per cui iniziamo subito a discutere di come dividere i reticoli del modello. Nel caso della Buccaneer, Pat si è occupato degli stati di danneggiamento e delle luci, mentre io ho gestito parte del lavoro di ottimizzazione. In questo ambito, noi utilizziamo un processo chiamato “skinning”, che è simile alla creazione del modello di un personaggio: si prendono vari reticoli e li si uniscono in un unico reticolo, riducendo così il numero di chiamate di rendering e migliorando le prestazioni. Successivamente, dobbiamo agganciare tutto questo alla nostra piattaforma di animazione del manichino e… Ad esempio, nel caso dei propulsori della nave, dobbiamo allargare la bocchetta del motore, per cui in questo caso collegherei le animazioni ed il componente a cui si riferiscono. Stessa cosa vale anche per il carrello di atterraggio della nave: deve essere in grado di estendersi, permettere alla nave di poggiare sulla piattaforma e deve avere i materiali e le collisioni necessarie.

Io mi occupo di tutto questo.

Patrick Salerno (PS): Quando ricevo una nave dargli artisti, la prima cosa che faccio o inizio ad impostare è la maniera in cui si staccano le singole parti. Ciò solitamente richiede di andare su MAX, prendere gli XML, impostare una varietà di componenti, come la possibilità di sganciare le ali, e normalmente a questo punto la nave è quasi pronta, per cui il design può iniziare a definire i valori di resistenza, come le varie parti si distaccheranno e la maniera in cui questi eventi andranno ad influenzare la capacità di volo della nave.

Per cui devo fare in modo che tutto funzioni prima di potermi dedicare agli shader ed agli effetti necessari a rendere il tutto fantastico.

Una volta completata la definizione di tutti i punti di sgancio, configuro la maniera in cui i vari pezzi di staccheranno dalla nave, ovvero quelli che definiamo i vettori. Per esempio, quando fate saltare un pezzo di una nave, questo inizierà a ruotare, giusto? Quel comportamento è basato sul suo punto di fulcro. E successivamente quel componente inizierà a ruotare ed andrà alla deriva nello spazio, per cui devo configurare il suo comportamento. Fatto questo, devo recarmi nello XML ed impostare i pezzi che si sganceranno dagli altri. Diciamo, ad esempio, che abbiate fatto saltare l’enorme motore della Buccaneer, ma c’è ancora un’ala attaccata. Ci sono anche i propulsori e, forse, anche i flap dell’ala. A quel punto vi chiederete: se l’esplosione sarà sufficientemente grossa, sarà in grado di strappare anche questi pezzi? Per cui sparando loro sarà possibile far saltare altri componenti della nave in maniera più o meno casuale.

Questa è soltanto la fase di preparazione dei danni della nave. Successivamente, passo ad assicurarmi che tutto abbia l’aspetto giusto quando si distaccherà dalla nave. Questo step comporta di preparare uno shader per i danni che abbiamo aggiunto. Ne abbiamo già parlato in passato, abbiamo uno shader dei danni procedurale che lavora progressivamente su tutta la superficie della nave. Per far ciò, utilizziamo quella che chiamiamo la configurazione UV2… Gli UV rappresentano la maniera in cui le texture vengono mappate sulla superficie della vostra nave, ed in più esiste un altro set di UV che riguardano la propagazione dei danni e del livello di degradazione della nave. In questo caso, si crea un reticolo che assomiglia molto alla forma della nave e, partendo da qui, si fanno una serie di prove, perché non c’è una vera e propria metodologia da seguire. Modifichiamo tutto man mano che ci lavoriamo sopra. Tuttavia, con l’andare avanti la qualità tende a migliorare, e questa è soltanto la configurazione di base.

Dunque, quello che sto facendo ora nell’editor è sparare alla nave per testarne i danni. Mi devo assicurare che ci siano due tipologie di danni: ci sono le decalcomanie che saltano fuori quando si spara alla nave, per cui un proiettile lascerà un foro con una bruciatura o un’ammaccatura. Ma ci sono anche gli shader dei danni. Ora, lo shader dei danni si comporta in maniera differente a seconda del tipo di arma che ha colpito la nave: un laser scioglierebbe in parte lo scafo, lasciando delle bruciature, mentre un proiettile ammaccherebbe il metallo. Man mano che continuerete a sparare, potreste causare un foro. In questi casi, i modellisti preparano la struttura in maniera tale che ad ogni foro corrispondano dei danni interni.

KT: Affinché sia possibile implementare questi danni, il reparto artistico tecnico deve prima prepararli. Ciò richiede di generare i contenuti che verranno mostrati con l’accumularsi dei danni. Per cui svilupperemo dei danni relativi alla struttura interna. In questa fase, come abbiamo già menzionato in precedenza, sviluppiamo la struttura interna delle ali e del corpo della nave, così da avere qualcosa da mostrare quando la corazzatura salterà via, ed inoltre realizziamo anche il passaggio iniziale di quelli che chiamiamo gli UV2. Sostanzialmente, si tratta di un secondo canale UV che utilizziamo per generare proceduralmente, al volo, una mappa alpha che dice al motore dove mostrare i danni subiti dalla nave.

PS: Dopo aver completato gli UV2 ed averli modificati per fare in modo che abbiano un bell’aspetto e che ci sia un mare di metallo fuso od altra roba, si passa agli effetti V. Ora, allo stadio di preparazione di questi effetti V partecipano tante persone. Io mi occupo principalmente della fase iniziale. Dal momento che realizzo gli shader dei danni, la procedura è divisa in due parti. Ci sono quelli che chiamiamo “i petardi”, che sono una specie di piccole cariche esplosive che creano degli shader di danno entro un certo raggio. In questo caso, mi occupo di impostare le dimensioni massime e minime di tale raggio, e poi passo a preparare le particelle visive, cose come fiamme, scariche elettriche, fumo, esplosioni e via dicendo. In realtà, non sono io a realizzare questi effetti particellari, ma li prendo da una libreria contente tutti gli effetti che abbiamo sviluppato ed inizio ad impostarli, distribuendoli dove penso che le cose possano esplodere. Qui ci sono dei tubi? Allora forse ci saranno delle fuoriuscite di gas, cose del genere.

Dopo che ho impostato tutto e mi sono assicurato che il risultato sia fantastico, quando ci sono scintille, fiamme e fumo ovunque, invio il modello ai ragazzi che si occupano degli effetti particellari e che effettuano un passaggio di ottimizzazione, assicurandosi che siano state utilizzate le librerie corrette. L’ultimo passaggio consiste nell’assicurarsi che tutto si sganci nella maniera corretta. Cose del tipo: quando un pezzo salta via, l’arma che vi è attaccata lo segue?

In genere, gli artisti si occupano di configurare le luci delle loro navi, per cui questo lavoro viene effettuato durante il passaggio artistico, e poi ci sono i componenti, per cui se salta un’ala e su di essa era attaccata una luce, quest’ultima dovrebbe seguirla. È parte del lavoro di configurazione. È buonsenso, ma… Di solito c’è anche altro da fare.

Quando si parla di luci, queste si dividono in due parti. Abbiamo quelli che sono chiamati i prefabbricati per le sorgenti luminose multiple, il che vuol dire, ad esempio, che quando un giocatore si siede nel sedile di un abitacolo ed avvia la nave, tutte le luci attorno a lui si accendono insieme. Poi ci sono quelle che chiamiamo le luci contenitori oggetti, che invece sono leggermente differenti: i container oggetti sono una nuova tecnologia, ne abbiamo parlato di recente, ma sostanzialmente quando ci sono delle luci all’interno di un container oggetti, queste sono sempre attive. Per cui le utilizziamo principalmente per gli interni, le luci estetiche che dovrebbero essere sempre attive. Se invece qualcosa richiede di dare potenza alla nave, allora si utilizzano le fonti luminose multiple. Mi occupo anche di questo durante la fase di preparazione della nave, anche se è una specie di lavoro di postproduzione che avviene nello stadio finale, quando si apportano le ultime rifiniture. Quindi sparo alla nave, mi assicuro che tutto funzioni bene ed abbia un aspetto fantastico, che non ci siano dei brutti UV, che non ci siano degli elementi penzolanti e così via…

Ma per la maggior parte, questi lavori rientrano nel passaggio artistico tecnico, e successivamente il modello viene inviato agli altri dipartimenti per la finalizzazione.

MS: Una delle sfide più interessanti che saltano sempre fuori all’ultimo momento consiste nel fatto che, quando si chiude con una nave, ci sono sempre un po’ di lavori casuali da terminare. Del genere: “Oh diamine, non posso credere di aver dimenticato di completare questa parte”, oppure si tratta di inseguire qualcosa che sembra non funzionare senza apparente motivo. Uno degli aspetti più famigerati di questa fase riguarda solitamente le collisioni. A volte si tratta soltanto di sistemare il carrello di atterraggio, mentre tutto il resto funziona come dovrebbe, ma di tanto in tanto può capire che le ruote si comportino come se fossero sempre distese, oppure la nave potrebbe precipitare attraverso il pavimento ed esplodere senza motivo apparente.

PS: Al momento sto rincorrendo alcuni di questi elementi che abbiamo lasciato in sospeso. Ci sono dei problemi con alcuni shader e con delle texture. Io poi mi sto occupando anche del malfunzionamento di un propulsore, che non restituisce i parametri corretti della bocchetta, e di un bagliore all’interno dei motori. Questi problemi verranno risolti prima che il pubblico abbia finalmente modo di vedere la nave.

MS: Si tratta semplicemente di mettere in riga queste parti, sistemarle o aiutare chi di dovere a ripulire il tutto. A volte dobbiamo sistemare il carrello di atterraggio stesso ed iniziare ad inseguire la soluzione che sembra essere la migliore per i nostri problemi. E nel lungo termine, puntiamo ad avere una libreria dei migliori fix che abbiamo apportato ai vari problemi incontrati durante lo sviluppo di una nave, così che, se in futuro si ripresentasse qualcosa di simile, potremmo ricorrere alle soluzioni già usate proprio perché sono le migliori in assoluto.

Andrew Nicholson (AN): Probabilmente io sono l’ultima persona a mettere le mani su una nave. La fase di cui mi è occupo io è ridondante, in quanto devo testare un po’ tutto quello che riguarda la nave stessa e poi farle fare avanti ed indietro con i vari reparti. Si tratta semplicemente di apportare le ultime modifiche e prendere tutto quello che abbiamo già progettato per assicurarci che la nave in gioco rispecchi quanto inizialmente previsto.

Il processo di bilanciamento è piuttosto… Bisogna essere in grado di vedere come la nave si dovrebbe comportare rispetto alle altre, dove si dovrebbe andare ad inserire in un’ipotetica classifica assieme alle altre navi. Per cui bisogna essere in grado di vedere come le varie navi si pongano tra loro e compararle. Questo è esattamente il mio compito, assicurarmi che la nave si comporti come dovrebbe, che non abbia nulla di più di quanto inizialmente previsto, che non sia più performante di quanto non dovrebbe essere, soprattutto in relazione alle capacità di volo, e che non sia troppo veloce o troppo manovrabile. La nave dovrebbe andare ad occupare esattamente il posto che le spetta. È una cosa difficile da fare e, spesso, richiede svariate iterazioni che continuano anche dopo che è stata rilasciata, coinvolgendo sia i tester interni che quelli esterni, i quali mettono in luce i vari errori o le imperfezioni del modello di volo della nave, consentendoci di sistemarlo.

Lo stesso ragionamento vale per le armi. Dobbiamo assicurarci che l’arsenale della nave non sia troppo potente, soprattutto negli scontri diretti.

Quando si tratta di trovare i problemi relativi allo sbilanciamento delle prestazioni, come ad esempio con l’equipaggiamento delle armi, è mio compito indicare ai designer responsabili della nave cosa ci sia da cambiare o quale dovrebbe essere il margine d’azione del velivolo. La Buccaneer è un altro esempio di tutto ciò: la nave dispone di un arsenale piuttosto ampio, in grado di colpire duramente. È un aspetto che mi preoccupava parecchio. Nei termini più ampi del bilanciamento, potrebbe essere leggermente troppo potente, più di quanto non dovrebbe essere.

Per cui ne abbiamo discusso, cercando di trovare un compromesso. Se fossimo stati in grado di assicurarci che la nave in sé fosse debole, ma disponesse di un notevole potenziale offensivo, allora sarebbe stato ok. Sarebbe stata bilanciata.

MS: Non sono del tutto sicuro che possa parlare già di questo argomento… Non stiamo trattando nel dettaglio tutti i vari aspetti della compagnia.

Traduzione a cura di Darnos.
Trascrizione originale completa disponibile presso Relay.
Articolo originale disponibile presso le Roberts Space Industries.