Nel primo post, abbiamo fatto due chiacchere su perchè dovrebbe interessarci sapere come è fatta una architettura multiplayer. Con tutto la ricerca e lo studio che si può fare, i segreti rimarranno sempre alla DICE.
La comprensione dei concetti generali, invece, no. Quella possiamo apprenderla, magari facendo qualche esperimento con i server. Iniziamo perciò veramente a parlare di come funziona in generale un gioco multiplayer.
Come pure il gatto mio sa, ci sono un numero di giocatori che giocano ciascuno usando il proprio client (console o pc) e c'è un server che in qualche modo gestisce i client.
Evitiamo perciò di parlare di quei sistemi dove uno dei client fa anche da server, come in COD.
La domanda è "che cosa vuol dire gestire i client"? Quando comunicano, che cosa si comunicano?
Anche il gatto mio può immaginare che
uno dei problemi di questo sistema (per sistema intendo i client + server) è condividere le posizioni di ciascun giocatore agli altri in modo ottimale.
La differenza è sottile. Avete capito la differenza?
Se questo modello fosse applicato in un sistema NON perfetto, diciamo con un 1 secondo di ritardo tra client e server (non ho detto ping, ho detto ritardo), ad un movimento dello stick corrisponderebbe un movimento del giocatore sullo schermo dopo ben 2 secondi (1 sec in trasmissione e 1 in ricezione).
Nel modello perfetto funzionerebbe tutto perchè il ritardo è zero.
Ok, nelle reti normali il ritardo (continuo a non dire ping) è dell'ordine dei millisecondi e non secondi. Peccato che vedremo a breve, quando uscira il prossimo articolo della categoria scholar, che bastano pochi ms (non vi dico ancora quanti) per rendere inaccettabili il controllo della mira.
Ipotizzando che il client conosca il ritardo che ha con il server, può muovere lui la posizione del giocatore sullo schermo in attesa che il server gli dica che è tutto ok.
Nel nostro esempio esagerato, il povero client riceve una risposta dopo 2 secondi. In quei 2 secondi, ha modificato sul video la posizione del giocatore in totale autonomia.
All'istante 0 il giocatore inizia a correre e il video si modifica.
Questo processo, visto nella fase iniziale è abbastanza buffo. Ora immaginiamo di vederlo dopo qualche secondo: il client continuerà a mostrare a video la predizione di un pacchetto che gli ritornerà validato dal server dopo 2 secondi.
Ecco il primo grande criterio: Il vostro giocatore si trova nel futuro, grazie a quello che viena chiamata PREDICTION.
Che succede se invece cambia direzione o salta continuamente di qua e di là come fanno in tanti?
Incredibile. Il un sistema multiplayer, il server sposta noi, ovvero la fonte delle informazioni.
1) Server in Australia
Non sto parlando di ping. Ho creato così tanto ritardo tra me ed il server, da farlo bestemmiare a tal punto che noterete quante volte la mia posizione venga riportata indietro.
Nel video, vado avanti e cambio direzione e dopo un pò (un bel pò), la mia posizione viene corretta.
uno dei problemi di questo sistema (per sistema intendo i client + server) è condividere le posizioni di ciascun giocatore agli altri in modo ottimale.
Fermiamoci su questo concetto e ragioniamo, in questo post, da soli ovvero immaginiamo di essere da soli in questo sistema: un solo client e un server, esattamente come quando stiamo in una mappa da soli.
Nel sistema con molti giocatori, un server è l'unico a conoscere la posizione di tutti. Dovrà perciò preoccuparsi di notificarla agli altri. Avendo in mente questo, un sistema perfetto, senza lag e senza cheating, dovrebbe funzionare a questa maniera:
Il giocatore si muove
Il client invia il movimento al server
il server capisce, giudica la posizione autorevole e la propaga a tutti (giocatore originario incluso)
il client riceve l'approvazione del server e altera la grafica in modo da spostare il giocatore in avanti.
Con questo criterio, un giocatore avanza nella mappa non quando muove lo stick, ma quando il client riceve dal server la nuova posizione dovuta proprio al movimento dello stick.
La differenza è sottile. Avete capito la differenza?
L'avanzamento non è dovuto all'input (stick), ma alla risposta di un server.
La differenza ora non dovrebbe essere più sottile come prima.
Se questo modello fosse applicato in un sistema NON perfetto, diciamo con un 1 secondo di ritardo tra client e server (non ho detto ping, ho detto ritardo), ad un movimento dello stick corrisponderebbe un movimento del giocatore sullo schermo dopo ben 2 secondi (1 sec in trasmissione e 1 in ricezione).
Nel modello perfetto funzionerebbe tutto perchè il ritardo è zero.
Nel mondo di fastweb, libero, telecom etc, sarebbe ingiocabile.
Ok, nelle reti normali il ritardo (continuo a non dire ping) è dell'ordine dei millisecondi e non secondi. Peccato che vedremo a breve, quando uscira il prossimo articolo della categoria scholar, che bastano pochi ms (non vi dico ancora quanti) per rendere inaccettabili il controllo della mira.
Come si risolve questo problema?
Semplice.
Ipotizzando che il client conosca il ritardo che ha con il server, può muovere lui la posizione del giocatore sullo schermo in attesa che il server gli dica che è tutto ok.
Il client, perciò, predice le risposte del server.
Nel nostro esempio esagerato, il povero client riceve una risposta dopo 2 secondi. In quei 2 secondi, ha modificato sul video la posizione del giocatore in totale autonomia.
Non appena riceve la risposta, il client verifica se la sua predizione è stata verosimile e continua a predire e mandare pacchetti.
In questo esempio, il povero server riceve continuamente pacchetti ritardati di 1 secondo.
Facciamo l'esempio di un giocatore che corre in avanti.
All'istante 0 il giocatore inizia a correre e il video si modifica.
Dopo il primo secondo il server finalmente riceve l'informazione dello stato del giocatore mentre sul video del client, il giocatore si è spostato avendo corso per 1 secondo.
Dopo il secondo secondo, il client finalmente riceve la conferma del messaggio inviato 2 secondi prima.
Questo processo, visto nella fase iniziale è abbastanza buffo. Ora immaginiamo di vederlo dopo qualche secondo: il client continuerà a mostrare a video la predizione di un pacchetto che gli ritornerà validato dal server dopo 2 secondi.
Ecco il primo grande criterio: Il vostro giocatore si trova nel futuro, grazie a quello che viena chiamata PREDICTION.
Si nel futuro.
Il movimento mostrato deve ancora essere validato e per di più non è visibile immediatamente agli altri client, qualora ce ne fossero. Incredibile. Muoverlo nel presente corrispondere a essere "nel futuro" per il sistema.
Tutto semplice se il giocatore mantiene il proprio stato (correre nella stessa direzione).
Che succede se invece cambia direzione o salta continuamente di qua e di là come fanno in tanti?
Il problema è quello per il quale la predizione del client e la posizione riportata dal server non faranno più scopa.
A quel punto il sistema, con vari tipi di algoritmi, corregge la posizione del client in base alla autorità ovvero il server. Tipicamente è il client a spostare la posizione.
Sul proprio video, perciò, tipicamente si vede il proprio giocatore teletrasportarsi di qua e di la nella mappa.
Incredibile. Il un sistema multiplayer, il server sposta noi, ovvero la fonte delle informazioni.
Sorprendente ma scontato.
Se non facesse così con tutti, il server propagherebbe agli altri una realtà che è diversa da quella che ogni giocatore vede di se stesso. Occhio alla frase appena scritta.
Nel video sono solo, siamo solo io ed il server.
Il ritardo tra me ed il server è stato ricreato secondo queste condizioni:
1) Server in Australia
2) Streaming twitch tv attivato sul tablet alla massima risoluzione
3) youtube attivo sul pc a 1080 attivato
Non sto parlando di ping. Ho creato così tanto ritardo tra me ed il server, da farlo bestemmiare a tal punto che noterete quante volte la mia posizione venga riportata indietro.
Alcuni sapientoni potrebbero dire che in realtà i pacchetti non arrivano al server, visto la saturazione della banda. Li aspetto al prossimo post.
Nel video, vado avanti e cambio direzione e dopo un pò (un bel pò), la mia posizione viene corretta.
Se perciò vi dovesse capitare di vedere qualcosa di simile, allora siete voi e non parlo di ping. Il ping potrebbe rimanere anche inalterato.
Se vi doveste stancare di vedermi laggare per 1 minuto e mezzo, andate alla fine che è veramente comica.
Se vi doveste stancare di vedermi laggare per 1 minuto e mezzo, andate alla fine che è veramente comica.
Eccoci qua. Abbiamo iniziato a capire che cosa vuol dire ritardo, che tipo di meccanismo usa un client con se stesso e con il server, sempre con le proprie informazioni.
Ancora non siamo pronti per vedere quello che succede con gli altri, furiamoci con i loro proiettili.
Nel prossimo post continueremo ad essere solo noi e il server, interagendo in maniera più estesa del semplice correre.
Nessun commento:
Posta un commento