Multiplayer Online – Sotto la Scocca
Il mondo del gaming moderno sta facendo di tutto per inserire termini tecnici che confondono sempre più le acque. Risoluzione, FPS, HDR, PBR, GI e chi più ne ha, più ne metta. Non trovo fondamentalmente sbagliato usare la corretta terminologia, ma c’è bisogno di filtrare l’informazione nel modo giusto, altrimenti si crea solo confusione. Prendendo spunto da questa news su Splatoon 2 dove si parlava del tick rate, ho ritenuto opportuno fare una panoramica sull’argomento, così da evitare confusioni future.
Partiamo dalle basi. Quando un gioco viene eseguito in un ambiente multiplayer online, c’è bisogno di scambiare informazioni con l’esterno. Offline, in Mario Kart 8 la distanza tra le auto è una quantità nota aggiornata di continuo localmente. Online invece, se chi mi sta davanti si muove a destra, questa informazione deve essere passata dalla sua console alla mia. Tutto il codice che gestisce queste interazioni è chiamato genericamente netcode. Ci sono in genere tre strutture di rete per scambiare informazioni: Peer to Peer, Listen Server e Client/Server.
Il Peer to Peer o P2P è un sistema a ragnatela dove tutti i device sono connessi tra di loro e si scambiano informazioni. In ambito gaming oramai non è molto usato. Il modo migliore per immaginare un sistema P2P è quello di pensare a tanti computer in un ufficio con tante stampanti. Spesso il termine P2P si usa impropriamente per indicare il “Listen Server” in ambito gaming. Praticamente quando si crea un match online si sceglie un giocatore e questo diventa il “Server” del gioco, tutti gli altri sono connessi a lui. Questo ha il vantaggio di non richiedere un’infrastruttura per funzionare, ma è molto dipendente dalla qualità delle proprie linee. Se un gioco va a 60fps, l’host ha 16ms di tempo per inviare i dati a tutti gli altri, presupposto ideale non sempre raggiungibile. Il sistema Client/Server invece si basa sull’avere un sistema esterno a massima autorità, il server, al quale si connettono i giocatori, che sono i client. Il server ha lo scopo di aggiornare lo stato del gioco e inviare i dati a tutti i client.
Quando si gioca online, lo scopo dell’infrastruttura è quella di minimizzare i ritardi nel ricevere le informazioni. Perché se è vero che qualche millisecondo di ritardo non è notabile, gli elementi in gioco sono molti ed i ritardi si sommano, fino ad arrivare a valori percettibili. E in un gioco dove è richiesta una certa precisione, dove è necessario saper studiare le posizioni degli avversari e gli effetti delle loro armi, il lag può inficiare enormemente sull’abilità personale. Ci sono molti valori e termini usati per indicare questi ritardi. Ping, RTT ed Tick Rate sono tra i principali.
Il Ping indica il tempo necessario per un pacchetto di dati a viaggiare dal vostro client al server e tornare indietro. È un valore di controllo, asettico, fatto in ambiente controllato e dipende dalla qualità della vostra connessione e dalla distanza con il server. Il Round Trip Time o RTT è invece il valore che indica il tempo di risposta dal server dopo che si esegue un comando nel gioco. Il valore è una stima ed è più alto del Ping, ma è più vicino alla realtà. In queste metriche si inseriscono il Tick Rate del server e l’interpolazione. Il Tick rate rappresenta la frequenza di aggiornamento del server. Lo stato globale del gioco viene aggiornato un certo numero di volte al secondo. Per il testfire di Splatoon 2 questo valore era 12,5Hz. Un gioco come Overwatch lavora a 64Hz ovvero: i suoi server possono inviare pacchetti ai client 64 volte al secondo. Quindi il mio gioco si aggiorna ogni 15ms? Non proprio, per via dell’interpolazione. Questa è una tecnologia che permette di rendere fluido il movimento degli oggetti. Se un server ha l’informazione di un giocatore in due punti, il movimento tra i due punti viene creato dal client. Per fare ciò è necessario avere l’informazione dei due punti, quindi in genere si introduce un ritardo pari al doppio del tick rate.
Tutto questo va messo in fila. Io nel mio gioco mi muovo. Il gioco aggiorna il mio movimento in base al mio framerate. Nello stesso tempo invia l’informazione al server in base alla mia latenza. Il server riceve l’informazione e si aggiorna. A questo punto invia l’informazione ai client, tenendo conto di tutte le loro latenze e il client si aggiornerà un po’ in ritardo per l’interpolazione. A questo si aggiunge anche l’aggiornamento del framerate del gioco. Quindi un mio avversario non vede il me di adesso, ma vede un me nel passato, sempre. Ci sono ovviamente numerose tecniche per minimizzare errori dovuti a questi ritardi e la qualità di alcuni giochi dipende proprio da come sono gestiti questi accorgimenti da parte degli sviluppatori.
Nel caso del testfire di Splatoon 2, avevamo il gioco che si aggiornava localmente ogni 16ms per i suoi 60fps. Se però il server mi manda informazioni ogni 80ms (12,5Hz) si perde molta della precisione dei comandi. Questi lunghi tempi di risposta rendono meglio con connessioni scarse. Un server a tick rate maggiori porta ad un gioco più reattivo e con meno ritardi, ma se si ha una connessione lenta si perdono più tick e quindi il lag fa più male. È la classica coperta corta. Nei titoli estremamente competitivi si tendono a favorire tick rate molto elevati. Per questo ci sono state lamentele per i 20Hz di Overwatch e per i 12,5Hz per Splatoon 2. Se il giocatore medio potrebbe non darci peso, la sfera competitiva è abbastanza fissata su questi aspetti. E non sono “futili”, hanno un impatto percettibile sul gameplay a certi livelli.
Gestire un gioco online non è semplice. Maggiore è la complessità dello stato del gioco, maggiore sarà il lavoro da fare per rendere l’esperienza utente reattiva e robusta. Per dubbi, domane e curiosità, sfruttate i commenti. E rilancio la solita domanda: quale argomento vorreste vedere trattato in futuro?
