Vi proponiamo di seguito la traduzione di un articolo pubblicato sul sito ufficiale di GOALS che si focalizza sulla volontà di proporre un’esperienza di gioco senza Lag. Ringraziamo per la segnalazione Nicola Morgese.
Segui GOALS sui nostri canali
GOALS Italia – Pagina Facebook
GOALS Italia – Gruppo Facebook
GOALS Italia – Canale Telegram
Input lag, latenza di input, server difettosi e tick rate basso sono alcune delle frasi usate per descrivere un gameplay che non risponde. Dividiamolo in parti più piccole e parliamo di dove e perché ciò accade e cosa possiamo fare per migliorare l’esperienza.
In GOALS vogliamo creare la migliore esperienza di gioco possibile e sappiamo che non ci sono scorciatoie per raggiungerla. GLI OBIETTIVI dovrebbero essere buoni e reattivi al gioco; non dovrebbe esserci alcun ritardo quando si preme un pulsante. Per fare in modo che ciò accada, costruiremo strumenti che ci aiutino a misurare il ritardo nelle prime fasi del processo di sviluppo.
I test in questo articolo sono stati eseguiti con un progetto vuoto di Unreal Engine 4 con un server dedicato e un client su una singola macchina. Questi valori potrebbero non essere accurati al 100%, ma ti daranno alcune informazioni su dove si verifica la latenza. Il client funzionava a 120 fps e il server era impostato su una frequenza di tick di 60. L’FPS del client e la frequenza di tick del server per questi test sono stati selezionati per semplificare la misurazione e la presentazione per il lettore.
Hardware
L’hardware utilizzato può essere un fattore per il ritardo di input percepito. Abbiamo un controller, un mouse o una tastiera collegati tramite Bluetooth, USB o Wi-Fi. Tutti questi dispositivi hanno un piccolo ritardo e varia tra il dispositivo specifico, la velocità di polling e il tipo di connessione. Sia i controller Xbox che PlayStation hanno un piccolo ritardo ma hanno una frequenza di polling predefinita diversa che potrebbe causare una maggiore varietà nei ritardi. La frequenza di polling di un dispositivo è il numero di volte in cui il sistema operativo/driver richiederà modifiche. Ad esempio, un controller Xbox 360 ha una frequenza di polling predefinita di 120 volte al secondo e un controller Playstation 4 di 250 volte al secondo. Ciò significa che il controller Xbox ha un ritardo massimo di 8,3 ms e il controller Playstation 4 ms.
Il ritardo per il rendering di un fotogramma sul monitor o sulla TV può variare tra 1 ms e 200 ms. Per un nuovo monitor da gioco, il ritardo è molto basso (di solito tra 1-2 ms) e per i monitor più vecchi può essere di circa 2-6 ms. I televisori sono diversi, hanno uno schermo più grande e non sono ottimizzati per il rendering veloce. Il ritardo può variare tra 14 ms e fino a 200 ms. Alcuni nuovi televisori sono compatibili con GSync e hanno un’impostazione della modalità di gioco in cui alcuni filtri sono disabilitati per ridurre il ritardo nel rendering. Anche la frequenza di aggiornamento su monitor e TV è diversa. I monitor hanno una frequenza di aggiornamento compresa tra 60 e 360 Hz mentre i televisori sono compresi tra 50 e 120 Hz. La frequenza di aggiornamento indica la frequenza con cui un fotogramma verrà disegnato sullo schermo, valori più alti faranno apparire i movimenti più fluidi e reattivi.
Tabella del frame rate del cliente
| Frequenza dei fotogrammi | Tempo per fotogramma | Commento |
|---|---|---|
| 30 | 33 ms | TV e console più vecchie |
| 60 | 16,7 ms | Frequenza di aggiornamento più comune |
| 120 | 8,3 ms | |
| 144 | 6,9 ms | |
| 240 | 4,2 ms |
Il tasso di spunta del server
Diamo un’occhiata più da vicino a come funzionano i server di gioco, in particolare come funziona il tick rate e come influisce sulla reattività.
La frequenza di tick è il numero di volte in cui un server elaborerà l’input, aggiornerà lo stato del gioco e invierà aggiornamenti ai client al secondo. Un server con una frequenza di 60 tick elaborerà l’input ogni 16,7 ms e per un server impostato su una frequenza di 120 tick, è ogni ~8,3 ms. Un tick rate più alto sul server ridurrà il tempo necessario per elaborare l’input dal client e aggiornare la logica di gioco. Ciò ha il costo di una maggiore potenza di elaborazione e traffico di rete poiché è necessario sincronizzare ed elaborare più dati.
In un gioco in cui lo stato del gioco è grande e ci sono molti cambiamenti, il server potrebbe non essere in grado di elaborare l’intero stato più di 30 volte al secondo (30 tick rate), mentre in un gioco in cui lo stato è davvero piccolo potrebbe essere in grado di elaborare lo stato del gioco a 240 volte al secondo senza alcun problema.
Il tick rate influenzerà la latenza di input tra 0 e 1/[tick rate] secondi a seconda di quando il pacchetto di input arriva al server.
Internet e comunicazione in rete
I giochi multiplayer su Internet avranno sempre una latenza varia e ciò è dovuto al tipo di connessione, al numero di percorsi tra il client e il server, nonché alla quantità di traffico su quella linea fisica. Internet è molto inaffidabile e può far sì che i pacchi arrivino nell’ordine sbagliato o si perdano per strada. Quando un pacchetto viene perso, il client/server deve decidere se richiedere un nuovo invio o semplicemente scartarlo. Questo di solito viene fatto in anticipo nel motore di gioco, contrassegnando alcuni pacchetti come affidabili o inaffidabili. I pacchetti affidabili richiedono che il server/client risponda con un ack (riconoscimento) quando il pacchetto è arrivato mentre la versione inaffidabile è solo fire-and-forget e ignora i pacchetti persi.
L’input dovrebbe sempre essere inviato come un pacchetto affidabile poiché i dati non dovrebbero mai essere persi, mentre gli aggiornamenti di posizione possono essere inviati come inaffidabili. Rinviare una vecchia posizione di un giocatore nel gioco potrebbe essere uno spreco perché quando raggiunge la destinazione i dati sono vecchi (questo varia tra i diversi tipi di giochi).
Quando i pacchetti vengono persi, si verificherà una sorta di ritardo, in alcuni casi il gioco potrebbe apparire bloccato e in altri casi potresti riscontrare che il tuo personaggio non ha reagito abbastanza velocemente al tuo input.
Rendering e sincronizzazione
Esistono alcune impostazioni che possono modificare il modo in cui un fotogramma viene visualizzato sullo schermo per aumentare le prestazioni, ridurre la latenza, evitare lo strappo dello schermo, ecc. Ecco una breve panoramica di come influiscono sulle prestazioni e sul ritardo di input percepito.
È possibile eseguire il rendering di un frame nel buffer posteriore (il buffer letto dal display) scrivendo direttamente nel buffer, scrivendo in un buffer temporaneo e copiando il buffer quando è pronto o in diversi buffer e scambiando semplicemente il sorgente. Questi ultimi due sono chiamati doppio e triplo buffering. Entrambi aumenteranno le prestazioni del gioco poiché non scrive direttamente nel buffer posteriore ma introdurrà anche una piccola latenza. (vedi riferimenti per informazioni approfondite su questo)
Lo screen tearing è qualcosa che accade quando la frequenza di aggiornamento del monitor non corrisponde alla frequenza dei fotogrammi nel gioco. VSYNC è un modo per risolvere questo problema mantenendo la frequenza dei fotogrammi (scrittura nel buffer posteriore) sincronizzata con la frequenza di aggiornamento del monitor. Ciò darà al giocatore un’esperienza molto fluida senza strappi dello schermo, ma introdurrà una piccola latenza sull’input poiché ogni fotogramma deve attendere che il monitor sia pronto per il rendering.
GSync/Freesync è una nuova tecnologia di monitoraggio che consente alla GPU di controllare la frequenza con cui il monitor deve eseguire il rendering anziché il contrario. Ciò elimina sia l’input lag che lo strappo dello schermo e offrirà la migliore esperienza possibile. Lo svantaggio è che richiede hardware speciale, sia la GPU che il monitor devono supportare GSync(Nvidia) o Freesync(AMD).
I test in Unreal Engine
Abbiamo creato alcuni semplici strumenti per tenere traccia della latenza dalla pressione di un pulsante fino a quando il server non risponde con gli aggiornamenti.
La barra blu è il client ed è il tempo impiegato da Unreal Engine per registrare un clic su un pulsante. In Unreal Engine l’input è legato al frame rate, un frame rate alto eseguirà il polling dell’input più spesso, un frame rate più basso aumenterà la latenza. La barra rossa è la comunicazione con il server dove impacchetta i dati, invia il pacchetto, decomprime i dati ed esegue il metodo sul server. La barra gialla è il tempo impiegato dalla risposta per tornare al client.
Se li suddividiamo in parti più piccole e li confrontiamo con ciò che abbiamo imparato finora: il client funziona a 120 fps, il che significa che l’input verrà interrogato ogni ~8,3 ms, il che ci darebbe un ritardo di input medio di ~4 SM. Questo può essere visto nel grafico sopra.
La frequenza di tick del server è impostata su 60 e ogni input verrà letto ogni 16,7 ms (media a ~8,3 ms), questa è la barra rossa nel grafico. Il server invia la risposta al client e il client legge quella risposta ogni 8,3 ms (120 fps), questa è la parte gialla.
Il caso peggiore in questo scenario è di 30 ms tra un clic del pulsante e il codice viene eseguito sul client e il migliore è inferiore a 10 ms.
Nel grafico sottostante possiamo vedere un confronto di quanto tempo ci vuole prima che si verifichi un evento di rilascio di un pulsante (questo è un normale clic con il pollice su un controller PS4). Ciò significa che se il gioco reagisce con il pulsante in alto anziché con il pulsante in basso, avrai un ritardo di 50-120 ms prima che l’input sia stato letto ed elaborato dal loop di gioco. Per ridurre il ritardo di input dovresti eseguire l’azione sugli eventi button-down, tuttavia in alcuni casi ciò potrebbe non essere possibile. Ad esempio, nei giochi in cui premi due volte o premi + tieni premuto, il codice del gioco deve attendere un certo periodo di tempo prima di poter decidere quale azione stai facendo. Se utilizzi lo stesso pulsante per un solo tocco, dovrai comunque attendere quel lasso di tempo prima che sappia quale azione stai eseguendo.
Sommario
Abbiamo parlato di hardware, software e Internet. Ci sono molti passaggi tra la pressione di un pulsante fino a quando non accade qualcosa sullo schermo. Nella tabella sottostante puoi vedere tutti i passaggi che accadono quando premi un pulsante nel test che abbiamo fatto. Quando tutto è perfetto, la maggior parte di questi passaggi sarà molto vicina a 0 e nel peggiore dei casi si sommerà a un numero elevato in base a frame rate, tick rate, latenza Internet, dispositivo di input e impostazioni di rendering.
I tempi di rendering e visualizzazione non sono stati da noi misurati, questi numeri provengono da test che si possono trovare nella sezione riferimenti.
| Fonte | Possibile latenza | Commento |
|---|---|---|
| Dispositivo di input (controller, tastiera, mouse) | 0 – 10 ms | Il ritardo nel dispositivo fisico, nei driver e nel sistema operativo. |
| Ciclo di gioco (lettura input) | 30 fps = 33 ms 60 fps = 16,7 ms 120 fps = 8,3 ms |
La frequenza dei fotogrammi a cui è in esecuzione il gioco se il motore esegue il polling dell’input una volta ogni fotogramma. |
| Invia input al server | 0 – 0,2 ms | Packaging/Serializzazione dei dati sul cliente. |
| Internet/Rete | > 0 ms | Questo è il tempo impiegato da un pacchetto per raggiungere il server (questo non è RTT o Ping). Questo può variare molto a seconda della tua posizione e del tuo ISP. |
| Elabora l’input sul server | 30 tick = 0 – 33 ms 60 tick = 0 – 16,7 ms 120 tick = 0 – 8,3 ms |
Il pacco verrà elaborato ad ogni tick sul server, quindi a seconda di quando arriva il ritardo varierà. |
| Invia risposta al cliente | 0 – 0,2 ms | Pacchetto/Serializzare i dati sul server. |
| Internet/Rete | > 0 ms | È tempo che un pacco raggiunga il cliente. |
| Elabora messaggio sul client | 30 fps = 0 – 33 ms 60 fps = 0 – 16,7 ms 120 fps = 0 – 8,3 ms |
Nella maggior parte dei motori di gioco i pacchetti di rete verranno elaborati all’inizio del ciclo di gioco e i sistemi possono esaminare i valori nella loro funzione tick/aggiornamento. |
| Rendi | 0-10 ms | A seconda della tecnica di rendering utilizzata, questo può variare tra 0 e un paio di millisecondi. Dipende anche da quando viene elaborata la grafica nel ciclo di gioco. |
| Visualizzazione su monitor/TV | 1 – 200 ms | Il tempo impiegato dal monitor per mostrare ciò che la GPU ha nel buffer posteriore. |
Ci sono alcune cose che non abbiamo menzionato in questo articolo e che sono problemi che si verificano sul server, ad esempio un breve “blocco” sul server che fa sì che il tempo di elaborazione richieda più tempo del dovuto, si disconnette o rilascia pacchetti a causa di overflow di input, ecc.
Cosa sai fare?
Ci sono alcune cose che puoi fare per ridurre la latenza di input percepita.
- Esegui alcuni test con VSync e abilita/disabilita il doppio/triplo buffering.
- Se il tuo dispositivo supporta un tasso di polling più alto, probabilmente puoi trovare qualcosa nel manuale o in qualche forum online su come aumentarlo.
- Se hai un monitor o una TV più vecchi e stai considerando un aggiornamento, cerca qualcosa che sia fatto per i giochi.
- I monitor e le TV compatibili con GSync/Freesync/GSync renderanno il gioco migliore, assicurati che la tua scheda grafica lo supporti.
Cosa farà GOAL?
Alcune di queste cose di cui abbiamo parlato non sono qualcosa per cui GOALS può fare qualcosa, ma ci sono alcune parti in cui faremo del nostro meglio per migliorare la reattività del gioco.
Le prestazioni sul client e sul server sono una parte che influisce sulla latenza di input ed è qualcosa con cui possiamo lavorare. Aggiungeremo molti punti di telemetria all’inizio dello sviluppo del gioco in modo da poter monitorare l’impatto di ogni modifica e funzionalità che aggiungiamo. Questo ci darà una migliore comprensione di quali parti possono essere ulteriormente ottimizzate per ottenere un frame rate più elevato.
Esistono molte tecniche diverse che possono essere utilizzate per migliorare la latenza percepita prevedendo la mossa che fa il giocatore, come avviare un’animazione quando viene premuto il pulsante invece di aspettare che il server lo approvi. Lo svantaggio è quando il client e il server non sono d’accordo su qualcosa e sperimenterai un piccolo effetto elastico.
Passeremo molto tempo a testare diverse soluzioni a questo problema in modo da poter offrire al giocatore un’esperienza eccezionale anche quando le condizioni della rete non sono ottimali.
Ti terremo aggiornato con i nostri progressi e condivideremo i dettagli su come stiamo misurando le prestazioni e la reattività.
Collegamenti e riferimenti
Monitor/TV
- https://hdtelevizija.com/en/input-lag-measurements/
- https://www.rtings.com/monitor/tests/inputs/input-lag
Monitora il ritardo di input per i controller
Rendering
