NET CODE: (pt.6) PRIME CONSIDERAZIONI FINALI

In questo post, vogliamo iniziare a tirare qualche somma, qualche conclusione, qualcosa finalmente di utilizzabile di questa serie di post sull'architettura di un multiplayer.
Abbiamo capito che ogni volta che spariamo a qualcuno e non riceviamo neanche un hit marker, dobbiamo prendercela con il lag e con il sistema.

Abbiamo capito che per il lag non possiamo farci niente.
Con il sistema forse, qualcosa la possiamo fare.

Intanto abbiamo capito che nella situazione sopra descritta, almeno uno dei tre meccanismi necessari per farci giocare ha fallito:

Client prediction
Estrapolation
Lag compensation

Siamo in grado di capire quale?
La risposta è fino ad un certo punto.

Il primo sicuramente si. Siamo in grado di vedere se i nostri movimenti laggano.
Abbiamo anche visto che basta sparare ad un oggetto distruttibile per capire il nostro lag.
Ma gli altri?
Diciamo che forse dovremmo imparare a percepire il lag degli altri.
Come?

Vediamo questo esempio.

Siamo tutti d’accordo che una claymore è un oggetto che ha una hit detection lato server?
Direi di si.
Riuscireste ad immaginare quanti messaggi dovrebbero scambiarsi server e client per verificare (hit detection lato client) se un altro giocatore ci è passato sopra? E poi non mi sembra di aver visto mai una cheat con le claymore.

Studiamo perciò questo caso: client + server ma con oggetti nemici (claymore).

In questo esempio, il lag del nostro avversario può essere qualsiasi, visto che non entra in gioco.

OK. Adesso guardate il filmato di me che laggo volutamente (solito setup spiegato qui) e che riesco a passare indenne sopra ad una claymore nemica.
Ci sono due modi con i quali ci passo sopra: il salto e lo zig zag. La semplice corsa invece farebbe detonare la claymore in qualunque caso.

LINK YOUTUBE

Dai che avete capito: la corsa e lo zig zag (uniti al mio lag) mettono in crisi il meccanismo di lag compensation. Il server non riesce a ricostruire correttamente la mia posizione nel tempo.
Quando ci riesce, è sicuramente impattata da un errore. Ed ecco perciò che la claymore scoppia e nessun/scarso danno viene inflitto alla mia salute.
Avete capito allora?

Un giocatore molto dinamico che fa continue variazioni, che si muove sempre, che non sta mai fermo mette in crisi ( a proprio vantaggio) tale meccanismo.

La stessa dinamicità mette in crisi l’altro meccanismo, ovvero l’estrapolation, necessario per far vedere gli altri giocatori in sincrono sul proprio schermo.

Quale livello di accuratezza potrà mai dare un server nel propagare informazioni di posizione di un giocatore che cambia sempre direzione? Le informazioni sullo schermo saranno sempre affette da un errore. Va bene che la hit detection lato client dirà al server che abbiamo colpito qualcuno, ma il server, tramite il lag compensation, correggerà il suddetto errore, a scapito di colui che invece bramava una kill.

Avete visto quanti giocatori si muovono continuamente facendo destra-sinistra rimanendo però sempre sulla loro posizione?

Si chiama z-dodging. Lo avevamo esposto in questo articolo sulla mira in modo molto semplificato e adesso siamo in grado di capirlo veramente.
Lì lo avevamo semplificato come un movimento a zig zag. Nella realtà stiamo parlando del semplice fare destra sinistra sulla propria posizione.

Tutti quelli che fanno z-dodging mettono in crisi estrapolation (il video del giocatore sullo schermo) e lag compensation (la posizione riportata indietro al tempo di un proiettile difficilmente farà scopa).
Lo z-dodging perciò è una cosa da imparare, ma soprattutto è il concetto (in generale) che bisogna cercare di essere impredicibili.

Di contro, rispetto a questo esempio, un camper o una persona che fa persistere il proprio stato per un po’ (tipo il correre o il camminare o il cadere) sarà sicuramente più semplice da predire per il sistema.
Non vi siete mai accorti che è più semplice uccidere uno fermo o che corre piuttosto che uno che cambia continuamente direzione e salta anche?

Se sei fermo, fai il miglior regalo al server perché farà la migliore estrapolation possibile negli schermi degli altri giocatori e la lag compensation sarà sempre perfetta.

E chi sono, in genere, quelli fermi o che corrono alla rinfusa? Quelli che giocano da poco.
Chi sono quelli che si muovono tanto? I veterani.

Mi dispiace per i novizi. E’ una lotta impari.

Se perciò abbiamo davanti a noi qualcuno che si muove molto, e abbiamo il feeling del nostro lag, dobbiamo fargli le misure e cercare di sparargli (se possibile) quando crediamo che farà persistere il suo stato (tipo la corsa in una direzione) per un po’ (poco, qualche centinaio di millisecondi).

Vi rigiro il concetto con questo consiglio: mai sparare quando vedete che il vostro avversario stà superando un ostacolo.
Quante volte sparate a quella animazione e ricevete al massimo una hit?
Aspettate che abbia finito. L’animazione dura un po’. E’ quel persistere dello stato di cui vi dicevo. Il momento nel quale l’animazione finisce è il momeno in assoluto dove estrapolation e lag compensation hanno l’accuratezza maggiore. Provare per credere.

Questi criteri apparentemente sono indipendenti dal lag del vostro avversario.
Nel prossimo articolo (link) vedremo come funzionano i suoni in un multiplayer e che relazione hanno con il lag.
Nel frattempo mi piacerebbe sentire qualche parere...