Simuler le lag et la perte de paquets d’un jeu
Le netcode s’écrit sur une connexion locale à 1 ms de ping et se teste avec des joueurs sur le Wi-Fi d’un hôtel. Cet outil comble cet écart sur votre propre machine, sur le seul processus du jeu, tandis que le reste de l’ordinateur reste utilisable.
Pour commencer
Visez le client du jeu, donnez-lui une mauvaise connexion réaliste et laissez-le s’arrêter de lui-même au bout de cinq minutes :
BeanNetworkTester.exe --latency 120 --jitter 60 --loss 3 --target mygame.exe --duration 300Il existe aussi une chronologie prête à l’emploi : overloaded-game-server.json, dans le dossier scenarios, conduit une connexion jusqu’à la congestion puis l’en ramène, pour que vous voyiez comment le client gère les deux sens du changement. Voir scénarios temporels.
Pourquoi un jeu montre de la perte alors qu’un navigateur non
La plupart du trafic de jeu est de l’UDP, et l’UDP n’a rien derrière quoi cacher la perte. Une page web en TCP retransmet discrètement et met simplement plus de temps, ce qui explique qu’un navigateur puisse sembler correct à 5 % de perte alors qu’une partie, avec ces mêmes 5 %, saccade, revient en arrière et se désynchronise.
Cela fait d’un jeu l’endroit honnête pour tester la perte : ce que vous réglez est ce que le client vit réellement.
Quoi régler, et ce que cela met à l’épreuve
| Réglage | À essayer | Ce que cela révèle |
|---|---|---|
| Latence | 80 à 250 ms | Prédiction et interpolation. Votre personnage glisse-t-il en arrière après un tir ? |
| Gigue | 40 à 100 ms | Mise en tampon. Un 200 ms constant se cache plus facilement qu’un ping qui bouge sans cesse. |
| Perte | 2 à 10 % | Les mises à jour d’état manquantes, et si le client se rétablit ou dérive. |
| Pics | 1 seconde, rarement | Le blocage que provoque un transfert entre antennes-relais. Souvent le plus moche. |
| Liaison coupée puis rétablie | cycle de 10 s, 30 % hors service | Reconnexion et retour dans la partie. |
Mesurez la gigue comme l’écart entre le 95e centile et la médiane plutôt que comme une moyenne : la gigue modifie à peine une moyenne, ce qui explique qu’une exécution puisse sembler identique sur le papier et se jouer différemment.
Comparer deux versions demande une graine
Une perte aléatoire rend deux exécutions différentes, donc « la nouvelle version me semble moins bonne » n’est pas une preuve. La même graine rejoue la même perte et la même gigue, ce qui transforme une impression en comparaison :
BeanNetworkTester.exe --latency 120 --jitter 60 --loss 5 --seed 42 --target mygame.exe --duration 180Ce qu’il ne peut pas faire
Cela façonne le trafic de votre machine. Il ne ralentit pas le serveur, ne change pas son taux de tick et ne met pas les autres joueurs sur une mauvaise connexion : il teste donc votre client face à une mauvaise liaison, pas votre serveur sous charge. Pour le côté serveur, il faut des tests de charge, et pour un salon plein de mauvaises connexions, il faut plus d’une machine.