Simulare lag e perdita di pacchetti nei giochi
Il netcode si scrive su una connessione locale con 1 ms di ping e lo provano giocatori sul Wi-Fi di un hotel. Questo colma quel divario sul tuo computer, solo sul processo del gioco, mentre il resto del computer resta utilizzabile.
Parti da qui
Punta al client del gioco, dagli una brutta connessione realistica e lascia che si fermi da solo dopo cinque minuti:
BeanNetworkTester.exe --latency 120 --jitter 60 --loss 3 --target mygame.exe --duration 300
C’è anche una linea temporale pronta per questo: overloaded-game-server.json, nella cartella scenarios, porta una connessione alla congestione e ritorno, così puoi vedere come il client gestisce entrambe le direzioni del cambiamento. Vedi scenari nel tempo.
Perché un gioco mostra perdita e un browser no
La maggior parte del traffico dei giochi è UDP, e UDP non ha nulla dietro cui nascondere la perdita. Una pagina web su TCP ritrasmette in silenzio e ci mette solo più tempo, ed è per questo che un browser può andare bene con il 5% di perdita mentre una partita con lo stesso 5% scatta, torna indietro e si desincronizza.
Questo rende un gioco il posto onesto per provare la perdita: ciò che imposti è ciò che il client vive davvero.
Cosa impostare e cosa mette alla prova
| Impostazione | Prova | Cosa rivela |
|---|---|---|
| Latenza | da 80 a 250 ms | Predizione e interpolazione. Il tuo personaggio scivola indietro dopo uno sparo? |
| Jitter | da 40 a 100 ms | Buffering. Un 200 ms costante si nasconde meglio di un ping che continua a muoversi. |
| Perdita | dal 2 al 10% | Aggiornamenti di stato mancanti, e se il client si riprende o va alla deriva. |
| Picchi | 1 secondo, raramente | Il blocco causato da un passaggio tra celle. Di solito il più brutto. |
| Collegamento che va e viene | ciclo di 10 s, 30% di inattività | Riconnessione e rientro. |
Misura il jitter come la distanza tra il 95º percentile e la mediana, non come una media: il jitter sposta appena una media, ed è per questo che un’esecuzione può sembrare identica sulla carta e giocarsi in modo diverso.
Confrontare due build richiede un seed
La perdita casuale rende diverse due esecuzioni, quindi «la nuova build sembra peggio» non è una prova. Lo stesso seed riproduce la stessa perdita e lo stesso jitter, e trasforma una sensazione in un confronto:
BeanNetworkTester.exe --latency 120 --jitter 60 --loss 5 --seed 42 --target mygame.exe --duration 180
Cosa non può fare
Questo modella il traffico della tua macchina. Non rallenta il server, non cambia il suo tick rate e non mette gli altri giocatori su una brutta connessione, quindi prova il tuo client contro un brutto collegamento, non il tuo server sotto carico. Per il lato server servono test di carico, e per una lobby piena di brutte connessioni serve più di una macchina.