Download to read offline
Uploaded byKengo Nakajima
ゲームの通信をつくる仕事はどうなるのだろう？
サムザップ 第7回テックナイトの講演で使ったスライドです。 5Gやクラウドインフラの変化によって通信ゲームの作り方がどんなふうに変わるのかについて考えます。
ゲームの通信をつくる仕事はどうなるのだろう？
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12. • WiFi 1: 802.11b (1999) 11Mbps • WiFi 2 : 802.11a (1999) 54Mbps • WiFi 3 : 802.11g (2003) 54Mbps • WiFi 4 : 802.11n (2009) ~600Mbps • WiFi 5 : 802.11ac (2014) 292Mbps~6.9Gbps • WiFi 6 : 802.11ax (2019) 9.6Gbps • WiFi 7 : 802.11be (2024?) ? WiFi
- 13. モバイル通信 名称 時期 帯域幅遅延 料金 2G 1991 40Kbps 100ms~ ∝パケ数 3G 2000 144Kbps~ 100ms~ ∝パケ数 4G 2009 ~1Gbps 10ms~ ∝パケ数/定額 5G 2018 ~数Gbps(複雑) 1ms~ 定額? 6G ? Tbps? マイクロ秒 ?
- 14. クラウドマシン CPUコスト • 1CPUコアの2GB程度なマシン/1ヶ月 •AWS/Google/Azure他:5000円〜1万円でじわじわ下落 • Linode/DigitalOcean等 : 500円〜1000円で下落中
- 15. クラウドマシンからの送信コスト • 1GB送信 • AWS/Google/Azure他:5~10円 • Linode/DigitalOcean等 : 1~2円 • だんだん下がっている • 単価下げ • 無料枠の拡大
- 16. クラウドストレージのコスト • AWS S3TBあたり (標準タイプ) • 2006 : $150 • 2010 : $140 • 2012 : $95 • 2014 : $30 • 2019 : $21
- 17.
- 18. インターネット層 • IPv4, IPv6 •遅延の大きさ • クラウドはどこにある
- 19.
- 20.
- 21. 長距離転送 • 東京 -サンフランシスコ • 往復 16000km • 光速 200000km/s • 理論上の時間 : 80ms • pingして計測 : 110ms~120ms • 10年前は150ms~200msだった • これ以上改善は難しいかも
- 22. 中距離転送 • 東京 -富山 • 往復 1600km (大阪経由) • 光速 200000km/s • 理論上の時間 8ms • pingして計測 24ms • まだ改善するかもしれない
- 23. 都市内転送 • 都内であれば0.5~2ms • AWS-Google/Azure0.5ms~1ms • AWS-AWS 0.1~1ms • AWS-Linode 2ms
- 24. 同一AZ内転送 • AWS • ピークは10Gbps/ 20Gbps (インスタンスによる) • インスタンスタイプによって様々な制限がかかる • 負荷が一定以上継続すると制限 • 帯域制限 • パケット数制限 (100万~140万pps) • 高額なインスタンスは制限がゆるい https://cloudonaut.io/ec2-network-performance-cheat-sheet/
- 25.
- 26.
- 27.
- 28.
- 29. インターネットの性能 • パケットロス率 • 有線LAN: スイッチとケーブルがちゃんとしてたら、ほぼ0だが、 受信側マシンに余裕がなくなると消える • 無線LAN : 負荷がないときでも10000個に1個ぐらい消える。負荷 が高いと、100個に1個消えるときもある • モバイルネットワーク : 電波がいいときでも100個に1個消えるか も、電波が悪いと1割消えたりする
- 30. 2つの主要プロトコル UDP TCP 宛先マシン内の特定のポートに届ける ○○ チェックサムで誤り訂正 ○ ○ パケットロスのとき再送する ○ データの順序を保証する ○
- 31. ソケットAPIにおける「ポート番号 」 Linuxマシン1 プロセス1 Windowsマシン1 10.0.1.11 10.0.1.12 プロセス2 プロセス1 TCP 8080 UDP 3001 TCP443 UDP 53 インターネット→ TCPパケット IP:10.0.1.11 PORT: 8080 UDPパケット IP:10.0.1.12 PORT: 53
- 32. トランスポート層: TCPの時代分け • 1980年代: TCP登場、telnetでマシンを遠隔操作 • 1990年代 : メールやHTTPなどで大ブレイク • 2000年代 : モバイルで長時間のストールを防ぎたい！ • 2010年代 : 動画や音声を高速送信したい! Nagleアルゴリズム、スロースタート 高速リカバリの導入と改良 Long Fat パイプへの対応 状況や用途に合わせてアルゴリズムの使い分け
- 33. TCPがどうしても解決できない問題 • head-of-line blocking •IPアドレスの変化に対応できない
- 34. head of lineblocking TCP こんなふうにしたい packet1の影響で、全体が長時間ストールする packet1はストールするがpacket2,3は早く届く packet1の再送 packet1の再送 https://qiita.com/Jxck_/items/0dbdee585db3e21639a8
- 35.
- 36. QUIC • TCPの欠点を克服するUDPベースのプロトコル(RUDP) • 2012年,Google • 現在は仕様のドラフト23、早いペースで改良中 • head of line blocking回避 • アドレス変化に対応 • マルチチャネル • 0RTT接続 (新規接続が速い) • 暗号化 • WebSocketsどころではなく大きな全部入り仕様
- 37. MRU : MonobitRUDP • C++(ほぼC), 小さい • IPアドレス変化への対応 • 正しい順序で送る • 確実に送る (早めの再送,QUICにはない) • 順序も確実さも保証しない方法で送ることもできる • 0RTTハンドシェイク • チェックサム • サーバサイドの動的なアドレス, QUICにはない • C10K以上のMMO向けにチューニング(少人数ももちろんOK) • スロット飽和攻撃対策 • IP偽装対策 • 大量接続対策 • Linux/Windows/iOS/Android/MacOSに対応、ゲーム機は対応予定 • 暗号化は上位レイヤで実装
- 38. HTTPの発展 接続＞1ページGET>切断 KEEPALIVE, パイプライン化 ストリーム多重(並列)化, フロー制御 headof line blocking 回避, アドレス変化への対応 https://bloggeek.me/who-needs-quic-in-webrtc/
- 39. ブラウザ双方向通信の発展 • 2011 WebSockets: TCP / HTTP1.1 に追加された • 2011 WebRTC : UDP • 2020~? WebTransport / UDP Socket : WebSockets の UDP版
- 40.
- 41.
- 42. クラウドゲーミング • サーバからクライアントに映像を送信する • ゲームのプログラムを配布しない •インストール不要、即クライアント起動 • 違法コピー/リバースエンジニアリング防止 • テストとデバッグの方法が柔軟に • クライアントのプラットフォーム別の対応が不要 • ネットコードなしでマルチプレイを実装できる
- 43. クラウドゲーミング3つのモデル • 1:1 1ユーザーに1サーバー •N:N 1:1ゲームをNユーザーでマルチプレイ • 1:N Nユーザーに1サーバー
- 44. インターネット 画面/スピーカー タッチパネル、マウ ス、パッド 操作内容 描画結果の映像 ゲームフロントエンドサーバ ビューワプログラム CPU, GPU,Flashストレージetc 操作 出力 サーバOS (Linux, Windows,etc) 描画指示 描画結果 各種ハードウェア/OS 1:1 一人用ゲーム プレイヤー側端末 ゲーム提供側環境(クラウド)
- 45. インターネット プレイヤー側端末 ゲーム提供側環境(クラウド) 操作内容 描画結果 画面/スピーカー タッチパネル、マウ ス、パッド ビューワプログラム ゲームフロントエンドサーバ CPU, GPU,Flashストレージetc サーバOS (Linux, Windows,etc) 画面/スピーカー タッチパネル、マウ ス、パッド ビューワプログラム ゲームフロントエンドサーバ CPU, GPU, Flashストレージetc サーバOS (Linux, Windows,etc) 操作内容 描画結果 任意の形式で直接通信 各種ハードウェア/OS各種ハードウェア/OS N:N 2人用
- 46. インターネット プレイヤー側端末 ゲーム提供側環境(クラウド) 操作内容 描画結果 画面/スピーカー タッチパネル、マウ ス、パッド ビューワプログラム 画面/スピーカー タッチパネル、マウ ス、パッド ビューワプログラム ゲームフロントエンドサーバ CPU, GPU,Flashストレージetc サーバOS (Linux, Windows,etc) 操作内容 描画結果 各種ハードウェア/OS各種ハードウェア/OS ネットワークコードなしでマルチプレイを実装できる 1:N
- 47. インタ ーネッ ト Unity on GPUつきサーバー 1:N映像ストリーム 映像+データ 操作 ゲームデータはひとつ。 全モデルデータ、全メッシュ テクスチャ、シェーダなど GPU内のオブジェクトをすべて共有した状態で 4回レンダリングするだけ。 クライアントでデータを受信し、 HUDを重ねて描画する
- 48.
- 49. クラウドゲームと遅延 • スタンドアロンゲーム(非タッチ) • 入力~0.1ms 描画 16.6~33.3ms 合計16.6~33.3ms • スタンドアロンゲーム(タッチ) • 入力 40~100ms 描画 16.6~33.3ms 合計 50~135ms • クラウドゲーム(非タッチ) • 4G 入力 ~0.1ms ネットワーク 40~100ms 描画 16.6~33.3ms ネットワーク 40~100ms デコード 1ms 描画 16.6ms 合計110〜250ms • 5G 入力 ~0.1ms ネットワーク 5~20ms 描画 16.6~33.3ms ネットワーク 5~20ms デコード 1ms 描画 16.6ms 合計45〜90ms • クラウドゲーム (タッチ) • 非タッチ＋40~100ms • 4G 合計 150~350ms • 5G 合計 85~190ms
- 50. クラウドゲームで必要な帯域 • 伝統的な同期 • 10~100Kbps •描画コマンドストリーム • 10~500Kbps • 映像 • 500K~1Mbps (640x480) • 1~3Mbps (1280x720)
- 51. 映像送信の最適化 • ゲームロジックがエンコーダに指示できる • シーンごとに圧縮率・フレームレート切り替え •画面の部分ごとに圧縮率切り替え • スクロールゲームにおける圧縮ヒント • 音声再生だけクライアントで行う • etc.. 1280x720で2Mbpsから、1Mbps~ 500Kbps台へ
- 52.
- 53. 鍵となる環境の変化 • 送信コストが1GBあたり1円 • 100Kbpsの音声を78000秒 •500Kbpsのアバターモーションを 15625秒 • 1280x720 2Mbpsの映像を3900秒 • GPUインスタンスの費用 • 今の半分でもまだ高いかも • EC2 g2 > g3 > g4 > … • 5G定額 • ブラウザでUDP
- 54. ゲームデータの同期は必要なくなるの か？ • クラウドゲーミングでも N:Nなら必要 •MMOのサーバー間通信 • スタンドアロンゲームと共通のコードにする場合 • 併用する場合 • オーバーレイ部分の同期 でも、プロトタイプ段階では全く不要になるかも。 そのままリリースという流れもある？
- 55. ありえそうな今後の展開 • Unityなどのエンジンやミドルウェアが1:Nをサポート • 映像式、描画コマンド式どちらも •プラットフォーム自体が1:Nをサポート • 映像再生用の汎用プレイヤークライアントが普及 • クライアントとしてWebブラウザの利用が進む ネットコード書くのは誰でもできるわけではないし、 できるとしても、すごくめんどくさい！
- 56. こんなふうになったらいいな • ゲーマーとして • ゲームの実況サイトでクリックしたらすぐ参加してプレ イ •アプリストアでクリックした瞬間プレイし始めてプレイ 時間で課金 • エンジニアとして • マルチプレイゲームをネットコードなしで開発して、ち ょっとWebでテスト公開してもデータはぬすまれない。