Star Engine e la tecnologia dietro Star Citizen

La tecnologia dietro Star Citizen dal 2012 è cambiata nel tempo e in maniera complessa. Ricercare le informazioni – e le fonti – per questo articolo non è stato facile, così come non è stato facile scriverlo: parlare di Star Citizen è spesso e volentieri complicato, anche per chi lo segue da tempo e nel dettaglio. È come cercare di descrivere un fiume che nasce in un modo, si evolve nel tempo e la cui foce rimane sempre a tre-quattro anni di distanza, a prescindere da dove ci si trovi.

C’è chi dice che un fiume del genere non esiste, o che lo scopo del fiume è semplicemente quello di continuare ad esistere per sempre, a scapito della pioggia che ne permette il flusso costante e impervio. Ed è la sua stessa natura indomita, indefinita e in continuo cambiamento a rendere questo progetto così difficile da spiegare e così facilmente prono a mistificazioni, incomprensioni e superficialità.

Spesso non ci si rende conto della quantità di lavoro che è stato fatto – e rifatto – negli anni per rendere il gioco possibile. Tra i videogiocatori si discute ogni tanto sul perché un altro motore di gioco sarebbe stato migliore, di come il gioco sarà vecchio all’uscita e di incredibili tecnologie che la concorrenza ha e che a Star Citizen mancano. Lo scopo di questo articolo è di ripercorrere la storia tecnologica di Star Citizen, o almeno di scalfirne un po’ la superficie. Anche se non è la prima volta che si parla e si cerca di analizzare Star Citizen dal punto di vista tecnologico, Digital Foundry ha fatto dei video e degli articoli non troppo tempo fa, è comunque importante almeno tentare di dare un’idea chiara della situazione attuale e della strada percorsa.

C’ERA UNA VOLTA IL CRYENGINE 3

Tutto ha inizio dal motore di gioco, da quel contratto firmato da Crytek e Chris Roberts nel 2012, dove si permetteva alla Cloud Imperium di utilizzare il CryEngine per sviluppare Star Citizen e Squadron 42. Il contratto permetteva di modificare il motore di gioco in modo da andare incontro alle esigenze della Cloud Imperium.

Sul perché abbiano preferito il CryEngine ad Unreal, lo dirà Chris Roberts nel 2016: Unreal Engine 4 al tempo non era molto maturo a differenza del CryEngine 3, e in ogni caso avrebbero dovuto comunque modificare enormente il motore di gioco per rendere Star Citizen possibile. In un’altra intervista del 2013, spiegò invece perché non avesse deciso di crearsi un suo motore di gioco: avrebbe richiesto tempo e inizialmente si era dato tempistiche strette. Ecco dunque che bisognava partire subito e partire veloci, realizzando la tecnologia necessaria in corso d’opera.

Inizialmente dunque alcune tecnologie sono state implementate anche tramite middleware, ovvero tecnologie di terze parti, come per esempio Kythera AI, FMOD (per poi passare a Wwise nel 2014, che viene usato ancora oggi), Scaleform (parzialmente ancora in uso), FoIP di Faceware e Gene Splicing di 3Lateral. Contemporaneamente si lavorò per creare le tecnologie per rendere la visione di Star Citizen possibile, una visione che è diventata tecnicamente sempre più ambiziosa negli anni rispetto al progetto iniziale, al punto da dire che l’importanza di Star Citizen è legata alla sua ambizione: “Star Citizen matters BECAUSE it is big“.

Dal 2012 il gioco ha usato il CryEngine come base tecnologica, aggiornandolo fino alla versione 3.7-3.8. Ciò avvenne nel 2015, quando decisero di staccarsi dagli update di Crytek, in quanto era sempre più difficile integrarli senza che andassero in conflitto con gli altri elementi e tecnologie.

LUMBERYARD SOLO DI NOME?

Nel 2016 annunciarono il passaggio al Lumberyard, che in realtà fu principalmente un passaggio di licenza. Il Lumberyard non è altro che il CryEngine acquistato, modificato e distribuito da Amazon. Inoltre durante la causa legale tra Cloud Imperium e Crytek si è scoperto che Amazon aveva dato anche la licenza per lo stesso CryEngine che stavano utilizzando.

A livello tecnico dunque non ci sono stati cambiamenti significativi nel passaggio tra CryEngine e Lumberyard. Il Senior Graphics Programmer Ben Perry, attualmente in Nequinox Studios, e il Lead Gameplay Engineer Chad McKinney hanno dichiarato nel Maggio 2020 di come l’Engine utilizzato dalla Cloud Imperium è stato così ampiamente modificato da rendere l’esperienza passata su Cryengine o Lumberyard non troppo rilevante per un nuovo arrivato.

Questo perché nel tempo Cloud Imperium ha sviluppato molti strumenti proprietari, cambiando e modificando intere sezioni del motore di gioco, al punto da chiamarlo internamente Star Engine, anche se sembra che ora il nome sia Vers3D. Per rendere una idea, Clive Johnson, Lead Network Programmer, ha fatto una lista su Spectrum di circa un centinaio di elementi sulle modifiche e aggiunte che sono state fatte al motore di gioco nel tempo… e non era una lista esaustiva.

LE TECNOLOGIE CREATE

È dunque praticamente impossibile andare a toccare ogni modifica e novità tecnologica realizzata, ma cercheremo di trattare e spiegare quelle più importanti. Quelle tecnologie che possono essere considerate fondamenta necessarie per lo sviluppo e la realizzazione di Star Citizen. Tecnologie che rendono l’opera di Chris Roberts possibile, e che sono state create tenendo presente i bisogni specifici della Cloud Imperium.

SISTEMA DI COORDINATE A 64 BIT

L’essenza dei giochi spaziali è banalmente… lo spazio. Molto spazio. La Cloud Imperium ha lavorato su questa tecnologia nel 2014 e nel 2015, e alla fine di quello stesso anno è stata implementata con il rilascio dell’Alpha 2.0.

La maggior parte dei motori di gioco non hanno un sistema di coordinate a 64 bit e questo limita molto l’estensione della mappa in un gioco multiplayer. Nativamente, l’Unreal Engine 5 attualmente non risulta avere questa feature, anche se si stanno attivamente muovendo per implementarla. Lumberyard non ha questa feature. E anche il CryEngine sembra essere messo allo stesso modo (non si trova alcuna fonte che dichiari un loro supporto ad un sistema di coordinate a 64 bit).

Sia chiaro: un sistema di coordinate a 64 bit porta svantaggi: permette di avere un’area di gioco enorme, ma richiede anche più risorse. Giochi come No Man’s Sky e Space Engineers usano soluzioni proprietarie, così come fa anche Star Citizen.

DATAFORGE e ITem 2.0

Dataforge è uno strumento sviluppato internamente per salvare e modificare dati. Il CryEngine usava file XML che si erano dimostrati nel tempo sempre meno adatti alla complessità e alle continue modifiche che Star Citizen necessita.

Hanno iniziato il suo sviluppo nel 2014 ed è stato usato dal 2016 in poi. Questo strumento è stato molto importante nalla gestione degli Item 2.0, un’altra tecnologia che permette agli elementi di essere interconnessi in maniera coerente e scalabile. Item 2.0 è una tecnologia che hanno sviluppato nel 2017 e che ha richiesto sforzi enormi per la compagnia nel convertire tutto a questa feature, tant’è che durante il 2018 questo processo era ancora in corso.

TECNOLOGIA PLANETARIA

La tecnologia planetaria è sicuramente una delle Major Feature di Star Citizen. Rappresenta il fulcro della logica semi-procedurale, l’idea che la proceduralità debba essere comunque messa al servizio degli artisti, più che essere lasciata andare controllata da fredde regole matematiche, come per esempio succede in No Man’s Sky o Elite: Dangerous.

Attualmente siamo arrivati alla quarta versione della Tecnologia Planetaria, una versione che a distanza di due anni ci lascia ancora a bocca aperta. Una tale tecnologia semiprocedurale è praticamente unica nel mondo videoludico. Per ulteriori informazioni sulla tecnologia planetaria, vi invitiamo a leggere il nostro speciale dedicato.

SUBSUMPTION AI

Nel corso del 2017 la Cloud Imperium lavorò per lasciarsi alle spalle Kythera AI e implementare la tecnologia proprietaria Subsumption AI. Questa tecnologia è stata pensata per poter gestire l’enorme varietà di IA che Star Citizen richiede: dagli NPC che combattono dentro ad un bunker sotteraneo alla nave pirata che vi sta attaccando, passando per il comportamento dei civili e il loro uso di props.

Il tutto tenendo a mente che alcune funzionalità previste non sono ancora state implementate, come le routine dei civili, la possibiltà di avere NPC come equipaggio della propria nave e la facoltà dei nemici di passare dallo spazio al combattimento a terra.

Problemi dopo problemi, parte delle potenzialità di questa IA si è vista con il barista nella 3.10, dove quando funzionava (causa prestazioni del server) dava davvero l’impressione di relazionarsi coerentemente con lo spazio circostante. Certo, la strada sembra ancora un po’ lunga, ma il potenziale ci fa ancora sognare.

BIND CULLING, OBJECT CONTAINER STREAMING CLIENT-SIDE E SERVER-SIDE

Nel 2016 la Cloud Imperium iniziò a parlare di Bind Culling. Sarebbe dovuta essere la tecnologia che avrebbe permesso un radicale aumento delle prestazioni lato client. Prevista e rimandata patch dopo patch, la Cloud Imperium è riuscita ad implementarla insieme all’Object Container Streaming Client-Side nel 2018.

Un lavoro enorme che ha cambiato radicalmente la struttura di gestione dei livelli all’interno dell’engine. Il suo funzionamento è simile a quello di una matrioska, dove l’universo è diviso in contenitori di oggetti che racchiudono altri contenitori più piccoli. Il giocatore, entrando in gioco, caricherà solo i contenitori più vicini e non tutto l’universo tutto insieme. Il suo rilascio ha effettivamente migliorato molto le prestazioni, permettendo anche di superare a volte i 100fps. Tale magia non è però durata a lungo: il rilascio di località e feature più complesse ed esose ha ridotto di molto le prestazioni nelle patch successive.

A fine 2019 è arrivato invece l’Object Container Streaming Server-Side. Abbiamo parlato molto in passato delle particolarità di questa tecnologia. Molto semplicemente ragiona sul fatto che ci possono essere aree non necessarie sul server (perché magari non ci sono giocatori) e dunque queste aree possono venire congelate e conservate a parte. E se nell’attuale gestione delle istanze tale tecnologia non aiuta molto, questa parte risulta fondamentale in ottica Server Meshing.

BUILDING BLOCKS

Se c’è un elemento onnipresente all’interno delle aspirazioni dell’opera di Cloud Imperium, è sicuramente l’interfaccia. L’interfaccia è fondamentale per dare informazioni al giocatore su cosa sta succedendo, è fondamentale per concretizzare svariati elementi di gameplay.

Purtroppo l’uso di Scaleform faceva sì che creare e modificare interfacce fino a qualche anno fa era molto complicato e richiedeva molto tempo. Building Blocks è una tecnologia proprietaria della Cloud Imperium in sviluppo da anni e che va a semplificare enormemente quel lavoro, permettendo ai designer di creare una interfaccia grezza ma funzionante, sulla quale il team UI realizzerà una versione esteticamente gradevole. E se Scaleform e Flash sono ancora presenti in parte, l’idea della compagnia è di andare a sostituire tutto con elementi proprietari.

LE TECNOLOGIE IN ARRIVO

E se questo può sembrare già un lavoro impressionante, il grosso non è ancora arrivato. Ci sono cinque tecnologie su cui stanno estensivamente lavorando e che arriveranno in un prossimo futuro.

GEN 12 RENDERER

Un nome poco entusiasmante per un rework che lato visivo non porterà in teoria cambiamenti. Rappresenta tuttavia un cambiamento tecnologico radicale, poiché rappresenta un completo rework della parte di rendering del motore di gioco.

Un aggiornamento tecnologico importantissimo per implementare anche le API Vulkan, che saranno probabilmente anche le uniche API supportate in futuro, e che dovrebbero portare notevoli miglioramenti alle prestazioni lato client.

Il Gen 12 è in sviluppo da più di due anni ormai e se in passato avevano dichiarato che una prima parziale versione sarebbe arrivata con la 3.14, oggi non è chiaro se richiederà ancora un po’ di tempo. Sicuramente non è lontano.

EDIT 30/07/21: La CIG ha confermato su Spectrum che alcuni elementi del Gen 12 sono presenti nella 3.14, pur non avendo questi un impatto tangibile sulle prestazioni. Sarà l’implementazione vera e propria del Renderer a dare i miglioramenti sperati.

PERSISTENZA E ICACHE

Il più grande contrabbandiere del sistema ha nascosto un piccolo ma preziosissimo tesoro in un luogo sconosciuto nella luna X del pianeta Y. Lui non lo sa, ma le voci sono iniziate già a circolare. Quel tesoro forse non rimarrà a lungo nelle sue mani.

Si parla da anni di persistenza completa: la facoltà di posare un oggetto in qualsiasi punto del ‘Verse e ritrovarlo lì anche dopo una settimana. Certo, lasciare qualcosa in giro significa anche rischiare che qualcuno lo trovi, NPC o player che sia, ma fa parte del gioco. L’idea è che ci siano comunque dei sistemi per prevenire una tale quantità di oggetti in un luogo da far andare eventuali giocatori nella zona a 10fps.

Questa tecnologia è collegata necessariamente alle fondamenta tecnologiche del gioco e ciò rende tutto più complicato, viste le ambizioni del titolo. Per rendere un’idea, nel 2020 si è parlato molto del funzionamento di iCache, ovvero la complessa infrastruttura del database dove verranno conservati i dati della persistenza. Un sistema che non solo deve essere scalabile, ovvero deve poter gestire potenzialmente milioni di giocatori, ma deve anche non andare in crisi in caso di errori o bug nel gioco, il tutto supportando le tecnologie già presenti e quelle che arriveranno in futuro, come il server meshing.

Non soprende dunque che lo sviluppo della persistenza abbia richiesto più tempo del previsto, ma ci siamo. Una prima versione è attualmente prevista per la fine del 2021.

DANNI FISICALIZZATI

John Crewe, Vehicle Director, parlando dei condesatori li definì come un cambiamento molto grande in arrivo per la 3.14. Parlando poi dei danni fisicalizzati, disse che sarebbe stato un “cambiamento apocalittico“. Ecco, i danni fisicalizzati non cambieranno un po’ il gameplay: in un certo senso cambieranno il gioco.

Non è un segreto l’attuale gestione della “vita” della nave. Ogni nave è divisa in sezioni, dove ogni sezione ha una barra della vita dedicata. Quando la barra di una sezione vitale arriva a zero, la nave intera esplode. Questo sistema è temporaneo e verrà in futuro sostituito dai danni fisicalizzati, ovvero il danneggiamento fisico dello scafo a causa dei danni. Danni che potranno portare a varchi nello scafo, danneggiamento di componenti interni e quindi non necessariamente una distruzione completa della nave, ma una sua più probabile disabilitazione.

Ciò rappresenta il famoso passaggio dal “time to kill” al “time to disable”, che permetterà di aprire le porte a gameplay più complessi ed emergenti, come un tentativo di catturare vivo un criminale o la necessità di riparare quel che rimane della propria nave. Inoltre sembrano del tutto intenzionati ad usare questa tecnologia anche per il resto del gioco, con tutti i cambiamenti che ciò comporta.

Attualmente non abbiamo idea delle tempistiche per una implementazione in-game. Sappiamo dal Progress Tracker che del lavoro sulla tecnologia si è concluso a Giugno 2021 e anche sperando che non servano altri sistemi e altro lavoro sulla tecnologia in sé, chi scrive ritiene che la conversione alla nuova tecnologia per le navi difficilmente richiederà meno di 6 mesi. Forse anche un anno.

SERVER MESHING

Inizialmente non era previsto alcun Server Meshing. L’idea iniziale di Chris era di creare delle istanze dinamiche in caso di presenza di altri giocatori nella zona, in modo da dare un’idea di esperienza continua e multiplayer in un gioco dove tutto era frammentato e non necessariamente gestito da dei server.

Era il design di un gioco sostanzialmente differente rispetto a quello che sta diventando negli ultimi anni, dove la parola chiave è invece “Server Meshing”. Un elemento critico, citando lo stesso Chris Roberts, che deve essere realizzato per permettere all’attuale visione del gioco di concretizzarsi, permettendo ai server di dividersi in maniera invisibile aree e persone. Lato tempistiche, lo stesso Chris non si è sentito in grado di farne, allontanando le speranze di vedere una prima rudimentale implementazione per la fine dell’anno.

Su come funzionerà invece il Server Meshing, abbiamo in passato tradotto un lungo intervento di Clive Johnson su Spectrum. Nella sua prima implementazione il server meshing sarà un ponte tra server diversi che gestiranno zone diverse. Nella sua versione finale, ancora non definita completamente lato tecnico, i vari server gestiranno invece i gruppi di giocatori vicini tra loro e i singoli client potranno ricervere informazioni da più server, permettendo dunque di avere un’unica grande istanza che comprende tutti i giocatori.

Ovviamente rimangono molti punti interrogativi: desync, capacità di riuscire a mitigare il ping tra le varie aree del mondo e la capacità della Cloud Imperium stessa di riuscire a creare un sistema tanto complesso e dinamico quanto stabile. Questo però non dà meno valore all’enorme lavoro tecnico portato avanti dalla Cloud Imperium nel cercare di oltrepassare i limiti di un motore di gioco non pensato per gli MMO.

QUANTUM

Chris non ha mai nascosto di voler creare un universo dinamico. Un universo pieno di NPC e dall’economia solo parzialmente controllata dai giocatori. Quantum rappresenta l’elemento tecnico per raggiungere tale risultato: una simulazione di universo, il Matrix di Star Citizen. I giocatori sono nella simulazione e la influenzano. La simulazione definisce poi i prezzi delle merci, gli incontri e altri elementi di gioco. Un lavoro tecnico enorme, poiché la simulazione non solo deve funzionare di per sé, ma deve costantemente ricevere, elaborare e mandare le varie informazioni necessarie per il corretto funzionamento dei vari sistemi di gioco.

Per chi volesse recuperare le varie informazioni date in questi anni, potete trovare sia l’articolo sul panel del 2019, sia l’AMA realizzato nel 2020 e anche un video-riassunto delle ultime novità relative al 2021. E se andrà tutto bene, una prima parziale implementazione di Quantum dovrebbe arrivare proprio per la fine del 2021.

PARLANDO DEL FUTURO

Chris in una intervista di fine 2019 dichiarò di guardare con molto interesse due tecnologie d’avanguardia: il ray tracing e un’altra che avrebbe permesso ai giochi di fare a meno dei poligoni. Il Ray Tracing potrà in teoria essere implementato sfruttando le API Vulkan, e il loro arrivo è legato al Gen 12 Renderer.

Sulla seconda tecnologia Chris non è stato molto chiaro: è molto probabile che si riferisse ad una implementazione più corposa nei giochi della tecnologia Voxel, ma non è del tutto escluso che si potesse riferire alla possibilità di non pensare ai LOD nel realizzare un gioco, un po’ come sarà possibile fare con la tecnologia Nanite dell’Unreal Engine 5.

In ogni caso una cosa è chiara. Nel gestire Star Citizen come un prodotto in continua evoluzione, la Cloud Imperium ha tutta l’intenzione di adattare e inserire tutte quelle tecnologie che possono permettere al gioco di stare al passo con i tempi. È probabile che sarà più una rincorsa che una avanguardia: il gioco intende sfruttare al massimo quello che già c’è, focalizzarsi su alcune tecnologie proprietarie avveniristiche e non rimanere troppo indietro con il resto. Ragionando attentamente su ogni passo da fare, cercando di capire quando una tecnologia è abbastanza matura da essere implementata senza troppi problemi.

QUELLO CHE SERVE PER RIMANERE

Andare in esplorazione tecnologica significa camminare per terreni incerti e potenzialmente pericolosi. Significa non sollevarsi sulle spalle dei giganti che ci hanno preceduto, ma riscoprirci piccoli uomini davanti ad un grande mondo. Ed è naturale che per mantenere stabilità, un po’ si esplora e un po’ si consolida. Il Ray Tracing non arriverà nel giro di qualche mese. L’equivalente di Nanite, se mai arriverà, sarà implementato fra anni e non mesi. E va benissimo così. 

Star Citizen non ha bisogno di ogni innovazione tecnologica che avviene nell’industria: ha bisogno della tecnologia necessaria per rendere il gioco stesso possibile. Solo poi, quando sarà più semplice inserire certe cose (perché altri avranno esplorato e sperimentato prima), si potrà implementare l’equivalente di Nanite e tutto il resto. La meraviglia tecnologica è potente, ma temporanea. Star Citizen e Squadron 42 avranno bisogno di molto più per resistere alla prova del tempo: avranno bisogno di meccaniche solide e divertenti, di sistemi vari e profondi e di una coerenza di design che attualmente a volte manca. Non è fondamentale che quest’ultima ci sia, ma darebbe quella marcia in più. È quello che serve per rimanere nei cuori delle persone.