WebRTC 上のオープンソース クラウド ゲーム: p2p、マルチプレイヤー、ゼロ遅延

サービスとしてのソフトウェア、サービスとしてのインフラストラクチャ、サービスとしてのプラットフォーム、サービスとしての通信プラットフォーム、サービスとしてのビデオ会議、サービスとしてのクラウド ゲームはどうですか? Google が最近立ち上げた Stadia など、クラウド ゲーム (Cloud Gaming) を作成する試みはすでにいくつかあります。 スタジアム WebRTC は初めてではありません, しかし、他の人も同じように WebRTC を使用できるのでしょうか?

Thanh Nguyen 氏は、この機会をオープンソース プロジェクト CloudRetro でテストすることにしました。 CloudRetro は Pion をベースにしており、 人気の Go ベースの WebRTC ライブラリ (ありがとう) それで この記事の作成に協力していただいた Pion 開発チームから）。 この記事では、Thanh 氏がプロジェクトのアーキテクチャの概要を説明し、作業中に学んだ有益なことや遭遇した課題についても語ります。

エントリー

昨年、Google が Stadia を発表したとき、私は衝撃を受けました。 このアイデアは非常にユニークかつ革新的で、既存のテクノロジーでどのようにしてこれが可能なのかを常に疑問に思っていました。 このトピックをより深く理解したいという欲求から、私はオープンソース クラウド ゲームの独自バージョンを作成するようになりました。 結果はただただ素晴らしかったです。 以下に私のXNUMX年間の取り組みのプロセスを共有したいと思います プロジェクト.

TLDR: ハイライトを含む短いスライド バージョン

クラウド ゲームが未来である理由

私は、クラウド ゲーミングが近いうちにゲームだけでなく、コンピューター サイエンスの他の分野でも次世代になると信じています。 クラウド ゲームはクライアント/サーバー モデルの頂点です。 このモデルは、リモート サーバー上でゲーム ロジックをホストし、画像/音声をクライアントにストリーミングすることにより、バックエンド管理を最大限に高め、フロントエンドの作業を最小限に抑えます。 サーバーが重い処理を実行するため、クライアントはハードウェアの制限に翻弄されることがなくなります。

Google Stadia では基本的にプレイできるようになります AAA ゲーム （ハイエンドの大ヒットゲームなど）を YouTube のようなインターフェースで視聴できます。 同じ方法論は、オペレーティング システムや 2D/3D グラフィック デザインなど、他の高負荷のオフライン アプリケーションにも適用できます。 そのため、複数のプラットフォームにわたる低スペックのデバイスでも一貫して実行できます。

このテクノロジーの将来: Microsoft Windows 10 が Chrome ブラウザーで実行されたらどうなるかを想像してみてください。

クラウド ゲームは技術的に難しい

ゲームは、継続的かつ迅速なユーザー応答が必要とされる稀な分野の 2 つです。 ページをクリックしたときに 500 秒の遅延が発生する場合がありますが、これは許容範囲です。 ライブビデオストリームは数秒遅れる傾向がありますが、それでも適度な使いやすさを提供します。 ただし、ゲームに XNUMX ミリ秒の遅延が頻繁に発生する場合は、単純にプレイできません。 私たちの目標は、入力とメディアの間のギャップをできる限り小さくするために、極めて低いレイテンシーを達成することです。 したがって、ビデオ ストリーミングに対する従来のアプローチはここでは適用できません。

一般的なクラウド ゲーム テンプレート

オープンソース プロジェクト CloudRetro

私はクラウド ゲームのテスト サンプルを作成して、これほど厳しいネットワーク制限下ですべてが可能かどうかを確認することにしました。 概念実証に Golang を選択したのは、Golang が私にとって最もなじみのある言語であり、後でわかったことですが、他の多くの理由からこの実装に適していたからです。 Go はシンプルで、開発が非常に早いです。 Go のチャネルはマルチスレッドの管理に最適です。

プロジェクト クラウドレトロ.io は、レトロゲーム向けのオープンソースのクラウド ゲーム サービスです。 このプロジェクトの目標は、従来のレトロ ゲームに最も快適なゲーム体験をもたらし、マルチプレイヤーを追加することです。
プロジェクトの詳細については、こちらをご覧ください。 https://github.com/giongto35/cloud-game.

CloudRetro の機能

CloudRetro は、レトロ ゲームを使用してクラウド ゲーミングの威力を実証します。 これにより、多くのユニークなゲーム体験を得ることができます。

• ゲームの移植性
  • ページを開いたときに即時再生; ダウンロードやインストールは必要ありません
  • モバイルブラウザで動作するため、ソフトウェアを実行する必要はありません

• ゲームセッションは複数のデバイス間で共有でき、次回ログインするときのためにクラウドに保存できます。
• ゲームはストリーミングすることも、複数のユーザーが同時にプレイすることもできます。
  • TwitchPlayPokemon のようなクラウドプレイ、よりクロスプラットフォームでよりリアルタイムなだけ
  • オンラインのオフライン ゲーム。 多くのユーザーはネットワークを設定せずにプレイできます。 サムライスピリッツはCloudRetroネットワーク経由で2人のプレイヤーでプレイできるようになりました

  
  さまざまなデバイスでのオンライン マルチプレイヤー ゲームのデモ バージョン

  インフラ

  要件とテクノロジースタック

  以下は、プロジェクトを開始する前に設定した要件のリストです。

  1. プレイヤー XNUMX 人
  この要件は、ここではそれほど重要でも明白でもないように思えるかもしれませんが、これは私の重要なポイントの XNUMX つであり、これによりクラウド ゲームを従来のストリーミング サービスから可能な限り遠ざけることができます。 シングルプレイヤー ゲームに焦点を当てる場合は、不特定多数にストリーミングする必要がないため、集中サーバーや CDN を取り除くことができます。 ストリームをシンク サーバーにアップロードしたり、パケットを集中 WebSocket サーバーに渡したりする代わりに、サービス ストリームはピアツーピア WebRTC 接続を介してユーザーに直接配信されます。

  2. 低遅延のメディア ストリーム
  Stadia について読んでいると、いくつかの記事で WebRTC について言及しているのをよく見かけます。 WebRTC は優れたテクノロジーであり、クラウド ゲームでの使用に最適であることがわかりました。 WebRTC は、シンプルな API を介して Web ブラウザーとモバイル アプリケーションにリアルタイム通信を提供するプロジェクトです。 ピアツーピア接続を提供し、メディア用に最適化されており、VP8 や H264 などの標準コーデックが組み込まれています。

  私は、高品質のグラフィックスを維持することよりも、可能な限り最高のユーザー エクスペリエンスを確保することを優先しました。 アルゴリズムでは多少の損失は許容されます。 Google Stadia には、サーバー上の画像サイズを縮小する追加の手順があり、フレームはピアに送信される前に高品質にアップスケールされます。

  3. 地理的ルーティングを備えた分散インフラストラクチャ
  圧縮アルゴリズムとコードがどれほど最適化されていても、レイテンシに最も影響を与える決定要因は依然としてネットワークです。 アーキテクチャには、ラウンドトリップ時間 (RTT) を削減するために、ユーザーに最も近いサーバーをペアリングするメカニズムが必要です。 アーキテクチャには、1 つのコーディネーターと、米国西部、米国東部、ヨーロッパ、シンガポール、中国など世界中に分散された複数のストリーミング サーバーが必要です。 すべてのストリーミング サーバーは完全に分離する必要があります。 システムは、サーバーがネットワークに参加またはネットワークから離脱するときに、その分散を調整できます。 したがって、トラフィックが大きい場合は、サーバーを追加することで水平方向のスケーリングが可能になります。

  4. ブラウザの互換性
  クラウド ゲームは、ユーザーの要求を最小限に抑えたときに最高のパフォーマンスを発揮します。 つまり、ブラウザ上で実行できるということです。 ブラウザは、ユーザーがソフトウェアやハードウェアをインストールする手間を省き、ゲーム体験をできる限り快適にするのに役立ちます。 ブラウザは、モバイル バージョンとデスクトップ バージョンの間でクロスプラットフォーム機能を提供するのにも役立ちます。 幸いなことに、WebRTC はさまざまなブラウザーで十分にサポートされています。

  5. ゲームインターフェイスとサービスの明確な分離
  私はクラウドゲームサービスをプラットフォームとして捉えています。 誰もがあらゆるものをプラットフォームに接続できる必要があります。 今、私は統合しました LibRetro LibRetro は SNES、GBA、PS などのレトロ ゲーム用の美しいゲーム エミュレータ インターフェイスを提供しているため、クラウド ゲーム サービスを利用できます。

  6. マルチプレイヤー、クラウドプレイ、ゲームとの外部リンク（ディープリンク）用の部屋
  CloudRetro は、レトロ ゲームの CrowdPlay や​​オンライン マルチプレイヤーなど、多くの新しいゲームプレイをサポートしています。 複数のユーザーが異なるコンピューターで同じディープリンクを開いた場合、同じゲームが実行されているのが表示され、ゲームに参加することもできます。

  さらに、ゲームの状態はクラウド ストレージに保存されます。 これにより、ユーザーはいつでも他のデバイスでプレイを続けることができます。

  7. 水平方向のスケーリング
  最近の他の SAAS と同様に、クラウド ゲームも水平方向にスケーラブルになるように設計する必要があります。 コーディネーターとワーカーの設計により、より多くのトラフィックを処理するためにワーカーを追加できます。

  8. XNUMX つのクラウドに接続できない
  CloudRetro のインフラストラクチャは、さまざまな地域のさまざまなクラウド プロバイダー (Digital Ocean、Alibaba、カスタム プロバイダー) でホストされています。 インフラストラクチャの Docker コンテナでの実行を有効にし、単一のクラウド プロバイダーにロックされないように bash スクリプトを使用してネットワーク設定を構成します。 これを WebRTC の NAT トラバーサルと組み合わせることで、CloudRetro をあらゆるクラウド プラットフォーム、さらにはあらゆるユーザーのマシンに柔軟にデプロイできるようになります。

  建築デザイン

  ワーカー： (または前述のストリーミング サーバー) は、ゲームを増やし、エンコード パイプラインを実行し、エンコードされたメディアをユーザーにストリーミングします。 ワーカー インスタンスは世界中に分散されており、各ワーカーは複数のユーザー セッションを同時に処理できます。

  コーディネーター： 新しいユーザーをストリーミングに最適なワーカーとペアリングする責任があります。 コーディネーターは、WebSocket を介してワーカーと対話します。

  ゲーム状態のストレージ: すべてのゲーム状態を集中リモートストレージで管理します。 このストレージは、リモート セーブ/ロードなどの重要な機能を提供します。

  
  CloudRetro のトップレベルのアーキテクチャ

  カスタムスクリプト

  以下の図に示す手順 1 と 2 で新しいユーザーが CloudRetro を開くと、コーディネーターと利用可能なワーカーのリストが最初のページに要求されます。 この後、ステップ 3 で、クライアントは HTTP ping リクエストを使用してすべての候補の遅延を計算します。 この遅延のリストはコーディネーターに送り返され、コーディネーターはユーザーにサービスを提供するのに最適なワーカーを決定できます。 以下のステップ 4 でゲームを作成します。 WebRTC ストリーミング接続は、ユーザーと割り当てられたワーカーの間に確立されます。
  
  アクセス権取得後のユーザースクリプト

  労働者の中には何があるのか

  ゲームとストリーミング パイプラインはワーカー内に分離して保存され、インターフェイスを通じてそこで情報を交換します。 現在、この通信はメモリ上のデータを転送することによって実行されます。 Golang チャンネル 同じプロセスで。 次の目標は分離です。 別のプロセスでゲームを独立して起動します。

  
  ワーカーコンポーネントの相互作用

  メインコンポーネント：

  • WebRTC： ユーザー入力を受け入れ、エンコードされたメディアをサーバーから出力するクライアント コンポーネント。
  • ゲームエミュレータ: ゲームコンポーネント。 Libretro ライブラリのおかげで、システムは同じプロセス内でゲームを実行し、メディアと入力ストリームを内部的にインターセプトできます。
  • ゲーム内フレームがキャプチャされてエンコーダーに送信されます。
  • 画像/音声エンコーダ: メディア フレームを取得し、バックグラウンドでエンコードし、エンコードされた画像/音声を出力するエンコード パイプライン。

  具現化

  CloudRetro はバックボーン テクノロジーとして WebRTC に依存しているため、Golang 実装の詳細に入る前に、WebRTC 自体について話すことにしました。 これは驚くべきテクノロジーで、ストリーミング データのレイテンシーを XNUMX 秒未満にするのに大いに役立ちました。

  WebRTC

  WebRTC は、シンプルな API を使用してネイティブ モバイル アプリとブラウザーで高品質のピアツーピア接続を提供するように設計されています。

  NATトラバーサル

  WebRTC は、NAT トラバーサル機能で知られています。 WebRTC はピアツーピア通信用に設計されています。 その目標は、NAT ゲートウェイとファイアウォールを回避して、と呼ばれるプロセスを介してピアツーピア通信を行う、最も適切な直接ルートを見つけることです。 ICE。 このプロセスの一環として、WebRTC API は STUN サーバーを使用してパブリック IP アドレスを検索し、それをリレー サーバーに転送します (順番) ダイレクト接続が確立できない場合。

  ただし、CloudRetro はこの機能を十分に活用していません。 そのピアツーピア接続はユーザー間ではなく、ユーザーとクラウド サーバーの間に存在します。 このモデルのサーバー側では、一般的なユーザー デバイスに比べて直接的な通信制限が少なくなります。 これにより、サーバーが NAT の背後にないため、受信ポートを事前に開いたり、パブリック IP アドレスを直接使用したりできます。

  以前、私はこのプロジェクトをクラウド ゲーミングのゲーム配信プラットフォームにしたいと考えていました。 このアイデアは、ゲーム クリエーターがゲームとストリーミング リソースを提供できるようにすることでした。 そしてユーザーはプロバイダーと直接対話することになります。 この分散型の方法では、CloudRetro はサードパーティのストリーミング リソースをユーザーに接続するためのフレームワークにすぎず、ホストされなくなったときの拡張性が向上します。 ここでの WebRTC NAT トラバーサルの役割は、サードパーティのストリーミング リソースでのピアツーピア接続の初期化を促進し、作成者がネットワークに簡単に接続できるようにするために非常に重要です。

  ビデオ圧縮

  ビデオ圧縮はパイプラインに不可欠な部分であり、スムーズなフローに大きく貢献します。 VP8/H264 ビデオ エンコーディングの詳細をすべて知る必要はありませんが、概念を理解すると、ストリーミング ビデオ速度オプションを理解し、予期しない動作をデバッグし、遅延を調整するのに役立ちます。

  ストリーミング サービス用にビデオを圧縮することは、アルゴリズムによって、合計のエンコード時間 + ネットワーク送信時間 + デコード時間が可能な限り短くなることを保証する必要があるため、困難です。 さらに、コーディングプロセスは一貫性があり、継続的である必要があります。 一部のエンコードのトレードオフは適用されません。たとえば、ファイル サイズやデコード時間よりも長いエンコード時間を優先したり、一貫性のない圧縮を使用したりすることはできません。

  ビデオ圧縮の背後にある考え方は、ユーザーが許容できるレベルの精度を維持しながら、不要な情報を削除することです。 個々の静止画像フレームをエンコードすることに加えて、アルゴリズムは前後のフレームから現在のフレームを推測するため、それらの差分のみが送信されます。 パックマンの例からわかるように、差分ポイントのみが送信されます。

  
  パックマンを例にしたビデオフレームの比較

  音声圧縮

  同様に、音声圧縮アルゴリズムでは、人間が認識できないデータは省略されます。 Opus は現在最もパフォーマンスの高いオーディオ コーデックです。 これは、RTP (Real Time Transport Protocol) などの順序付けされたデータグラム プロトコルを介して音声波を送信するように設計されています。 mp3やaacよりも遅延が少なく、高品質です。 レイテンシは通常 5 ～ 66,5 ミリ秒程度です。

  Pion、Golang の WebRTC

  パイ中間子 は、WebRTC を Golang に提供するオープンソース プロジェクトです。 Pion は、ネイティブ C++ WebRTC ライブラリの通常のラッピングの代わりに、より優れたパフォーマンス、Go 統合、および WebRTC プロトコルでのバージョン管理を備えた WebRTC のネイティブ Golang 実装です。

  このライブラリでは、多くの優れた組み込み機能を使用して XNUMX 秒未満の遅延でストリーミングすることもできます。 STUN、DTLS、SCTPなどの独自の実装があります。 QUIC と WebAssembly を使った実験もいくつかあります。 このオープン ソース ライブラリ自体は、優れたドキュメント、ネットワーク プロトコルの実装、クールな例を備えた非常に優れた学習リソースです。

  非常に情熱的なクリエイターが率いる Pion コミュニティは非常に活発で、WebRTC について多くの質の高い議論が行われています。 この技術に興味がある方はぜひご参加ください http://pion.ly/slack – たくさんの新しいことを学ぶでしょう。

  Golang で CloudRetro を書く

  
  Go でのワーカーの実装

  実際の G​​o チャネル

  Go の美しいチャネル設計のおかげで、イベント ストリーミングと同時実行の問題が大幅に簡素化されています。 図にあるように、異なる GoRoutine には複数のコンポーネントが並行して実行されます。 各コンポーネントはその状態を管理し、チャネルを通じて通信します。 Golang の選択的アサーションにより、ゲーム内で毎回 XNUMX つのアトミック イベントが強制的に処理されます (ゲーム ティック)。 これは、この設計ではロックが必要ないことを意味します。 たとえば、ユーザーが保存するときは、ゲーム状態の完全なスナップショットが必要です。 この状態は、保存が完了するまでログイン状態のまま継続する必要があります。 各ゲーム ティック中、バックエンドは保存操作または入力操作のみを処理できるため、プロセスがスレッド セーフになります。

  func (e *gameEmulator) gameUpdate() {
  for {
  	select {
  		case <-e.saveOperation:
  			e.saveGameState()
  		case key := <-e.input:
  			e.updateGameState(key)
  		case <-e.done:
  			e.close()
  			return
  	}
      }
  }

  ファンイン/ファンアウト

  この Golang テンプレートは、私の CrowdPlay とマルチプレイヤーのユースケースに完全に適合します。 このパターンに従って、XNUMX つの部屋内のすべてのユーザー入力は中央の入口チャネルに組み込まれます。 その後、ゲーム メディアが同じ部屋内のすべてのユーザーに展開されます。 このようにして、異なるユーザーの複数のゲーム セッション間でゲーム状態を分割することができます。

  
  異なるセッション間の同期

  Golangの欠点

  Golang は完璧ではありません。 チャンネルが遅いです。 ブロッキングと比較すると、Go チャネルは同時イベ​​ントやスレッド化されたイベントを処理する簡単な方法であるだけですが、チャネルは最高のパフォーマンスを提供しません。 チャネルの下には複雑なブロッキング ロジックがあります。 そこで、パフォーマンスを最適化するためにチャネルを置き換えるときにロックとアトミック値を再適用して、実装にいくつかの調整を加えました。

  さらに、Golang のガベージ コレクターは管理されていないため、疑わしいほど長い一時停止が発生することがあります。 これは、リアルタイム ストリーミング アプリケーションに大きな干渉を与えます。

  Cgo

  このプロジェクトでは、メディア圧縮には既存のオープン ソース Golang VP8/H264 ライブラリを、ゲーム エミュレータには Libretro を使用します。 これらのライブラリはすべて、Go の C ライブラリの単なるラッパーです。 Cgo。 デメリットの一部を以下に挙げます デイブ・チェイニーによるこの投稿。 遭遇した問題:

  • Golang RecoveryCrash を使用しても CGO でクラッシュを捕捉できない。
  • CGO で詳細な問題を検出できない場合、パフォーマンスのボトルネックを特定できません。

  まとめ

  クラウド ゲーム サービスを理解し、オンラインで友達と懐かしいレトロ ゲームをプレイできるプラットフォームを作成するという目標を達成しました。 このプロジェクトは、Pion 図書館と Pion コミュニティの支援がなければ不可能でした。 集中的な開発に非常に感謝しています。 WebRTC と Pion が提供するシンプルな API により、シームレスな統合が保証されました。 ピアツーピア (P2P) 通信に関する予備知識がまったくなかったにもかかわらず、私の最初の概念実証は同じ週にリリースされました。

  統合の容易さにもかかわらず、P2P ストリーミングは実際、コンピューター サイエンスにおいて非常に複雑な領域です。 彼女は、ピアツーピア セッションを作成するために、IP や NAT などの長年にわたるネットワーク アーキテクチャの複雑さに対処する必要があります。 このプロジェクトに取り組んでいる間、私はネットワーキングとパフォーマンスの最適化に関する多くの貴重な知識を得ることができたので、皆さんも WebRTC を使用して P2P 製品を構築してみることをお勧めします。

  CloudRetro は、レトロゲーマーとしての私の観点から予想したすべてのユースケースに対応します。 ただし、ネットワークの信頼性とパフォーマンスを向上させたり、より高品質のゲーム グラフィックスを提供したり、ユーザー間でゲームを共有したりする機能など、プロジェクトには改善できる点がたくさんあると思います。 私はこれに一生懸命取り組んでいます。 従ってください プロジェクト そして気に入ったらサポートしてください。

出所： habr.com