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à,

NETCODE: (pt-11) ANCHE LO SPECTATOR MODE HA IL NETCODE BACATO?

Come dico spesso, le cose succedono così, per caso. C'è chi dice che la conoscenza è potere e chi dice che la conoscenza porta dolore. Secondo me, vale la seconda.

Un vecchio film comico anni 80 diceva "Beata l'ignoranza, se stà bene de mente, de core e de panza".

E' con questa premessa che voglio raccontarvi una cosa, di cui mi sono accorto, sullo spectator mode. Sono sicuro che tra i miei lettori affezionati che giocano alla console, non sanno che esiste la possibilità di guardare le partite degli altri. I pc-isti sono invece più preparati.

Ultimamente, invece di guardare i soliti video di youtuber famosi che fanno squadra in server di nabbi o che recensiscono armi con una ignoranza feroce, preferisco "spectare" partite di tornei. Lo ritengo molto più interessante ed educativo di vedere il solito fenomeno che fa backrage oppure la solita trollata.

Ero intento a seguire questo match di disarmo quando ad un certo punto ho visto questo che vi riporto in figura:

NET CODE: (pt-10) LA NUOVA (e vecchia) HIT DETECTION IN BF4

La conoscenza avviene così, per caso. A volte, continuando a giocare e a cercare, non si riesce a cavare un ragno dal buco. Poi ti capita di trovarti in quei server impazziti e le bestemmie iniziali possono diventare quei classici "ooohhh" perchè ti appare qualcosa di stupefacente che neanche credevi.

Sono ormai 10 gli articoli di questa serie (link) sul net code, resa famosa dall'articolo sul fattore di fluidità di rete (link). Come al solito consiglio ai nuovi di leggerli tutti, perchè secondo me non si può giocare con un gioco "a scatola chiusa".

In questo articolo, voglio dimostrarvi che cosa è cambiato nella gestione delle hit detection in Battlefield4, rispetto a BF3. Qualcosa è rimasto uguale, ma qualcosa è cambiato. Come al solito, per provare la mia teoria, me ne sono andato in un server australiano (200ms di ping) e mi sono fatto aiutare da amico di psn, L-J90, chiedendogli di essere colpito una sola volta. Semplice.

Senza ulteriori chiacchere, guardiamo la prima delle due figure (la più importante) che rappresenta una normale sequenza di sparo, qui sotto.

NET CODE: (pt.9) DUBBI SULLA DISTRUZIONE IN BF4

Non si fa che parlare di netcode al momento nel quale scrivo questo articolo. Questa serie di articoli (link) era nata con l'intento di svelare agli interessati le speficità e le problematiche nel pensare un sistema multiplayer tra più client, ognuno con la propria connessione.
Riprendiamo il discorso perchè a volte le scoperte si fanno così per caso e vorrei condividere con voi la mia scoperta ovvero una differente scelta progettuale che è stata fatta in Battlefield 4 rispetto al netcode di Battlefield 3.
Ripartiamo dal questo articolo (link) nel quale parlavo della distruzione in Battlefield 3.
Nel video di quel articolo si vedeva chiaramente che

NET CODE: (pt.8) FATTORE FLUIDITA' DI RETE

Rapido: Abbassatelo solo se avete una connessione buona. Quanto basso?

Mi dispiace per tutti quelli che giocavano a Battlefield 3 su console e che pensavano a sparare e divertirsi senza doversi scervellare a capire tutti i problemi di lag di un FPS. Questa mia serie di articoli, giunta all'ottavo appuntamento, era nata per incuriosire e spiegare a chi aveva interesse, cosa ci fosse dietro ad una architettura software distribuita con un FPS.
Ora in Battlefield 4, il parametro di FATTORE FLUIDITA' DI RETE (NETWORK SMOOTHING FACTOR) è disponibile anche per le console. Perciò, ora, è necessario che anche i consollari inizino a studiare il lag e i suoi effetti.
Vediamo perciò che cosa sia questo parametro per poi dare un criterio assoluto per tararlo a dovere. Come al solito, se non lo avete fatto, ripartite dal primo articolo (link). Non nascondo che i molti complimenti ricevuti sulla chiarezza di esposizione, mi spingono a pensare bene di quanto ho scritto e perciò volentieri mi auto faccio pubblicità.
Durante l'apprendimento graduale del sistema, diciamo a metà circa, avevamo capito che

NET CODE: (pt.7) I SUONI

Riprendiamo il discorso sull'architettura di un multiplayer cercando di capire i segreti dietro ad una componente molto importante di Battlefield e più in generale di un FPS: i suoni.

Prima di continuare, essendo arrivato al settimo articolo, suggerisco ai nuovi di partire dal primo articolo (link) dato che darò come presupposto la conoscenza di quanto precedentemente detto.

Lo suggerisco anche perché il prossimo articolo sarà sul network smoothing factor, un parametro di Battlefield 4 da sistemare per bene e sul quale c'è mooooolta ignoranza.

Volendo parlare dei suoni, la prima classificazione che possiamo fare è la seguente:

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:

NET CODE: (pt.5) LAG COMPENSATION

Quinto appuntamento con questa serie di articoli dedicati alla comprensione dei meccanismi e problemi generali dietro all'architettura di un gioco multiplayer.
Siamo finalmente giunti al momento di parlare di hit detection ovvero quella funzionalità del sistema di verificare se un oggetto che ha un potere nocivo colpisca o meno un oggetto che ha un parametro di salute.
Ovviamente se non avete seguito (e spero compreso, con tutti i miei limiti espositivi) gli articoli precedenti, non andate avanti, altrimenti vi risulterà ostico capire che cosa si intende per passato, presente e futuro.  Meglio partire dal primo articolo.
Prima di tutto, fughiamo un dubbio.

Hit detection non è collition detection.

La collition detection rappresenta

NET CODE: (pt.4) LA POSIZIONE DEGLI AVVERSARI

Nei primi post, abbiamo capito che il server controlla il nostro stesso movimento. Abbiamo capito che, però, il nostro client non può aspettare le conferme dal server delle nostre posizioni, così, il client, deliberatamente sceglie di predire il risultato del server, mostrandocelo subito in video.

Abbiamo capito che il nostro video, perciò, è qualcosa nel futuro che il server,e quindi gli altri client, riceveranno dopo.

Come si fa a giocare così? con un sistema che ha un metodo di computazione in ritardo e un video, che pur rappresentando il nostro presente, viene considerato come futuro?

Presi da queste domande abbiamo iniziato ad approcciare con il nostro lag, provando a sparare contro un riparo la cui distruzione sembra essere gestita dal server.

Adesso la domanda:

Come fanno gli altri giocatori ad essere mostrati sul nostro schermo?

NET CODE: (pt.3) NOI ED IL NOSTRO LAG

Continuiamo la nostra discussione su come un sistema multiplayer gestica i client.
Nei primi due post abbiamo iniziato a capire che anche il solo andare avanti con il nostro personaggio, può mettere in difficoltà il server. Questo vale sia per il caso di 1 secondo considerato sia per il casi di pochi millisecondi. La quantità di ritardo non fa cambiare l'entità dei problemi in gioco.
Vediamo perciò ora qualcosa di un pò più elaborato, pur rimanendo nel solo caso di un client e un server.
Fatemi fare, prima, un piccolo chiarimento: qualcuno, dal precedente post, potrebbe dirmi che

NET CODE: (pt.2) NOI ED IL SERVER

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

NET CODE: (pt.1) INTRODUZIONE

Troppo spesso sento parlare di lag, ping, one shoot, connesionati, lag compensation, rubber banding, hit register, prediction e altre cose ancora.
La gente ovviamente le tira fuori quando muore e mai quando uccide qualcuno, chissà perchè. Beh, per la cronaca, anche io sono così.
Secondo me, la maggior parte delle volte, nascondono semplicemente una mancanza di mira e una mancanza di prontezza di riflessi. Altre volte invece no.
Altri, invece, sfruttano le debolezze e i limiti (che esistono) di un sistema multiplayer, distribuito su internet, a proprio vantaggio. Non ci crederete, ma è così.
E' venuto il momento, perciò, per questo blog, di affrontare l'argomento, dopo