Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

ゲームの通信をつくる仕事はどうなるのだろう?

1 027 vues

Publié le

サムザップ 第7回テックナイトの講演で使ったスライドです。 5Gやクラウドインフラの変化によって通信ゲームの作り方がどんなふうに変わるのかについて考えます。

Publié dans : Ingénierie
  • Soyez le premier à commenter

ゲームの通信をつくる仕事はどうなるのだろう?

  1. 1. ゲームの通信をつくる 仕事はどうなるのだろう? 2019年10月 モノビットエンジン 取締役CTO 中嶋謙互 Twitter @ringo https://github.com/kengonakajima
  2. 2. なぜこの仕事を • 音楽とか絵みたいな感じで一人でオンラインゲームを好きなよ うに作って、世界中の人と一緒に遊びたい。 • それを可能にするような方法を考えたい。 • そのやり方を多くの開発者とシェアしたい。
  3. 3. • 今日は低いレイヤーから上へ行きます
  4. 4. Internet Protocol Stack https://www.w3.org/People/Frystyk/thesis/TcpIp.html ハードウェア 1個1個のパケットを マシンまで届ける マシンの中のプロセスや ソケットにデータを届ける それぞれのアプリケーション
  5. 5. Internet Protocol Stack https://www.w3.org/People/Frystyk/thesis/TcpIp.html ハードウェア 1個1個のパケットを マシンまで届ける マシンの中のプロセスや ソケットにデータを届ける それぞれのアプリケーション
  6. 6. ハードウェア層 • ゲームにかかわるマシン(サーバー、クライアント)は • どう変わってきたのか? • どう変わっていくのか?
  7. 7. プロセッサ性能 http://www.clivemaxfield.com/area51/do-not-delete/pam-0001-emb-nca-01-lg.jpg
  8. 8. メモリ帯域幅 https://www.karlrupp.net/2013/06/cpu-gpu-and-mic-hardware-characteristics-over-time/
  9. 9. メモリのコスト https://hblok.net/blog/posts/2017/12/17/historical-cost-of-computer-memory-and-storage-4/
  10. 10. 消費電力あたり性能 https://www.karlrupp.net/2013/06/cpu-gpu-and-mic-hardware-characteristics-over-time/
  11. 11. Ethernet https://insidehpc.com/2018/03/new-2018-ethernet-roadmap-looks-future-speeds-1-6-terabits-s/
  12. 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. 13. モバイル通信 名称 時期 帯域幅 遅延 料金 2G 1991 40Kbps 100ms~ ∝パケ数 3G 2000 144Kbps~ 100ms~ ∝パケ数 4G 2009 ~1Gbps 10ms~ ∝パケ数/定額 5G 2018 ~数Gbps(複雑) 1ms~ 定額? 6G ? Tbps? マイクロ秒 ?
  14. 14. クラウドマシン CPUコスト • 1CPUコアの2GB程度なマシン/1ヶ月 • AWS/Google/Azure他:5000円〜1万円でじわじわ下落 • Linode/DigitalOcean等 : 500円〜1000円で下落中
  15. 15. クラウドマシンからの送信コスト • 1GB送信 • AWS/Google/Azure他: 5~10円 • Linode/DigitalOcean等 : 1~2円 • だんだん下がっている • 単価下げ • 無料枠の拡大
  16. 16. クラウドストレージのコスト • AWS S3 TBあたり (標準タイプ) • 2006 : $150 • 2010 : $140 • 2012 : $95 • 2014 : $30 • 2019 : $21
  17. 17. Internet Protocol Stack https://www.w3.org/People/Frystyk/thesis/TcpIp.html ハードウェア 1個1個のパケットを マシンまで届ける マシンの中のプロセスや ソケットにデータを届ける それぞれのアプリケーション
  18. 18. インターネット層 • IPv4, IPv6 • 遅延の大きさ • クラウドはどこにある
  19. 19. IPv4, IPv6 https://tech.nikkeibp.co.jp/it/article/COLUMN/20071009/284087/ v6はアドレス空間がとても広い
  20. 20. IPv6 https://www.google.com/intl/en/ipv6/statistics.html
  21. 21. 長距離転送 • 東京 - サンフランシスコ • 往復 16000km • 光速 200000km/s • 理論上の時間 : 80ms • pingして計測 : 110ms~120ms • 10年前は150ms~200msだった • これ以上改善は難しいかも
  22. 22. 中距離転送 • 東京 - 富山 • 往復 1600km (大阪経由) • 光速 200000km/s • 理論上の時間 8ms • pingして計測 24ms • まだ改善するかもしれない
  23. 23. 都市内転送 • 都内であれば0.5~2ms • AWS-Google/Azure 0.5ms~1ms • AWS-AWS 0.1~1ms • AWS-Linode 2ms
  24. 24. 同一AZ内転送 • AWS • ピークは10Gbps / 20Gbps (インスタンスによる) • インスタンスタイプによって様々な制限がかかる • 負荷が一定以上継続すると制限 • 帯域制限 • パケット数制限 (100万~140万pps) • 高額なインスタンスは制限がゆるい https://cloudonaut.io/ec2-network-performance-cheat-sheet/
  25. 25. データセンター AWS Google Azure DigitalOcean
  26. 26. Internet Protocol Stack https://www.w3.org/People/Frystyk/thesis/TcpIp.html ハードウェア 1個1個のパケットを マシンまで届ける マシンの中のプロセスや ソケットにデータを届ける それぞれのアプリケーション
  27. 27. トランスポート層 • 信頼できないインターネット上で • あるマシンのあるプロセスに対して • データを届ける
  28. 28. IPv4, IPv6の基本動作 引用元: atmarkit
  29. 29. インターネットの性能 • パケットロス率 • 有線LAN : スイッチとケーブルがちゃんとしてたら、ほぼ0だが、 受信側マシンに余裕がなくなると消える • 無線LAN : 負荷がないときでも10000個に1個ぐらい消える。負荷 が高いと、100個に1個消えるときもある • モバイルネットワーク : 電波がいいときでも100個に1個消えるか も、電波が悪いと1割消えたりする
  30. 30. 2つの主要プロトコル UDP TCP 宛先マシン内の特定のポートに届ける ○ ○ チェックサムで誤り訂正 ○ ○ パケットロスのとき再送する ○ データの順序を保証する ○
  31. 31. ソケットAPIにおける「ポート番号 」 Linuxマシン1 プロセス1 Windowsマシン1 10.0.1.11 10.0.1.12 プロセス2 プロセス1 TCP 8080 UDP 3001 TCP 443 UDP 53 インターネット→ TCPパケット IP:10.0.1.11 PORT: 8080 UDPパケット IP:10.0.1.12 PORT: 53
  32. 32. トランスポート層: TCPの時代分け • 1980年代 : TCP登場、telnetでマシンを遠隔操作 • 1990年代 : メールやHTTPなどで大ブレイク • 2000年代 : モバイルで長時間のストールを防ぎたい! • 2010年代 : 動画や音声を高速送信したい! Nagleアルゴリズム、スロースタート 高速リカバリの導入と改良 Long Fat パイプへの対応 状況や用途に合わせてアルゴリズムの使い分け
  33. 33. TCPがどうしても解決できない問題 • head-of-line blocking • IPアドレスの変化に対応できない
  34. 34. head of line blocking TCP こんなふうにしたい packet1の影響で、全体が長時間ストールする packet1はストールするがpacket2,3は早く届く packet1の再送 packet1の再送 https://qiita.com/Jxck_/items/0dbdee585db3e21639a8
  35. 35. IPアドレス変化 サーバ インターネ ット IPアドレス固定 光回線+無線LAN モバイルネットワーク IPアドレス 1.2.3.4 IPアドレス 3.4.5.6 屋外から自宅内に移動して、 4GからWiFiに移行
  36. 36. QUIC • TCPの欠点を克服するUDPベースのプロトコル(RUDP) • 2012年, Google • 現在は仕様のドラフト23、早いペースで改良中 • head of line blocking回避 • アドレス変化に対応 • マルチチャネル • 0RTT接続 (新規接続が速い) • 暗号化 • WebSocketsどころではなく大きな全部入り仕様
  37. 37. MRU : Monobit RUDP • C++(ほぼC), 小さい • IPアドレス変化への対応 • 正しい順序で送る • 確実に送る (早めの再送,QUICにはない) • 順序も確実さも保証しない方法で送ることもできる • 0RTTハンドシェイク • チェックサム • サーバサイドの動的なアドレス, QUICにはない • C10K以上のMMO向けにチューニング(少人数ももちろんOK) • スロット飽和攻撃対策 • IP偽装対策 • 大量接続対策 • Linux/Windows/iOS/Android/MacOSに対応、ゲーム機は対応予定 • 暗号化は上位レイヤで実装
  38. 38. HTTPの発展 接続>1ページGET>切断 KEEPALIVE, パイプライン化 ストリーム多重(並列)化, フロー制御 head of line blocking 回避, アドレス変化への対応 https://bloggeek.me/who-needs-quic-in-webrtc/
  39. 39. ブラウザ双方向通信の発展 • 2011 WebSockets : TCP / HTTP1.1 に追加された • 2011 WebRTC : UDP • 2020~? WebTransport / UDP Socket : WebSockets の UDP版
  40. 40. Internet Protocol Stack https://www.w3.org/People/Frystyk/thesis/TcpIp.html ハードウェア 1個1個のパケットを マシンまで届ける マシンの中のプロセスや ソケットにデータを届ける それぞれのアプリケーション
  41. 41. アプリケーション層 • どうやってゲームを作るか?
  42. 42. クラウドゲーミング • サーバからクライアントに映像を送信する • ゲームのプログラムを配布しない • インストール不要、即クライアント起動 • 違法コピー/リバースエンジニアリング防止 • テストとデバッグの方法が柔軟に • クライアントのプラットフォーム別の対応が不要 • ネットコードなしでマルチプレイを実装できる
  43. 43. クラウドゲーミング3つのモデル • 1:1 1ユーザーに1サーバー • N:N 1:1ゲームをNユーザーでマルチプレイ • 1:N Nユーザーに1サーバー
  44. 44. インターネット 画面/スピーカー タッチパネル、マウ ス、パッド 操作内容 描画結果の映像 ゲームフロントエンドサーバ ビューワプログラム CPU, GPU, Flashストレージetc 操作 出力 サーバOS (Linux, Windows,etc) 描画指示 描画結果 各種ハードウェア/OS 1:1 一人用ゲーム プレイヤー側端末 ゲーム提供側環境(クラウド)
  45. 45. インターネット プレイヤー側端末 ゲーム提供側環境(クラウド) 操作内容 描画結果 画面/スピーカー タッチパネル、マウ ス、パッド ビューワプログラム ゲームフロントエンドサーバ CPU, GPU, Flashストレージetc サーバOS (Linux, Windows,etc) 画面/スピーカー タッチパネル、マウ ス、パッド ビューワプログラム ゲームフロントエンドサーバ CPU, GPU, Flashストレージetc サーバOS (Linux, Windows,etc) 操作内容 描画結果 任意の形式で直接通信 各種ハードウェア/OS各種ハードウェア/OS N:N 2人用
  46. 46. インターネット プレイヤー側端末 ゲーム提供側環境(クラウド) 操作内容 描画結果 画面/スピーカー タッチパネル、マウ ス、パッド ビューワプログラム 画面/スピーカー タッチパネル、マウ ス、パッド ビューワプログラム ゲームフロントエンドサーバ CPU, GPU, Flashストレージetc サーバOS (Linux, Windows,etc) 操作内容 描画結果 各種ハードウェア/OS各種ハードウェア/OS ネットワークコードなしでマルチプレイを実装できる 1:N
  47. 47. インタ ーネッ ト Unity on GPUつきサーバー 1:N 映像ストリーム 映像+データ 操作 ゲームデータはひとつ。 全モデルデータ、全メッシュ テクスチャ、シェーダなど GPU内のオブジェクトをすべて共有した状態で 4回レンダリングするだけ。 クライアントでデータを受信し、 HUDを重ねて描画する
  48. 48. インタ ーネッ ト GPUなしサーバー 1:N 描画コマンドストリーム 描画コマンドデータ 操作 ゲームデータはひとつ。 オブジェクトの位置や角度などを毎フレーム送る 映像に比べて帯域消費が小さい+GPUが不要 汎用の再生クライアントで オブジェクトデータを受信し、 全体を描画する。 テクスチャなどのデータも必要なものだけを受信する ゲーム サーバー
  49. 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. 50. クラウドゲームで必要な帯域 • 伝統的な同期 • 10~100Kbps • 描画コマンドストリーム • 10~500Kbps • 映像 • 500K~1Mbps (640x480) • 1~3Mbps (1280x720)
  51. 51. 映像送信の最適化 • ゲームロジックがエンコーダに指示できる • シーンごとに圧縮率・フレームレート切り替え • 画面の部分ごとに圧縮率切り替え • スクロールゲームにおける圧縮ヒント • 音声再生だけクライアントで行う • etc.. 1280x720で2Mbpsから、1Mbps~ 500Kbps台へ
  52. 52. インゲーム映像+オーバーレイUIの分 離 地形、キャラ、 モブ、エフェクト類は インゲーム映像として サーバでレンダリング HUDはクライアントでレンダリング これならブラウザでOK
  53. 53. 鍵となる環境の変化 • 送信コストが1GBあたり1円 • 100Kbpsの音声を78000秒 • 500Kbpsのアバターモーションを 15625秒 • 1280x720 2Mbpsの映像を3900秒 • GPUインスタンスの費用 • 今の半分でもまだ高いかも • EC2 g2 > g3 > g4 > … • 5G定額 • ブラウザでUDP
  54. 54. ゲームデータの同期は必要なくなるの か? • クラウドゲーミングでも N:Nなら必要 • MMOのサーバー間通信 • スタンドアロンゲームと共通のコードにする場合 • 併用する場合 • オーバーレイ部分の同期 でも、プロトタイプ段階では全く不要になるかも。 そのままリリースという流れもある?
  55. 55. ありえそうな今後の展開 • Unityなどのエンジンやミドルウェアが1:Nをサポート • 映像式、描画コマンド式どちらも • プラットフォーム自体が1:Nをサポート • 映像再生用の汎用プレイヤークライアントが普及 • クライアントとしてWebブラウザの利用が進む ネットコード書くのは誰でもできるわけではないし、 できるとしても、すごくめんどくさい!
  56. 56. こんなふうになったらいいな • ゲーマーとして • ゲームの実況サイトでクリックしたらすぐ参加してプレ イ • アプリストアでクリックした瞬間プレイし始めてプレイ 時間で課金 • エンジニアとして • マルチプレイゲームをネットコードなしで開発して、ち ょっとWebでテスト公開してもデータはぬすまれない。

×