NETCODE: (pt-12) NETCODE MIGLIORATO? MA PER FAVORE!

Mi ritengo veramente sdegnato dalle ultime vicende sul fantomatico miglioramento del netcode. Non fraintendetemi, le cose sembrano migliorate (scrivo "sembra" perchè io sono e resto un ingegnere che se non vede, non crede. Troppe volte uccidiamo avversari già colpiti precedentemente da qualcun altro, troppe volte siamo vittime dell'effetto placebo).
Sono e resto un ingegnere, con più di 10 anni di esperienza di architetture software in ambienti realt-time, dispositivi critici, simulatori e sistemi asincroni. Battlefield, per certi versi, assomiglia ad alcune cose che si sviluppano in azienda da me. A volte lo vedo solo come un videogioco, a volte no, anche se non lo conosco.
E proprio qui viene il bello.
Avete visto il video del fantomatico miglioramento del 60% di Battlefield post patch? Eccolo qui. (LINK). Guardatelo è importante.

Voi forse avrete visto solo il numero finale. Io invece ho fatto caso a quello che in gergo si chiama "test bed" (ambiente di test) con il quale hanno verificato una specifica di performance.
Cerchiamo di fare un minimo di reverse engineering e cerchiamo di capire con che sistema abbiamo a che fare e perchè dovremmo forse essere ancora un tantinello incazzati.

In internet, alla fine, sono uscite queste considerazioni sul netcode migliorato:

frequenza di aggiornamento in uscita dal computer = 30hz ovvero 30 pacchetti al secondo ovvero 1 pacchetto ogni 33,333333 millisecondi (ms)
frequenza di aggiornamento in ingresso al computer 30hz (versione "migliorata") ovvero 30 pacchetti che entrano
frequenza di calcolo = 30 hz.

Queste foto sono prese da un canale youtube che ha molto seguito le caratteristiche del netcode e che vi suggerisco di seguire: BATTLE(NON)SENSE.
C' è una cosa che sfugge a molti e cerchiamo i fare chiarezza: che vuol dire frequenza di calcolo 30hz? Iniziamo.
Le persone, con naturalità,
concepiscono il tempo in maniera continua. Scontato.
In un certo tipo di software, invece, il tempo è scandito in periodi temporali. Un certo numero di periodi temporali, chiamati in genere "time frame", formano un secondo.
All'interno di un time frame si eseguono delle operazioni, che vengono ripetute time frame dopo time frame.
Il server di battlefield migliorato è stato progettato per scandire un secondo con 30 frame.
In ogni frame, il server acquisisce tutti i dati di ingresso (posizioni dei giocatori, orientazione dei giocatori, stato dei giocatori, proiettili, etc), li elabora (verifica le collisioni dei proiettili con i giocatori, elabora le posizioni future dei giocatori i modo da compensare il lag, etc) e poi li invia a tutti i computer collegati.
Al successivo frame, rifà la stessa sequenza acquisizione, elaborazione, invio e così via per sempre.
Se avete compreso la cosa che ho appena scritto, ovvero il fatto di processare i dati in istanti di tempo separati (e non continui), devo purtroppo dirvi che la cosa che ho scritto non è veramente corretta. Perchè?
Perchè la versione di Battlefield che avevate all'inizio non era a 30 hz, ma a 10 hz, ovvero la parte destra del disegno di prima. Vi ricordate quanto casino all'inizio?
10 hz vuole dire che il server [acquisisce, elabora e invia] 10 volte al secondo, ovvero invia ogni 100 enormi ed interminabili millisecondi. Ahahahaha, la gente si lamenta per 30 di ping quando c'è un server che li farà aspettare ALMENO 100 millisecondi per sapere se un proiettile ha colpito oppure no il nostro avversario, ahahahaha La scritta "ALMENO" è sottile e lo lascio come esercizio a chi vuole cimentarsi. (nella prima riga c'è un errore, ma che vedremo alla fine).
Chissà perchè 10hz? Problemi di carico del server? della rete? qualche standard restrittivo applicabile sulle console? Boh.
Sta di fatto che, su questa architettura che elabora 10 aggiornamenti al secondo, hanno aggiunto una ulteriore architettura sovracampionata di 30 volte al secondo, ma che elabora solo una parte di tutti i dati (posizione dei giocatori, orientazione, proiettili etc) e solo in una ridotta regione spaziale intorno al giocatore. Tutto il resto rimane a 10 volte al secondo.
Avete letto bene? Un ridotto numero di input, elaborato e inviato più frequentemente, ma solo per una piccola porzione della mappa intorno al giocatore, tipo 100 metri. Il classico esempio della coperta troppo corta che se copre i piedi, scopre la testa e viceversa. Il classico esempio di problemi di performance. Ma di chi? Non lo so, non voglio e non posso dirlo. Eppure ho letto che alcuni hanno iniziato a lamentarsi di nuovo di rubberbanding (Warping), che se non erro era un problema di prestazioni dei server.....
Andiamo avanti. In questo articolo, provo a fare il Piero Angela, ma non mi voglio sforzare più di tanto. Arriverà a fine articolo solo chi se lo sarà meritato e guadagnato. La conoscenza è potere. La conoscenza è dolore. Così si dice al lavoro da me.
Vediamo l'esempio del proiettile, con un 60% di miglioramento. Urka.
Abbiamo visto che un server lavora a time frame. Beh, la stessa cosa deve fare il client, pc o console.
Il pc acquisisce due ingressi: tutte le informazioni del server, più tutti i vostri input su tastiera e mouse o joypad; li elabora, e poi fornisce due uscite: i pacchetti verso il server e il video sul vostro monitor.
Come si fa a conciliare il fatto che voi giocate nel vostro tempo continuo, mentre sotto al culo avete un computer che fa cicli di operazioni in "quanti di tempo" separati?
E' possibile che lo sparo, la pressione del tasto del mouse, corrisponda all'inizio di un time frame, così come possa essere a metà oppure alla fine. Voi sparate un colpo, ma non sapete quando quello verrà inviato al server. Sapete solo che constantemente un pc invia 30 volte un informazione.
Mettiamoci perciò nel caso peggiore: il pc ha appena inviato un pacchetto e voi premete il tasto dello sparo. Che sfiga,eh? Pur avendo premuto il bottone, dovremo aspettare 33 ms prima che questa informazione esca dal pc. Avete capito? ALMENO 33ms buttati.
il pacchetto finalmente esce. Nell'esempio di Battlefield si dice "una latenza STABILE di 50 ms". La latenza è il ping. Lo "STABILE" è sottile davvero e vuol dire che non c'è jitter (AHAHAHAHAHAH ma le nostre reti sono piene di jitter. Si capisce che quella è una lan che ricrea una situazione reale molto conveniente)
ok.
50 ms di ping vuol dire che il pacchetto impiega 25 ms.
Per ora il totale fa 33+25=78ms
Adesso questo pacchetto arriva al server che stà lavorando secondo i suoi "time frame".
Anche questo pacchetto può arrivare all'inizio di un frame oppure alla fine oppure in mezzo. Si verifica perciò lo stesso problema di prima. Dovremmo metterci nella condizione più sfortunata.
Qui purtroppo differenti architetture sw di processing possono far variare di molto il ritardo. Prendiamone in considerazioni due:

ogni giocatore potrebbe avere associato un processo software perciò i 30hz potrebbero essere sincroni al giocatore. Arriva un pacchetto, lo processo, vedo la situazione del campo di battaglia in quel momento e aggiorno ogni 33,33333 ms (situazione abbastanza irrealistica)

oppure all'inizio del time frame del server, si acquisiscono tutti gli ingressi, si elaborano e poi si inviano ai client. Con questa configurazione, se arriva un ingresso durante l'elaborazione, non viene accettato, ma messo in coda per l'elaborazione al giro dopo. Se un pacchetto arriva durante l'elaborazione, questo pacchetto deve aspettare che finisca il time frame corrente ed entrare nel successivo.

In questa situazione perciò diciamo che il tempo perso è metà di un time frame al quale poi aggiungiamo il time frame successivo di elaborazione ovvero (0,5*33,33333 + 33,333333) = 50 ms
Quanto fa il parziale che abbiamo?
78ms di prima + 50ms del server = 128ms.

Adesso mettiamo il 1/2 ping di ritorno -> 128 + 25 = 153 ms.

Ehi, ma è simile  a quello di Battlefield, calcolato senza alcuna prova pratica. OK, in reverse engineering, perciò con una validità che può passare dal 100% alla cazzata micidiale (ne siamo tutti consapevoli, quanto vorrei avere un bel contraddittorio tecnico con quale tecnico della DICE, che forse non mi direbbe mai i propri segreti industriali....)

Vi voglio far notare che questo numero NON E' STATO CALCOLATO GUARDANDO UN VIDEO. Tutti gli youtuber fanno prove sulle schermo, ma non sanno che sono vittime di altri meccanismi asincroni che possono comportsi in maniera favorevole, ma anche sfavorevole.

Non abbiamo neanche considerato un minimo di Jitter, che potrebbe portarci a peggiorare ulteriormente la performance.

Quello che voglio dire è che nessuno ha capito che il numero presentato è uno dei casi possibili e non il numero vero, che stà tra il caso migliore e quello peggiore, assolutamente calcolabili con carta e penna, senza bisogno di alcuna prova empirica. Se fate caso, nel video due salti danno risultati diversi e il valore presentato è quello medio (che non è detto che sia quello corretto).

Un cosa inoltre che non credo abbia capito nessuno è che non è possibile accettare come miglioramento ciò che prima era assolutamente inaccettabile. Avere una latenza prima di più di 200ms è criminale, così come è criminale dire che si sia migliorato del tanto % partendo da un numero orribile.

Personalmente ritengo ancora inaccettabile questo risultato e se l'archittettura di sistema non è diversa, non credo sia possibile migliorare ritardi fisiologici. Ma questo non lo so.

Quello però che riesco a capire è, paradossalmente, il senso che aveva il sistema sw di prima a 10hz.
Prima la struttura era la seguente:
il client invia a 30hz e riceve a 10hz
Il server riceve a 30hz e invia a 10 hz
Perchè mai il client invia frequentemente i dati e ne riceve pochi? La spiegazione si intuisce se si cambia prospettiva e si osserva il server.
Perchè il server dovrebbe ricevere frequentemente ingressi e inviare uscite meno frequenti? Aiutino?

Cambiate la parola "ingressi" con "posizione dei giocatori".

In questo contesto, avere a disposizione più informazioni sulla posizione e altre informazioni di un giocatore è un bene. Poter inviare la posizione di un giocatore come il frutto di una interpolazione su 3 istanti è un bene. Il sovracampionamento dello stato dei giocatori è un bene.
Se il giocatore avesse cambiato direzione nei 3 istanti, il server avrebbe potuto dare una informazione magari "mediata" dai 3 istanti e non il classico teletrasporto che si vede sugli schermi.

PECCATO CHE LA FREQUENZA di USCITA A 10HZ fosse inaccettabile per un FPS.

Una buona idea? oppure semplicemente vincoli di qualche tipo?
E adesso che frequenza di ingresso e uscita sono uguali (30hz client in-out, 30hz server in-out), quale meccanismo di lag compensation o interpolation viene usato? Quelli classici? Come si compensa il lag?
Ricordate cosa avevo scritto nei primi articoli (non metto il link. Andate a cercarli nella sezione NETCODE)? Il sistema deve fare in modo di presentare realtà omogenee in tempi diversi e correggere problemi temporali, strutturali a questa architettura, come ad esempio, il cambio direzione oppure l'entrare-uscire in copertura?
Se tutte le cose che entrano in un server devono uscire con la stessa frequenza, come si fa a combattere il lag?
Avete colto l'ironia?
Voglio darvi un aiuto.

Vi siete mai accorti che il caso più inconsistente di netcode è quando, correndo, girate l'angolo e vi trovate un avversario praticamente davanti. Vi siete solo accorti di lui, appena girato l'angolo, e poi vi trovate subito morti, chiedendovi come ha fatto quello che stava addirittura guardando altrove?
Non mi dite che non ci avete fatto caso? Come mai?

Come mai secondo voi adesso nel CTE si stanno facendo le seguenti prove:
giocatori con meno di 70 di ping
giocatori con meno di 150 di ping
e via così?

Lo avete capito perchè?

Basta per ora. Quello che voglio dire è che il tick rate migliorato ha sicuramente migliorato l'inaccettabilità del sistema di prima, ma ha cambiato, secondo  me, l'equilibrio del netcode.

Mi voglio rendere spiacevole: mi fanno ridere tutti quelli che dicono "ehi, con la nuova patch vanno giù come birilli". Per metà di quelli è placebo (su ps4 solo alcuni server non noti in conquest a 64 sono stati aggiornati), per l'altra metà è invece solo percezione di una variazione, partita da una situazione inaccettabile.

Personalmente non mi sono accorto di una enorme differenza. Come si fa a sapere se quello davanti a voi è "vergine" e tutti i colpi sono i vostri?

Mai mi sarei immaginato 10hz di aggiornamento all'inizio. Ma i processori non hanno ora i gigaherz? Le reti, forse? Parliamo delle console? Mi tocca tirare fuori un articolo scientifico che dice che, in un fps, bisogna preferire il video refresh rate piuttosto che la qualità grafica?

Mi auguro che i prossimi FPS siano AAA per le meccaniche di gioco e non per la grafica.

E tutti a dire di Counter Strike? Tick rate elevato, alta frequenza di pacchetti piccoli, il minimo indispensabile per giocare e un comparto grafico, di effetti, e di distruttibilità rispettivamente orribile, scarno e assente? Gioco brutto ma FPS con hit detection performante.

Ma non è che forse Battlefield ha fatto il passo più lungo della gamba? Non è che forse è arrivato il momento di separare sviluppi pc e sviluppi console? Sviluppi lan per competizioni e sviluppi per la internet di merda che abbiamo tutti?

Di sicuro una cosa è certa.
Come avevo detto io in tempi non sospetti, continuate a fare i beta tester per la DICE e forse Battlefield HARDLINE avrà un netcode accettabile. Scommettete che a E3 tutti a dire che avrà un netcode fantastico?

Mi dispiace, ma sono profondamente amareggiato. E non so in quanti riescano a capirmi. Ma forse è meglio così: meglio soli che male accompagnati.