Seconda parte dell’approfondimento della Conversione delle Navi al Sistema Oggetti 2.0, ricco di dettagli ed informazioni tecniche!


  

 

AGGIORNAMENTI DAGLI STUDI – FOUNDRY 42 UK

Lavori Importanti

·        È stato completato il Controllore del Traffico Aereo.

o   Con la 3.0, per poter atterrare nelle zone controllate sarà necessario richiedere il permesso di atterraggio mediante comunicazione con il Controllore.

o   Per farlo, sarà necessario attivare il canale di comunicazione utilizzando il nuovo Sistema di Interazione.

o   Nel PU, il Controllore del Traffico Aereo non si occuperà soltanto dei permessi di atterraggio, ma regolerà anche le richieste di spawn delle navi sulle piattaforme.

·        Per facilitare i primi passi delle persone che hanno dato poco iniziare a giocare a Star Citizen, hanno creato una serie di suggerimenti su schermo che guideranno i neofiti nei loro primi viaggi per il Verse.

·        Stanno modificando la maniera in cui i giocatori spawneranno all’interno del PU.

o   Attualmente, i punti di spawn nel PU sono collegati ai letti di Port Olisar e di GrimHEX, a cui sono associati dei grafici di flusso necessari per posizionare correttamente i giocatori e riprodurre le animazioni legate all’alzarsi dal letto.

o   Con la 3.0, i possibili punti di spawn aumenteranno, ma per evitare che ciò causi un incremento esponenziale del numero e della complessità di questi grafici di flusso, stanno mettendo a punto un componente di spawn che gestirà tutte le animazioni ed i flussi di azioni correlati allo spawn.

o   In questo modo, basterà loro aggiungere questo componente agli elementi che vogliono trasformare in zone di spawn ed il sistema farà il resto, semplificando notevolmente la configurazione dei livelli.

·        Stanno implementando il Broker delle Missioni ed il Manager delle Missioni, che stabiliranno quali saranno le missioni a cui i giocatori potranno avere accesso e cosa dovranno fare per completarle, seguendone anche i progressi.

·        Stanno raffinando la logica di movimento dell’IA degli NPC per renderla più realistica e naturale, evitando bruschi ed innaturali cambi di direzione.

Team Grafico

·        Stanno ricontrollando ed implementando svariate funzionalità previste per la 3.0, tra cui la Foschia Illuminata, la Tecnologia delle Sonde Ambientali, quella dell’Illuminazione Planetaria e la tecnologia di Rendering su Texture.

·        Hanno anche migliorato il modello di illuminazione per meglio definire i riflessi generati dal Sole sul terreno all’alba ed al crepuscolo.

Team di Animazione

·        Continuano i lavori sulle armi FPS.

o   È stata completata la nuova pistola balistica Gemini l86.

o   Devono ancora apportare qualche rifinitura alle animazioni di ricarica del fucile da cecchino Arrowhead.

·        Hanno implementato e stanno continuando a raffinare le animazioni relative agli abbattimenti in mischia dei personaggi.

·        Stanno continuando a lavorare alle animazioni degli NPC per le operazioni di pattugliamento e per l’identificazione di una minaccia tramite contatto visivo/rumore.

·        Il team delle animazioni di Derby ha completato le animazioni facciali dei nuovi quest giver della 3.0, come Miles Eckart.

o   Le stanno iniziando ad implementare nel gioco.

·        La scorsa settimana hanno girato alcune riprese di mocap per delle nuove animazioni per il PU.

Team dei VFX

·        Stanno continuando a testare le nuove entità luce, principalmente per gli effetti speciali legati all’elettricità.

·        Inoltre, stanno provando il nuovo sistema degli effetti particellari sviluppato dal team grafico.

·        Stanno effettuando il primo passaggio di implementazione dei VFX di Levski.

·        Hanno completato i VFX del nuovo modello della Cutlass, che include i nuovi effetti dei propulsori e quelli relativi ai danni interni della nave.

·        Continuano i lavori sugli effetti visivi legati al volo atmosferico, su cui hanno effettuato vari test di gioco e prove.

·        Continuano anche i lavori di rifinitura dei VFX, sia di quelli delle nuove armi che delle vecchie.

Team Concettuale

·        Hanno completato la bozza della serie Origin 600.

·        Hanno anche terminato lo sviluppo di un nuovo veicolo di superficie.

Team delle Armi delle Navi

·        Hanno sviluppato dei nuovi Laser del Produttore Klaus e Verner, prendendo spunto dall’estetica delle loro armi FPS.

·        Inoltre, hanno creato dei nuovi mitragliatori a neutroni della MaxOx.

Team Artistico

·        Continuano i lavori sulla Stazione Mineraria Shubin, di cui stanno migliorando gli interni per renderli più credibili.

·        Hanno creato dei nuovi elementi di supporto per le capsule abitative, tra cui dei collettori dell’acqua, sistemi di comunicazione portatili, ecc.

·        Hanno implementato nuove texture ed oggetti artistici per vari elementi del Sistema Stanton, come ad esempio le nebulose.

o   Queste risorse verranno anche utilizzate per Squadron 42, per cui stanno testando una serie di funzionalità aggiuntive.

·        Stanno creando le texture ed i materiali di rivestimento delle Stazioni di Servizio, comprese le varianti legate ad usura e danni.

o   Stanno finalizzando le strutture di queste stazioni, di cui al momento stanno ulteriormente sviluppando il modello dei pannelli solari.

o   Il team è concentrato sul completamento della stanza centrale della stazione. Una volta terminata, passeranno ad occuparsi delle sezioni anteriori e posteriori.

o   Buona parte del lavoro in corso è incentrato sull’assicurarsi che tutti i vari pezzi modulari si incastrino bene gli uni con gli altri e non appaiano ripetitivi.

o   Stanno arricchendo i dettagli delle piattaforme di atterraggio.

·        Sono stati sviluppati due nuovi archetipi degli Avamposti Planetari.

o   Il primo è un Rifugio di Emergenza, che si potrà trovare un po’ ovunque sulle lune e permetterà ai piloti che si sono schiantati con la nave di trovare riparo.

o   Il secondo è un Laboratorio di Droghe Illegali che si potrà trovare su una delle lune.

·        Hanno testato le texture ed i materiali degli Avamposti Planetari destinati ai biomi sabbiosi e ghiacciati.

o   Inoltre, stanno testando il branding procedurale degli oggetti che si potranno trovare all’interno di questi Avamposti.

Team delle Navi

·        È stata completata la Stanza dei Droni della Reclaimer.

o   Al momento si stanno concentrando sullo sviluppo del meccanismo di funzionamento dei droni e su quello di immagazzinamento dei Materiali Recuperati.

·        Inoltre, hanno terminato anche la sala motori, per cui sono state riutilizzate le risorse già sviluppate per la Idris.

o   Queste sono state reskinnate, utilizzando i materiali della Reclaimer, per rendere gli ambienti più consistenti.

·        Stanno per completare anche gli stati di danneggiamento della nave, che richiedono la creazione della geometria degli interni delle parti che sono state distrutte e sono esposte alla vista.

·        Sono in via di completamento i lavori relativi alla prima serie di navi relitto, che verranno utilizzare per creare nuovi scenari ed ambienti di missioni sia a terra che nello spazio.

o   Per ciascuna nave sono state create diverse variazioni dei materiali, per adattare l’aspetto dei relitti ai biomi in cui verranno posizionati.

o   Restano da implementare alcuni elementi visivi, come i LED, ed altri tecnici, come le collisioni.

·        Hanno aggiornato l’abitacolo della Gladius per adattarlo alla nuova esperienza dell’abitacolo.

o   Hanno modificato la visibilità del cannone gatling principale, l’accessibilità ai vari pulsanti che verranno utilizzati con il Sistema di Interazione e, in generale, migliorato le animazioni associate a queste interazioni.

o   Inoltre, è stato allungato anche lo spazio stesso dell’abitacolo per permettere ai giocatori di vedere con più chiarezza i vari elementi della plancia di comando e migliorarne l’illuminazione.

o   Si è trattato di un test di preparazione alla conversione delle navi al Sistema Oggetti 2.0, cui hanno partecipato più dipartimenti CIG per migliorare anche l’immersione dell’esperienza di gioco.

·        Stanno terminando il meccanismo di estensione del carrello di atterraggio della Hull C.

o   In aggiunta, stanno inserendo nuovi dettagli nella stiva, di cui stanno creando le prime animazioni e la versione artistica definiva.

o   Hanno completato il modello degli interni della sezione anteriore della nave, che è stato sottoposto ad un primo passaggio di illuminazione utilizzando la nuova tecnologia del Controller dei Gruppi Luci.

o   Terminata questa fase, passeranno ad occuparsi della sala motori e del tunnel centrale.

Team di Design

·        Continua la creazione di nuovi contenuti per il PU.

·        In aggiunta, hanno migliorato le mappe dell’Arena Commander e di Star Marine.

o   Hanno implementato gli asteroidi procedurali nella mappa Stella Morente (Death Star).

o   Entrambe le mappe di Star Marine hanno ricevuto diverse modifiche di bilanciamento.

·        Continuano i lavori sul design del nuovo mobiGlass, che è stato aggiornato con nuove funzionalità, come ad esempio il tracking dello stato della tuta e delle condizioni di salute del giocatore.

o   Tra i nuovi elementi, c’è anche un’app di gestione dell’equipaggiamento del giocatore, che verrà utilizzata anche per interfacciare il mobiGlass con il sistema di personalizzazione delle navi.

o   Stanno aggiornando l’UI del mobiGlass per farle utilizzare la nuova tecnologia del Rendering su Texture, che ne migliorerà la resa qualitativa.

·        Stanno progettando ed implementando l’interfaccia di creazione e personalizzazione dei personaggi.

o   La prima versione di questa interfaccia sarà limitata, ma in futuro aggiungeranno nuove opzioni e possibilità di personalizzazione.

Team Audio

·        Stanno sviluppando il sistema di generazione procedurale dell’audio ambientale dei pianeti.

·        Inoltre, stanno raffinando il sistema di produzione degli armamenti delle navi e delle armi FPS.

o   Come banco di prova, hanno usato il cannone laser Behring di dimensione 2.

·        Parallelamente, hanno anche creato dei nuovi effetti audio per le varie interfacce che saranno disponibili nella 3.0

·        Si stanno preparando per effettuare delle nuove riprese audio negli studi di Pinewood per migliorare gli effetti associati alle armature, ai vestiti ed ai passi dei personaggi.

·        Hanno continuano a lavorare ad altri sistemi fondamentali per il reparto audio, come ad esempio il sistema dello Stato Attore o quello della Propagazione Dinamica.

 

CONVERSIONE DELLE NAVI AL SISTEMA OGGETTI 2.0 – PARTE II

TLDR

·        La conversione delle navi al Sistema Oggetti 2.0 è un processo estremamente importante che ha comportato sfide di design e programmazione notevoli.

o   Buona parte di queste sfide sono state dovute alle differenze strutturali esistenti tra l’architettura del Sistema Oggetti 1.0 e quella del Sistema Oggetti 2.0.

·        In passato, i sedili erano parte integrante delle navi. Svolgevano una serie di funzionalità, come ad esempio gestire le animazioni di ingresso ed uscita dai velivoli, ma tutte queste erano direttamente collegate ai sedili stessi.

·        Durante la conversione al Sistema Oggetti 2.0 è stato necessario trasformare i sedili in qualcosa a sé stante, separando le loro funzionalità in più componenti e sottosistemi.

o   Tuttavia, ciò ha comportato una serie di problemi aggiuntivi, dovuti al modo stesso in cui erano pensate le vecchie funzioni ed alla maniera in cui erano collegate a tutti gli altri sistemi.

o   Ad esempio, hanno dovuto tagliare e dividere le animazioni di ingresso ed uscita dall’abitacolo.

·        Ciò ha comportato la creazione di svariati componenti di gioco, ciascuno dei quali gestiva una porzione delle mansioni che prima erano assegnate ai sedili stessi.

o   Ad esempio, adesso oltre al sedile, che gestisce soltanto le animazioni di ingresso ed uscita dalla postazione ed un paio di controlli, c’è anche un componente della Plancia di Comando, che invece gestisce le interazioni con il resto dell’abitacolo.

·        In aggiunta, hanno dovuto anche riscrivere alcuni elementi del codice perché inizialmente avevano dovuto “barare” per renderli compatibili con il Sistema Oggetti 1.0, cosa che ha richiesto del tempo aggiuntivo.

·        Hanno già stilato una pianificazione precisa e dettagliata dei lavori di conversione delle navi al Sistema Oggetti 2.0, ma dal momento che ciascuna di esse è unica del suo genere, è molto probabile che saranno necessari degli interventi addizionali ad hoc, specifici per ogni velivolo.

o   Un esempio di ciò è la Gladiator: nel vecchio Sistema, i sedili del pilota e del copilota non erano consapevoli l’uno dello stato dell’altro, ma entrambi erano collegati al carrello di atterraggio, per cui quando si decollava, entrambi i sedili si spostavano e diventavano inaccessibili, rendendo così impossibile al copilota di salire in un secondo momento.

·        Un altro problema riscontrato durante la conversione è stato quello dell’Host del Sedile. Nel Sistema Oggetti 1.0 avevano creano un componente chiamato Host del Sedile, il quale gestiva tutte le funzionalità dell’abitacolo, come il radar, il lancio dei missili, ecc.

o   Questo Host riceveva e mandava informazioni a tantissimi elementi delle navi, ma è stato rimosso dal Sistema Oggetti 2.0 a favore della suddivisione delle varie funzioni in più sottosistemi.

o   Per sopperire alla rimozione di questo componente, tutti i vari sistemi che si appoggiavano a lui sono stati modificati per fare in modo che si richiamassero non più al sedile stesso, bensì ai singoli componenti cui sono riferiti.

o   Questo vuol dire che nel Sistema Oggetti 2.0, la UI dello stato di alimentazione della nave è collegata direttamente al generatore di energia e lo controlla senza passare per altri intermediari, semplificandone la gestione.

·        Un cambiamento importante del Sistema Oggetti 2.0 è la gestione degli eventi in gioco.

o   In passato, c’era un Sistema Eventi che inviava a tutti i sistemi e sottosistemi le informazioni su quanto stesse accadendo in gioco, ma lo faceva in maniera istantanea, utilizzando il thread principale.

o   Di conseguenza, ogni volta che venivano trasmessi gli eventi, il thread principale doveva attendere che tutti i sistemi si aggiornassero, cosa che poteva causare dei ritardi o altri problemi.

o   Con il Sistema Oggetti 2.0 è stato introdotto il Sistema Eventi multi thread, che piuttosto che trasmettere le informazioni nel momento stesso in cui vengono generate, le comprime in uno degli aggiornamenti di gruppo ed aggiorna contemporaneamente soltanto i componenti interessati da quell’evento.

o   Ogni aggiornamento di gruppo viene effettuato in momenti precisi utilizzando dei thread a parte, cosa che comporta quindi una riduzione del carico di informazioni trasmesse ad ogni aggiornamento, lo ripartisce in più thread e riduce il lavoro compiuto dal thread principale.

o   In aggiunta, adesso ogni componente e parte delle navi ha il suo Sistema Eventi associato, cosa che permetterà di effettuare degli aggiornamenti localizzati che interesseranno soltanto questo o quell’elemento di gioco.

·        Attorno a questo Sistema Eventi multi thread è stata costruita una gerarchia di controllo basata sull’approccio modulare del Sistema Oggetti 2.0.

o   Ogni elemento di una nave è gestito da un suo controller, il quale a sua volta riceve le informazioni da un’entità chiama Oggetto Utente, che è collegata al Sistema Eventi di quel determinato componente della nave e tradurrà le azioni dei giocatori in istruzioni per le luci, le armi, i motori, ecc.

o   In questo contesto, la nave stessa è diventata un Gestore di Controllo, ovvero l’elemento che permette al giocatore di prendere il controllo ed inviare le istruzioni ai vari Oggetti Utente nel momento in cui si siede nel sedile.

 

TRASCRIZIONE COMPLETA

Mark Abent (MA): La scorsa settimana abbiamo parlato della conversione di tutte le nostre navi al Sistema Oggetti 2.0, che è un processo estremamente importante. Oggi, voglio descrivervi alcune delle sfide che abbiamo affrontato in questo ambito.

Prendiamo i sedili: sono abbastanza semplici, ci permettono di entrare ed uscire dalla nave ed hanno un altro paio di funzioni di base. Ma funzionano soltanto con i veicoli: sono parte integrante della loro stessa logica, per cui uno dei passaggi obbligati per la conversione al Sistema Oggetti 2.0 comportava di trasformare i sedili in qualcosa di più generico. Si può dire che siano il punto di collegamento tra il veicolo ed il Sistema Oggetti 2.0. Per far questo, abbiamo dovuto suddividere i sedili in elementi individuali per implementare le animazioni di ingresso ed uscita e tutto il resto. Ma quando abbiamo iniziato a trasferire al nuovo sistema tutte le varie funzioni, siamo incappati in alcuni problemi che avevamo risolto nel vecchio sistema, ma che necessitavano di un approccio completamente diverso ne nuovo.

Mettiamo di avere un caccia monoposto ed apriamone l’abitacolo, facciamo uscire la scaletta e quindi saliamoci sopra per entrare all’interno della calotta. Con i vecchi sedili avevamo degli elementi chiamati post-azioni… E penso ci fossero anche le pre-azioni. Sostanzialmente, riproducevano l’animazione di apertura dell’abitacolo e poi il giocatore poteva entrarvi dentro, sedersi, e la calotta gli si chiudeva sopra. Con il sistema 1.0 non era possibile dire al veicolo di riprodurre queste animazioni, ma era possibile dire all’animazione stessa di partire. Ma i sedili del primo sistema erano stati utilizzati anche per le navi multiequipaggio, in cui non era necessario riprodurre le animazioni della nave, ma soltanto quelle relative al sedile stesso. Ad esempio, nella Retaliator c’è l’animazione di avvicinamento ed interazione con la plancia di comando. Tutti questi elementi erano separati dalla nave stessa, ma per riprodurli erano comunque necessario passare dal sedile della nave. Per cui avevamo due differenti tipologie di sedili, ciascuna delle quali risolveva un problema diverso. Ma con il Sistema Oggetti 2.0 volevamo rimuovere queste due versioni dei sedili e creare un sistema che risolvesse entrambi questi problemi. Per cui abbiamo dovuto realizzare sia una componente sedile, che una componente plancia del sedile, così che il sedile fosse responsabile soltanto dell’animazione di entrata ed uscita del giocatore, nonché dell’assegnazione del controllo del sedile. E nient’altro. Invece la plancia, che è poi l’infrastruttura che vedete intorno a voi nell’abitacolo, mostra la UI, la cloche e tutto il resto. In più, comunica con il sistema di accesso al sedile, che determina come vi siete seduti in quel sedile. In questo modo potevamo replicare quanto già facevamo con il vecchio sistema, ma come avete visto abbiamo dovuto suddividere le varie funzionalità in più componenti.

Ora abbiamo tre diversi elementi che gestiscono aspetti che prima erano associati esclusivamente alla nave. Per cui dovevamo prendere tutte le risorse, ripartirle ed inserirle in questi componenti. Dovevamo spacchettare tutte le animazioni nei vari stati. È vero, il sistema ci permette di avere una maggiore flessibilità e capacità di interazione, ci permette di fare cose che non erano possibili con il vecchio sistema. Cose che alcuni ragazzi del team delle animazioni volevano implementare da tempo. Ma per via del modo in cui erano stati progettati i vecchi sedili delle navi, siamo stati costretti a tornare sui nostri passi e riguardare l’approccio che avevamo seguito all’epoca. Abbiamo dovuto cambiare svariati elementi artistici, abbiamo dovuto modificare l’intero processo, estrarre le animazioni, dividerle per tipologia, tutto per far sì che fossero compatibili con la nuova infrastruttura del Sistema Oggetti 2.0.

Inoltre, all’inizio avevamo provato ad implementare delle funzionalità che, in un secondo momento, si erano rivelate essere impossibili da inserire nel vecchio sistema, per cui avevamo dovuto usare qualche trucchetto. Tuttavia, proprio per questo motivo siamo stati costretti a ritornare su questi elementi e modificarli, riportarli a quello che era il loro design iniziale, riscriverli nella maniera in cui avevamo voluto implementarli fin dall’inizio. Ciò ha richiesto tantissimi incontri con il team di design e quello delle animazioni. È un passaggio addizionale che è stato necessario effettuare per convertire tutto al nuovo sistema, e questa è una delle ragioni per cui questo lavoro sta richiedendo così tanto tempo.

In realtà, abbiamo un piano ben dettagliato che riporta la maniera in cui convertiremo tutte le navi al nuovo sistema, comprensivo delle operazioni di ripartizione delle risorse nei nuovi componenti. I punti in cui tagliare le animazioni, dove spostarle, dove mettere i vari oggetti, più i test correlati. E questo andrà fatto per tutte le navi, che di per sé sono già uniche e diverse le une dalle altre, per cui ciascuna di esse necessiterà di attenzioni particolari. Ma dal momento che abbiamo un piano ben preciso che indica come ogni configurazione si dovrà comportare, ci resta soltanto da capire come potremo fare per esportare e dividere tutti i vari pezzi così che risultino essere compatibili con la nuova infrastruttura. Una delle precauzioni che stiamo adottando con tutte le nuove navi consiste nell’imparare dai problemi del passato, da tutto quello che di sbagliato o differente abbiamo fatto e che ha causato bug su bug.

Una bellissima nave che ci ha strappato più di qualche sorriso è la Gladiator. Al suo interno ci sono due sedili, che si trovano nella parte alta del velivolo, mentre in quella bassa è situato il portellone del vano delle bombe. Inizialmente, volevamo che entrambi i sedili si abbassassero contemporaneamente, mentre il carrello di atterraggio si sarebbe dovuto alzare, permettendo la chiusura del vano bombe. Ma così facendo, sia il pilota che il copilota sarebbero dovuti entrare nello stesso momento, perché una volta abbassati i sedili non sarebbe stato possibile salirci sopra. Fortunatamente, siamo riusciti a dividere la logica in maniera tale che i due sedili fossero indipendenti gli uni dagli altri. Tuttavia, restava il problema dell’animazione portellone del vano delle bombe, perché questo era collegato al sistema di atterraggio ed al sistema dei sedili, che è costituito da due diversi collegamenti con i sedili che, nel vecchio sistema, non erano l’uno consapevole dello stato dell’altro. Per cui tutto il meccanismo non funzionava benissimo. Ma ora, con il Sistema Oggetti 2.0, possiamo lasciare lo sportello del vano bombe aperto, per cui possiamo aprire per primo questo, poi il giocatore può scendere… Ciascuno dei due piloti può scendere, ed i sedili torneranno a posto per conto loro senza problemi. Per cui anche se abbiamo già tutta una serie di sistemi pronti o in fase di completamento, ogni nave è un caso speciale a sé stante e dobbiamo assicurarci che tutto funzioni anche dopo la conversione al nuovo Sistema Oggetti. Anche dopo che avremo separato il sedile dal resto della nave, trasformandolo in questa specie di elemento ibrido chiamato sedile 1.0.

In passato, c’era un elemento chiamato “Host del Sedile”, il cui scopo era quello di rimuovere dalla nave quella parte di logica di gioco collegata al sedile stesso, per trasformarla in qualcosa di più generico. Era uno dei primi tentativi che abbiamo fatto per far funzionare le navi, ma finì per diventare una strana miscela di più cose, perché la adottammo per un po’ tutto, dal controllo della nave, a quello delle torrette e via dicendo. Ma per questo motivo, molti altri componenti delle navi iniziarono a fare affidamento su questo Host del Sedile, per cui il codice del giocatore andava a controllare se l’utente fosse agganciato ad esso, poi c’era l’UI che controllava se il giocatore fosse seduto nel sedile e così via. Per cui tantissimi sistemi si richiamavano a all’Host del Sedile. Era un approccio orribile, ma era anche l’unico modo in cui potevamo far funzionare tutto nel mentre che separavamo le varie funzioni in componenti a sé stante. Ed ora dobbiamo prendere tutti queste elementi che facevano affidamento sull’Host del Sedile e trasformarli in qualcosa di più generico.

Una delle sfide più grandi sarà ovviamente l’UI: elementi come il visore facevano grande affidamento sull’Host del Sedile, perché lo usavamo per leggere gli eventi e le informazioni di gioco. Cose come l’identificazione di una nave, il lancio dei missili e così via. L’UI riceveva queste informazioni, e se non interessavano il giocatore poteva ignorarle, anche se ciò non avveniva in tutti i casi, o per tutti gli eventi di gioco. Per cui l’UI otteneva i dati relativi agli avvenimenti in gioco tramite l’Host del Sedile. Ma dopo la scomparsa di questo componente, il registro eventi aveva preso a crashare e sperimentammo una serie infinita di problemi. Per risolverli, ideammo una nuova architettura per la UI dei sedili, che avrebbe fatto affidamento più sui componenti oggetto stessi, piuttosto che sul sedile. Ciò ci ha permesso di concentrarci esclusivamente sui vari oggetti, così che, ad esempio, l’UI relativa allo stato di alimentazione della nave si sarebbe basata esclusivamente sullo stato del generatore di energia ed avrebbe ignorato la nave, avrebbe ignorato il giocatore e qualsiasi cosa a cui questo sarebbe stato agganciato. Il vantaggio di questo approccio è che, teoricamente, io potrei agganciare questa UI ad un distributore Big Benny dotato di un generatore di energia e potrei vedere il suo stato di alimentazione. Ma questo era l’obiettivo finale, e separare tutti i vari componenti della UI è stata una delle modifiche più grandi ed importanti che dovevamo effettuare non soltanto per la UI stessa, ma anche per tutte le altre sezioni del codice interessate.

Ci stiamo ancora lavorando, perché ad un certo punto dovevamo supportare sia il sistema 1.0 che quello 2.0, almeno fino a quando non saremmo stati in grado di effettuare il passaggio da uno all’altro, cioè fino a quando non avremmo potuto premere il pulsante che avrebbe decretato l’abbandono della 1.0. Per cui al momento abbiamo la UI che si basa sull’Host del Sedile, la UI che è in grado di leggere lo stato di alimentazione della nave indipendentemente da tutto il resto e ci troviamo in una situazione piuttosto strana, perché stiamo continuando a lavorare cercando di non spaccare il vecchio sistema, almeno fino a quando non saremo pronti per il passaggio a quello nuovo.

Un altro cambiamento architetturale piuttosto grosso su cui stiamo lavorando riguarda i veicoli stessi.  In passato, i vari componenti si appoggiavano ad una funzionalità chiamata Sistema Eventi che identificava gli eventi relativi al veicolo e li trasmetteva ai componenti interessati. Dal momento che lo usavamo per praticamente tutto: uno, ogni elemento del gioco lo usava e, due, permetteva la comunicazione istantanea di nuovi dati tramite il thread principale. Questo vuol dire che, se volevo mandare un evento a tutti i vari sistemi, il thread principale doveva aspettare fino a quando questi non avevano ricevuto quella particolare informazione ed avevano effettuato gli aggiornamenti necessari. Dal momento che l’evento veniva comunicato istantaneamente, il radar registrava immediatamente il segnale dei nemici, la comparsa di navi ostili, e la UI creava le risorse necessarie per mostrare questo dato. Per cui quando viene inviato un nuovo evento, succedono tantissime cose diverse, che interessano ambiti differenti del codice.

Uno degli elementi che abbiamo modificato è stato il funzionamento di questo meccanismo: piuttosto che avere un Sistema Eventi single thread, abbiamo implementato una funzionalità chiamata Sistema Eventi multi thread e piuttosto che collegare tutto al Sistema Eventi del veicolo, abbiamo creato un Sistema Eventi per ciascun componente, che inoltre si può interconnettere con quello degli altri oggetti. Per cui se adesso voglio sapere cosa che stia accadendo sul radar, posso collegarmi direttamente ad un componente chiamato Banca Dati del Radar, perché quando il radar identifica un nuovo segnale, questa informazione viene inviata direttamente alla Banca Dati. Questo a sua volta non elaborerà immediatamente il dato ricevuto, ma lo farà con uno degli aggiornamenti di gruppo di cui abbiamo parlato la scorsa volta, cioè si terrà il dato fino a quando non sarà arrivato il suo momento di aggiornare lo stato del gioco, quindi lo elaborerà ed invierà le nuove informazioni ai sistemi interessati, il tutto utilizzando un thread a parte. E gli altri sistemi faranno la stessa identica cosa, con il risultato che avremo diviso un flusso dati estremamente pesante in più parti, garantendoci la corretta ricezione di tutti i dati al momento giusto.

Grazie a questo Sistema Eventi, potremo anche permetterci di localizzare gli eventi stessi. Prima stavo dicendo che abbiamo separato il personaggio che controlla la nave dal sistema di controllo dei vari oggetti, che chiamiamo Utente Oggetto. L’Utente Oggetto utilizza gli eventi principali, che noi definiamo eventi di input, i quali non sono altro che i dati trasmessi in uscita dal Sistema Eventi. È in grado di ricevere input da qualsiasi elemento di gioco e può inviare dei dati di output in risposta a queste informazioni. Per cui se premessi un pulsante, l’Utente Oggetto riceverà l’evento ed accenderà, ad esempio, le luci, traducendo questo avvenimento in un messaggio di output che informerà tutti gli oggetti interessati dell’emissione di calore. Ma questa trasmissione avverrà solo quando sarà il momento giusto, quando gli elementi interessati saranno pronti a riceverla. Per cui il giocatore potrà premere un bottone, accendere le luci e questa azione trasmetterà un evento al controllore incaricato delle luci, che quindi lo riceverà in un aggiornamento di gruppo e, a sua volta, genererà un nuovo evento che informerà tutte le luci del fatto che si dovranno accendere. Le luci a loro volta scaricheranno l’informazione in un aggiornamento di gruppo e, in base a quei dati, sapranno se dovranno accendersi, se dovranno spegnersi e via dicendo. Per cui ora abbiamo trasformato tutte queste funzionalità in un sistema più generico e globale, non più strettamente legato al veicolo, e possiamo trasmettere gli eventi soltanto a dei componenti specifici, ottenendo quindi un sistema più localizzato. Il tutto utilizzando il meccanismo degli aggiornamenti di gruppo e l’intera infrastruttura di oggetti e controller che abbiamo realizzato con il Sistema Oggetti 2.0.

E questa è un’altra caratteristica del nuovo sistema, perché nel vecchio sistema 1.0, quando un giocatore si sedeva in una nave, prendeva il controllo di tutte le armi, i vari sistemi, ecc., ma ciascuno di essi utilizzava una propria logica. Se premevo il pulsante per sparare, il sottosistema correlato eseguiva il suo codice e sparava. Abbiamo voluto suddividere tutto questo in una struttura più solida e coerente, per cui dopo diverse discussioni con il dipartimento di design abbiamo elaborato un nuovo approccio secondo cui ogni nave è un Gestore di Controllo. L’utente, il giocatore, si connette a questo Gestore di Controllo quando prende posto nella nave ed invia le istruzioni direttamente ai vari controller a monte di ogni componente. Per cui adesso c’è un controller per l’energia, uno per le luci, uno per le porte e via dicendo. Ciascuno di essi gestirà i vari sottosistemi a cui sono assegnati, ricevendo gli input del giocatore e ritrasmettendoli agli elementi di gioco. Questo vuol dire che un controller dell’alimentazione gestirà tutti i sottosistemi di alimentazione, vi riferirà il loro stato attuale e riceverà le vostre istruzioni tramite la UI, o tramite la manetta, per modificare la quantità di energia trasmessa ai propulsori. Ed ogni volta che gli direte di fare qualcosa, verificherà se potrete o non potrete compiere quell’azione e comunicherà i comandi ai componenti della nave. Quest’ultimi quindi non sono altro che dei pezzi fittizi che gestiscono una logica di gioco estremamente specifica. Ad esempio, se un generatore di energia deve fornire X potenza alla nave, il controller dell’energia riceverà l’input dalla UI, dall’utente, e lo tradurrà in istruzioni per i sotto-oggetti, che effettueranno quelle operazioni specifiche e soltanto quelle. Nel complesso, abbiamo realizzato un meccanismo composto da elementi estremamente specializzati che gestiscono quella che chiamiamo la gerarchia di controllo.

Come Ash ha ribadito la scorsa settimana, sebbene l’implementazione di questa tecnologia richieda tantissimo lavoro, cambierà radicalmente l’esperienza di gioco. Il Sistema Oggetti 2.0 tocca ogni aspetto di Star Citizen e permetterà di creare un’esperienza di interazione molto più immersiva.

Redazione a cura di Darnos.
Articolo originale disponibile presso le Roberts Space Industries.