PREMESSA
Sul come il Server Meshing verrà implementato in Star Citizen non si hanno molte informazioni. Si sa che necessita dell’OCS server-side, si sa che verrà sviluppato insieme all’OCS server-side e in linea teorica permetterà a tutti di giocare insieme sotto però alcuni limiti.
QUELLO CHE AVEVAMO CAPITO
L’idea che ci eravamo fatti era che all’inizio (prima implementazione) questo Server Meshing avrebbe diviso i sistemi solari in zone fisse, ognuna gestita da un server. Passando da una zona all’altra ci sarebbe stato un qualche tipo di caricamento e ogni zona avrebbe avuto un massimo di giocatori.
Es. Crusader e le sue lune rappresentano una zona gestita da un server che al massimo gestisce 50 giocatori. Dovesse quel server riempirsi e dovesse un gruppo di 10 giocatori dirigersi verso Crusader, il gioco creerebbe un zona Crusader “2” dove far andare questo gruppo di 10 giocatori, perché zona Crusader “1” era piena. Si tratterebbe dunque di un server meshing un po’ farlocco, dove potrebbero esistere in contemporanea anche 10 Crusader e 15 ArcCorp, rendendo sostanzialmente impossibile quelle grandi battaglie che molti giocatori sognano.
CHI È CLIVE JOHNSON
Clive Johnson è dal 2016 Lead Network Programmer in Foundry 42 UK, ovvero il capo dietro al team che si occupa del netcode e lavora nello studio a Wilmslow, vicino Manchester. Clive Johnson prima di arrivare alla Cloud Imperium nel 2014, ha lavorato direttamente e indirettamente per compagnie come EA (FIFA 08) e Ubisoft (The Crew).
In un recente post dove si chiedevano chiarimenti sul Server Meshing, Clive Johnson è stato molto disponibile a rispondere alle domande dei backers.
I SERVER
Come molti già sanno, Star Citizen utilizza i server Amazon. Clive ha dichiarato che nello specifico utilizzano l’Elastic Cloud Computing di Amazon (EC2) e di non conoscere i numeri esatti ma di essere sicuro che Amazon abbia decine di migliaia di server per regione (AUS/EUR/US). Questo permette alla CIG di mettere su nuovi server nel giro di minuti e la quantità di server che possiede Amazon supera di gran lunga le necessità della CIG, anche sul lungo periodo.
LA PRIMA INTERAZIONE
La prima versione del Server Meshing prevede che appunto i vari server siano legati alle zone. Clive ha dichiarato di sperare e di intuire che questa prima interazione verrà sostituita prima dell’introduzione dei sistemi solari dopo Stanton. Il motivo di tale cautela nelle dichiarazioni è dovuto al fatto che ancora non è pronta una definita roadmap interna al riguardo.
Il motivo per cui intendono fare questa versione “introduttiva” del server meshing è dovuto al fatto che intendono far testare le varie parti del server meshing ai giocatori man mano che vengono completate. Per prima cosa inseriranno i limiti dei server nello spazio profondo e dunque si potrà passare da un server all’altro solo tramite Quantum Travel e questo limiterà il passaggio di entità e giocatori tra server. Man mano che i vari bug verranno sistemati e che avranno confidenza con la tecnologia, potrebbero far sì che ci siano più server a gestire le varie zone.
LO SCOPO FINALE
Alla fine l’idea è che i server gestiscano il gioco per gruppi di giocatori, non zone. Man mano che i giocatori si sparpaglieranno, la zona gestita dal server aumenterà. Man mano che i giocatori si raggrupperanno, la zona si ridurrà. Nel momento in cui gruppi di giocatori gestiti da server differenti si incontreranno, saranno i server a decidere se raggruppare i giocatori in un solo server, se dividerseli o se creare un nuovo server per gestirli. In questa versione del server meshing, i server gestiranno solo i luoghi dove ci sono giocatori, riducendo di gran lunga il numero di server necessari e permettendo di gestire più giocatori ad un costo minore.
Q&A ESTRATTO DAL POST SU SPECTRUM
Domanda: Diciamo per esempio che mi trovi in una stazione spaziale con 50 persone (gestite da server 1) e che ci sia una nave vicino alla stazione con 50 persone (gestite da server 2), potremmo vederci tra noi? Ovvero, il client riceverà aggiornamenti da entrambi i server?
Risposta: Sì.
Domanda: Mettiamo che ci sia una battaglia tra i giocatori gestiti da server 1 e server 2 (per esempio dentro la zona cargo di una nave e in un landing pad della stazione), Come riusciranno i server a gestire tutti quei proiettili al secondo senza lag?
Risposta: Proiettili come le pallottole, i laser e fulmini di plasma non sono server-side, in quanto vanno in linea retta. Solo il fatto che l’arma abbia sparato viene comunicato al server. Recentemente in un AtV si è anche parlato del “Projectile Manager” e di diverse ottimizzazioni che sono state fatte in quell’area.
Domanda: Nel momento in cui i giocatori di due diversi server iniziano ad interagire fra di loro o cercano di scontrarsi tra loro, non rischiano il desync?
Risposta: Sì, il desync è una possibilità concreta. La cosa ottimale sarebbe quello di trasferire tutti i giocatori nello stesso server per ridurre il problema. Nella situazione in cui entrambi server siano saturi e che il numero di giocatori sia superiore a quello che un singolo server possa gestire, l’idea sarebbe di dividere i giocatori a secondo di come stiano combattendo: dovesse essere una battaglia 50 vs 50, dividere il tutto in battaglie 10 vs 10 o una cosa del genere. Anche nel caso che poi queste battaglie siano vicine tra loro, l’unica cosa importante è evitare il desync tra il giocatore e coloro che sta interagendo. Là dove non sarà possibile dunque mettere tutti sullo stesso server, daremo comunque l’impressione che sia così. La resa finale non dovrebbe comunque essere peggiore dei giochi che hanno il multiplayer peer-to-peer. Una volta che il server meshing sarà implementato, il team che si occupa del network passerà gran parte del proprio tempo per rendere l’esperienza piacevole per tutti.
Domanda: Quando arriverà l’OCS server-side? Attualmente non è presente nella roadmap e quindi non possiamo vedere gli eventuali progressi. Oppure attualmente vi state dedicando ad altro, come l’Actor Networking Rework e il sistema di persistenza?
Risposta: Il Team Network (il mio team) non sta lavorando a nulla di tutto ciò. Ognuno di questi aspetti viene portato avanti da team diversi che lavorano in parallelo. L’OCS server-side e il server meshing non si trovano in roadmap perché sono elementi che toccano tantissimi altri sistemi e richiede tempo e lavoro di altri team per far funzionare tutto. Attualmente i piani alti (direttori/dirigenti) stanno rivedendo i piani per entrambe le tecnologie, eventualmente spostando elementi nella roadmap per fare spazio e dare il tempo ai vari team di lavorarci. Sicuramente a quel punto la roadmap sarà aggiornata. Nel frattempo si continua comunque a lavorare su entrambe le tecnologie.
Domanda: Non sarebbe meglio far calcolare l’IA a dei server dedicati a tale scopo o direttamente dai client dei giocatori con un eventuale controllo da parte dei server per evitare cheat?
Risposta: Con il server meshing è possibile scaricare determinati sistemi su altri server. È una delle possibilità che sono state prese in considerazione, ma non è stato ancora deciso nulla in tal senso.
Domanda: E in caso di battaglie enormi da migliaia di giocatori, magari intorno a una luna e con tanto di Bengal?
Risposta: Una battaglia così grande richiederebbe sicuramente qualche trucchetto da parte nostra. Se sei mai stato in mezzo ad una grande folla, saprai che si è molto consapevoli delle persone che ci sono immediatamente vicine, ma tale consapevolezza si affievolisce man mano che aumenta la distanza. Credo che le battaglie più grandi funzioneranno in maniera simile, dove l’intera battaglia sarà gestita da tanti server, ognuno dei quali gestirà solo una piccola area a causa della densità di giocatori. Ognuno sarà capace di vedere i giocatori nella propria zona e quelli che si troveranno nelle zone vicine, ma il proprio server non riuscirà a connettersi ad altri che si trovano dopo una certa distanza e sarà impossibile vedere giocatori su quei server. La speranza è che la densità dei giocatori intorno a te facciano presumere che ce ne siano altri al di là del visibile, simile a quello che avviene tra la folla. In caso di una visuale più ampia, o dall’alto (in caso di una battaglia su una luna o un pianeta), si potranno vedere i vari giocatori man mano che ci si muoverà per il campo di battaglia.
Domanda: Il Server Meshing terrà conto dell’orbita di lune, navi e pianeti?
Risposta: Sì, sarà vincolato alle griglie fisiche e come la griglia si muoverà, così sarà lo spazio gestito dal server.
Domanda: Cosa accadrà se una persona che gioca dalla Spagna cercherà di incontrare qualcuno che gioca dalla Nuova Zelanda? Come verrà gestito l’inevitabile lag?
Risposta: Attualmente non ho una risposta sicura, posso fare solo speculazioni. Dunque potrebbe andare molto diversamente da quello che sto per dire.
Probabilmente faremo degli shard regionali prima di tentare di inglobare tutto in un’unica shard per affrontare il problema della latenza. Una volta che il server meshing funzionerà bene, avremo qualche opzione da esplorare. Ovviamente le tradizionali tecniche per il network come “lag compensation” e “client-side prediction” verranno usate. Uno dei benefici nell’usare i server Amazon è che la comunicazione tra server in regioni differenti usa il CDN backbone di Amazon, che ha una latenza del 10% inferiore rispetto alla norma. Potremmo provare a quel punto a far sì che i client siano sempre connessi al server nella loro regione e che poi siano i server a mandare le informazioni al server della regione corrispondente. Visto che siamo noi a controllare i server, possiamo fidarci di quello che si comunicano tra loro, quindi la “hit detection” quando spari ad un giocatore di un’altra regione potrà essere verificata dal server della tua regione. Questo però farebbe sì che chi spara abbia un vantaggio, cosa che potrebbe infastidire il giocatore in alcune situazioni. Un’altra opzione che potrebbe ridurre il problema sarebbe mettere i giocatori in un server che si trova a metà strada tra di loro: per esempio se un giocatore si trova a Los Angeles e un altro a Wilmslow, potremmo metterli in un server a New York. Oppure si potrebbe fare un misto di queste idee… ma prima bisogna realizzare il server meshing.
Domanda: Che tipo di istanza viene usata dai server di gioco? A1, T3, M5…?
Risposta: C5 per l’Universo Persistente, C4 per Arena Commander e Star Marine. Accumuliamo un paio di istanze nella stessa Virtual Machine mentre modifichiamo il codice per sfruttare al meglio i core disponibili. Ma questa informazione potrebbe essere vecchia in quanto il nostro team DevOps cambia spesso il modo in cui vengono distribuiti i server.
