ゲームのラグとパケットロスを再現する
ネットコードは1 msのpingのローカル接続で書かれ、ホテルのWi-Fiにいるプレイヤーによってテストされます。このツールは、そのギャップを手元のマシンで、ゲームのプロセスだけを対象に埋めます。コンピューターのほかの部分は使えるままです。
ここから始める
ゲームクライアントを狙い、現実的な悪い回線を与え、5分後に自動で止まるようにします：
BeanNetworkTester.exe --latency 120 --jitter 60 --loss 3 --target mygame.exe --duration 300このための用意済みタイムラインもあります。scenarios フォルダーの overloaded-game-server.json は、接続を輻輳に追い込み、そこから回復させるので、変化の両方向をクライアントがどう扱うか見られます。時間で変わるシナリオを参照してください。
ブラウザでは見えないパケットロスが、ゲームでは見えるのはなぜか
ゲームの通信の大半はUDPで、UDPにはパケットロスを隠す仕組みがありません。TCPのWebページは黙って再送し、時間がかかるだけです。そのため、5%のパケットロスでもブラウザは快適に感じられる一方、同じ5%の対戦ではカクつき、巻き戻され、同期がずれます。
だからゲームは、パケットロスを正直にテストできる場です。設定した値が、そのままクライアントの体験になります。
何を設定し、何を調べるか
| 設定 | 試す値 | 何が露わになるか |
|---|---|---|
| 遅延 | 80から250 ms | 予測と補間。撃ったあとにキャラクターが引き戻されませんか？ |
| ジッター | 40から100 ms | バッファリング。一定の200 msは、動き続けるpingよりも隠しやすいものです。 |
| パケットロス | 2から10% | 状態更新の欠落と、クライアントが回復するのか、ずれていくのか。 |
| スパイク | 1秒、まれに | 基地局のハンドオーバーが起こす停止。たいてい最も見苦しいものです。 |
| 回線のオン・オフ | 10秒周期、30%を断に | 再接続と再参加。 |
ジッターは平均ではなく、95パーセンタイルと中央値の差として測ってください。ジッターは平均をほとんど動かさないため、実行が書面上は同じに見えても、遊んでみると違うのです。
2つのビルドを比べるにはシードが必要
ランダムなパケットロスでは2回の実行が異なるため、「新しいビルドのほうが悪く感じる」は証拠になりません。同じシードなら同じパケットロスと同じジッターが再生されるので、感覚が比較に変わります：
BeanNetworkTester.exe --latency 120 --jitter 60 --loss 5 --seed 42 --target mygame.exe --duration 180できないこと
これが整形するのはあなたのマシンの通信です。サーバーを遅くすることも、ティックレートを変えることも、他のプレイヤーを悪い回線に置くこともありません。つまりテストできるのは、悪い回線に対するクライアントであって、負荷がかかったサーバーではありません。サーバー側には負荷テストが、悪い接続だらけのロビーには複数台のマシンが必要です。