Simular lag y pérdida de paquetes en juegos
El netcode se escribe en una conexión local con 1 ms de ping y lo prueban jugadores con el Wi-Fi de un hotel. Esto cierra esa brecha en tu propia máquina, solo en el proceso del juego, mientras el resto del sistema sigue siendo utilizable.
Empieza aquí
Apunta al cliente del juego, dale una mala conexión realista y deja que se detenga solo a los cinco minutos:
BeanNetworkTester.exe --latency 120 --jitter 60 --loss 3 --target mygame.exe --duration 300También hay una línea de tiempo lista para esto: overloaded-game-server.json, en la carpeta scenarios, lleva una conexión a la congestión y de vuelta, para que veas cómo gestiona el cliente los dos sentidos del cambio. Consulta escenarios temporales.
Por qué un juego muestra pérdida y un navegador no
La mayor parte del tráfico de juegos es UDP, y UDP no tiene nada tras lo que esconder la pérdida. Una página web sobre TCP retransmite en silencio y solo tarda más, por eso un navegador puede sentirse bien con un 5 % de pérdida mientras una partida con ese mismo 5 % da tirones, retrocede y se desincroniza.
Eso convierte a un juego en el lugar honesto para probar la pérdida: lo que ajustas es lo que el cliente experimenta de verdad.
Qué ajustar y qué pone a prueba
| Ajuste | Prueba | Qué deja al descubierto |
|---|---|---|
| Latencia | 80 a 250 ms | Predicción e interpolación. ¿Tu personaje retrocede después de un disparo? |
| Jitter | 40 a 100 ms | Almacenamiento en búfer. Unos 200 ms estables se disimulan mejor que un ping que no deja de moverse. |
| Pérdida | 2 a 10 % | Actualizaciones de estado perdidas, y si el cliente se recupera o se desvía. |
| Picos | 1 segundo, rara vez | La parada que causa un traspaso entre antenas. Normalmente la más fea. |
| Enlace que va y viene | ciclo de 10 s, 30 % caído | Reconexión y reincorporación. |
Mide el jitter como la diferencia entre el percentil 95 y la mediana, y no como un promedio: el jitter apenas mueve un promedio, y por eso una ejecución puede parecer idéntica sobre el papel y jugarse de otra manera.
Comparar dos compilaciones necesita una semilla
La pérdida aleatoria hace distintas dos ejecuciones, así que «la compilación nueva se siente peor» no es una prueba. La misma semilla reproduce la misma pérdida y el mismo jitter, y eso convierte una sensación en una comparación:
BeanNetworkTester.exe --latency 120 --jitter 60 --loss 5 --seed 42 --target mygame.exe --duration 180Lo que no puede hacer
Esto modela el tráfico de tu máquina. No ralentiza el servidor, no cambia su tick rate y no pone a otros jugadores en una mala conexión, así que prueba tu cliente frente a un mal enlace, no tu servidor bajo carga. Para el lado del servidor necesitas pruebas de carga, y para una sala llena de malas conexiones necesitas más de una máquina.