Progetto Star Citizen?
9 maggio 2003 - 9 maggio...
10 Anni! Tanti Auguri Vie...
SiS Intro 10th Year
9 Anni di Gaming!
Vittorie su Battlefield 3...
SETTEMBRE 2018
LMMGVSD
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567
 
eVo 1-3 Dettagli
Fuon 4-2 Dettagli
KA 1-3 Dettagli
EYE 2-2 Dettagli
AI 4-0 Dettagli
xF 1-3 Dettagli

Warning: in_array() [function.in-array]: Wrong datatype for second argument in D:\inetpub\vhosts\sis.gamesclan.net\httpdocs\index.php on line 218
Networking Client-Server (CSS) [indietro]
Scritto da Elias il 27-08-2008

Ad un anno e mezzo dalla sua stesura, rendiamo pubbliche alcune note sui parametri di ottimizzazione dei client di giochi fps, con motori di networking moderni. Le informazioni contenute derivano dall'engine Source, precisamente dal suo modulo di networking. Sono ormai tecniche consolidate per diversi engine e possonO oandare bene per altri giochi.

Le teorie e i test esposti sono il risultato di lettura di articoli on line e prove in game fatte dai membri del clan Elias e ViCE.

TICKRATE
Un server di gioco elabora l'evolversi di un mondo digitale (insieme di oggetti che si muovo su uno sfondo) che varia in base ai dati ricevuti dai client connessi e in base alle regole stabilite dal gioco stesso.

Ogni passo di simulazione del mondo è detto tick, ogni server è caratterizzato dal proprio tickrate, cioè il numero di simulazioni al secondo del mondo. Maggiore è il numero di simulazioni maggiore è il carico della cpu e della banda di rete.

RATE, UPDATE RATE, COMMAND RATE
Anche il client deve ricevere gli aggiornamenti dal server, naturalmente ogni client ha una visione parziale del mondo, quella che basta per compiere le varie azioni.

Gli aggiornamenti al client arrivano ovviamente tramite rete e sono soggette ai tempi di latenza, detti comunemente ping. Ogni client può impostare un rate, cioè l'ampiezza di banda per la ricezione dei dati. Accanto al rate, c'è l'update rate, cioè il numero di aggiornamenti (snapshot) al secondo che desidera e può ricevere. Ovviamente il numero massimo di update che può ricevere un client è limitato da quanto può dare il server a cui è connesso. Ad esempio un server con 66 di tickrate non può dare a un client 70 snapshot al secondo.

Un terzo parametro importante è il command rate. I comandi del client al server (come la pressione di WASD o lo sparo) non sono mandati uno alla volta, ma impacchettati e poi spediti. Aumentando il command rate di mandano piu comandi in un pacchetto e quindi si aumenta la reattività del client, ma richiede più banda.

INTERPOLATION (movimenti oggetti)
Un client riceve le informazioni sul movimento degli oggetti per lui rilevanti dal server. Ma se dovesse aspettare di ricevere ogni volta i dati prima di effettuare il movimento allora risulterebbe tutto molto scattoso. Per questo motivo entra in gioco il concetto di interpolazione.

In pratica, tramite un algoritmo noto di calcolo numerico, è possibile fare una predizione sul movimento di un oggetto sulla base di almeno 2 snapshot che descrivono la sua precedente posizione. Questo algoritmo è eseguito sul client e richiede l'uso della cpu. L'esecuzione di questo algoritmo richiede un certo tempo e produce un lag fisso che non dipende dal lag di rete. il tempo necessario alla sua esecuzione dipende dall'update rate. E' infatti necessario attendere di avere almeno 2 update, cioè snapshot, per poter fare la predizione.

Facendo un esempio, se ho un update rate a 20 al secondo, cioè un update ogni 50ms, avrò bisogno di 100ms per il tempo di interpolazione affinchè possa disporre di 2 snapshot. Se miglioro l'update rate a 40 al secondo, avrò un update ogni 25ms e quindi basteranno 50ms di interpolation time. E' evidente che radoppiando l'update rate da 20 a 40 e dimezzando il tempo di interpolazione abbiano ridotto il lag del 50%.

In sintesi, la formula corretta che lega update rate e interpolation time è la seguente:
inter = 2 * (1/update rate)
otteniamo l'intervallo in secondi per una corretta interpolazione.


INPUT PREDICTION (movimenti del proprio player)
Se il proprio player dovesse attendere il comando di azione dal server, ogni movimento risulterebbe scattoso. Per ovviare a questo problema si è introdotto la input prediction client side, ovvero l'esecuzione da parte del client dello stesso codice e dello stesso insieme di regole del gioco del server per poter fare azioni istantanee al proprio personaggio.

Dopo l'opportuno ritardo di rete il server riceve le informazioni sulla nuova posizione del player e trasmette al client il risultato del calcolo. Il client compara l'attuale posizione con quella prevista e se necessario fa una correzione. La correzione può essere graduale e svolta su intervalli temporali ridotti (smooth time).

La predizione è possibile solo se client e server condividono lo stesso codice e le stesse regole per implementare le azioni. Non è poi possibile predirre azioni degli altri player od oggetti sullo schermo per ovvia mancanza di informazione da parte del client.


LAG COMPENSATION (calcolo impatti)
Il problema di fondo è la latenza di rete, il ping. La posizione di un player sul client non coincide con quella del server, ma c'è un ritardo dovuto alla latenza di rete tra il client e il server.

Questo significa che se player 1 vede player 2 e spara mirando correttemente, nel server player 2 potrebbe essere già in una posizione diversa e ancora non comunicata al client player 1.

Per ovviare a questo problema ogni server utilizza un algoritmo di latency compensation che tiene conto dei ritardi di rete e dei ritardi client interpolation. L'idea di base è quella di "tornare indietro nel tempo" per ricostruire qual era l'esatta posizione di player 2 sullo schermo di player 1 al momento dello sparo. In questo modo la traiettoria del proiettile viene "aggiustata" e viene fatto il corretto calcolo degli impatti sul server.

La formula del tempo è: command execution time = current server time - packet round trip time - client view interpolation time.


CONCLUSIONE
In conclusione, per ottenere dei miglioramenti rispetto alle impostazioni di default dei client, è possibile impostare un update rate più alto, compatibile con il tick rate dei server su cui andiamo e compatibile con il rate del client stesso (la sua banda in entrata). Dopo aver impostato l'update rate, possiamo adeguare il tempo di interpolazione seguendo la formula data in precedenza.

Tutto questo discorso di ottimizzazione è legato alla capacità dei server di avere alti tick rate. Se un server ha un tick rate basso (es 33), non potrà soddisfare la richiesta del client di update rate (es 66), ma si limiterà al valore massimo possibile (poniamo 33). Ma se l'interpolation time era stato studiato per un update rate di 66 (e ci troviamo in realtà con un update rate dimezzato) si corre il rischio di non ottenere due snaphost nell'intervallo desiderato e quindi (supposizione) la probabile attivazione dell'algoritmo alternativo di estrapolazione, più impreciso dell'interpolazione e attivato nei casi di packet loss (in questo caso presunto).


ESEMPI
Un server CSS in media va a 66 tick rate. Si può impostare il client update rate a 66 e l'interpolation time a 0,03. Il lag di interpolazione è ridotto così a 30ms e non più al valore di default che è 100ms.

Infine si può aumentare il command rate, ormai la banda è buona per tutti, quindi dal 30 di default si passa ad un 100.

NB: queste impostazioni aumentano il consumo di banda e cpu, quindi bisogna valutare bene le risorse a disposizione prima di procedere.

I comandi di esempio sono:

rate 25000
cl_updatarate 66
cl_interp 0.03
cl_cmdrate 100


Altri comandi:

cl_interpolate 1, attiva interpolazione
cl_extrapolate 1, attiva estrapolazione
cl_lagcompensation 0, disattiva la lag compensation
cl_predict 1, attiva la prediction client side
cl_smoothtime n, intervallo di correzione errori di client prediction
net_graph 1, dati di rete (fps, ping, cl_updaterate, dimensione pacchetti+banda+pacchetti ricevuti/s ricevuti e trasmessi)


Fonti
http://www.gamedev.net/reference/art...rticle1370.asp
http://developer.valvesoftware.com/w...yer_Networking
 
GamesClan.it

 
 

 










Data: 21-02-2008
Sezione: -SiS- Generale
Autore: Aleksei
SiS vs. Oz3
Risultato: 21-12
Data: 20-02-2009
Torneo: CB ladder Pro
Modalità: SD
Progaming.it intervista E...
Netgaming.it intervista E...
ClanWar Importanti dei Si...
Cosa Dicono di Noi
Networking Client-Server...
SiS GameServers Monitorin...
Tutorial: CSS Plugin
Tutorial: IRC
Tutti gli Articoli
-SiS- Forum
AS Airborne Gaming
AS OX-Gaming
AS Udine Gaming
Battlefield Italia Net
ClanBase.com SiS COD4
ClanBase.com .hs team
ClanBase.com SiS clan
ClanBase.it
COD4/IT
EA Battlefield Blog
ESL.eu SiS clan
eSports4all
G4P Game for Prize
GameMonitor
GamesClan
Inferno eSports
ITN intervista i SiS
Konkuri
Liquid Quake Clan
Netgaming.it
PG.it Intervista i SiS
ProGaming Italia
Pure Pwnage
R!OT Gamers
Refresh Gaming
SiS on Facebook
Special Forces
Steam Stats
Team Impact
Team Made In Italy
TS Viewer SiS
VideoGames Release
Vietcong ITALIA
Xjao Clan