JP2023502667A - クラウドゲーム用のアダプティブグラフィックス - Google Patents

Abstract

【解決手段】方法が提供され、方法は、以下の動作、クラウドゲーム機によってビデオゲームを実行することであって、ビデオゲームの実行はゲームプレイビデオをレンダリングすることを含む、実行することと、ネットワークを介してクライアントデバイスにストリーミングするために、ストリーミングサーバによってゲームプレイビデオを処理することと、ストリーミングサーバとクライアントデバイスとの間のネットワークを介した接続品質を監視することと、ストリーミングサーバとクライアントデバイスとの間の接続品質の変化を検出したことに応じて、クラウドゲーム機によってゲームプレイビデオのレンダリングを調整することと、を含む。【選択図】図１

Description

本開示は、クラウドゲーム用のアダプティブグラフィックスのためのシステム及び方法に関する。

ゲーム業界の現在の傾向は、クラウドゲームへの移行である。クラウドゲームは、ビデオゲームのリソースを保証できるデータセンタでビデオゲームのリモート実行を可能にすることにより、エンドユーザに利点を提供する。リモートで実行されるビデオゲームによって生成されたビデオは、ユーザの機器にストリーミングされ、ユーザからの入力はデータセンタに送り返される。これにより、ゲーム自体を実行するためにエンドユーザが特定のハードウェアを所有する必要がなくなる。むしろ、エンドユーザはゲームプレイをストリーミングするのに十分なハードウェアを所有するだけでよく、それでも高品質のゲームエクスペリエンスを楽しむことができる。さらに、理論的には、クラウドゲームは、ネットワーク接続が利用可能な任意の場所からのゲームを可能にする。

ビデオゲーム業界の継続的な傾向は、グラフィックスの高度化と、最新のゲームエンジンの需要を満たすためのコンピューティングリソースの可用性である。ビデオゲームが進化するにつれて、その解像度とフレームレートは増加し続け、非常にリアルで詳細な仮想環境のレンダリングを可能にしている。加えて、クラウドゲームの人気は高まり続けており、クラウドで実行されるビデオゲームへの移行により、高品質のゲームエクスペリエンスへのさらなるアクセス向上を可能にしている。

大まかに言えば、現在のクラウドゲームアーキテクチャは、既存のコンソールまたはＰＣゲームタイトルのストリーミングに依存している。既存の変更されていないゲームが使用され、それらの「知識」がなければ、それらのビデオとオーディオがキャプチャされ、ユーザにストリーミングされる。このようなストリーミング中は、インターネット接続に基づいてユーザに最高のエクスペリエンスを提供するように注意が払われる。接続が悪い場合は、ビデオ解像度、フレームレート、圧縮設定などのビデオエンコーダ設定を変更することで画質を低下させることができる。しかしながら、このような調整は、ビデオゲームによってすでに出力されているビデオ／オーディオに対して実行される。

このようなコンテキストにおいて、本開示の実施形態は生じる。

本開示の実施態様は、クラウドゲーム用のアダプティブグラフィックスのためのシステム及び方法を提供する。現在のクラウドゲームシステムは、ビデオエンコーダの設定を変更することで様々なインターネット状態に対処しているが、このような変更は、ビデオゲームによってすでに生成されている既存のビデオ／オーディオにのみ影響し、ビデオゲーム自体には影響しない。ビデオゲームが品質調整に関与している場合、より良い画質と改善されたユーザエクスペリエンスを実現できる。例えば、ビデオゲームでは、圧縮しやすい低解像度のテクスチャをレンダリングしたり、不要なオブジェクトをまったくレンダリングしなかったりすることができる。本開示の実施態様は、ユーザにとってより高品質のストリームを得るために、ビデオゲームとビデオストリーミングソリューションとの間のより良い協力を提供する。

いくつかの実施態様では、以下の動作を含む方法が提供され、方法は、クラウドゲーム機によってビデオゲームを実行することであって、ビデオゲームの実行はゲームプレイビデオをレンダリングすることを含む、実行することと、ネットワークを介してクライアントデバイスにストリーミングするために、ストリーミングサーバによってゲームプレイビデオを処理することと、ストリーミングサーバとクライアントデバイスとの間のネットワークを介した接続品質を監視することと、ストリーミングサーバとクライアントデバイスとの間の接続品質の変化を検出したことに応じて、クラウドゲーム機によってゲームプレイビデオのレンダリングを調整することと、を含む。

いくつかの実施態様では、ストリーミングサーバによってゲームプレイビデオを処理することは、圧縮されたビデオフォーマットでのゲームプレイビデオの符号化を含む。

いくつかの実施態様では、接続品質を監視することには、帯域幅またはレイテンシのうち１つ以上の監視が含まれる。

いくつかの実施態様では、接続品質を監視することには、ゲームプレイビデオのストリーミング中に発生するパケット損失を監視することが含まれる。

いくつかの実施態様では、クラウドゲーム機によってゲームプレイビデオのレンダリングを調整することは、ゲームプレイビデオのフレームレートまたは解像度を調整することを含む。

いくつかの実施態様では、クラウドゲーム機によってゲームプレイビデオのレンダリングを調整することは、ゲームプレイビデオのレンダリングの詳細レベルを調整することを含む。

いくつかの実施態様では、クラウドゲーム機によってゲームプレイビデオのレンダリングを調整することは、ゲームプレイビデオに含めるコンテンツの量を調整することを含む。

いくつかの実施態様では、接続品質の変化は接続品質の低下によって定義され、クラウドゲーム機によってゲームプレイビデオのレンダリングを調整することは、ネットワークを介したゲームプレイビデオのストリーミングのビットレートを低減するように構成される。

いくつかの実施態様では、接続品質の変化は接続品質の向上によって定義され、クラウドゲーム機によってゲームプレイビデオのレンダリングを調整することは、ネットワークを介したゲームプレイビデオのストリーミングのビットレートを増加するように構成される。

いくつかの実施態様では、接続品質の変化を検出すると、ストリーミングサーバからクラウドゲーム機へのメッセージの送信がトリガーされ、クラウドゲーム機によってゲームプレイビデオのレンダリングを調整することは、当該メッセージに応じるものである。

いくつかの実施態様では、以下の方法動作を含む方法が提供され、方法は、クラウドゲーム機によってビデオゲームを実行することであって、ビデオゲームの実行はゲームプレイビデオをレンダリングすることを含む、実行することと、ネットワークを介してクライアントデバイスにストリーミングするために、ストリーミングサーバによってゲームプレイビデオを処理することであって、ストリーミングサーバによってゲームプレイビデオを処理することは、圧縮されたビデオフォーマットでゲームプレイビデオを符号化することを含む、処理することと、ストリーミングサーバとクライアントデバイスとの間のネットワークを介した接続品質を監視することであって、接続品質を監視することは、ゲームプレイビデオのストリーミング中に発生するパケット損失を監視することを含む、監視することと、ストリーミングサーバとクライアントデバイスとの間の接続品質の変化を検出したことに応じて、クラウドゲーム機によってゲームプレイビデオのレンダリングを調整することであって、クラウドゲーム機によってゲームプレイビデオのレンダリングを調整することは、ゲームプレイビデオのフレームレートまたは解像度を調整することを含む、調整することと、を含む。

いくつかの実施態様では、システムが提供され、システムは、ビデオゲームを実行するクラウドゲーム機であって、ビデオゲームの実行はゲームプレイビデオをレンダリングすることを含む、クラウドゲーム機と、ネットワークを介してクライアントデバイスにストリーミングするためにゲームプレイビデオを処理するストリーミングサーバであって、ストリーミングサーバとクライアントデバイスとの間のネットワークを介した接続品質を監視するストリーミングサーバと、を含み、ストリーミングサーバとクライアントデバイスとの間の接続品質の変化を検出したことに応じて、ゲームプレイビデオのレンダリングは、クラウドゲーム機によって調整される。

本開示の他の態様及び利点は、添付の図面と併せて、本開示の原理を例として示す以下の詳細な説明から明らかになる。

本開示は、そのさらなる利点と共に、添付の図面と併せて下記の説明を参照することにより、最も良く理解されるであろう。

本開示の実施態様による、ネットワーク状態に基づいてビデオ／オーディオ品質調整にビデオゲーム自体を関与させるように構成されたクラウドゲームシステムを概念的に示す。 本開示の実施態様による、ビデオ／オーディオ品質がストリーム品質に基づいて調整される、ゲームストリーム品質フィードバックループを概念的に示す。 本開示の実施態様による、ビデオゲームによってレンダリングされた後にストリーミングサーバによって実行されるのに対して、実行中のビデオゲームによってネイティブに実行されるフレームレートの低下を概念的に示す。 本開示の実施態様による、ビデオゲームのフレームレートを制御または設定するための方法を概念的に示す。 本開示の実施態様による、仮想環境におけるコンテンツの可変的なレンダリングを概念的に示す。 本開示の実施態様による、ネットワーク帯域幅フィードバックに基づくいくつかのコンテンツ設定を概念的に示す。 本開示の実施態様による、ビデオゲームからストリーミングロジックへのフィードフォワード最適化を概念的に示す。 本開示の実施態様による、クラウドゲームサイトを介して利用可能なゲームのゲームファイルをロードするために使用される例示的なシステムを示す。 本開示の実施態様による、クラウドビデオゲームをクライアントデバイスにストリーミングするために実行される様々な動作を概念的に示すフロー図である。 本開示の実施態様による、情報サービスプロバイダアーキテクチャの実施形態を示す。

下記の説明では、本開示の完全な理解を提供するために、多くの具体的な詳細が述べられる。しかしながら、本開示は、これらの具体的な詳細の一部または全てがなくとも実践できることは、当業者には明らかであろう。他の例では、本開示を不明瞭にしないために、周知のプロセスステップについては詳細に説明していない。

本開示の実施態様は、ビデオゲームを品質調整フィードバックループに含めることによって、クラウドゲームセッションのオーディオ／ビデオ品質を改善する。通常、品質は、帯域幅、レイテンシ、及びパケット損失に関するインターネット接続の変動に基づいて調整される。既存のクラウドゲームシステムでは、通常、ゲームはこれらの調整に関与しない。しかしながら、ビデオ／オーディオの品質の調整にビデオゲームを関与させることにより、クラウドゲームセッションの品質と応答性を向上させるためのよりインテリジェントな決定を行うことができる。

大まかに言えば、クライアントとサーバ間のインターネット接続は、利用可能な帯域幅、レイテンシ、及びパケット損失において変動する。現在のクラウドゲームシステムでは、セッション中に接続が監視され、これに基づいてオーディオ／ビデオの品質が調整される。例えば、ユーザの帯域幅がサーバ側のオーディオ及びビデオエンコーダ用に構成された帯域幅よりも低くなったときなどに調整が必要である。調整を行わないと、接続でデータを処理できなかったため、ユーザは全てのデータを受信できなくなり、その結果パケット損失が発生し、エクスペリエンスが低下する。また、使用可能な帯域幅が増加した場合は、エンコーダのビットレートを増加させることで品質を向上させることができる。

現在、品質調整はクライアントとサーバ間のフィードバックループによって機能する。オーディオまたはビデオエンコーダのビットレート、フレームレート、ビデオ解像度など、調整可能な設定がいくつかある。しかしながら、ストリーミングソフトウェアは、符号化するために完成したオーディオまたはビデオフレームを受信するため、これらのノブは最適ではない。サーバは解像度を調整できるが、その調整はレンダリング済みの画像をスケーリングすることによるものであり、フレームレートを調整することはできるが、その調整はビデオフレームを破棄することによるものである。これらの調整は、ビデオとオーディオの元のネイティブレンダリングには影響せず、すでにレンダリングされているビデオとオーディオをさらに処理するだけなので、理想的とは言えない。

しかしながら、ビデオゲーム自体を品質調整に関与させることで、より良い結果を得ることができる。したがって、本開示の実施態様は、ストリーミング品質フィードバックループを拡張して、ビデオゲーム自体を関与させる。既存のフィードバックループは、ストリーミングソフトウェアからビデオゲームへのチャネルで拡張できる。このチャネルは、品質調整をトリガーするために使用できるが、ゲームの一時停止やストリーミングソフトウェアのヒントを提供するゲームなどの他の目的にも使用できる（例えば、ビデオエンコーダが処理するのが一般的に難しいシーンの変更時に）。

図１は、本開示の実施態様による、ネットワーク状態に基づいてビデオ／オーディオ品質調整にビデオゲーム自体を関与させるように構成されたクラウドゲームシステムを概念的に示す。示されるように、クラウドゲームインフラストラクチャは、通常、データセンタ１００内に配置され、ビデオゲーム１０４を実行するゲーム機１０２、及びストリーミングロジック／サーバ１１０を実装するストリーミングサーバコンピュータ１０８からなる。ゲーム機１０２は、ビデオゲーム１０４を実行するのに十分なハードウェアを有するデバイスである。限定されない例として、ゲーム機は、ゲームコンソールまたはそのハードウェア同等物（例えば、ブレードバージョン）、１つ以上のサーバコンピュータ、またはビデオゲーム１０４に適切な実行環境を提供することができる任意の他のデバイスであり得る。いくつかの実施態様では、ゲーム機は、ビデオゲームが実行される仮想マシン（例えば、ハイパーバイザを使用する）、クラウドコンピューティング、または他の仮想化リソース（例えば、オペレーティングシステムを含む）を実装する。

大まかに言えば、実行中のビデオゲーム１０４は、例えば、ネイティブの非圧縮フォーマットで、ビデオゲームのゲームプレイを反映するビデオ及びオーディオ（例えば、仮想キャラクタの視点などのビデオゲームの仮想環境のレンダリング、ならびに付随するサウンド効果及びサウンドトラック）を生成する。ストリーミングロジック／サーバ１１０は、ビデオ及びオーディオを圧縮フォーマットで符号化してから、ネットワーク１１６を介してそれをクライアントデバイス１２２にストリーミングする。この目的のために、ストリーミングロジック１１０は、例えばビデオコーデックを使用して、またはビデオ圧縮プロトコルに従って、圧縮されたビデオフォーマットでビデオを符号化することができるビデオエンコーダ１１２を含む。より具体的には、ストリーミングロジックは、ネットワーク状態またはクライアントからのフィードバックに基づいて、ビデオまたはオーディオの符号化を調整することができる（例えば、ビットレート、フレームレート、解像度などを調整する）。いくつかの実施態様では、ビデオエンコーダ１１２はまた、例えばオーディオコーデックを使用して、またはオーディオ圧縮プロトコルに従って、圧縮されたオーディオフォーマットでオーディオを符号化するオーディオエンコーダを含む。いくつかの実施態様では、オーディオエンコーダはビデオエンコーダ１１２から分離されている。

前述のように、符号化されたビデオ／オーディオは、ネットワーク１１６を介してクライアントデバイス１２２にストリーミングされる。限定されない例として、クライアントデバイス１２２は、ゲームコンソール、パーソナルコンピュータ、ラップトップ、タブレット、携帯電話、または本開示のようにクラウドゲームプロバイダからのビデオゲームのゲームプレイをストリーミングすることができる任意の他のデバイスであり得る。クライアントデバイス１２２は、符号化されたビデオ／オーディオを受信し、ユーザ１１８が見るディスプレイ１２８にレンダリングするためにビデオを復号し、さらに、ユーザ１１８が聞く１つ以上のスピーカーを通して再生するためにオーディオを復号する、クライアントアプリケーション１２４を実行する。ディスプレイ１２８及び／またはスピーカーは、様々な実施態様において、クライアントデバイスと統合することができ、またはクライアントデバイス１２２から分離することができる。いくつかの実施態様では、ディスプレイ１２８は、テレビ、モニタ、スクリーン、プロジェクタ、またはユーザ１１８がビデオを見ることができる他のデバイスである。加えて、ユーザ１１８は、入力デバイス１２０を操作して、ビデオゲーム１０４に入力を提供することができる。限定されない例として、入力デバイス１２０は、ゲームコントローラ、モーションコントローラ、キーボード、マウス、タッチパッド、トラックボール、カメラ、深度カメラ、マイクロフォン、またはビデオゲームのためのインタラクティブ入力を供給可能である他の任意の感知デバイスであり得る。

示されるように、ストリーミングロジック１１０は、クライアントデバイス１２２へのストリーミングの品質を監視するように構成されたストリームモニタ１１４を含むか、または起動する。限定されない例として、ストリームモニタ１１４は、パケット損失または再送信、クライアントデバイスからの肯定的な確認応答（例えば、クライアントデバイスによって受信されたデータ／パケットの場合）、クライアントデバイスからの否定確認応答（例えば、クライアントデバイスによって受信されないデータ／パケットの場合）、ネットワークレイテンシ、クライアントデバイス１２２へのｐｉｎｇ時間、ネットワーク帯域幅、またはストリーミングロジック１１０とクライアントデバイス１２２との間のデータ伝送の品質の任意の他のインジケータを監視することができる。

加えて、いくつかの実施態様では、クライアントアプリケーション１２４は、接続モニタ１２６を含むか、または起動することができる。接続モニタ１２６は、上記のストリームモニタ１１４と同様のネットワーク状態を監視するように構成することができるが、パケット／データ損失、ネットワーク帯域幅、ネットワークレイテンシなど、クライアント側からである。いくつかの実施態様では、クライアントアプリケーション１１４はストリーミングロジック１１０へのそのようなネットワーク状態に関するフィードバックを送信する。

ネットワークレイテンシまたはネットワーク帯域幅状態などの感知されたネットワーク状態に応じて、ストリーミングロジック１１０は、ビデオゲーム自体を含むようにストリーミング品質フィードバックループを拡張するように構成される。すなわち、ストリーミングロジック１１０は、変化するネットワーク状態を補償するために、ビデオ／オーディオレンダリングまたはゲームプレイなどのビデオゲームの実行のいくつかの態様を調整するためにビデオゲーム１０４と通信するように構成される。例えば、これには、ゲームストリームの帯域幅要件を減らす方法でビデオゲームのビデオ／オーディオレンダリングを調整することが含まれる場合がある。いくつかの実施態様では、ストリーミングロジック１１０は、ビデオゲーム１１４によって行われる調整に加えて、ビデオ符号化の調整を実行することができる。加えて、ビデオゲーム１０４は、ストリーミングロジック１１０、及び／またはストリーミングロジック１１０を介してクライアントデバイス１２２に、ビデオの関心領域に関する情報、またはシーンの変更など、ビデオの今後のイベントに関するヒントなどのビデオ／オーディオの符号化または復号に関連する情報を通信することができる。加えて、通信は、クライアント側のレンダリングまたはインターフェース動作のための情報を送信するなどの他の目的のために、ストリーミングロジック１１０を介してビデオゲーム１０４からクライアントアプリケーション１１４へのパスを確立することができる。

ビデオゲーム１０４とストリーミングロジック１１０との間の通信を容易にするために、ビデオゲーム１０４は、限定されない例として、ＡＰＩ１０６または共有メモリまたはソケットを公開することができる。いくつかの実施態様では、ストリーミングロジック１１０は、ビデオゲーム１０４によるビデオ／オーディオ出力の調整をリクエストするメッセージを送信するために、ビデオゲーム１０４のＡＰＩ１０６にアクセスする。一般的に言えば、ビデオゲーム１０４は、ゲームループを実行し、これは、通常、入力（例えば、コントローラ／モーション／音声入力、ネットワークリクエストまたはマルチプレイヤーゲームにおける他のプレイヤーからの入力などの、ユーザインタラクティブ入力）の処理、ゲーム状態の更新、及び現在のゲーム状態を使用したビデオ／オーディオのレンダリングを含む。したがって、様々な実施態様において、ＡＰＩ１０６またはソケットを介して受信され得るストリーミングロジック１１０からのメッセージは、ゲームのゲームループへの別の入力を構成し得、及び／または現在のゲームの状態に基づいているビデオ／オーディオのレンダリングに影響を与えるように処理され得る。

さらに、ストリーミングロジック１１０とビデオゲーム１０４との間の通信は、フィードバックループの一部であり得、ビデオゲーム１０４によって行われた調整が実施され、そのような調整の結果が監視され（例えば、ストリーム品質を監視し続けることによって）、及び必要に応じて追加の調整が行われる。例えば、ストリーミングロジック１１０が、ビデオゲーム１０４に、劣化したネットワーク状態に応じてビデオ／オーディオ品質を低下させる場合、ストリーミングロジックのビデオエンコーダ１１２を介してビデオ符号化が実行されるまで、その効果が劣化したネットワーク状態を克服するのに十分意味があるかどうかが完全にはわからない場合がある。したがって、効果が十分に大きくない場合、ビデオ品質をさらに低下させるために、ストリーミングロジック１１０からビデオゲーム１０４への追加の指示が必要となる可能性がある。ある意味で、状況を評価するためにいくつかのビデオフレームが必要であり、適切なビデオ／オーディオ品質レベルに到達する前に、ビデオゲーム１０４による複数回の調整が必要となる場合がある。ネットワーク状態が改善する反対のシナリオも同様の方法で処理できるが、ストリーミングロジックがビデオゲームにビデオ／オーディオ品質を上げるように指示することが理解されよう。

本開示の実施態様は、ストリーミングロジック１１０がビデオゲーム１０４とは別のコンピューティングデバイス上に実装される構成に一般的に描かれるが、他の実施態様では、本明細書で説明されるストリーミングロジック１１０の機能は、ビデオゲーム１０４と同じデバイス（ゲーム機１０２など）に実装され得るか、またはいくつかの実施態様では、ビデオゲーム１０４の一部として論理的に組み込まれることさえあり得ることが理解されよう。

図２は、本開示の実施態様による、ビデオ／オーディオ品質がストリーム品質に基づいて調整される、ゲームストリーム品質フィードバックループを概念的に示す。方法動作２００において、クラウドビデオゲームが開始され、これには、ユーザをデータセンタ及びクラウドゲーム機に割り当てること、クラウドゲーム機上でクラウドビデオゲームを実行すること、ストリーミングサーバとユーザのクライアントデバイスとの間の接続を設定することが含まれ得る。方法動作２０２において、実行中のビデオゲームのビデオ／オーディオがクライアントデバイスにストリーミングされ、クラウドビデオゲームのインタラクティブなゲームプレイは、ユーザが、例えば、コントローラデバイスまたは他の入力デバイスを使用して、ストリーミングされたビデオ／オーディオとインタラクトするときに開始する。

方法動作２０４において、ゲームストリーム品質または接続品質またはネットワーク状態が監視される。限定されない例として、これは、ゲームがストリーミングされるデータセンタとクライアントデバイスとの間の、パケット損失、レイテンシ、帯域幅などの状態を監視することを必要とする場合がある。

方法動作２０６において、ゲームストリームの品質が許容可能であるかどうか、さらに、ビデオゲームの品質設定を上げるべきかまたは下げるべきかが決定される。大まかに言えば、ゲームストリームの品質が所与の閾値を下回る場合、方法動作２０８で、ビデオゲームは、ゲーム品質設定を下げるように指示される。限定されない例として、所与の閾値を下回るゲームストリーム品質は、事前定義された閾値を超えるパケット損失、事前定義された閾値を下回る帯域幅、事前定義された閾値を超えるレイテンシなどの様々な測定値によって定義することができる。結果としてのゲーム品質設定の低下には、解像度またはフレームレートの低下、テクスチャ品質の低下、詳細設定の低下、レンダリングされる仮想環境の範囲の縮小など、本明細書でさらに詳細に説明する様々な測定値を含めることができる。

上記と同様に、ゲームストリーム品質が所与の閾値を上回る場合、いくつかの実施態様ではアクションをとる必要がないが、他の実施態様では、方法動作２１０において、ビデオゲームはオプションでゲーム品質設定を上げるように指示される。限定されない例として、所与の閾値を上回るゲームストリーム品質は、事前定義された閾値を下回るパケット損失、事前定義された閾値を上回る帯域幅、事前定義された閾値を下回るレイテンシなどの様々な測定値によって定義することができる。実行されるとき、結果としてのゲーム品質設定の上昇には、解像度またはフレームレートを上げること、テクスチャ品質を上げること、詳細設定を上げること、レンダリングされる仮想環境の範囲を拡大することなど、本明細書でさらに詳細に説明する様々な測定値を含めることができる。

上記を考慮して、いくつかの実施態様では、ゲームストリーム品質は、目標範囲を有することができ、ゲームストリーム品質が目標範囲上（上限）または下（下限）にあるときに、それぞれゲーム品質設定が上方または下方に調整されることが理解されよう。

ゲーム品質設定を上げるかまたは下げた後、方法は方法動作２０４に戻り、そこでストリーム品質がさらに監視され、必要に応じて追加の調整が行われ、したがって、変化する可能性があるネットワーク状態を考慮してストリーム品質を最適化し、ビデオゲームを関与させて、ビデオゲームのレンダリング、ロジック、またはその他の設定の態様を調整することによってそれを行う、フィードバックループが形成されることが理解されよう。

図３は、本開示の実施態様による、ビデオゲームによってレンダリングされた後にストリーミングサーバによって実行されるのに対して、実行中のビデオゲームによってネイティブに実行されるフレームレートの低下を概念的に示す。本開示の実施態様によれば、ビデオのストリーミングに必要なデータの量を減らす１つの方法は、ビデオのフレームレートを下げることであることが理解されよう。既存のビデオエンコーダはフレームレートを下げることができるが、ただし、これが最適に機能するのは、フレーム間の間隔が一定に保たれるように、例えば６０フレーム／秒（ＦＰＳ）ビデオを受信し、それを３０ＦＰＳで符号化する（そして場合によってはクライアントで補間を実行する）など、倍数の間を移動する場合である。

ただし、６０ＦＰＳから３０ＦＰＳに落とすと、使用可能な帯域幅を考慮すると、必要以上にデータが削減される可能性がある。しかしながら、６０ＦＰＳビデオから例えば５０ＦＰＳに削減しようとすると、ビデオエンコーダは６フレームごとに破棄する可能性があるが、フレーム間の間隔が一定していないため、フレームのペーシングがぎくしゃくしているので、モーションがスムーズに見えない場合がある。このシナリオは、参照番号３００に示される一連の画像フレームによって概念的に示され、これらは、６０ＦＰＳでビデオゲーム１０４によって生成され、各フレーム間に１６．６７ミリ秒（ｍｓ）の間隔を有する。しかしながら、ビデオエンコーダが６フレームごとにドロップすると、ドロップされた各フレームの前後のフレーム間の間隔は２倍の３３．３３ｍｓになり、もはや他のフレーム間の間隔と一致しなくなる。クライアント側の補間を実行することはできるが、そのような補間は欠落しているフレームの内容の最善の推測でしかなく、実際にドロップされたフレームと一致しない可能性があり、場合によってはアーティファクトが生成されたり、人工的に見える結果が生成されたりする。

ビデオゲーム自体がフレームレートをネイティブに５０ＦＰＳに下げると、より良い結果が達成され得る。この結果、参照番号３０２に示されているように、フレーム間に不整合がなく、一定の２０ミリ秒間隔のビデオフレームが生成される。ビデオゲーム自体にビデオフレームレートを調整させることにより、フレーム間の一定の間隔さえも備えて、任意のカスタムフレームレートをネイティブに生成できる。前述のように、フレームレートは、感知されたネットワーク状態またはストリーム品質に応じて調整できる。例えば、ストリーム品質またはネットワーク状態が悪化するとき、ビデオゲーム１０４にそのフレームレートを低下させることになり得る。そして、ストリーム品質またはネットワーク状態が改善されるとき、ビデオゲーム１０４はそのフレームレートを増加させることになり得る。ビデオゲームをフレームレート調整に関与させることにより、ゲームはフレームが配信される内部タイミングとレートを調整できるようになり、現在のアプローチのフレームペーシングの制限が解かれるので、他のレートへのフレームレートの低下（または増加）が可能になる。

図４は、本開示の実施態様による、ビデオゲームのフレームレートを制御または設定するための方法を概念的に示す。いくつかの既存のＰＣ／コンソールゲームは、モニタ／ディスプレイの垂直同期（Ｖｓｙｎｃ）を待機するように構成されている。つまり、ゲームがビデオフレームをＧＰＵドライバに渡すとき、ＧＰＵドライバはディスプレイが新しい画像の次のラインを開始するまで待機し、この間、ＧＰＵドライバがフレームを受け入れるまでゲームループがブロックされ、これによりゲームループを絞り、それをディスプレイのリフレッシュレート（例えば、６０Ｈｚ、１２０Ｈｚなど）に同期する。

しかい、クラウドビデオゲームの場合、クラウドビデオゲームを同期できる実際のディスプレイはない。したがって、いくつかの実施態様では、上記のように実際のＶｓｙｎｃの効果を模倣する仮想Ｖｓｙｎｃが作成される。例えば、いくつかの実施態様では、人工のＶｓｙｎｃタイミング信号が所与のフレームレートで生成され、このフレームレートは、データ使用量の削減や増加など、ビデオストリームに所望の効果を達成するように設定または調整される。いくつかの実施態様では、仮想Ｖｓｙｎｃの効果はＧＰＵドライバによって作り出される。

いくつかの実施態様では、上記のようにＶｓｙｎｃタイミング信号を使用するのと同様の効果が、例示の実施態様に示されているように、タイマ／クロックを使用して達成される。ゲームループが示されており、方法動作４００において、ゲームコントローラまたは他のデバイスなどの入力デバイスの動作を通じてユーザインタラクティブ入力から生成された入力などの入力が処理される。方法動作４０２において、ゲーム状態は、リアルタイム物理エンジンまたはゲームの仮想環境内のオブジェクトの状態を決定するための他のプロセスなどのゲームのロジックに基づいて更新される。

次に、方法動作４０４において、次のビデオフレームが、更新されたゲーム状態に従ってレンダリングされる。方法動作４０６において、ゲームループは一時停止され、続行する前にタイマ／クロック４０８を待つ。タイマ／クロック４０８は、フレーム間の間隔を設定し、したがって、上記のようにストリーミングロジックから受信されるフィードバック４１０に基づいて、ゲームループを所望のフレームレートに絞るように構成される。いくつかの実施態様では、タイマは、オペレーティングシステムまたはビデオゲームロジックまたはゲームエンジンによって提供される。例示の実施態様では、ゲームループは、最後のフレームのレンダリング後にタイマによって一時停止されるように示されているが、他の実施態様では、他の、入力を処理するステップ、ゲーム状態を更新するステップのいずれかの後に、ゲームループを一時停止することができる。ゲームループの一時停止を実装することにより、ゲームループから出力されるビデオのフレームレートを任意のカスタムレートに設定でき、ビデオフレーム間の間隔を一定にして、モーションがスムーズに見えるようにする。

ビデオゲーム自体によって調整できるゲームプレイビデオの別の態様は、ビデオの解像度である。現在のクラウドゲームシステムでは、ストリーミングロジック／サーバはビデオゲームから完成したビデオフレームを受信し、事後にビデオフレームの寸法と色深度をスケーリングすることしかできない。しかしながら、ビデオゲーム自体に、事後にスケーリングするのではなく、より低い解像度でビデオをレンダリングするように指示することで、品質を向上させることができる。例えば、生成されたビデオフレームのサイズが１２８０×７２０ピクセルの場合、それを他の解像度にスケーリングすると、それが１２８０×７２０の適切な分数でなければ問題となり、テキストの品質が低下する可能性がある。

しかしながら、そのようなビデオフレームがすでに生成された後にスケーリングするのではなく、ビデオゲーム自体に、ビデオフレームを異なる解像度でレンダリングするように指示する（またはレンダリングさせる）ことができ、これにより、ビデオゲームは選択した解像度のレンダリングを最適化でき、例えば、テキストの品質が最適化されるようにする。このようにして、事後のスケーリングによるペナルティなしに、解像度をいかなる任意の解像度にも動的に変更できる。例えば、ストリーム品質またはネットワーク状態が悪化するとき、ビデオゲーム１０４にビデオ解像度を低下させることになり得る。そして、ストリーム品質またはネットワーク状態が改善されるとき、ビデオゲーム１０４はビデオ解像度を増加させることになり得る。

いくつかの実施態様では、ビデオゲームは、ビデオのアスペクト比を既存の第１のアスペクト比から（異なる）第２のアスペクト比（例えば、１６：９から４：３など）に変更するように指示することができる。アスペクト比の変更は、モバイルデバイス（例えば、携帯電話、タブレットなど）や、ユーザが通常の動作中にディスプレイを回転させる可能性のあるその他のデバイスなど、向きが変わる可能性のあるディスプレイを備えたデバイスに役立つ。したがって、いくつかの実施態様では、ディスプレイの感知された回転（または向きの変化）は、ストリーミングロジックをトリガーして、ビデオゲームにアスペクト比を変更するように指示することができる。このようにして、ビデオは、ストリーミングロジックに依存してビデオが既に生成された後にアスペクト比を変更するのではなく、ディスプレイの表示方法に適したアスペクト比でビデオゲーム自体から配信される。ビデオゲームによってアスペクト比を変更することは、水平／垂直の角度視野を調整するなど、ビデオを通してレンダリングされる視野を調整することを必要とし得ることが理解されよう。いくつかの実施態様では、アスペクト比は、ディスプレイの全画面領域を、ユーザが見るための正しいまたは好ましい向きに一致させるように変更される。

いくつかの実施態様では、デバイスの回転（または向きの変更、例えば、縦向きから横向きへ、またはその逆）を検出することにより、本開示の他の場所で説明されるビデオゲームによってもたらされる他の変更のいずれかをトリガーすることができる。

いくつかの実施態様では、あるデバイスから別のデバイスへの切り替えの検出は、ビデオ解像度、フレームレート、またはアスペクト比の上記の変更など、ビデオゲームによって実行される調整をトリガーすることができる。例えば、ユーザがゲームプレイをテレビから携帯電話に切り替えると、システムはこれを検出し、携帯電話のディスプレイに合わせてビデオ解像度、フレームレート、またはアスペクト比を変更することができる。

図５は、本開示の実施態様による、仮想環境におけるコンテンツの可変的なレンダリングを概念的に示す。いくつかの実施態様では、例えば、ストリーム品質またはネットワーク状態に関するフィードバックに応じて、ビデオゲーム自体によって調整できる別の態様は、ビデオフレームでレンダリングまたは表示される仮想環境内のコンテンツの量である。これを実現する１つの方法は、仮想環境での視距離を調整することによるものである。

例えば、例示の実施態様では、仮想キャラクタ５００が仮想環境において概念的に示されている。ビデオゲームのユーザが見るためにレンダリングされる仮想環境のビューは、仮想キャラクタ５００の視点からの（そして、ユーザが制御できる仮想環境における視野方向を有する）視野５０２内に入る部分であり得る。一般に、視野５０２は、レンダリングされる水平角度量及び垂直角度量によって定義される。所与の時点で、レンダリングされる仮想環境のビューは、仮想キャラクタ５００の位置から、仮想環境内の深さＤ２（または半径または距離）まで拡張できる。すなわち、視野５０２内及び深さＤ２内（すなわち、例示の実施態様では領域５０４及び５０６内）にある仮想環境内のオブジェクトは、ビデオゲームによって出力されるビデオフレームにレンダリングされる。一方、領域５０８内にあるオブジェクトなど、深さＤ２を超えるオブジェクトはレンダリングされない。これにより、仮想環境内のオブジェクトが見るためにレンダリングされる距離が効果的に制限される。

いくつかの実施態様では、例えば、ストリーム品質やネットワーク状態の悪化に応じて、仮想環境からレンダリングするオブジェクトを少なくするために、レンダリングの深さを減らすことができる。例えば、例示の実施態様に示されるように、深さはＤ２から深さＤ１に減少され得る。したがって、この状態では、領域５０４内のオブジェクトがレンダリングされ、当該オブジェクトは、視野５０２内にあり、深さＤ１内にある。一方、領域５０６及び５０８にあるものなど、深さＤ１を超えるオブジェクトは、ユーザが見るためにレンダリングされない。

いくつかの実施態様では、例えば、ストリーム品質やネットワーク状態の改善に応じて、仮想環境からレンダリングするオブジェクトをより多くするために、レンダリングの深さを増加させることができる。例えば、例示の実施態様に示されるように、深さはＤ２から深さＤ３に増加され得る。したがって、この状態では、当該オブジェクトが、視野５０２内にあり、深さＤ３内にあるため、領域５０４、５０６及び５０８内のオブジェクトが全てレンダリングされる。深さＤ３を超えるオブジェクトは、ユーザが見るためにレンダリングはされないことが理解されよう。

ビデオゲームによってビデオフレームにレンダリングされるシーン内の仮想オブジェクトの量を調整することによって、ビデオフレームの複雑さが増加または減少し、その結果、ビデオを忠実に送信するために必要なデータ帯域幅の量が変化することが理解されよう。上記の実施態様において、ビューに含まれる仮想オブジェクトの量は、距離または深さに基づいて決定されているが、レンダリングされる仮想オブジェクトの量を調整する他の方法を使用できることが理解されよう。例えば、いくつかの実施態様では、ストリームの品質及び／またはネットワークの状態に基づいて、特定のタイプまたはクラスのオブジェクトをレンダリングに含める／除外することができる。いくつかの実施態様では、オブジェクトに優先順位または優先度値が割り当てられ、これにより、仮想環境のレンダリングされたビューに含めるための優先順位付けが定義される。つまり、レンダリングされたビデオフレームに含まれるオブジェクトの量が減ると、オブジェクトがドロップされる順序は、優先度の低いオブジェクトから優先度の高いオブジェクトへとなる。または、逆に、レンダリングするオブジェクトの量が増えると、オブジェクトが追加される順序は、優先度の高いオブジェクトから低いオブジェクトへと変わる。

したがって、仮想オブジェクトは、仮想環境のレンダリングされた画像フレームへの包含に関してオンまたはオフにすることができる。また、ネットワークの状態が悪化する、またはストリームの品質が低下するとき、レンダリングの優先度が最も低いオブジェクトが最初にフレームレンダリングから削除される。一般に、レンダリングから除外されるオブジェクトは、その削除がゲームプレイに大きな影響を与えないオブジェクトであると予想されることが理解されよう。

ビデオゲーム自体で調整できる別の態様は、画質である。例えば、ネットワーク状態が悪化している場合、画質を調整する目的は、より符号化しやすいビデオフレームを取得するために、シーンの複雑さを調整することである。ビデオゲームには、所与のネットワーク状態に応じて画質を調整するように指示できる。これには、仮想環境のサーフェスに適用されるテクスチャの品質の調整が含まれ得る。高品質のテクスチャは符号化が非常に複雑になる可能性があるため、テクスチャの品質を下げることで、これが仮想環境のサーフェスの詳細の量を減らし、それらの符号化をより簡単なようにレンダリングし、ストリーミングされるビデオの帯域幅を減らす。いくつかの実施態様では、監視されるネットワーク状態に応じてテクスチャの解像度を調整できる。例えば、ネットワーク帯域幅の減少に応じて、テクスチャの解像度を低下させることができる（例えば、４Ｋ×４Ｋから１Ｋ×１Ｋのテクスチャへ）。これにより、テクスチャの鮮明さが低下するが、エンコーダによる符号化がはるかに簡単になり、符号化アーティファクトが少なくなり、エンコーダレベルで高解像度のテクスチャが単純化された場合よりも全体的なユーザエクスペリエンスが向上する。

いくつかの実施態様では、テクスチャに使用される色深度、または色空間、または色域、または色数が調整される。例えば、このような色パラメータは、帯域幅の減少に応じて縮小または調整したり、帯域幅の増加に応じて戻して拡大したりすることができる。

いくつかの実施態様では、仮想環境で所与のサーフェスまたはオブジェクトをモデル化するために使用されるポリゴンまたはポイントの数を調整できる（例えば、ネットワーク帯域幅の減少に応じて減らせる）。

いくつかの実施態様では、ネットワーク帯域幅またはストリーム品質の低下に応じて、照明効果、パーティクル効果、霧効果、反射、またはその他のレンダリングパラメータを簡略化または減少できる。いくつかの実施態様では、ビデオゲームが特定のジオメトリをレンダリングしないようにできる（例えば、屋外シーンの植生の量または詳細レベルを減らす）。

いくつかの実施態様では、ゲームのコンテキストまたは機能に応じて、ゲームは、帯域幅などのネットワーク状態に基づいて、提供するビジュアルコンテンツ／コンテキストについて決定できる。例えば、霧のある森の中で外を歩いているキャラクタの場合、ユーザが仮想環境で遠くを見ることができないように、霧の量を増やすようにゲームを構成できる。

いくつかの実施態様では、ビデオゲームは、含めるコンテンツの量または詳細を決定する様々なレベルのコンテンツ設定を実装できる。図６は、本開示の実施態様による、ネットワーク帯域幅フィードバックに基づくいくつかのコンテンツ設定を概念的に示す。動作６００において、利用可能なネットワーク帯域幅が検出される。動作６０２において、いくつかのオプションの中からビデオゲームの詳細レベルが設定される。例えば、低帯域幅オプションは、参照番号６０４に示され、２つのキャラクタは、キャラクタが立っている草を表す単純なテクスチャからなる単純な背景、及び雲または他の詳細が示されていない空と共に示されている。

参照番号６０６に示されている中帯域幅オプションの場合、草は多角形で表され、草の個々の葉を認識できるようになっている。加えて、いくつかの雲が表示されているが、単純に描かれており、詳細度は低くなっている。

しかしながら、参照番号６０８に示されている高帯域幅オプションの場合、草の個々の葉はより多く、密度が高くなる。さらに、草の葉は揺れたり動いたりするように構成することができる。また、雲は非常に詳細に描かれている。また、高帯域幅の背景に表示される木があるが、これは低詳細設定では前に表示されなかった。花、低木、その他の種類の植物など、追加の植生を表示できる。

したがって、ビデオゲームは、ネットワーク状態またはストリーム品質の変化に応じて、コンテンツの量または当該コンテンツの詳細レベルを調整するように構成することができる。植生、キャラクタ、乗り物などの仮想要素の視距離、テクスチャ、ディテール、量を調整するなど、様々な調整を行うことができる。したがって、仮想環境の品質レベルを動的に変更でき、これは、以前の方法とは異なる。なぜなら、それらがすでにレンダリングされた後にフレームレートを単に変更するのではなく、本開示の実施態様は、コンテンツ自体の変更を提供するからである。いくつかの実施態様では、ビデオゲームによるコンテンツの変更を、必要に応じて動的に切り替える高／中／低帯域幅の選択肢など、様々なレベルに設定できる。いくつかの実施態様では、ユーザがその相対的重要度レベルの設定など、コンテンツ調整に関する好みを設定できるようにするために、ユーザの好み設定を提供することができる。例えば、ユーザは、テクスチャ品質、オブジェクトの数、解像度、フレームレートなどの側面の相対的な好みのレベルを示すことができ、ビデオゲームはそれに応じて様々な態様に優先順位を付ける。

いくつかの実施態様では、ユーザの好みを判断するために機械学習方法が適用される。例えば、いくつかの実施態様では、システムはユーザのゲーム履歴を分析してユーザの好みを判断するように構成されている。ユーザの好みを決定するために、プレイヤーがどれだけ優れているか、プレイヤーが死ぬ頻度、エクスペリエンスのレベル、選択された難易度設定、プレイヤーが使用するゲーム入力の組み合わせなどの因子を考慮することができる。

ビデオゲームは、ビデオイメージに影響を与える調整を行うだけでなく、ビデオゲームによってレンダリングされるオーディオを調整することもできる。既存のクラウドゲームシステムでは、ビデオゲームは、例えばステレオ、５．１サラウンドサウンド、またはその他の高忠実度オーディオ設定でレンダリングされたオーディオを配信し、このような設定はゲームの起動時に固定される。ストリーミングサーバのオーディオエンコーダはオーディオストリームを符号化し、オーディオ品質を調整するために使用できるオプションは限られている。例えば、ネットワークの状態が悪化した場合（例えば、ユーザが５．１でストリーミングしたが、現在はステレオの帯域幅しかない場合）、オーディオエンコーダはチャンネルをドロップするかステレオにダウンミックスする必要がある。さらに、オーディオエンコーダはオーディオビットレートを低下させることができる。ただし、このような調整は、オーディオが既にレンダリングされた後に行われる。ダウンストリームの符号化調整に依存するのではなく、ビデオゲーム自体でオーディオを調整することで、より良い結果を得ることができる。

いくつかの実施態様では、ユーザのオーディオ機能が変更される場合がある。例えば、ユーザが５．１オーディオ設定を使用しているが、ゲームの途中で代わりにヘッドフォンを使用するように切り替えたとする。このようなオーディオ機能の変更の場合、システムはビデオゲームをトリガーしてそのオーディオ設定を変更し、例えば５．１からステレオに切り替えることができる。様々な実施態様において、ユーザのオーディオ機能またはユーザのリスニングデバイスの検出された変化に応じて、ビデオゲームをトリガーして、オーディオ設定を、新しいオーディオ機能またはリスニングデバイスに適したオーディオ設定／構成に変更できることが理解されよう。

ビデオゲームがオーディオの調整に関与できるようにすることで、オーディオレンダリングに関するよりインテリジェントな決定を行うことができ、それによりユーザエクスペリエンスが向上する。上記の例を考慮すると、５．１サラウンドでのビデオゲームのレンダリングはステレオでのレンダリングに切り替えることができ、これにより、事後にダウンミックスするよりも優れたエクスペリエンスが提供される。帯域幅の減少に対応して適用できる他のオプションには、オーディオ／サウンド効果の制限、またはバックグラウンドミュージックなどのバックグラウンドオーディオの無効化が含まれる。いくつかの実施態様では、ユーザの接続品質に応じて動的にオフ／オンにする目的で、サウンド効果に優先順位を付けることができる。一般的に言えば、上記の例では、帯域幅の減少などのネットワーク状態の悪化に応じて、ビデオゲームによってオーディオ品質が低下される。同様に、反対のシナリオでは、ネットワーク状態が改善されるとき、それに応じてオーディオ品質がビデオによって向上され得ることが理解されよう。

いくつかの実施態様では、ビデオゲームは、ネットワーク接続またはストリーム品質（例えば、レイテンシ及び帯域幅）に基づいてゲームの難易度を調整し、ビデオゲームがユーザにとってプレイ可能で楽しいままであることを保証する目的を果たすことができる。例えば、ビデオゲームは、クライアントとストリーミングサーバ間のレイテンシに応答するように構成できる。いくつかの実施態様では、レイテンシはｐｉｎｇ時間に基づいて決定される。いくつかの実施態様では、ビデオゲームは、所与の入力が所与のアクションを実行する期限（例えば、ボタンを押してジャンプしたり敵をキルしたりする期限）など、内部タイミングを調整できる。例えば、いくつかの実施態様では、レイテンシが増加するとき、内部タイミングが緩和される。つまり、より多くの時間が許可されるか、所与のアクションの期限が延長される。逆に、レイテンシが短くなるとき、内部タイミングが厳しくなる。つまり、許可される時間が短くなるか、所与のアクションの期限が短くなる。例えば、これは、レイテンシが長くなると敵を攻撃したりキルしたりするなどのアクションを実行しやすくし、逆に待ち時間が短くなるとより困難にする効果がある。

いくつかの実施態様では、ビデオゲームは、接続品質が低下したとき、例えば、レイテンシが比較的高いとき、ゲームはより困難になる可能性があるので、ゲーム内のプレイヤー支援機能（自動照準、ステアリング支援など）の効果を高める。逆に、いくつかの実施態様では、接続品質が向上すると、ビデオゲームはゲーム内プレイヤー支援機能の効果を低下させる。繰り返しになるが、ゲーム内支援機能の上記の動的調整は、ネットワーク状態が低下するとゲームを容易にし、ネットワーク状態が改善するとゲームをより困難にする効果がある。これは、ユーザに対して所与のレベルの公平性を維持するのに役立つ。

いくつかの実施態様では、ユーザのデバイスタイプに応じてゲームの難易度を調整できる。例えば、タッチコントロールを使用して電話でビデオゲームをプレイすることは、コントローラを使用してゲームコンソールでプレイするよりも難しい場合がある。したがって、ユーザがあるタイプのデバイスの使用から別のタイプのデバイスに切り替えるときに、ゲームの難易度を調整（低減）することが役立ち得る。

いくつかの実施態様では、ビデオゲームは、ユーザ接続品質またはストリーム品質が特に悪いか、または最小閾値レベルを下回った（例えば、ユーザが携帯電話で４Ｇ／５Ｇセルラーデータネットワークを使用していて、トンネルを通過する電車など、受信状態の悪い場所に一時的に入っている）ときにゲームを一時的に一時停止するように構成できる。同様に、ビデオゲームは、接続／ストリームの品質が許容レベルに戻ったときにゲームの一時停止を解除するように構成できる。いくつかの実施態様では、ゲームが一時停止している間に広告を表示することができ、広告は、接続不良／ストリーム品質の状況に遭遇する前に、ユーザデバイスに送信され、保存されている。

他の実施態様では、ビデオゲームは、（接続品質の低下に対応するのではなく）広告の表示を可能にするために、システムによって意図的に一時停止される。

様々な実施態様において、ストリーミングサーバとビデオゲームは、接続／ストリーム品質の変化に基づいてビデオまたはオーディオを調整するために異なる方法でインタラクトすることができる。限定されない例として、監視されたパケット損失に基づいて、ビデオエンコーダまたはオーディオエンコーダのターゲットビットレートがあり得る。いくつかの実施態様では、ビデオゲームが最初に調整を行うために用いられ、次にビデオゲームによる調整が十分でない場合、ビデオエンコーダまたはオーディオエンコーダがさらなる調整（例えば、スケーリング、フレームのドロップ、ビットレート、ＱＰ設定などを下げるためのエンコーダ設定の調整）を行うために用いられる。ある意味で、ビデオゲーム自体による調整が現在の接続品質に対して不十分である場合、ストリーミングサーバは独自のメカニズムに逆戻りすることができる。

いくつかの実施態様では、ストリーミングサーバは最初に特定の調整を実行し、次にストリーミングサーバによる調整が十分でない場合、ビデオゲームが調整を実行するために用いられる。

いくつかの実施態様では、ビデオゲームとストリーミングサーバの両方が、接続品質の変化に応じて実質的に同時に調整を開始するように構成されている。

いくつかの実施態様では、接続品質に応じて調整を実行するために、ビデオゲームとストリーミングサーバのいずれかまたは両方を使用するための閾値が存在し得る。例えば、いくつかの実施態様では、レイテンシが所与の閾値を超えると、ビデオゲームの使用がトリガーされて調整が実行される。

いくつかの実施態様では、ゲームに応じてストリーミングサーバを論理的に設定できる。つまり、各ゲームは、ストリーミングサーバに対するビデオゲームによって行われる調整のタイプと量を管理する設定を定義できる。いくつかの実施態様では、ゲームは特定のゲームのプリセットを含む構成ファイルを提供する。構成ファイルは、ビデオゲームのゲームエンジンとストリーミングサーバのいずれかまたは両方に、特定の設定の優先度を提供することができる。例えば、一人称シューティングゲームは解像度よりもフレームレートを優先し得るが、パズルゲームはフレームレートよりも解像度を優先し得る。

いくつかの実施態様では、ストリーミングサーバは、ビデオゲームによる調整をいつ起動するかを決定し、いくつかの実施態様では、クライアントとの接続品質を監視しているため、ビデオゲームに対して行う調整のタイプをさらに決定する。

本明細書で説明する実施態様は、クライアントまたはストリーミングソフトウェアからビデオゲームに戻るフィードバックに基づくストリーミング最適化を提供するが、ビデオゲームがストリーミング最適化を可能にするためにストリーミングサーバまたはクライアントに情報を提供するフィードフォワードパスもあり得る。図７は、本開示の実施態様による、ビデオゲームからストリーミングロジックへのフィードフォワード最適化を概念的に示す。仮想キャラクタ７０２及びドア／エレベータ７０６を含む、ビデオゲームのシーン７００が概念的に示されている。

いくつかの実施態様では、ビデオゲームは、関心領域についてビデオエンコーダに通知することができる。ビデオゲームは、ビデオフレームのどの部分が変化しているかを判断するように構成でき、ストリーミングサーバに通知できるため、ビデオエンコーダは変化している部分に焦点を合わせることができる。既存のゲームストリーミングシステムでは、どの部分が変更される可能性があるかがわからないため、ビデオエンコーダはビデオフレームの全ての異なる部分に一定量のビットを割り当てる。しかしながら、例えばフレームの４分の３で画面の変更がない場合、ビデオゲームはこれらの変更されていない部分のデータを送信せず、これらの変更されていない部分に割り当てられたビットは必要ない。したがって、既存のシステムとは対照的に、いくつかの実施態様では、ビデオエンコーダは、変更が発生している画面の領域に（そうでなければ変更されていない部分に不必要に割り当てられていた）ビットを割り当てることができ、それらの領域は、結果としてより良好な画質を有することができる。このビットの割り当ては、関心のある領域または変化している領域を識別するビデオゲーム自体から情報を受信するストリーミングサーバに基づいている。さらに、例えばビューのパンニングのためにシーン全体が変化している可能性がある場合でも、関心領域の識別は、ビデオエンコーダが、ユーザによって焦点が当てられる可能性の高い特定の領域（例えば、キャラクタが配置されている領域、ターゲットとしている領域、アクティビティが発生している領域など）を他の領域よりも優先できるようにするのに役立ち得る。

図７を引き続き参照すると、例示の実施態様において、関心領域７０４は、仮想キャラクタ７０２が配置されている領域であるビデオゲーム（参照番号７０８）によって識別される。この領域は、仮想キャラクタ７０２の位置に基づいて、さらに仮想キャラクタの動きに基づいて、ビデオゲームによって識別され得る。例えば、関心領域は、仮想キャラクタが向かっている領域、またはインタラクションが発生する可能性が高い領域を含むように識別できる。識別された関心領域７０４は、ストリーミングロジック１１０に通信され、関心領域の符号化品質に優先順位を付けるためにビデオエンコーダ１１２によって使用される。

既存のストリーミングシステムのビデオエンコーダのもう１つの課題は、エンコーダがフレームの大量の変更（例えば、受信したｐフレームのサイズがはるかに大きい）を認識せず、単に「見る」だけであるため、シーンの変更があるときに発生する。したがって、フレームが大きくなりすぎて都合よく処理できない可能性があり、変更が非常に多いために画像が安定するまでに時間がかかる可能性があるため、シーンの変更は課題である。その結果、シーンが変更される前の状態に画質を復元するのに多くのフレームが必要になる場合があり、その間、ユーザエクスペリエンスは低下する。しかしながら、本開示の実施態様によれば、ビデオエンコーダには、シーン変更が近づいていること、または現在のフレームがシーン変更の一部であることをビデオゲームによって通知することができる。この情報は、ビデオエンコーダで利用して、例えばビットバジェットの割り当て方法を決定することができる。

例示の実施態様では、仮想キャラクタ７０２は、ドア／エレベータ７０６に向かって移動している。仮想キャラクタ７０２がドア７０６に到達すると、シーンが変化する。ビデオゲームは、シーンの変化がすぐに発生する可能性が高いと判断し、この情報をストリーミングロジック１１０に伝達する（参照番号７１０）。この情報は、ビデオエンコーダ１１２によってその符号化設定（例えば、差し迫ったシーン変更を処理するためのビットバジェットの割り当て）を調整するために利用される。

いくつかの実施態様では、ゲーム機／システムのオペレーティングシステムは、特定の「フィードフォワード」情報も取得できる。これは、フィードフォワード情報を提供するように修正されていないゲームに特に役立つことができ、及び／またはストリーミングロジックに追加の手がかりを提供し得る。例えば、プロセスは、ゲームがディスク上のどのファイルにアクセスしているか（例えば、新しいレベルまたは他のイベントのロードを示す可能性がある）、またはハードウェア／ｓｓｄのスループット（例えば、スループットの突然の変化はシーンの変化または他のイベントを示す可能性がある）を監視できる。いくつかの実施態様では、プロセスは、ビデオゲームがアクセスしているメモリの領域を監視することができる。

いくつかの実施態様では、これらのシステムレベルのインジケータに基づくゲームのプロファイルを（例えば、ＱＡオペレータによって）生成することができる。システムレベルのインジケータは、ユーザがゲームのどこにいるかを判断するためのマーカーとして使用できる。したがって、ビデオゲームの適切な参照設定をインジケータに基づいて選択し、プロファイルに保存することができる。例えば、プロファイルは、インジケータの様々なものを特定の参照設定にマッピングすることができ、その結果、インジケータが特定の値を有するとき、ビデオゲームは、参照設定に従ってそのビデオ／オーディオレンダリングを調整するように指示される。ゲームの様々な領域で様々な設定を行うことができる。例えば、ユーザが戦闘中の場合（例えば、ストレージアクセス、ビデオ画像の機械学習、オーディオデータの機械学習、ユーザがボタン／スティックを押す速度から推測される）、フレームレートを優先することができる。一方、ユーザがかなり静的な領域にいる場合やアクティビティが少ない場合は、代わりに解像度または別のビデオプロパティが優先され得る。

いくつかの実施態様では、データチャネルをビデオゲームからストリーミングサーバ、クライアントに拡張できるため、ビデオゲームはコンテンツをクライアントに送信でき、例えば、オーバーレイを描画したり、コード／スクリプトを送信していくつかのクライアントロジックを提供したりできる。ビデオゲームはストリーミングサーバにフィードフォワードし、ストリーミングサーバはクライアントにフィードフォワードする。例えば、ビデオゲームは共有アセットを送信して、例えば、ステータス情報、プレイヤーの健康状態、ボスを倒すなどの成果などのアイテムのオーバーレイを描画することができる。いくつかの実施態様では、タッチインターフェースのクライアント側の描画を可能にするために、データがデータチャネルに送信され得る。いくつかの実施態様では、データチャネルを介してクライアントに送信されるコードは、タイマ、例えば、ゲームが１０秒で終了するのをカウントダウンしているクロックをレンダリングするように構成できる。いくつかの実施態様では、データチャネルは、マイクロフォン、カメラ、またはゲーム固有の周辺機器などの周辺機器に使用して、ビデオゲームが周辺機器の処理を制御する方法を提供することができる。

そのようなデータチャネルは、一定量の利用可能な帯域幅を消費するので、いくつかの実施態様では、ストリーミングロジックは、データチャネルに利用可能な帯域幅の量をビデオゲームに通信することができる。いくつかの実施態様では、ビデオゲームは、情報がクライアントに伝達されるための優先度設定または期限を設定することができる。いくつかの実施態様では、データチャネルのパケットが伝播される速度を必要に応じて調整でき、例えば、ビデオ／オーディオのストリーミングに使用できる一定量の帯域幅を維持できる。

本開示の実装態様は、ゲームエンジンの一部として含めることができる。大まかに言えば、ゲームエンジンは、ビデオゲームの効率的な開発を可能にする機能を提供するソフトウェア開発フレームワークである。ゲームエンジンには、再利用可能なモジュールを備えたソフトウェアライブラリを含めることができて、ゲーム機能の様々な態様を処理でき、これには、限定されない例として、グラフィックスレンダリング（例えば、頂点処理、ポリゴン処理、シェーディング、ライティング、テクスチャリングなどを含む）、サウンド、物理学（衝突処理を含む）、アニメーション、スクリプティング、人工知能、ネットワーキング、ストリーミング、メモリ管理、スレッド化、ローカリゼーションサポート、シーングラフ、シネマティクスなどが含まれる。

ゲームエンジンは、ゲームコンソール、モバイルデバイス、パーソナルコンピュータなど、様々なハードウェアプラットフォーム用に最適化できる。限定されない例として、ゲームエンジンは、プラットフォームに応じてメモリ使用（例えば、グラフィックスパイプラインにおける様々なタスクの優先順位付け方法など）を最適化できる。いくつかの実施態様では、ハードウェアは、ゲームコンソールなどの特定の処理エンティティのブレードバージョンであり得る。したがって、ユーザを特定のブレードに割り当てることができ、これにより、コンソールゲームが最適化されたものと同じハードウェアが与えられる。

ストリーミング及び／または他のサービス（パケット化、符号化、サービス品質（ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ、ＱＯＳ）監視、帯域幅テスト、ソーシャルネットワーク／友人へのアクセスなど）を提供するためのゲームサーバロジックもあり得ることが理解されよう。

いくつかの実施態様では、クラウドインフラストラクチャがハイパーバイザを実行することができ、ハイパーバイザは、ハードウェアを抽象化し、オペレーティングシステム（ＯＳ）をロードできる仮想マシンフレームワークを提供する。したがって、スタックには、基盤となるハードウェアにロードされるハイパーバイザによってインスタンス化された仮想マシン（ＶＭ）にロードされる、ＯＳ上で実行されるアプリケーション／ビデオゲームが含まれてもよい。このように、アプリケーションの実行は必ずしも特定のハードウェアに結びつけられているわけではない。

いくつかの実施態様では、アプリケーション／ビデオゲームがコンテナ上で実行され、アプリケーションレイヤで抽象化され、コードと依存関係が一緒にパッケージ化されるため、ＯＳやハードウェアプラットフォームに依存しないソフトウェア開発が可能になり、プラットフォーム間でのソフトウェアの移植性が向上する。

いくつかの実施態様では、ゲームエンジンの異なる部分を異なる計算エンティティによって処理することができる分散型ゲームエンジンが採用されている。例えば、物理エンジン、レンダリングエンジン（２Ｄ／３Ｄグラフィックス）、サウンド、スクリプト、アニメーション、ＡＩ、ネットワーキング、ストリーミング（符号化）、メモリ管理、スレッド化などのゲームエンジンの機能は、多くの異なるコンピューティングに分散されている様々な機能的な処理ブロック及び／またはサービスに分割することができる。分散型ゲームエンジンの場合、レイテンシの問題を回避するために低レイテンシの通信が必要であることが理解されよう。必要なフレームレートを維持するには、計算と通信の合計時間が特定の制約を満たす必要がある。したがって、プロセスをより短い時間で完了することが可能かどうかに応じて、特定のタスクを分割することが効率的である場合とそうでない場合がある。

分散型ゲームエンジンを使用する利点は、必要に応じてコンピューティングリソースをスケールアップまたはスケールダウンできるエラスティックコンピューティングを利用できることである。例えば、従来は単一のハードウェアサーバで実行されていた大規模なマルチプレイヤーゲームでは、例えば約１００人のプレイヤーがいると、ハードウェアリソースが制限されるので、より多くのプレイヤーを追加できなくなる。ゲームは追加のプレイヤーをキューに入れる可能性があり、つまり、プレイヤーはゲームに参加するのを待たねばならない。しかしながら、分散型ゲームエンジンでは、エラスティッククラウドコンピューティングリソースを使用することで、需要を満たすためにより多くの計算ノードを追加できるため、例えば数千人のプレイヤーが利用できる。ゲームは、特定のハードウェアサーバの制限による制約をもはや受けない。

したがって、クラウドゲームエンジンは、様々な処理エンティティに機能を分散させることができる。異なるフレームワークで異なる機能を実行できることが理解されよう。例えば、一部の機能（ソーシャルなど）はコンテナで実行する方が容易な場合があるが、グラフィックスはＧＰＵに接続されたＶＭを使用して実行する方が良い場合がある。

クラウドゲームエンジンの機能の分散を容易にするために、分散／同期レイヤは、ジョブの分散を管理でき、例えば、ジョブの送信、データ戻りの受信、どのタスクがいつ実行されるか、ジョブが求められるよりも早く完了する場合のキューイングの処理などである。いくつかの実施態様では、特定のタスクを必要に応じて動的に細分化できる。例えば、アニメーションに照明を含めることができ、照明が特に複雑な場合、照明を３つの照明ジョブに細分化して、コンピューティングのために送信し、戻ったときに再構築することができる。したがって、ゲームエンジンの機能は、より多くの作業が必要な場合に細分化できる。

クラウドサービスプロバイダは、例えば１秒あたりの入出力動作（「ＩＯＰＳ」）など、指定されたパフォーマンスレベルでコンピューティングを提供する。したがって、ゲームプロバイダは、クラウドサービスプロバイダからＶＭ、専用の処理能力、メモリの量などを指定し、クラウドサービスプロバイダのシステムを使用して分散型クラウドゲームエンジンをインスタンス化することができる。

いくつかの実施態様では、ライブラリモジュールと更新ハンドラは、ゲームエンジンの１つ以上のコンポーネントまたはモジュールにすることができる。いくつかの実施態様では、ライブラリモジュールと更新ハンドラを個別のコンポーネントにすることも、統合することもできる。いくつかの実施態様では、ライブラリモジュールと更新ハンドラがゲームエンジンへの追加として動作することができる。いくつかの実施態様では、上記のように、ゲームエンジンは分散型ゲームエンジンであり得る。

前述のように、本開示の実施態様は、クラウドゲームシステムに適用され得る。クラウドゲームシステムの一例として、Ｐｌａｙｓｔａｔｉｏｎ（登録商標）Ｎｏｗクラウドゲームシステムが挙げられる。現在、このようなシステムでは、クライアントデバイスは、Ｐｌａｙｓｔａｔｉｏｎ（登録商標）４ゲームコンソールなどのゲームコンソールであり得るか、またはパーソナルコンピュータ、ラップトップ、タブレット、携帯電話、モバイルデバイスなどの別のデバイスであってもよい。

大まかに言えば、ゲームタイトルのユーザリクエストが受信されると、クラウドゲームを有効化するために、クラウドゲームサイトに対応付けられたデータセンタ内の１つ以上のサーバによりいくつかの動作が実行される。クラウドゲームサイトがユーザリクエストを受信するとき、選択されたゲームタイトルに対応付けられたゲームをホストするデータセンタが識別され、選択されたゲームタイトルのゲームをインスタンス化するために、識別されたデータセンタにリクエストが送信される。リクエストに応じて、データセンタのサーバは、ゲームコンテンツをユーザに提示する準備として、ゲームコードを識別し、識別したゲームコードをロードし、ゲームコードに関連するファイルを初期化する。ゲームに対応付けられたゲームデータには、一般的なゲームデータと、ユーザ固有のゲームデータとが含まれ得る。従って、ファイルを初期化することは、一般的なゲームデータ及びユーザ固有のゲームデータの両方を識別し、ロードし、初期化することを含み得る。一般的なゲームデータを初期化することは、グラフィックスエンジンを初期化すること、グラフィックスデータをインストールすること、サウンドファイルを初期化すること、アートワークをインストールすることなどを含み得る。ユーザ固有データを初期化することは、ユーザデータ、ユーザ履歴、ゲーム履歴などを検索すること、転送すること、及びインストールすることを含み得る。

一般的なゲームデータがロード及び初期化されている間、クライアントデバイスでレンダリングするための「スプラッシュ」画面が提供され得る。スプラッシュ画面は、ロードされているゲームの代表的な画像を提供するように設計され、ロードされているゲームの好例をユーザが下見することを可能にし得る。一般的なゲームデータがロードされると、特定の初期コンテンツがレンダリングされ得、選択／ナビゲーション画面が、ユーザ選択及びカスタマイズのために提示され得る。選択／ナビゲーション画面で入力されるユーザ選択には、ゲームレベルの選択、ゲームアイコン（複数可）の選択、ゲームモードの選択、ゲームの獲得物、追加のゲームコンテンツのアップロードが必要となり得る他のユーザ関連データが含まれ得る。いくつかの実施形態では、ゲームコンテンツは、ゲームクラウドシステムからユーザのコンピューティングデバイスにゲームコンテンツをストリーミングすることにより、視聴及びインタラクトするために利用可能となる。いくつかの実施態様では、ユーザ固有データをロードした後に、ゲームコンテンツはゲームプレイに利用可能となる。

図８Ａは、クラウドゲームサイトを介して利用可能なゲームのゲームファイルをロードするために使用される例示的なシステムを示す。システムは、ネットワーク８０２を介してクラウドゲームサイト８０４に通信可能に接続された複数のクライアントデバイス８００を含み、ネットワーク８０２は、ＬＡＮ、有線、無線、セルラー（例えば、４Ｇ、５Ｇなど）、またはインターネットを含む任意の他のタイプのデータネットワークを含むことができる。クラウドゲームサイト８０４にアクセスするリクエストがクライアントデバイス８００から受信されるとき、クラウドゲームサイト８０４は、ユーザデータストア８０８に記憶されたユーザアカウント情報８０６にアクセスして、リクエストを発信したクライアントデバイスに関連付けられたユーザを識別する。いくつかの実施形態では、クラウドゲームサイトはまた、ユーザが視聴／プレイを許可された全てのゲームを特定するために、識別したユーザを検証し得る。ユーザアカウントの識別／検証に続いて、クラウドゲームサイトは、ゲームタイトルデータストア８１０にアクセスして、リクエストを発信したユーザアカウントがクラウドゲームサイトで利用可能なゲームタイトルを識別する。今度は、ゲームタイトルデータストア８１０が、ゲームデータベース８１２とインタラクトして、クラウドゲームサイトが利用可能な全てのゲームのゲームタイトルを取得する。新しいゲームが導入されると、ゲームデータベース８１２はゲームコードが更新され、ゲームタイトルデータストア８１０は、新たに導入されたゲームのゲームタイトル情報が提供される。リクエストを発信したクライアントデバイスは、リクエストを発信した時に、クラウドゲームサイトに登録されている場合とされていない場合がある。リクエストを発信したクライアントデバイスのユーザが登録ユーザでない場合には、クラウドゲームサイトは、そのユーザを新規ユーザとして識別し、新規ユーザに好適なゲームタイトル（例えばデフォルトのゲームタイトル集合）を選択し得る。図８Ａに示されるように、特定されたゲームタイトルは、ディスプレイ画面８００－ａに提示されるように、クライアントデバイスに返される。

クライアントデバイス上でレンダリングされたゲームタイトルのうちの１つでユーザインタラクションが検出され、信号がクラウドゲームサイトに送信される。信号には、ユーザインタラクションが検出されたゲームタイトル情報と、ゲームタイトルで登録されたユーザインタラクションとが含まれる。クライアントデバイスから受信した信号に応じて、クラウドゲームサイトは積極的に、ゲームがホストされているデータセンタを特定し、特定したデータセンタに信号を送信して、ユーザインタラクションが検出されたゲームタイトルに関連付けられたゲームをロードする。いくつかの実施形態では、複数のデータセンタがゲームをホストしている場合がある。このような実施形態では、クラウドゲームサイトは、リクエストを発信したクライアントデバイスの地理的位置を特定し、クライアントデバイスに地理的に近いデータセンタを識別し、データセンタにゲームをプリロードするように信号を送信し得る。ユーザの地理的位置は、いくつか例を挙げると、クライアントデバイス内の全地球測位システム（ＧＰＳ）メカニズム、クライアントのＩＰアドレス、クライアントのｐｉｎｇ情報を使用して、特定され得る。当然ながら、ユーザの地理的位置を検出する前述の方法は例示であり得、他の種類のメカニズムまたはツールを使用して、ユーザの地理的位置を特定してもよい。クライアントデバイスに近いデータセンタを識別することにより、ユーザがゲームとインタラクトする際のレイテンシを最小限に抑えることができる。いくつかの実施形態では、識別されたデータセンタは、ゲームをホストするのに必要な帯域幅／処理能力を有さない場合がある、または過使用されている場合がある。これらの実施形態では、クラウドゲームサイトは、クライアントデバイスに地理的に近い第２のデータセンタを識別し得る。ゲームをロードすることは、ゲームコードをロードすることと、ゲームのインスタンスを実行することとを含む。

クラウドゲームサイトからの信号の受信に応じて、識別されたデータセンタは、データセンタでサーバを選択して、サーバ上でゲームをインスタンス化することができる。サーバは、利用可能なハードウェア／ソフトウェアの処理能力及びゲーム要件に基づいて選択される。サーバは、複数のゲームコンソールを含み得、サーバは、ゲームをロードするのに、複数のゲームコンソールのうちのどのゲームコンソールを使用するかを決定し得る。ゲームコンソールは、独立したゲームコンソールに類似し得る、またはラックマウントサーバもしくはブレードサーバであり得る。ブレードサーバは、次に、複数のサーバブレードを含み得、各ブレードは、ゲームなどの単一の専用アプリケーションをインスタンス化するのに必要な回路を有する。当然ながら、前述のゲームコンソールは例示であり、限定として見なされるべきではない。ゲームステーションなどを含む他の種類のゲームコンソール、及び他の形態のブレードサーバも、識別されたゲームをホストするために用いられてよい。

ゲームコンソールが識別されると、ゲームの一般的なゲーム関連コードがゲームコンソールにロードされ、ゲームがインスタンス化されるゲームコンソールを識別するネットワーク上でクラウドゲームサイトを介してクライアントデバイスに信号が返される。このように、ロードされたゲームは、ユーザに利用可能となる。

図８Ｂは、本開示の実施態様による、クラウドビデオゲームをクライアントデバイスにストリーミングするために実行される様々な動作を概念的に示すフロー図である。ゲームシステム８１８は、ビデオゲームを実行し、生の（非圧縮の）ビデオ８２０及びオーディオ８２２を生成する。ビデオ８２０及びオーディオ８２２は、示される図の参照番号８２４に示されるように、ストリーミングのために取り込まれ符号化される。符号化により、ビデオ及びオーディオのストリームが圧縮され、帯域幅の使用量は軽減され、ゲームエクスペリエンスは最適化され得る。符号化形式の例として、Ｈ．２６５／ＭＰＥＧ－Ｈ、Ｈ．２６４／ＭＰＥＧ－４、Ｈ．２６３／ＭＰＥＧ－４、Ｈ．２６２／ＭＰＥＧ－２、ＷＭＶ、ＶＰ６／７／８／９などが挙げられる。

符号化されたオーディオ８２６及び符号化されたビデオ８２８はさらに、インターネットなどのネットワークを介して送信するために、参照番号８３２に示されるように、ネットワークパケットにパケット化される。ネットワークパケット符号化プロセスは、データ暗号化プロセスも採用し得るため、データセキュリティが強化される。例示の実施態様では、オーディオパケット８３４及びビデオパケット８３６は、参照番号８４０に示されるように、ネットワークを介して転送するために生成される。

ゲームシステム８１８はさらに、触覚フィードバックデータ８３０を生成し、これもネットワーク送信のためにネットワークパケットにパケット化される。例示の実施態様では、参照番号８４０でさらに示されるように、ネットワークを介して転送するために、触覚フィードバックパケット８３８が生成される。

生のビデオ及びオーディオ並びに触覚フィードバックデータを生成することと、ビデオ及びオーディオを符号化することと、符号化されたオーディオ／ビデオ及び触覚フィードバックデータを転送用にパケット化することとの前述の動作は、クラウドゲームサービス／システムを集合的に定義する１つ以上のサーバ上で実行される。参考番号８４０に示されるように、オーディオ、ビデオ、及び触覚フィードバックのパケットは、インターネットなどのネットワーク、及び／またはインターネットを含むネットワークを介して、転送される。参考番号８４２に示されるように、オーディオパケット８３４、ビデオパケット８３６、及び触覚フィードバックパケット８３８は、クライアントデバイスにより復号／再構築され、クライアントデバイスにて、符号化されたオーディオ８４６、符号化されたビデオ８４８、及び触覚フィードバックデータ８５０が定義される。データが暗号化されている場合は、ネットワークパケットは暗号解読化も行われる。次に、符号化されたオーディオ８４６及び符号化されたビデオ８４８は、参照番号８４４に示されるように、クライアントデバイスにより復号され、クライアント側の生のオーディオ及びビデオデータが生成され、ディスプレイデバイス８５２上にレンダリングされる。触覚フィードバックデータ８５０は、処理／通信され、触覚効果をレンダリングすることができるコントローラデバイス８５６または他のインターフェースデバイスにて、触覚フィードバック効果が生成され得る。触覚効果の一例として、コントローラデバイス８５６の振動またはランブルが挙げられる。

ビデオゲームはユーザ入力に応答することから、ユーザ入力の送信及び処理に関しても、前述と同様の手順の流れを、クライアントデバイスからサーバへの逆方向で実行され得ることが、理解されよう。示されるように、コントローラデバイス８５６を操作するユーザは、入力データ８５８を生成し得る。この入力データ８５８は、ネットワークを介してクラウドゲームシステムに転送するために、クライアントデバイスでパケット化される。入力データパケット８６０は、クラウドゲームサーバにより解凍及び再構築されて、サーバ側で入力データ８６２が定義される。入力データ８６２は、ゲームシステム８１８に供給され、ゲームシステム８１８は、入力データ８６２を処理して、ビデオゲームのゲーム状態を更新する。

オーディオパケット８３４、ビデオパケット８３６、及び触覚フィードバックパケット８３８の転送中（参照番号８４０）、クラウドゲームストリームのサービス品質を保証するために、ネットワークを介したデータの送信が監視され得る。例えば、参照番号８６４により示されるように、アップストリーム及びダウンストリームの両方のネットワーク帯域幅を含むネットワーク状態が監視され得、ゲームストリーミングは、利用可能な帯域幅の変化に応じて調整され得る。すなわち、参考番号８６６により示されるように、ネットワークパケットの符号化及び復号は、現在のネットワーク状態に基づいて制御され得る。

図９は、情報サービスプロバイダアーキテクチャの実施形態を示す。情報サービスプロバイダ（ＩＳＰ）９７０は、ネットワーク９８６を介して、地理的に分散及び接続されたユーザ９８２に多数の情報サービスを届ける。ＩＳＰは、株価更新などのただ１つのタイプのサービス、またはブロードキャストメディア、ニュース、スポーツ、ゲーミングなどの様々なサービスを配送することができる。加えて、各々のＩＳＰによって供給されるサービスは、動的であり、すなわち、サービスがいずれかの時点で追加されてもよく、または取り除かれてもよい。従って、特定の個人に特定の種類のサービスを提供するＩＳＰは、時間の経過と共に変わり得る。例えば、ユーザが地元にいる間は、ユーザの付近のＩＳＰによりユーザはサービスを受け得、ユーザが別の街に移動した時は、異なるＩＳＰによりユーザはサービスを受け得る。地元のＩＳＰは、必要な情報及びデータを新しいＩＳＰに転送し、これにより、ユーザ情報は新しい街までユーザに「追従」し、ユーザはデータにより近くなり、アクセスしやすくなる。別の実施形態では、ユーザの情報を管理するマスタＩＳＰと、マスタＩＳＰの制御下のユーザと直接インターフェースで接続するサーバＩＳＰとの間に、マスタ－サーバ関係が確立され得る。別の実施形態では、クライアントが世界中を移動すると、あるＩＳＰから別のＩＳＰにデータが転送され、これにより、ユーザにサービスを提供するのにより良い位置に存在するＩＳＰが、これらのサービスを届けるＩＳＰとなる。

ＩＳＰ９７０には、アプリケーションサービスプロバイダ（ＡＳＰ）９７２が含まれており、これは、ネットワーク（例えば、限定されない例として、任意の有線または無線ネットワーク、ＬＡＮ、ＷＡＮ、ＷｉＦｉ（登録商標）、ブロードバンド、ケーブル、光ファイバ、衛星、セルラー（４Ｇ、５Ｇなど）、インターネットなど）を介してコンピュータベースのサービスを顧客に提供する。ＡＳＰモデルを使用して提供されるソフトウェアは、オンデマンドソフトウェアまたはソフトウエアアズアサービス（ＳａａＳ）と呼ばれることもある。特定のアプリケーションプログラム（顧客関係管理など）へのアクセスを提供する簡単な形式には、ＨＴＴＰなどの標準プロトコルが使用される。アプリケーションソフトウェアは、ベンダのシステムに常駐し、ＨＴＭＬを使用するウェブブラウザを介して、ベンダが提供する専用クライアントソフトウェアを介して、またはシンクライアントなどの他のリモートインターフェースを介して、ユーザによりアクセスされる。

広い地理的地域にわたって供給されるサービスは、多くの場合にはクラウドコンピューティングを使用する。クラウドコンピューティングとは、動的に拡張縮小可能で多くの場合仮想化されたリソースがインターネットを介したサービスとして提供される、コンピューティング様式である。ユーザは、それらをサポートする「クラウド」における技術インフラストラクチャでの専門家である必要はない。クラウドコンピューティングは、インフラストラクチャアズアサービス（ＩａａＳ）、プラットフォームアズアサービス（ＰａａＳ）、及びソフトウエアアズアサービス（ＳａａＳ）などの様々なサービスに分けられ得る。クラウドコンピューティングサービスは、多くの場合、ウェブブラウザからアクセスされる共通のビジネスアプリケーションをオンラインで提供するが、ソフトウェア及びデータは、サーバ上に格納される。クラウドという用語は、コンピュータネットワーク図におけるインターネットの描かれ方に基づいて、（例えばサーバ、ストレージ、及びロジックを使用する）インターネットの隠喩として使用され、複雑なインフラストラクチャを隠し持つことの抽象的概念である。

さらに、ＩＳＰ９７０は、ゲームクライアントがシングル及びマルチプレイヤービデオゲームをプレイするために使用するゲーム処理サーバ（ＧＰＳ）９７４を含む。インターネット上でプレイされるほとんどのビデオゲームは、ゲームサーバへの接続を介して動作する。通常、ゲームはプレイヤーからのデータを収集し、それを他のプレイヤーに配信する専用サーバアプリケーションを使用する。これは、ピアツーピア構成よりも効率的かつ効果的であるが、サーバアプリケーションをホストするために別個のサーバが必要となる。別の実施形態では、ＧＰＳは、プレイヤー及びプレイヤーのそれぞれのゲームプレイデバイスの間の通信を確立し、集中型ＧＰＳに依存せずに情報を交換する。

専用ＧＰＳは、クライアントとは独立して実行されるサーバである。このようなサーバは、通常、データセンタに配置された専用ハードウェア上で稼働し、より多くの帯域幅及び専用処理能力を提供する。専用サーバは、大部分のＰＣベースのマルチプレイヤーゲームのためのゲームサーバをホスティングするのに好ましい方法である。大規模なマルチプレイヤーオンラインゲームは、通常ゲームタイトルを所有するソフトウェア会社によってホスティングされた専用サーバ上で実行されて、その専用サーバがコンテンツを管理及び更新することを可能にする。

放送処理サーバ（ＢＰＳ）９７６は、視聴者にオーディオまたはビデオ信号を配信する。非常に狭い範囲の視聴者への放送は、ナローキャスティングと呼ばれることもある。放送配信の最終工程は、信号が聴取者または視聴者にどのように達するかであり、信号は、ラジオ局またはテレビ局と同様にアンテナ及び受信機に地上波で到来し得るか、または局を介してケーブルテレビもしくはケーブルラジオ（もしくは「無線ケーブル」）を通じて到来し得るか、またはネットワークから直接到来し得る。インターネットはまた、特に、信号及び帯域幅を共有できるマルチキャストを使用して、ラジオまたはテレビのいずれかを受信者に届け得る。歴史的に、放送は、全国放送または地域放送などの地理的領域により範囲が定められてきた。しかしながら、高速インターネットの普及に伴い、コンテンツは世界のほぼ全ての国に到達可能であるため、放送は地域によって定められない。

ストレージサービスプロバイダ（ＳＳＰ）９７８は、コンピュータストレージ空間及び関連する管理サービスを提供する。ＳＳＰは定期的なバックアップ及びアーカイビングも提供する。ストレージをサービスとして提供することにより、ユーザは必要に応じてより多くのストレージを注文することができる。別の大きな利点として、ＳＳＰはバックアップサービスを含み、コンピュータのハードドライブに障害が発生しても、ユーザがユーザの全てのデータを失うことはない。さらに、複数のＳＳＰは、ユーザデータの全体的または部分的なコピーを有することができ、これにより、ユーザの位置またはデータアクセスに使用されるデバイスとは無関係に、ユーザは効率的な方法でデータにアクセスすることが可能となる。例えば、ユーザは、自宅のコンピュータ、並びに移動中には携帯電話の中の、個人ファイルにアクセスすることができる。

通信プロバイダ９８０は、ユーザに接続性を提供する。通信プロバイダの一種として、インターネットへのアクセスを提供するインターネットサービスプロバイダ（ＩＳＰ）が挙げられる。ＩＳＰは、ダイヤルアップ、ＤＳＬ、ケーブルモデム、ファイバ、無線、または専用の高速相互接続など、インターネットプロトコルデータグラムの提供に好適なデータ伝送技術を使用して、顧客を接続する。通信プロバイダは、電子メール、インスタントメッセージ、及びＳＭＳテキストなどのメッセージサービスも提供し得る。通信プロバイダの別の種類として、インターネットへの直接のバックボーンアクセスを提供することにより帯域幅またはネットワークアクセスを販売するネットワークサービスプロバイダ（ＮＳＰ）が挙げられる。ネットワークサービスプロバイダは、電気通信会社、データキャリア、無線通信プロバイダ、インターネットサービスプロバイダ、高速インターネットアクセスを提供するケーブルテレビ事業者などから構成され得る。

データ交換９８８は、ＩＳＰ９７０内のいくつかのモジュールを相互接続し、ネットワーク９８６を介してこれらのモジュールをユーザ９８２に接続する。データ交換９８８は、ＩＳＰ９７０の全てのモジュールが近接している小さな領域をカバーすることができ、または異なるモジュールが地理的に分散している場合に大きな地理的領域をカバーすることができる。例えば、データ交換９８８は、データセンタのキャビネット内に高速ギガビットイーサネット（登録商標）（またはより高速）、または大陸間仮想エリアネットワーク（ＶＬＡＮ）を含むことができる。

ユーザ９８２は、少なくともＣＰＵ、メモリ、ディスプレイ、及びＩ／Ｏを含むクライアントデバイス９８４により、リモートサービスにアクセスする。クライアントデバイスは、ＰＣ、携帯電話、ネットブック、タブレット、ゲームシステム、ＰＤＡなどであり得る。一実施形態では、ＩＳＰ９７０は、クライアントが使用するデバイスの種類を認識し、採用する通信方法を調整する。他の場合では、クライアントデバイスは、ＨＴＭＬなどの標準的な通信方法を使用して、ＩＳＰ９７０にアクセスする。

本開示の実施形態は、ハンドヘルドデバイス、マイクロプロセッサシステム、マイクロプロセッサベースまたはプログラム可能な家庭用電化製品、ミニコンピュータ、メインフレームコンピュータなどを含む様々なコンピュータシステム構成で実施し得る。本開示はまた、有線ベースネットワークまたは無線ネットワークを介してリンクされたリモート処理デバイスによりタスクが行われる分散型コンピューティング環境においても、実施することができる。

いくつかの実施形態では、通信は、無線技術を使用して促進され得る。このような技術には、例えば、５Ｇ無線通信技術が含まれ得る。５Ｇは、セルラーネットワーク技術の第５世代である。５Ｇネットワークはデジタルセルラーネットワークであり、プロバイダがカバーするサービスエリアはセルと呼ばれる小さな地理的エリアに分割されている。サウンドと画像を表すアナログ信号は、電話でデジタル化され、アナログ－デジタルコンバータによって変換され、ビットのストリームとして送信される。セル内の全ての５Ｇ無線デバイスは、他のセルで再利用される周波数のプールからトランシーバ（送信機及び受信機）によって割り当てられた周波数チャネルを介して、セル内のローカルアンテナアレイ及び低電力自動トランシーバと電波で通信する。ローカルアンテナは、高帯域幅光ファイバまたは無線バックホール接続によって、電話網及びインターネットに接続される。他のセルネットワークと同様に、あるセルから別のセルに移動するモバイルデバイスは、新しいセルに自動的に転送される。５Ｇネットワークは単なる一例のタイプの通信ネットワークであり、本開示の実施形態は、５Ｇに続く後の世代の有線または無線技術と同様に、前世代の無線または有線通信を利用することができることを理解されたい。

上記の実施形態を考慮して、本開示は、コンピュータシステムに記憶されたデータを必要とする様々なコンピュータ実行動作を使用できることを理解されたい。これらの動作は、物理量の物理的操作を要する動作である。本開示の一部を形成する本明細書で説明される動作のいずれも、有用なマシン動作である。本開示はまた、これらの動作を実行するためのデバイスまたは装置に関する。装置は、必要な目的のために特別に構築され得る、または装置は、コンピュータに格納されたコンピュータプログラムにより選択的に有効化または構成される汎用コンピュータであり得る。具体的には、本明細書の教示に従って書かれたコンピュータプログラムと共に様々な汎用マシンを使用することができる、あるいは、必要な動作を実行するためにさらに特化した装置を構築するほうがより好都合である場合もある。

本開示はまた、コンピュータ可読媒体上のコンピュータ可読コードとしても具現化することができる。あるいは、コンピュータ可読コードは、前述のデータ交換相互接続を使用して、サーバからダウンロードされ得る。コンピュータ可読媒体は、後でコンピュータシステムにより読み出され得るデータを格納できる任意のデータストレージデバイスである。コンピュータ可読媒体の例には、ハードドライブ、ネットクワーク接続ストレージ（ＮＡＳ）、読み出し専用メモリ、ランダムアクセスメモリ、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、ＣＤ－ＲＷ、磁気テープ、並びに他の光学及び非光学データストレージデバイスが含まれる。コンピュータ可読媒体には、コンピュータ可読コードが分散方式で記憶され実行されるように、ネットワーク接続されたコンピュータシステムにわたり分散されたコンピュータ可読有形媒体が含まれ得る。

方法動作は特定の順序で説明されたが、オーバーレイ動作の処理が所望の方法で実行される限り、動作間に他の維持管理動作が実行されてもよく、または動作がわずかに異なる時間に起こるように調整されてもよく、またはシステム内に動作を分散することで、処理に関連する様々な間隔で処理動作が起こることを可能にしてもよいことを、理解すべきである。

前述の開示は、理解を明確にするためにある程度詳細に説明されたが、添付の特許請求の範囲内で特定の変更及び修正を実施できることは明らかであろう。したがって、本実施形態は、限定ではなく例示としてみなされるべきであり、本開示は、本明細書で提供される詳細に限定されるべきではなく、説明される実施形態の範囲内及び均等物内で変更されてもよい。

Claims (20)

1. クラウドゲーム機によってビデオゲームを実行することであって、前記ビデオゲームの前記実行は、ゲームプレイビデオをレンダリングすることを含む、前記実行することと、
   ネットワークを介してクライアントデバイスにストリーミングするために、ストリーミングサーバによって前記ゲームプレイビデオを処理することと、
   前記ストリーミングサーバと前記クライアントデバイスとの間の前記ネットワークを介した接続品質を監視することと、
   前記ストリーミングサーバと前記クライアントデバイスとの間の前記接続品質の変化を検出したことに応じて、前記クラウドゲーム機によって前記ゲームプレイビデオの前記レンダリングを調整することと、
   を含む、方法。
2. 前記ストリーミングサーバによって前記ゲームプレイビデオを処理することが、前記ゲームプレイビデオを圧縮されたビデオフォーマットで符号化することを含む、請求項１に記載の方法。
3. 接続品質を監視することが、帯域幅またはレイテンシのうちの１つ以上を監視することを含む、請求項１に記載の方法。
4. 接続品質を監視することが、前記ゲームプレイビデオの前記ストリーミング中に発生するパケット損失を監視することを含む、請求項１に記載の方法。
5. 前記クラウドゲーム機によって前記ゲームプレイビデオの前記レンダリングを調整することが、前記ゲームプレイビデオのフレームレートまたは解像度を調整することを含む、請求項１に記載の方法。
6. 前記クラウドゲーム機によって前記ゲームプレイビデオの前記レンダリングを調整することが、前記ゲームプレイビデオの前記レンダリングの詳細レベルを調整することを含む、請求項１に記載の方法。
7. 前記クラウドゲーム機によって前記ゲームプレイビデオの前記レンダリングを調整することが、前記ゲームプレイビデオに含めるためのコンテンツの量を調整することを含む、請求項１に記載の方法。
8. 前記接続品質の前記変化は、前記接続品質の低下によって定義され、
   前記クラウドゲーム機によって前記ゲームプレイビデオの前記レンダリングを調整することは、前記ネットワークを介した前記ゲームプレイビデオの前記ストリーミングのビットレートを低減するように構成されている、
   請求項１に記載の方法。
9. 前記接続品質の前記変化は、前記接続品質の改善によって定義され、
   前記クラウドゲーム機によって前記ゲームプレイビデオの前記レンダリングを調整することは、前記ネットワークを介した前記ゲームプレイビデオの前記ストリーミングのビットレートを増加するように構成されている、
   請求項１に記載の方法。
10. 前記接続品質の前記変化を検出することは、前記ストリーミングサーバから前記クラウドゲーム機へのメッセージの送信をトリガーし、前記クラウドゲーム機によって前記ゲームプレイビデオの前記レンダリングを前記調整することは、前記メッセージに応じるものである、請求項１に記載の方法。
11. クラウドゲーム機によってビデオゲームを実行することであって、前記ビデオゲームの前記実行は、ゲームプレイビデオをレンダリングすることを含む、前記実行することと、
    ネットワークを介してクライアントデバイスにストリーミングするためにストリーミングサーバによって前記ゲームプレイビデオを処理することであって、前記ストリーミングサーバによって前記ゲームプレイビデオを処理することは、圧縮されたビデオフォーマットで前記ゲームプレイビデオを符号化することを含む、前記処理することと、
    前記ストリーミングサーバと前記クライアントデバイスとの間の前記ネットワークを介した接続品質を監視することであって、接続品質を監視することは、前記ゲームプレイビデオの前記ストリーミング中に発生するパケット損失を監視することを含む、前記監視することと、
    前記ストリーミングサーバと前記クライアントデバイスとの間の前記接続品質の変化を検出したことに応じて、前記クラウドゲーム機によって前記ゲームプレイビデオの前記レンダリングを調整することであって、前記クラウドゲーム機によって前記ゲームプレイビデオの前記レンダリングを調整することは、前記ゲームプレイビデオのフレームレートまたは解像度を調整することを含む、前記調整することと、
    を含む、方法。
12. 前記クラウドゲーム機によって前記ゲームプレイビデオの前記レンダリングを調整することが、前記ゲームプレイビデオの前記レンダリングの詳細レベルを調整することを含む、請求項１１に記載の方法。
13. 前記接続品質の前記変化は、前記接続品質の低下によって定義され、
    前記クラウドゲーム機によって前記ゲームプレイビデオの前記レンダリングを調整することは、前記ネットワークを介した前記ゲームプレイビデオの前記ストリーミングのビットレートを低減するように構成されている、
    請求項１１に記載の方法。
14. 前記接続品質の前記変化は、前記接続品質の改善によって定義され、
    前記クラウドゲーム機によって前記ゲームプレイビデオの前記レンダリングを調整することは、前記ネットワークを介した前記ゲームプレイビデオの前記ストリーミングのビットレートを増加するように構成されている、
    請求項１１に記載の方法。
15. 前記接続品質の前記変化を検出することは、前記ストリーミングサーバから前記クラウドゲーム機へのメッセージの送信をトリガーし、前記クラウドゲーム機によって前記ゲームプレイビデオの前記レンダリングを前記調整することは、前記メッセージに応じるものである、請求項１１に記載の方法。
16. ビデオゲームを実行するクラウドゲーム機であって、前記ビデオゲームの前記実行は、ゲームプレイビデオをレンダリングすることを含む、前記クラウドゲーム機と、
    ネットワークを介してクライアントデバイスにストリーミングするために前記ゲームプレイビデオを処理するストリーミングサーバであって、前記ストリーミングサーバと前記クライアントデバイスとの間の前記ネットワークを介した接続品質を監視する、前記ストリーミングサーバと、
    を含み、
    前記ストリーミングサーバと前記クライアントデバイスとの間の前記接続品質の変化を検出したことに応じて、前記ゲームプレイビデオの前記レンダリングは前記クラウドゲーム機によって調整される、
    システム。
17. 前記ストリーミングサーバによって前記ゲームプレイビデオを処理することが、前記ゲームプレイビデオを圧縮されたビデオフォーマットで符号化することを含む、請求項１６に記載のシステム。
18. 接続品質を監視することが、帯域幅またはレイテンシのうちの１つ以上を監視することを含む、請求項１６に記載のシステム。
19. 接続品質を監視することが、前記ゲームプレイビデオの前記ストリーミング中に発生するパケット損失を監視することを含む、請求項１６に記載のシステム。
20. 前記クラウドゲーム機によって前記ゲームプレイビデオの前記レンダリングを調整することが、前記ゲームプレイビデオのフレームレートまたは解像度を調整することを含む、請求項１６に記載のシステム。

Images