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 
essermi documentato un pò, per capire maggiormente come funziona un gioco multiplayer, quali siano gli effetti in termini di giocabilità e, perchè no, come sfruttare a proprio vantaggio le debolezze del sistema.

In rete si riesce a trovare qualcosa di tecnico. Principalmente su sito della Valve, nella categoria sviluppo. Per il resto, solo un mare di chiacchere che si contraddice a vicenda. Ovviamente solo la Dice sa il tipo di net code implementato.
Non so se siete stati attenti, ma in un video dicevano che avevano trovato un modo di far vedere, a tutti i giocatori, la stessa onda, della stessa grandezza, facendo capire che, nella guerra in acqua, l'onda poteva diventare tatticamente utile.

Non vi ha incuriosito?

Più in generale, sul net code, qualche soffiata si trova su reddit, twitter, forum, ma poca roba che a volte deve essere anche interpretata.
Ovviamente si parla di software, di sistemi distribuiti, di analisi dei segnali e geometria nello spazio. Questo è il backgroud necessario per approcciare veramente ai concetti dietro alla codifica di un software che, in tempo reale, rappresenti un mondo virtuale omogeneo e consistente a tutti i giocatori.
Basteranno perciò un piccolo gruppo di articoli per entrare nel merito dell'architettura, fare propri i termini come lag compensation o altri e soprattutto evitando di sparlare a proposito.
A differenza di tanta gente che sparla, che non ha nè le competenze, nè tantomeno un briciolo di prova, cercherò di mostrare sempre un video di quello che penso. La descrizione si riferirà ovviamente ad un modello generale, cercando di capire, ove possibile, le implicazioni in battlefield, facendo degli esperimenti.
Quello che in termini tecnici si chiama "reverse engineering" ovvero non sviluppare e vedere l'effetto, ma osservare l'effetto e capire come è stato sviluppato.
Chi spara ad un carro armato e vede la differenza di valori di danno provocato, ad esempio, fa reverse engineering del codice software attribuisce un danno a seguito di un colpo.

Visto che anche io cercherò di fare reverse engineering, vi faccio conoscere il mio setup:

1 PS3
1 amico laggone (così si definisce ma nella realtà non mi sembra)
1 amico americano (appena è disponibile)
1 connessione (non wifi) con libero da 20MB testata con Speedtest.net con risultati: 14M download, 0,5M upload, 10ms ping.

Qualcuno si sarà spaventato del ping basso. Ping, un termine che si usa tantissimo.

Giusto per farvi capire che il ping forse non c'entra sempre, vi mostro questo spezzone di un filmato che riprenderemo poi.
Quello sono io che muore dietro ad un muro, la più classica lamentela che si sente in giro.
Mi ha aiutato Jack. Artificiosamente ho ricreato quella situazione. Non con un lag switch. Il risultato sarebbe stato differente.
Mentre facevo quella registrazione speed test mi dava 30 di ping. E come lo spiegano i sapientoni?
Chi c'era e chi ha assistito sa perchè. Ma lo vedremo con calma nel prossimo post.

LINK YOUTUBE