Nuovo appuntamento con l’Around the Verse: questa volta si parla dei server interni CIG!


  

AGGIORNAMENTO DALLO STUDIO – AUSTIN

Team di Design

·        Procedono i lavori sulle funzionalità principali della 3.0, come ad esempio il commercio, per il quale hanno collaborato con i programmatori di LA per scrivere il codice dello shopping e realizzare quello dei chioschi merci e della persistenza delle navi.

·        Hanno terminato il primo gruppo di richieste interattive per le navi.

·        Stanno continuando a lavorare su Miles Eckhart, NPC che sarà presente nella 3.0 e che introdurrà un complesso sistema di missioni che influenzeranno anche la reputazione con le fazioni.

·        Stanno suddividendo i singoli componenti di Levski per determinare quali saranno le aree tramite cui far passare le merci di contrabbando, in quali posti sarà possibile trovare gli NPC che forniranno le quest e, in generale, dove si potranno trovare i vari contenuti.

o   Stanno anche lavorando alle fazioni che saranno presenti all’interno della città ed alla loro caratterizzazione in termini di obiettivi nell’Universo di SC.

Team Artistico

·        Josh Coons sta lavorando ai modelli dei danni della Cutlass Black. La nave è quasi completa e necessita soltanto dei LOD.

Team Animazione del PU

·        Stanno aggiornando tutte le animazioni relative agli oggetti utilizzabili ad un nuovo sistema di interazione che permetterà loro di risparmiare memoria e creare più rapidamente delle nuove animazioni uniche.

·        Inoltre, il team di Austin ha effettuato delle riprese di mocap per raccogliere dati sulle animazioni per la raccolta di scatole a diverse altezze e per l’interazione con le porte in varie transizioni.

Team di Animazione della Nave

·        Stanno terminando il lavoro sulla Cutlass Black e stanno creando le animazioni di entrata ed uscita dalla Dragonfly a gravità zero.

·        Inoltre, stanno approfondendo ulteriormente l’esperienza di gioco nell’abitacolo, aggiungendo le reazioni del pilota agli impatti, le animazioni di pressione dei pulsanti ed arricchendo nel complesso l’intera struttura dell’abitacolo.

Team Ingegneristico

·        Stanno approntando un numero sempre maggiore di componenti della nuova infrastruttura di veicolazione delle informazioni, rinominata “Diffusione”, e li stanno integrando con i vari servizi attualmente in uso, come le liste amici, i dati analitici, il sistema di autenticazione e quello di presenza online.

·        La prossima fase consisterà nel passare ad occuparsi dei servizi più complessi, come la cache della persistenza, la gestione dei server di gioco, il matchmaker ed il database di persistenza.

o   Questi elementi verranno suddivisi in servizi più piccoli per migliorare le prestazioni e la scalabilità.

·        Il server ed il client di gioco sono prossimi alla conversione alla Diffusione.

·        Stanno apportando una serie di ottimizzazioni utilizzando una nuova tecnica chiamata “Router Biasing” per fornire una maggiore capacità di controllo alla gestione della banda.

Team QA

·        La prima parte del mese è stata dedicata alla 2.6.3.

·        Al momento invece si stanno concentrando sul ramo di game dev di Star Citizen e sui test per SQ42.

Team Community

·        Hanno passato del tempo con Turbulent per lavorare alle migliorie per lo Spectrum ed aggiornare la lista Evocati e quelle delle ondate PTU.

 

AGGIORNAMENTO DA TURBULENT

·        È stata rilasciata la versione 0.3.3 dello Spectrum.

·        Con questo rilascio sono state aggiunte le discussioni annidiate.

o   Hanno in programma di trasformare questa funzionalità in una modalità di visualizzazione delle discussioni, così da dare la possibilità di scegliere se vederle in questo modo o con il solito andamento cronologico.

o   Stanno ricontrollando l’impatto di questa funzionalità sull’indicatore delle notizie non lette e stanno lavorando al sistema di tracking dello staff.

·        Adesso è possibile segnalare i post alla moderazione sia all’interno del forum pubblico che in quello delle singole org.

·        Hanno fatto progressi nel supporto mobile al sistema della tastiera.

·        Stanno lavorando alla 0.3.4.

o   Hanno in programma di rifinire la funzionalità e l’utilizzo dei tag nei sottoforum, così che sia possibile passare da un canale qualsiasi ad un tag specifico all’interno di un canale.

o   Inoltre, daranno anche la possibilità di mettere i tag tra i segnalibri, come se fosse un canale.

·        Stanno aggiungendo nuovi filtri e stanno lavorando al sottosistema della ricerca.

o   Questo set di funzionalità legate alla ricerca permetterà di realizzare un nuovo mini profilo da cui sarà possibile vedere direttamente tutti i post di un certo giocatore.

·        Stanno lavorando ad alcune liste virtuali che permetteranno loro di renderizzare la lista delle persone presenti nella chat, aggiungendo un piccolo buffer per evitare una riduzione delle prestazioni.

·        Stanno lavorando ad un overlay tra il gioco e lo Spectrum.

·        Stanno lavorando ai PM di gruppo, così che sia possibile avere un sistema di party più evoluto per lobby specifiche.

·        Stanno apportando alcune modifiche all’infrastruttura e stanno spostando la piattaforma web su un nuovo hardware, cosa che potrebbe causare un piccolo downtime.

 

DIETRO LE QUINTE

TLDR

·        Mike Jones è responsabile di tutto l’hardware e l’infrastruttura della CIG, che è stata realizzata su misura per le loro necessità.

·        L’introduzione di un sistema di tri-build basato su una serie di Macchine Virtuali (VM) ha lo scopo di preservare la stabilità dei server interni CIG, dato che c’è un’enorme competizione per le risorse ed il traffico di rete tra i vari dipartimenti, ben superiore a quella che Mike aveva già visto in altri suoi lavori precedenti con altri giochi. Pertanto, hanno deciso di suddividere l’assegnazione delle macchine nei vari ambiti.

·        Hanno aggiunto tre nuovi host per isolare il sistema di tri-build e ridurre la disputa delle risorse facendo sì che tutti i vari lavori venissero suddivisi in parti più piccole.

·        I servizi di gioco vengono hostati esternamente per questioni di flessibilità e scalabilità e per evitare di investire un grosso capitale in macchine server, da cui l’ampliamento del loro sistema di compilazione delle build.

·        Il processo di aggiunta di un nuovo rack, posizionamento dei server, caricamento e configurazione del software è interessante e spesso richiede delle noiose operazioni di gestione cavi, ma ne vale la pena.

 

Trascrizione Completa

Mike Jones (MJ): Salve, mi chiamo Mike Jones e sono il Direttore della Tecnologia Aziendale & di Pubblicazione per la Cloud Imperium Games. E penso che al momento questo sia il titolo più lungo che abbiamo nella compagnia. È nato dalla fusione dei nostri dipartimenti IT e di Dev Ops. Per cui la mia responsabilità per quanto riguarda l’IT copre il lato hardware e l’infrastruttura, ma la rete, la sicurezza e la creazione dei server, nonché tutti i processi di automatizzazione e di gestione di rete correlati vengono tutti realizzati qui nel nostro team di Dev Ops. Per cui non c’è nulla di tutto questo che venga svolto da qualcun altro esterno alla società. Dunque… Sapete, alcuni dei servizi che usiamo sono abbastanza comuni, ma la maggior parte dei nostri sistemi è stata sviluppata e progettata specificatamente per le nostre necessità. Il motivo alla base di tutto questo è, ovviamente, il fatto che il nostro sia un gioco davvero unico. Abbiamo delle necessità uniche. Per cui uno dei miei interessi principali di questo mese è stato il nostro sistema di build e la necessità di nuove risorse ad esso destinate.

Il nostro attuale sistema di build è composto da sei server ad alta densità per un totale di 240 core virtuali e 2.3 TB di RAM. Questo è pieno di Macchine Virtuali (VM) per la compilazione delle build, ma di recente abbiamo introdotto il sistema di tri-build che, sostanzialmente, è un ulteriore sistema di creazione di build che è stato progettato per effettuare una precompilazione quando si verifica un controllo del codice. Ciò aiuta a preservare la stabilità del nostro sistema di build e quella delle build che vengono realizzate. Con la progressiva crescita del nostro progetto, stiamo osservando un incremento sempre maggiore del traffico in ingresso ed una maggiore competizione per le risorse di compilazione. Parte di quello che stiamo facendo è risolvere problemi che non si sono mai presentati in passato. Nei progetti di giochi su cui ho lavorato in precedenza pensavamo di star facendo qualcosa di davvero grosso, ma non è nulla in confronto a quello che stiamo sviluppando qui. Per cui il… Già il solo quantitativo delle risorse di gioco, le immagini, i dati precompressioni che arrivano ogni giorno è tremendo. Se devo effettuare il trasferimento anche soltanto di una versione della build attraverso una rete da 10 Giga, posso dover aspettare da mezz’ora a 45 minuti. Ed è per questo che dobbiamo suddividere queste mansioni. La situazione è la stessa con il resto del gioco. Dobbiamo dividere i vari elementi in pezzi più piccoli così da poterci lavorare di più ed in parallelo. È così che riusciamo a far progredire tutto molto velocemente ed è anche l’unico modo con cui tutto questo possa funzionare.

Nella nostra situazione attuale, il nostro sistema primario di build sfrutta sei host sparsi per un ambiente aggregato di VMware. Questa configurazione ci ha permesso di aggiungere la tri-build all’ambiente già esistente, ma man mano che siamo cresciuti, abbiamo visto un incremento nella competizione per le risorse. Ciò ci ha portato a tempi di attesa più lungi per un lavoro di tri-build. Aggiungendo tre nuovi host siamo stati in grado di isolare completamente il tri-build dal sistema di build primario, cosa che è particolarmente importante per gli ingegneri, dato che utilizzano continuamente il tri-build. Tante persone non capiscono perché ci voglia così tanto a compilare queste build all’interno del sistema di build o perché non si utilizzi l’approccio di compilazione che usiamo sui nostri computer desktop; tradizionalmente, quando si compila qualcosa su un pc fisso, si fa una cosa ed una soltanto. Si prende il codice sorgente e si effettua la compilazione di un client, un server o qualsiasi altra cosa sia, ma nel sistema di build abbiamo molte necessità e dobbiamo coprirle tutte. Per cui in aggiunta alla compilazione del client e del server, compiliamo anche le build di rilascio e quelle di profilo di svariati rami di sviluppo, a volte anche tre contemporaneamente. Ciò vuol dire che ogni volta che arriva una nuova build… Una nuova richiesta di compilazione di una build, creiamo un gran numero di macchine virtuali, ed abbiamo scoperto che con le dimensioni di questo gioco i tempi di compilazione possono diventare davvero lunghi. Per cui dividiamo questo lavori in tanti pezzi più piccoli, che è poi il motivo per cui possiamo distribuire questo processo su un hardware server così grande.

La ragione che ci ha spinto a scegliere di hostare i nostri servizi esternamente, piuttosto che internamente, è che… In realtà, c’è una miriade di ragioni, ma quella principale è legata alle tremende possibilità di scalabilità e flessibilità. Possiamo pagare soltanto quello di cui abbiamo davvero bisogno, piuttosto che dover effettuare un grosso investimento per acquistare diverse macchine e quindi pagare tutta la banda necessaria perché la gente possa accedervi. Inoltre, se pensate al lancio multi-regione che abbiamo effettuato di recente, questo non sarebbe stato facile da fare se avessimo avuto i server fisicamente localizzati in un unico centro dati. Ciò ci ha portato alla nostra attuale necessità di espandere il nostro sistema di build, per cui oggi stiamo ampliando il nostro rack attuale di sei host con tre nuovi host. In questo modo avremo 72 nuovi core virtuali ed un mare di nuovi elementi di networking, sarà davvero divertente.

Dal momento che il nostro rack attuale era pieno, ne abbiamo aggiunto un secondo e lo abbiamo collegato. In conclusione, abbiamo in programma di spostare tutti gli host al primo rack e tutti i dischi dati al secondo per questioni di semplicità, ma dovremo farlo poco per volta. Successivamente abbiamo posizionato i server dal basso verso l’alto per lasciare spazio per espansioni future. Ma dopo averli installati, ci siamo accorto che i nostri cavi fibra non erano della lunghezza giusta, per cui abbiamo spostato un poco i server per risolvere temporaneamente il problema. Una volta collegati, abbiamo installato e configurato il software per l’utilizzo. Adesso siamo in grado di farlo piuttosto velocemente, dal momento che tutto è virtualizzato nel nostro piccolo ambiente cloud. Da qui, si tratta soltanto di migrare le macchine virtuali usando VMotion. Questo vuol dire che possiamo migrare sulla rete un sistema già attivo senza rimanere offline. Ogni volta che facciamo uno di questi lavori, finiamo per ritrovarci con un groviglio di cavi. Succede di continuo e mi sembra quasi di sistemare continuamente tutto. Infatti, ormai è diventata un’abitudine ed a tutti piace vedere quanto tempo io impieghi prima di riuscire a trovare il modo di sistemarli, cosa che in genere non richiede molto. Ormai lo faccio praticamente in tutti gli studi in cui lavoro. Una volta che abbiamo messo insieme tutti i pezzi, possiamo lanciare le macchine e renderle operative in poco meno di tre ore. Di conseguenza, adesso c’è una minore competizione per le risorse del sistema di build ed abbiamo nuovo spazio a disposizione per continuare a crescere, e sono sicuro che ne avremo bisogno.

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