(57)【特許請求の範囲】
【請求項１】
複数の画面を描画し、該複数の画面に含まれる描画オブジェクトの少なくとも一部が該複数の画面間で共通である描画装置であって、
前記共通の描画オブジェクトを、描画属性が固定の第１の描画オブジェクトと描画属性が変更可能な第２の描画オブジェクトとに識別する識別手段と、
前記第１の描画オブジェクトについての描画処理を前記複数の画面についてまとめて行う第１の描画手段と、
前記第２の描画オブジェクトについての描画処理を前記複数の画面の各々について行う第２の描画手段と、
前記第１の描画手段及び前記第２の描画手段により描画処理が行われた後、描画された前記複数の画面のそれぞれを、接続された各々異なる装置に送信する送信手段と、
を有する描画装置。
【請求項２】
前記第２の描画手段は、前記第１の描画手段による描画処理が行われた後に描画処理を行う請求項１に記載の描画装置。
【請求項３】
前記第２の描画手段は、前記第１の描画手段による描画結果を複製し、前記複数の画面の各々について行った描画結果を該複製した描画結果に反映させる請求項２に記載の描画装置。
【請求項４】
前記第１の描画手段による描画処理と前記第２の描画手段による描画処理は並行して行われる請求項１に記載の描画装置。
【請求項５】
前記第１の描画手段は、描画処理において同一の演算結果を、前記複数の画面の各々についての描画結果として出力し、
前記第２の描画手段は、描画処理において前記複数の画面の各々について異なる演算結果を、前記複数の画面の各々についての描画結果に反映する請求項１、２及び４のいずれか１項に記載の描画装置。
【請求項６】
前記第２の描画手段は、前記第２の描画オブジェクトのうち、描画属性が共通する描画オブジェクトの描画処理は共通して行う請求項１乃至５のいずれか１項に記載の描画装置。
【請求項７】
前記第２の描画手段は、前記第１の描画手段による描画結果の少なくとも一部を変更する描画処理を含む請求項１乃至６のいずれか１項に記載の描画装置。
【請求項８】
前記複数の画面は、それぞれ異なる外部機器に接続された表示装置に表示される画面であり、
前記描画装置は、前記外部機器の各々について、前記第２の描画オブジェクトの描画属性の情報を取得する取得手段をさらに有し、
前記第２の描画手段は、前記第２の描画オブジェクトの描画属性の情報に基づいて、前記複数の画面の各々についての描画処理を行う請求項１乃至７のいずれか１項に記載の描画装置。
【請求項９】
前記第２の描画オブジェクトの変更可能な描画属性は、前記第２の描画手段による描画結果において前記第２の描画オブジェクトに対応する画素値を変更し得る属性である請求項１乃至８のいずれか１項に記載の描画装置。
【請求項１０】
前記第２の描画オブジェクトの変更可能な描画属性は、適用するテクスチャ及び影響を考慮する照明の少なくともいずれかを含む請求項１乃至９のいずれか１項に記載の描画装置。
【請求項１１】
前記複数の画面は、同一の視点について描画される画面である請求項１乃至１０のいずれか１項に記載の描画装置。
【請求項１２】
複数の画面を描画し、該複数の画面に含まれる描画オブジェクトの少なくとも一部が該複数の画面間で共通である描画方法であって、
前記共通の描画オブジェクトを、描画属性が固定の第１の描画オブジェクトと描画属性が変更可能な第２の描画オブジェクトとに識別し、
前記第１の描画オブジェクトについての描画処理を前記複数の画面についてまとめて行い、
前記第２の描画オブジェクトについての描画処理を前記複数の画面の各々について行い、
前記第１の描画オブジェクトについての描画処理と前記第２の描画オブジェクトについての描画処理を行った後、描画された前記複数の画面のそれぞれを、接続された各々異なる装置に送信する描画方法。
【請求項１３】
複数の画面を描画し、該複数の画面に含まれる描画オブジェクトの少なくとも一部が該複数の画面間で共通する１以上の描画機能を有するコンピュータを含む１以上のコンピュータを、請求項１乃至１１のいずれか１項に記載の描画装置の各手段として機能させるためのプログラム。
【請求項１４】
請求項１３に記載のプログラムを記録したコンピュータが読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して画像処理に関し、特に複数ユーザに鑑賞可能な画像をカスタマイズする方法及び装置に関する。
【背景技術】
【０００２】
ビデオゲーム産業は、スタンドアロン型アーケードゲームの導入から、家庭用コンピュータゲーム、専門コンソール用に作られたゲームの出現まで、目覚ましい発展が見受けられる。そして、インターネットの広範な一般利用は、所謂「クラウドゲーミング」等の他の主要な発展を導いた。クラウド型ゲーミングシステムでは、プレイヤはインターネットを介してビデオゲームサーバに接続するスマートフォンやタブレットのような、一般的なインターネット対応電子機器を使用することが可能である。ビデオゲームサーバは、プレイヤについてセッションを開始し、複数のプレイヤについてそのようにしてもよい。ビデオゲームサーバは、プレイヤ行動（例えば移動、選択）及びゲームについての他の属性に基づいて、プレイヤについての映像データの描画、及び音声の生成を行う。符号化された映像及び音声は、インターネットを介してプレイヤの装置に配信され、視聴可能な画像及び音声として再生される。このようにして、世界中のあらゆる場所のプレイヤは、専用のビデオゲームコンソール、ソフト、描画処理ハードウェアを使用せずに、ビデオゲームをプレイすることができる。
【０００３】
マルチプレイヤ用ビデオゲームに係るグラフィックスを生成する際、同一の画像が複数のプレイヤに重複される場合、描画、処理または帯域リソースのような特定のリソースを共有することが可能である。一方で、ゲーム体験をより明るくかつ楽しく認識させるために、シーン内のオブジェクトの描画表現は、同一のシーンを共有している場合であっても、様々なプレイヤにカスタマイズされる必要がある。リソース共有の必要性と及びカスタマイズの必要性は互いに反するものであるため、双方を実現する解決策が業界で望まれる。
【発明の概要】
【０００４】
本発明はこのような従来技術の課題に鑑みてなされたものである。本発明は、ステートセーブデータを容易に他の機器に提供可能なゲームシステム、ゲーム装置、制御方法、プログラム及び記録媒体を提供する。
【０００５】
本発明の第１の態様は、複数の画面を描画し、該複数の画面に含まれる描画オブジェクトの少なくとも一部が該複数の画面間で共通である描画装置であって、共通の描画オブジェクトを、描画属性が固定の第１の描画オブジェクトと描画属性が変更可能な第２の描画オブジェクトとに識別する識別手段と、第１の描画オブジェクトについての描画処理を複数の画面についてまとめて行う第１の描画手段と、第２の描画オブジェクトについての描画処理を複数の画面の各々について行う第２の描画手段と、を有する描画装置を提供する。
【０００６】
本発明の第２の態様は、複数の画面を描画し、該複数の画面に含まれる描画オブジェクトの少なくとも一部が該句数の画面間で共通である描画方法であって、共通の描画オブジェクトを、描画属性が固定の第１の描画オブジェクトと描画属性が変更可能な第２の描画オブジェクトとに識別し、第１の描画オブジェクトについての描画処理を複数の画面についてまとめて行い、第２の描画オブジェクトについての描画処理を複数の画面の各々について行う描画方法を提供する。
【０００７】
さらに、本発明の特徴は、（添付の図面を参照して）以下の例示的な実施形態の記載により明らかになるだろう。
【図面の簡単な説明】
【０００８】
【図１Ａ】本発明の非限定的な実施形態に係る、サーバシステムを含むクラウド型ビデオゲームシステムアーキテクチャのブロック図
【図１Ｂ】本発明の非限定的な実施形態に係る、ゲームプレイ中におけるデータネットワークを介したクライアント装置のセットとのインタラクションを示した、図１Ａのクラウド型ビデオゲームシステムアーキテクチャのブロック図
【図２Ａ】本発明の非限定的な実施形態に係る、図１Ｂのアーキテクチャの様々な物理的構成要素を示したブロック図
【図２Ｂ】図２Ａの変形例
【図２Ｃ】図２Ａ及び２Ｂの物理的構成要素により実現され得、かつゲームプレイ中に動作しうる、図１Ｂのアーキテクチャにおけるサーバシステムの様々な機能モジュールを示したブロック図
【図３Ａ】、
【図３Ｂ】、
【図３Ｃ】本発明の非限定的な実施形態に係る、ビデオゲームの実行中に行われる処理セットの実行を示したフローチャート
【図４Ａ】、
【図４Ｂ】本発明の非限定的な実施形態に係る、受信した映像及び音声の各々を処理するためのクライアント装置の動作を示したフローチャート
【図５】本発明の非限定的な実施形態に係る、一般オブジェクト及びカスタマイズ可能オブジェクトを含む、複数ユーザの画面描画範囲内のオブジェクトを示した図
【図６Ａ】本発明の非限定的な実施形態に係るオブジェクトデータベースを概念的に示した図
【図６Ｂ】本発明の非限定的な実施形態に係るテクスチャデータベースを概念的に示した図。
【図７】グラフィックスパイプラインを概念的に示した図
【図８】本発明の非限定的な実施形態に係る、グラフィックスパイプラインの画素処理サブプロセスの工程を例示したフローチャート
【図９】本発明の非限定的な実施形態に係る、描画されるオブジェクトが一般オブジェクトである場合の画素処理サブプロセスの更なる詳細を例示したフローチャート
【図１０Ａ】、
【図１０Ｂ】本発明の非限定的な実施形態に係る、描画されるオブジェクトがカスタマイズ可能オブジェクトである場合の画素処理サブプロセスの、第１パス及び第２パスの各々の更なる詳細を示したフローチャート
【図１１】本発明の非限定的な実施形態に係る、複数ユーザのフレームバッファ内のオブジェクトを示した図
【図１２】本発明の非限定的な実施形態に係る、２人の参加者についてのフレームバッファ時間を越える発展を概念的に示した図
【発明を実施するための形態】
【０００９】
《１．クラウドゲーミングアーキテクチャ》
図１Ａは、本発明の非限定的な実施形態に係るクラウド型ビデオゲームシステムアーキテクチャを概略的に示している。該アーキテクチャは、インターネット１３０等のデータネットワークを介してサーバシステム１００に接続されたクライアント装置１２０、１２０Ａを含みうる。２つのクライアント装置１２０、１２０Ａのみが示されているが、クラウド型ビデオゲームシステムアーキテクチャ内のクライアント装置の数は特に限定されるものではないことは理解されるべきである。
【００１０】
クライアント装置１２０、１２０Ａの構成は、特に限定されるものではない。いくつかの実施形態において、１以上のクライアント装置１２０、１２０Ａは、例えばパーソナルコンピュータ（ＰＣ）、家庭用ゲーム機（ＸＢＯＸ（登録商標）、ＰＳ３（登録商標）、Ｗｉｉ（登録商標）等のコンソール）、携帯ゲーム機、スマートテレビ、セットトップボックス（ＳＴＢ）等であってもよい。他の実施形態において、１以上のクライアント装置１２０、１２０Ａは、携帯電話、電子手帳（ＰＤＡ）、タブレットのような通信または計算装置であってもよい。
【００１１】
クライアント装置１２０、１２０Ａの各々は、各々のローカルアクセスネットワーク（不図示）を介することを含む、あらゆる好適な方式でインターネット１３０に接続していてもよい。また、サーバシステム１００は、ローカルアクセスネットワーク（不図示）を介してインターネット１３０に接続してもよいが、サーバシステム１００はローカルアクセスネットワークの媒介なく、インターネット１３０と直接接続してよい。サーバシステム１００と１以上のクライアント装置１２０、１２０Ａとの接続は、１以上のチャネルを含んでいてもよい。これらのチャネルは、物理的及び／または論理的リンクによりなされ、無線周波数、光ファイバ、光空間（free-space optical）、同軸ケーブル、及びツイストペアを含む様々な物理的媒体を回遊してもよい。チャネルはＵＤＰやＴＣＰ／ＩＰのようなプロトコルに従ってもよい。また、１以上のチャネルが、仮想プライベートネットワーク（ＶＰＮ）でサポートされていてもよい。いくつかの実施形態では、１以上の接続はセッションベースでなされてもよい。
【００１２】
サーバシステム１００は、クライアント装置１２０、１２０Ａのユーザが、ビデオゲームを個々に（即ち、シングルプレイヤ用ビデオゲーム）または集団で（即ち、マルチプレイヤ用ビデオゲーム）プレイすることを可能であってもよい。またサーバシステム１００は、他のプレイヤによりプレイされるゲームを観戦することを、クライアント装置１２０、１２０Ａのユーザに可能にさせてもよい。ビデオゲームの非限定的な例は、レジャー、教育及び／またはスポーツについてプレイされるゲームを含みうる。しかし、ビデオゲームは貨幣損益の可能性を参加者に提示する必要はない。
【００１３】
またサーバシステム１００は、ビデオゲームをテストする、及び／またはサーバシステム１００を管理することをクライアント装置１２０、１２０Ａのユーザに可能にさせてもよい。
【００１４】
サーバシステム１００は、場合によっては１以上のゲームサーバを含む１以上の演算リソースを含んでもよいし、場合によっては参加者データベース１０を含む１以上のデータベースを有するあるいは該データベースにアクセスするものであってもよい。参加者データベース１０は、識別データ、財務データ、位置データ、人口統計データ、接続データ等のような、様々な参加者及びクライアント装置１２０、１２０Ａについてのアカウント情報を格納しうる。ゲームサーバは、共通のハードウェア内に統合される、あるいは場合によってはインターネット１３０を介することを含む通信リンクを介して接続される異なるサーバ群であってもよい。同様に、データベースはサーバシステム１００内に統合される、あるいは場合によってはインターネット１３０を介する通信リンクを介してサーバシステム１００に接続されるものであってもよい。
【００１５】
サーバシステム１００は、ゲームプレイより前等、ゲーム環境外のクライアント装置１２０、１２０Ａとのインタラクションを扱うための管理アプリケーションを実装してもよい。例えば、該管理アプリケーションは、ユーザクラス（「プレイヤ」、「観戦者」、「管理者」または「テスター」等）に属する１つのクライアント装置１２０、１２０Ａのユーザを登録し、インターネットを介してユーザの接続性が追跡され、ゲームのインスタンスを開始する、参加する、終了する、または終了させるために、非限定的ないくつかの機能のうちのユーザコマンドに応答する。該目的の達成のため、管理アプリケーションは参加者データベース１０にアクセスする必要があってもよい。
【００１６】
管理アプリケーションは、非限定的な２〜３の可能性を挙げると、「プレイヤ」、「観戦者」、「管理者」及び「テスター」を含む異なるユーザクラスのユーザと、異なるインタラクションをしてもよい。
【００１７】
故に、一例において管理アプリケーションは、参加者データベース１０へのアカウントの設定及びプレイするビデオゲームの選択をプレイヤ（即ち「プレイヤ」ユーザクラスのユーザ）が可能なように、プレイヤとのインタフェースとして機能しうる。該選択に従い、管理アプリケーションはサーバ側ビデオゲームアプリケーションを起動しうる。サーバ側ビデオゲームアプリケーションは、仮想世界内のキャラクタ、アバター、レースカー、コックピット等の制御をプレイヤに可能ならしめる、プレイヤについての機能モジュールセットを実行するコンピュータ読み取り可能な命令により定義されうる。マルチプレイヤ用ビデオゲームの場合、仮想世界は２以上のプレイヤにより共有され得、１人のプレイヤのゲームプレイが他のプレイヤに影響を及ぼし得る。
【００１８】
他の例では管理アプリケーションは、参加者データベース１０へのアカウントの設定、及びユーザが観戦を所望する進行中のビデオゲームのリストからのビデオゲームの選択を観戦者（即ち「観戦者」ユーザクラスのユーザ）に可能ならしめる、観戦者とのインタフェースとして機能しうる。該選択に従い、管理アプリケーションは、観戦者が他のユーザのゲームプレイを観賞できるが該ゲーム内のアクティブキャラクタの制御はできないように、該観戦者についての機能モジュールセットを起動しうる（別段の指示がない限り、「参加者」との文言が使用された場合、「プレイヤ」ユーザクラスと「観戦者」ユーザクラスの両方に等しく適用されることを意味する）。
【００１９】
更なる例において、管理アプリケーションは、ゲームサーバアプリケーションの様々な機能の変更、更新の実行、及びプレイヤ／管理者アカウントの管理を管理者（即ち「管理者」ユーザクラス）が可能なように、管理者とのインタフェースとして機能しうる。
【００２０】
さらに別の例では、ゲームサーバアプリケーションは、テスト用のビデオゲームの選択をテスター（即ち「テスター」ユーザクラスのユーザ）が可能なように、テスターとのインタフェースとして機能しうる。該選択に従い、ゲームサーバアプリケーションは、ビデオゲームのテストをテスターに可能ならしめる、テスター用の機能モジュールセットを起動しうる。
【００２１】
図１Ｂは、「プレイヤ」または「観戦者」ユーザクラスのユーザについての、ゲームプレイ中におけるクライアント装置１２０、１２０Ａとサーバシステム１００との間に生じるインタラクションを示している。
【００２２】
いくつかの非限定的な実施形態において、サーバ側ビデオゲームアプリケーションは、クライアント装置１２０、１２０Ａのようなクライアント装置において実行中のコンピュータ読み取り可能な命令セットにより定義されうるクライアント側ビデオゲームアプリケーションと協働してもよい。クライアント側ビデオゲームアプリケーションの使用は、ゲームをプレイまたは観戦するため及びゲーム機能にアクセスするために、参加者用にカスタマイズされたインタフェースを提供してもよい。他の非限定的な実施形態において、クライアント装置は、該クライアント装置により直接的に実行可能なクライアント側ビデオゲームアプリケーションを特徴づけるものではない。むしろ、Ｗｅｂブラウザがクライアント装置の視点（perspective）からのインタフェースとして使用されてもよい。該Ｗｅｂブラウザは、サーバ側ビデオゲームアプリケーションとのインタラクションを最適化するように、自身のソフトウェア環境におけるクライアント側ビデオゲームアプリケーションのインスタンスを自身で作成してもよい。
【００２３】
クライアント装置１２０、１２０Ａのうちの任意の１つは、該任意のクライアント装置のユーザが入力を提供し、ビデオゲームに参加することを可能ならしめるために、１以上の入力装置（タッチスクリーン、キーボード、ゲームコントローラ、ジョイスティック等）が備えられていてもよいことは理解されるべきである。他の実施形態において、ユーザは身体動作を行う、外部オブジェクトを振る等してもよく、これらの動作はカメラや他のセンサ（例えばＫｉｎｅｃｔ（登録商標））により検出され、該任意のクライアント装置で動作するソフトウェアは、ユーザが該任意のクライアント装置に対して入力を提供しようとしているか、もしそうであれば該入力の本質を正確に推測することを試みる。任意のクライアント装置において（独立にまたはブラウザ内で）実行されるクライアント側ビデオゲームアプリケーションは、受信したユーザ入力及び検出されたユーザ動作を、インターネット１３０を介してサーバシステム１００に送信されうる「クライアント装置入力」に変換しうる。
【００２４】
図１Ｂに示されている実施形態では、クライアント装置１２０はクライアント装置入力１４０を生成し、クライアント装置１２０Ａはクライアント装置入力１４０Ａを生成してもよい。サーバシステム１００は、様々なクライアント装置１２０、１２０Ａから受信したクライアント装置入力１４０、１４０Ａを処理し、該様々なクライアント装置１２０、１２０Ａについての「メディア出力」１５０、１５０Ａをそれぞれ生成しうる。メディア出力１５０、１５０Ａは、（スクリーン上に表示された場合に画像を示す）符号化された映像コンテンツのストリーム及び（スピーカを介して再生された場合に音を示す）音声を含みうる。メディア出力１５０、１５０Ａは、パケットの形でインターネット１３０を介して送信されうる。クライアント装置１２０、１２０Ａの特定の１つに向けられたパケットは、インターネット１３０を介して該装置にルートされるように、このような方法でアドレスされうる。クライアント装置１２０、１２０Ａの各々は、サーバシステム１００から受信したパケット内のメディア出力をバッファして処理する電気回路、画像を表示するためのディスプレイ、及び音声を出力する振動子（例えばスピーカ）を含んでいてもよい。また、追加の出力装置は、動作を誘導するための電気機械システム等を提供してもよい。
【００２５】
映像データのストリームは、「フレーム」に分割されうることは理解されるべきである。ここでは、「フレーム」との文言は映像データのフレームと該映像データによりあらわされる画像との間の１対１対応の存在を要求するものではない。即ち、映像データの１つのフレームについて、表示される各画像の全体を示すデータを含めることも可能であるし、映像データの１つのフレームについて、画像の一部のみを示すデータを含めること、及び適切に再構成されて表示されるために、画像についてさらに２以上のフレームを要求することも可能である。同様に、映像データの１つのフレームは、Ｍ＜ＮであるＮ個の画像が映像データのＭ個のフレームを用いて示される等、１以上の完全な画像を示すデータを含んでいてもよい。
【００２６】
《２．サーバシステム１００（分散型アーキテクチャ）》
図２Ａは、サーバシステム１００の構成要素の非限定的な物理的構成の第１の態様を示している。本実施形態では、サーバシステム１００の個々のサーバが、専用の機能を実行するよう構成されうる。例えば、計算サーバ２００Ｃは、ユーザ入力に基づいてビデオゲーム内の状態変化の追跡についての役割を担い、描画サーバ２００Ｒは、グラフィック（映像データ）の描画についての役割を担い得る。
【００２７】
以下に記載される実施形態の例のために、クライアント装置１２０及びクライアント装置１２０Ａの両方は、プレイヤまたは参加者としてビデオゲームに参加しているものとする。しかしながら、いくつかのケースでは１人のプレイヤと観戦者なし、複数のプレイヤと１人の観戦者、１人のプレイヤと複数の観戦者、及び複数のプレイヤと複数の観戦者等で構成されてもよいことは理解されるべきである。
【００２８】
簡単のため、以下の説明では単一の描画サーバ２００Ｒに単一の計算サーバ２００Ｃが接続されているものとする。しかしながら、１以上の描画サーバ２００Ｒが同一の計算サーバ２００Ｃに接続される、あるいは１以上の計算サーバ２００Ｃが同一の描画サーバ２００Ｒに接続されるものであってもよいことは理解されるべきである。複数の描画サーバ２００Ｒが存在する場合、あらゆる適切な地理的領域に分散されるものであってもよい。
【００２９】
図２Ａの構成要素の非限定的な物理的構成に示されるように、計算サーバ２００Ｃは１以上の中央演算装置（ＣＰＵ）２２０Ｃ、２２２Ｃ及びランダムアクセスメモリ（ＲＡＭ）２３０Ｃを有していてもよい。ＣＰＵ２２０Ｃ、２２２Ｃは、例えば通信バスアーキテクチャを介してＲＡＭ２３０Ｃにアクセス可能である。２つのＣＰＵ２２０Ｃ、２２２Ｃのみが示されているが、計算サーバ２００Ｃのいくつかの実装例では、より多数のＣＰＵあるいは単一のＣＰＵのみが提供されてもよい。また、計算サーバ２００Ｃは、ビデオゲームに参加しているクライアント装置の各々から、インターネット１３０を介してクライアント装置入力を受信する、ネットワークインタフェース要素（ＮＩＣ）２１０Ｃ２を有していてもよい。以下に記載される実施形態の例では、クライアント装置１２０及び１２０Ａの両方は、ビデオゲームに参加しているものとし、従って、受信したクライアント装置入力はクライアント装置入力１４０及びクライアント装置入力１４０Ａが含まれうる。
【００３０】
さらに計算サーバ２００Ｃは、描画命令セット２０４を出力する他のネットワークインタフェース要素（ＮＩＣ）２１０Ｃ１を有していてもよい。ＮＩＣ２１０Ｃ１を介して計算サーバ２００Ｃから出力された描画命令セット２０４は、描画サーバ２００Ｒに送信されうる。一実施形態において計算サーバ２００Ｃは、描画サーバ２００Ｒに直接接続されてもよい。他の実施形態では計算サーバ２００Ｃは、インターネット１３０であってもよいし、その他のネットワークであってもよいネットワーク２６０を介して描画サーバ２００Ｒに接続されてもよい。仮想プライベートネットワーク（ＶＰＮ）は、ネットワーク２６０を介して計算サーバ２００Ｃと描画サーバ２００Ｒとの間に確立されてもよい。
【００３１】
描画サーバ２００Ｒにおいて、計算サーバ２００Ｃにより送信された描画命令セット２０４は、ネットワークインタフェース要素（ＮＩＣ）２１０Ｒ１において受信され、１以上のＣＰＵ２２０Ｒ、２２２Ｒに対して導かれうる。ＣＰＵ２２０Ｒ、２２２Ｒは、グラフィック処理装置（ＧＰＵ）２４０Ｒ、２５０Ｒに接続されてもよい。非限定的な例として、ＧＰＵ２４０Ｒは、ＧＰＵコア２４２Ｒのセット及びビデオランダムアクセスメモリ（ＶＲＡＭ）２４６Ｒを含んでもよい。同様に、ＧＰＵ２５０ＲはＧＰＵコア２５２Ｒのセット及びビデオランダムアクセスメモリ（ＶＲＡＭ）２５６Ｒを含んでもよい。ＣＰＵ２２０Ｒ、２２２Ｒの各々は、ＧＰＵ２４０Ｒ、２５０Ｒの各々に接続されていてもよいし、ＧＰＵ２４０Ｒ、２５０Ｒの集合に接続されていてもよい。ＣＰＵ２２０Ｒ、２２２ＲとＧＰＵ２４０Ｒ、２５０Ｒとの間の通信は、例えば通信バスアーキテクチャを用いて確立されてよい。２つのＣＰＵ及び２つのＧＰＵのみが示されるが、描画サーバ２００Ｒの特定の実装例では、２以上のＣＰＵ及びＧＰＵがあってもよいし、単一のＣＰＵまたはＧＰＵだけであってもよい。
【００３２】
ＣＰＵ２２０Ｒ、２２２Ｒは、描画命令セット２０４を参加する各クライアント装置用のグラフィック出力ストリームに変換するために、ＧＰＵ２４０Ｒ、２５０Ｒと協働しうる。本実施形態では、クライアント装置１２０、１２０Ａの各々について２つのグラフィック出力ストリーム２０６、２０６Ａがあり得る。このことは、さらに詳細が後述されるだろう。さらに描画サーバ２００Ｒは、これを介してグラフィック出力ストリーム２０６、２０６Ａがクライアント装置１２０、１２０Ａの各々に送信されうる、ネットワークインタフェース要素（ＮＩＣ）２１０Ｒ２を有していてもよい。
【００３３】
《３．サーバシステム１００（ハイブリッドアーキテクチャ）》
図２Ｂは、サーバシステム１００の構成要素の非限定的な物理的構成の第２の態様を示している。本実施形態ではハイブリッドサーバ２００Ｈは、ユーザ入力に基づいてビデオゲーム内の状態変化の追跡とグラフィック（映像）の描画の両方の役割を担いうる。
【００３４】
図２Ｂの構成要素の非限定的な物理的構成に示されるように、ハイブリッドサーバ２００Ｈは１以上の中央演算装置（ＣＰＵ）２２０Ｈ、２２２Ｈ及びランダムアクセスメモリ（ＲＡＭ）２３０Ｈを有していてもよい。ＣＰＵ２２０Ｈ、２２２Ｈは、例えば通信バスアーキテクチャを介してＲＡＭ２３０Ｈにアクセスできる。２つのＣＰＵ２２０Ｈ、２２２Ｈのみが示されているが、より多数のＣＰＵまたは単一のＣＰＵのみがハイブリッドサーバ２００Ｈのいくつかの実装例において提供されてもよいことは理解されるべきである。またハイブリッドサーバ２００Ｈは、ビデオゲームに参加するクライアント装置の各々からインターネット１３０を介してクライアント装置入力が受信されるネットワークインタフェース要素（ＮＩＣ）２１０Ｈを有していてもよい。以下に記載される実施形態の例では、クライアント装置１２０及びクライアント装置１２０Ａの両方は、ビデオゲームに参加しているものとし、故に受信したクライアント装置入力は、クライアント装置入力１４０及びクライアント装置入力１４０Ａを含んでもよい。
【００３５】
また、ＣＰＵ２２０Ｈ、２２２Ｈは、描画処理装置（ＧＰＵ）２４０Ｈ、２５０Ｈに接続されていてもよい。非限定的な例ではＧＰＵ２４０Ｈは、ＧＰＵコア２４２のセット及びビデオランダムアクセスメモリ（ＶＲＡＭ）２４６Ｈを含んでいてもよい。同様にＧＰＵ２５０Ｈは、ＧＰＵコア２５２Ｈのセット及びビデオランダムアクセスメモリ（ＶＲＡＭ）２５６Ｈを含んでいてもよい。ＣＰＵ２２０Ｈ、２２２Ｈの各々は、ＧＰＵ２４０Ｈ、２５０Ｈの各々またはＧＰＵ２４０Ｈ、２５０Ｈの集合に接続されていてもよい。ＣＰＵ２２０Ｈ、２２２ＨとＧＰＵ２４０Ｈ、２５０Ｈとの通信は、例えば通信バスアーキテクチャを用いて確立されてもよい。２つのＣＰＵと２つのＧＰＵのみが示されているが、ハイブリッドサーバ２００Ｈの特定の実装例では、２以上のＣＰＵがあってもよいし、ＣＰＵまたはＧＰＵが単一のみであってさえよい。
【００３６】
描画命令セット２０４を、参加している各クライアント装置につき１つであるグラフィック出力ストリームに変換するために、ＣＰＵ２２０Ｈ、２２２ＨはＧＰＵ２４０Ｈ、２５０Ｈと協働する。本実施形態では、参加しているクライアント装置１２０、１２０Ａの各々に対して、２つのグラフィック出力ストリーム２０６、２０６Ａが存在しうる。グラフィック出力ストリーム２０６、２０６Ａは、ＮＩＣ２１０Ｈを介してクライアント装置１２０、１２０Ａの各々に送信されうる。
【００３７】
《４．サーバシステム１００（機能概要）》
ゲームプレイの間、サーバシステム１００は、機能モジュールセットで構成されうるサーバ側ビデオゲームアプリケーションを実行する。図２Ｃを参照すると、これらの機能モジュールはビデオゲーム機能モジュール２７０、描画機能モジュール２８０、及び映像符号化器２８５を含んでいてよい。これらの機能モジュールは、上述した計算サーバ２００Ｃと描画サーバ２００Ｒ（図２Ａ）及び／またはハイブリッドサーバ２００Ｈ（図２Ｂ）の物理的構成要素により実現されうる。例えば、図２Ａの非限定的な実施形態に関しては、ビデオゲーム機能モジュール２７０は計算サーバ２００Ｃにより実現され、描画機能モジュール２８０及び映像符号化器２８５は描画サーバ２００Ｒにより実現されうる。図２Ｂの非限定的な実施形態に関しては、ハイブリッドサーバ２００Ｈはビデオゲーム機能モジュール２７０、描画機能モジュール２８０、及び映像符号化器２８５を実現しうる。
【００３８】
本実施形態の例は、図を簡略化するために単一のビデオゲーム機能モジュール２７０について議論する。しかしながら、サーバシステム１００の実際の実装において、ビデオゲーム機能モジュール２７０と同様の多くのビデオゲーム機能モジュールが平行に実行されうる。したがって、サーバシステム１００は、同一のビデオゲームの複数の独立したインスタンス化または複数の異なるビデオゲームの同時のインスタンス化をサポートしうる。また、ビデオゲームは、あらゆる種類の１人プレイヤ用ビデオゲームまたはマルチプレイヤ用ゲームであってもよいことは理解されるべきである。
【００３９】
ビデオゲーム機能モジュール２７０は、計算サーバ２００Ｃまたはハイブリッドサーバ２００Ｈの所定の物理的構成要素により実現されてもよい。具体的には、ビデオゲーム機能モジュール２７０は、ビデオゲーム機能モジュール２７０は、（計算サーバ２００ＣのＣＰＵ２２０Ｃ、２２２Ｃやハイブリッドサーバ２００ＨのＣＰＵ２２０Ｈ、２２２Ｈのような）ＣＰＵにより実行可能なコンピュータ読み取り可能な命令として符号化されうる。該命令は、（計算サーバ２００Ｃの）ＲＡＭ２３０Ｃ、（ハイブリッドサーバ２００Ｈの）ＲＡＭ２３０Ｈ、あるいは他の記憶領域に、ビデオゲーム機能モジュール２７０により使用される定数、変数及び／または他のデータとともに明白に（tangibly）格納されうる。いくつかの実施形態においてビデオゲーム機能モジュール２７０は、（計算サーバ２００ＣのＣＰＵ２２０Ｃ、２２２Ｃやハイブリッドサーバ２００ＨのＣＰＵ２２０Ｈ、２２２Ｈのような）ＣＰＵにより実行されているオペレーティングシステムによりサポートされうる、 バーチャルマシンの環境において実行されてもよい。
【００４０】
描画機能モジュール２８０は描画サーバ２００Ｒ（図２Ａ）あるいはハイブリッドサーバ２００Ｈ（図２Ｂ）の所定の物理的構成要素により実現されてもよい。一実施形態において、描画機能モジュール２８０は、１以上のＧＰＵ（図２Ａの２４０Ｒ、２５０Ｒ、図２Ｂの２４０Ｈ、２５０Ｈ）が引き受けてもよいし、ＣＰＵリソースを利用してもよいししなくてもよい。
【００４１】
映像符号化器２８５は、描画サーバ２００Ｒ（図２Ａ）またはハイブリッドサーバ２００Ｈ（図２Ｂ）の所定の物理的構成要素により実現されてよい。本技術分野に属する当業者は、映像符号化器２８５を実現する種々の手法があることは容易に理解するだろう。図２Ａの実施形態において、映像符号化器２８５はＣＰＵ２２０Ｒ、２２２Ｒ及び／またはＧＰＵ２４０Ｒ、２５０Ｒにより実現されうる。図２Ｂの実施形態では、映像符号化器２８５はＣＰＵ２２０Ｈ、２２２Ｈ及び／またはＧＰＵ２４０Ｈ、２５０Ｈにより実現されうる。その他の実施形態では、映像符号化器２８５は、分離された符号化チップ（不図示）により実現されてもよい。
【００４２】
動作において、ビデオゲーム機能モジュール２７０は、受信したクライアント装置入力に基づいて描画命令セット２０４を生成しうる。受信したクライアント装置入力は、行き先となるビデオゲーム機能モジュールを示すデータ（例えばアドレス）、及び由来するユーザ及び／またはクライアント装置を示すデータを運ぶものであってよい。クライアント装置１２０、１２０Ａのユーザは、ビデオゲームに参加（即ちプレイヤまたは観戦者）しており、受信したクライアント装置入力は、クライアント装置１２０、１２０Ａから受信したクライアント装置入力１４０、１４０Ａを含みうる。
【００４３】
描画命令は、映像データのフレームまたは映像データの一連のフレームを生成するように専用グラフィック生成装置（ＧＰＵ）に導くために用いられうる命令を示す。図２Ｃを参照すると、描画命令セット２０４は、描画機能モジュール２８０による映像データのフレームの生成をもたらす。これらのフレームにより示される画像は、ビデオゲーム機能モジュール２７０にプログラムされた、クライアント装置入力１４０、１４０Ａに応じた機能として変更されうる。例えば、ビデオゲーム機能モジュール２７０は、所定の特定の要因に応じてユーザに（将来のインタラクションが異なる、より挑戦的とさせる、あるいはより刺激的とさせる）進行体験を提供するような方法でプログラムされ得、一方で、他の特定の要因への応答は、回帰や終了の体験をユーザに与えるだろう。ビデオゲーム機能モジュール２７０への指示はバイナリ実行可能なファイルの形式で固定され得るが、クライアント装置入力１４０、１４０Ａは対応するクライアント装置１２０、１２０Ａを使用するプレイヤのインタラクション動作があるまで不明である。結果として、提供される特定のクライアント装置入力に応じて、様々な種類の生じ得る結果が存在してもよい。プレイヤ／観戦者とビデオゲーム機能モジュール２７０の間のクライアント装置１２０、１２０Ａを介した該インタラクションは、「ゲームプレイ」や「ビデオゲームをプレイしている」等として言及されうる。
【００４４】
描画機能モジュール２８０は、複数の映像データストリーム２０５を生成するために描画命令セット２０４を処理しうる。一般に、参加者ごとに（あるいはクライアント装置ごとにも同等）、１つの映像データストリームが存在してよい。描画が実行されている場合、３次元空間（例えば物理オブジェクト）あるいは２次元空間（例えばテキスト）に示される１以上のオブジェクトについてのデータは、特定のＧＰＵ２４０Ｒ、２５０Ｒ、２４０Ｈ、２５０Ｈのキャッシュメモリ（不図示）に展開される。該データは、ＧＰＵ２４０Ｒ、２５０Ｒ、２４０Ｈ、２５０Ｈにより、適切なＶＲＡＭ２４６Ｒ、２５６Ｒ、２４６Ｈ、２５６Ｈに格納されうる２次元画像を示すデータに変換されうる。このようにして、ＶＲＡＭ２４６Ｒ、２５６Ｒ、２４６Ｈ、２５６Ｈは、ゲーム画面についての画素値の一時的な格納領域を提供しうる。
【００４５】
映像符号化器２８５は、映像データストリーム２０５の各々に含まれる映像データを、対応する圧縮／符号化された映像データのストリームに圧縮及び符号化しうる。グラフィック出力ストリームとして言及される、圧縮／符号化された映像データの結果であるストリームは、クライアント装置基準で生成されうる。本実施形態の例では映像符号化器２８５は、クライアント装置１２０についてのグラフィック出力ストリーム２０６及びクライアント装置１２０Ａについてのグラフィック出力ストリーム２０６Ａを生成しうる。追加の機能モジュールが、インターネット１３０を介して送信可能なように映像データをパケット形式にするよう提供されてもよい。映像データストリーム２０５に含まれる映像データ、及び任意のグラフィック出力ストリームに含まれる圧縮／符号化された映像データは、複数のフレームに分割されうる。
【００４６】
《５．描画命令の生成》
以下、ビデオゲーム機能モジュール２７０による描画命令の生成が、図２Ｃ、３Ａ及び３Ｂを参照してより詳細に説明される。具体的には、ビデオゲーム機能モジュール２７０の実行は、いかに詳細が説明されるメインゲームプロセス３００Ａとグラフィック制御プロセス３００Ｂを含むいくつかのプロセスを伴いうる。
【００４７】
〈メインゲームプロセス〉
メインゲームプロセス３００Ａは、図３Ａを参照して説明される。メインゲームプロセス３００Ａは、連続的なループとして繰り返し実行しうる。メインゲームプロセス３００Ａの一部として、実行中、クライアント装置入力が受信されうる動作３１０Ａが提供されうる。ビデオゲームが観戦の可能性がない１人プレイヤ用ビデオゲームである場合、単一のクライアント装置（例えばクライアント装置１２０）からのクライアント装置入力（例えばクライアント装置入力１４０）が動作３１０Ａの一部として受信される。ビデオゲームがマルチプレイヤ用ビデオゲームまたは観戦の可能性がある１人プレイヤ用ゲームである場合、１以上のクライアント装置（例えばクライアント装置１２０及び１２０Ａ）からのクライアント装置入力（例えばクライアント装置入力１４０及び１４０Ａ）が、動作３１０Ａの一部として受信されうる。
【００４８】
非限定的な例示の目的で、任意のクライアント装置からの入力は、該任意のクライアント装置のユーザが、制御下にあるキャラクタに対して移動、ジャンプ、キック、旋回、揺動、押す、引く等をさせることを所望していることを伝送しうる。代替的あるいは追加的に、該任意のクライアント装置からの入力は、１以上の音声、映像またはゲームプレイ設定を変更する、ゲームをロード／セーブする、あるいはネットワークセッションの作成やセッションへの参加を行うために、該任意のクリア案と装置のユーザによりなされたメニュー選択を伝送しうる。代替的あるいは追加的に、該任意のクライアント装置からの入力は、該任意のクライアント装置のユーザが特定のカメラ視野（例えば１人称または３人称）の選択、あるいは仮想世界内の視野の再配置を所望していることを伝送しうる。
【００４９】
動作３２０Ａで、ゲームステートは、動作３１０Ａにおいて受信したクライアント装置入力の少なくとも一部及び他のパラメータに基づいて更新されうる。ゲームステートの更新は、次の動作を伴いうる。
【００５０】
第１に、ゲームステートの更新は、クライアント装置入力が受信されうるクライアント装置に関連付けられた参加者（プレイヤまたは観戦者）の所定の特性（property）を更新することを伴いうる。これらの特性は、参加者データベース１０に格納されうる。参加者データベース１０に保持されて動作３２０において更新されうる参加者特性の例は、カメラ視野の選択（例えば１人称、３人称）、プレイモード、選択された音声または映像の設定、スキルレベル、顧客グレード（例えばゲスト、プレミアム等）を含みうる。
【００５１】
第２に、ゲームステートの更新は、クライアント装置入力の解釈に基づいて、仮想世界内の所定のオブジェクトの属性を更新することを伴いうる。属性が更新されるオブジェクトは、いくつかのケースでは２次元または３次元モデルにより示されてもよいし、プレイキャラクタ、非プレイキャラクタ及び他のオブジェクトを含みうる。プレイヤキャラクタである場合、更新されうる属性はオブジェクトの位置、強さ、武器／防具、経過した寿命、特殊能力、速さ／方向（速度）、アニメーション視覚的効果、エネルギ、弾薬等を含みうる。他のオブジェクト（背景、植物、建物、乗り物、スコアボード等）である場合、更新されうる属性は、該オブジェクトの位置、速度、アニメーション、ダメージ／体力、視覚的効果、テキスト内容等を含みうる。
【００５２】
クライアント装置入力とは別のパラメータは、上述した（参加者の）特性及び（仮想世界オブジェクトの）属性に影響を与えうることは理解されるべきである。例えば、様々なタイマー（経過時間、特定のイベントからの時間、一日の仮想時刻、プレイヤ総数、参加者地理的位置等）が、ゲームステートの様々な態様に影響を及ぼしてもよい。
【００５３】
動作３２０Ａの実行に加えてゲームステートが更新されると、メインゲームプロセス３００Ａは動作３１０Ａに戻ってもよく、前回のメインゲームプロセスを終了してから受信した新たなクライアント装置入力が収集され、処理される。
【００５４】
〈グラフィック制御プロセス〉
以下、グラフィック制御プロセスとして言及される第２のプロセスについて、図３Ｂを参照して説明する。メインゲームプロセス３００Ａとは分離されて示されるが、グラフィック制御プロセス３００Ｂはメインゲームプロセス３００Ａの延長として実行してもよい。グラフィック制御プロセス３００Ｂは継続的に実行し、描画命令セット２０４の生成をもたらす。観戦の可能性がない１人プレイヤ用ビデオゲームの場合、１人のプレイヤのみが存在し、故に衛星される描画命令セット２０４の結果は１つのみである。マルチプレイヤ用ビデオゲームの場合、複数の独立した描画命令セットが複数のプレイヤについて生成されることが必要であり、従って各プレイヤについて１つである複数のサブプロセスが並行して実行しうる。観戦の可能性がある１人プレイヤ用ゲームの場合、また単一の描画命令セット２０４のみが存在し得るが、結果である映像データストリームは、描画機能モジュール２８０により複数の観戦者にも複製されうる。もちろん、これらはただの実装の例であり、限定として取られるべきものではない。
【００５５】
映像データストリーム２０５の１つを要求する任意の参加者についてのグラフィック制御プロセス３００Ｂの動作を考える。動作３１０Ｂにおいて、ビデオゲーム機能モジュール２７０は該任意の参加者について描画されるオブジェクトを決定しうる。この動作は、以下の種類のオブジェクトを識別することを含んでいてよい。
【００５６】
第１に、この動作は、仮想世界から任意の参加者についての「ゲーム画面描画範囲」（「シーン」としても知られる）内にある、これらのオブジェクトを識別することを含みうる。ゲーム画面描画範囲は、任意の参加者のカメラの画角（perspective）から「観ることが可能」な、仮想世界の一部を含みうる。これは、仮想世界内のオブジェクトに関連するカメラの位置及び方向に依るものであってもよい。動作３１０Ｂの非限定的な実装例において、錐台が仮想世界に適用され、該錐台内のオブジェクトが保持またはマークされる。錐台は、任意の参加者のカメラの位置に置かれた頂点を有し、該カメラの方向性により規定される方向を有するものであってもよい。
【００５７】
第２に、この動作は、仮想世界内に現れないが、それにも関わらず任意の参加者について描画される必要がありうる追加のオブジェクトを識別することを含みうる。例えば、これらの追加のオブジェクトは、非限定的な２〜３の可能性を挙げると、テキストメッセージ、グラフィック警告及びダッシュボードインジケータを含んでもよい。
【００５８】
動作３２０Ｂで、ビデオゲーム機能モジュール２７０は、動作３１０Ｂにおいて識別されたオブジェクトを、グラフィック（映像データ）に描画するための命令セットを生成しうる。描画は、視野及び適用される照明状態に従って、１つのオブジェクトまたはオブジェクト群の３次元または２次元座標の、表示可能な画像を示すデータへの変換を参照してもよい。これは、例えばここに参照により組み込まれる「"Computer Graphics and Geometric Modelling: Implementation & Algorithms", Max K. Agoston, Springer-Verlag London Limited, 2005」に記載されるような、あらゆるアルゴリズム及び技術を用いて達成されうる。描画命令は、ワシントン州レドモンドのマイクロソフト（登録商標）社の「Direct3D」及びオレゴン州ビーバートンのクロノスグループにより管理される「OpenGL」等の３Ｄアプリケーション・プログラミング・インタフェース（ＡＰＩ）に適合する形式を有するものであってもよい。
【００５９】
動作３３０Ｂで、動作３２０Ｂにおいて生成された描画命令は描画機能モジュール２８０に出力されうる。これは、描画機能モジュール２８０に送信する描画命令セット２０４への、生成された描画命令のパケット化を伴いうる。
【００６０】
《６．グラフィック出力の生成》
描画機能モジュール２８０は、描画命令セット２０４を解釈し、参加しているクライアント装置ごとに１つである、複数の映像データストリーム２０５を生成しうる。描画は、（図２Ａの）ＣＰＵ２２０Ｒ、２２２Ｒまたは（図２Ｂの）ＣＰＵ２２０Ｈ、２２２Ｈの制御の下、ＧＰＵ２４０Ｒ、２５０Ｒ、２４０Ｈ、２５０Ｈにより実現されうる。１つの参加者のクライアント装置に係る映像データのフレームが生成されるレートは、フレームレートとして参照されうる。
【００６１】
Ｎ名の参加者が存在する実施形態において、Ｎ個の描画命令セット２０４（各参加者について１つ）が存在し、Ｎ個の映像データストリーム２０５（各参加者について１つの）が存在し得る。この場合、描画機能は参加者間で共有されない。しかしながら、２〜３の描画命令セットが描画機能モジュール２８０により処理される必要があるように、Ｍ個（Ｍ＜Ｎ）の描画命令セット２０４からＮ個の映像データストリーム２０５が生成されてもよい。この場合、少ない数の描画命令セット２０４からより多い数の映像データストリーム２０５を生成するために、描画機能モジュール２８０は共有または複製を行ってもよい。このような共有または複製は、複数の参加者（例えば観戦者）が同一のカメラ画角を観ることを所望した場合に普及するものであってもよい。故に、描画機能モジュール２８０は、生成された映像データストリームが１以上の観戦者に複製されるように機能を実行してもよい。
【００６２】
次に、映像データストリーム２０５の各々における映像データは、映像符号化器２８５により符号化され、グラフィック出力ストリームとして参照され得、各クライアント装置に関連付けられた一連の符号化映像データが得られる。図２Ａ〜２Ｃの実施形態の例において、クライアント装置１２０についての一連の符号化映像データはグラフィック出力ストリーム２０６として参照され、クライアント装置１２０Ａについての一連の符号化映像データはグラフィック出力ストリーム２０６Ａとして参照されてもよい。
【００６３】
映像符号化器２８５は、デジタル映像についての映像圧縮または展開を可能にする、実行する、または定義する装置（またはコンピュータ読み取り可能な命令セット）であってもよい。映像圧縮は、（画素位置、色値等で表現される）デジタル画像データのオリジナルストリームを、より少ないビットを用いるが実質的に同一の情報を伝送するデジタル画像データの出力ストリームに変換しうる。あらゆる適切な圧縮アルゴリズムが用いられてよい。データ圧縮に加え、映像データの特定のフレームの符号化に用いられる符号化処理は、暗号化を伴ってもよいし、伴わなくともよい。
【００６４】
上述の手法で生成されたグラフィック出力ストリーム２０６、２０６Ａは、インターネット１３０を介して各クライアント装置に送信されうる。非限定的な例示目的で、グラフィック出力ストリームは、各々がヘッダ及びペイロードを有するパケットに、セグメント化あるいは形式化されてもよい。任意の参加者についての映像データに含まれるパケットのヘッダは、該任意の参加者に関連付けられたクライアント装置のネットワークアドレスを含んでもよく、ペイロードは全部または一部として映像データを含んでもよい。非限定的な実施形態において、所定の映像データを符号化するために用いられる圧縮アルゴリズムの身元（identity）及び／またはバージョンが、該映像データを伝送する１以上のパケットのコンテンツ内に符号化されてもよい。符号化映像データの他の送信手法は、本技術分野に属する当業者には思い当たるかもしれない。
【００６５】
本開示は個々が２Ｄ画像を示す映像データの描画にフォーカスするものであるが、本発明は３次元効果を生成するために、フレームごとに複数の２Ｄ画像を示す映像データの描画の可能性を除外するものではない。
【００６６】
《７．クライアント装置におけるゲーム画面再生》
以下、非限定的な例示の目的で、クライアント装置１２０またはクライアント装置１２０Ａたり得る、任意の参加者に関連付けられたクライアント装置により実行されうるクライアント側ビデオゲームアプリケーションの動作を示す図４Ａを参照する。動作にあたり、クライアント側ビデオゲームアプリケーションは、非限定的な２〜３の可能性を挙げると、クライアント装置により直接実行可能であってもよいし、Ｗｅｂブラウザにおいて起動してもよい。
【００６７】
動作４１０Ａで、１つのグラフィック出力ストリーム（例えば２０６、２０６Ａ）は、実施形態に応じて描画サーバ２００Ｒ（図２Ａ）から、あるいはハイブリッドサーバ２００Ｈ（図２Ｂ）から、インターネット１３０を介して受信されてもよい。受信されたグラフィック出力ストリームは複数のフレームに分割されうる圧縮／符号化された映像データを含みうる。
【００６８】
動作４２０で、映像データの圧縮／符号化されたフレームは、符号化／圧縮処理に用いられた符号化／圧縮アルゴリズムを補間する展開アルゴリズムに従って復号／展開される。非限定的な実施形態において、映像データの符号化／圧縮に用いられた符号化／圧縮アルゴリズムの身元またはバージョンは、予め知らされていてもよい。他の実施形態において、映像データの符号化／圧縮に用いられた符号化／圧縮アルゴリズムの身元またはバージョンは、映像データ自体が添付されてもよい。
【００６９】
動作４３０Ａで、映像データの（復号／展開された）フレームが処理されうる。これは、バッファへの映像データの復号／展開されたフレームの配置、誤り訂正、複数の連続するフレームにおけるデータの順序付け及び／または合成、アルファブレンディング、欠損したデータの一部の補間等を含みうる。該結果は、毎フレーム基準でユーザに提示される最終画像を示す映像データとなり得る。
【００７０】
動作４４０Ａで、最終画像がクライアント装置の出力機構を介して出力されうる。例えば、コンポジット映像フレームが、クライアント装置のディスプレイに表示されうる。
【００７１】
《８．音声生成》
以下、音声生成処理として言及される３番目の処理が、図３Ｃを参照して説明される。音声生成処理は、知覚可能な音声ストリームを要求する各参加者について、継続的に実行されうる。一実施形態において、音声生成処理はグラフィック制御プロセス３００Ｂと無関係に実行されてよい。他の実施形態において、音声生成処理及びグラフィック制御処理の実行が連動されてもよい。
【００７２】
動作３１０Ｃで、ビデオゲーム機能モジュール２７０は、生成される音声を決定しうる。具体的に該動作は、音量（音の強さ）及び／または仮想世界内において参加者への近さに応じて、地形音響特性に影響を及ぼす仮想世界内のオブジェクトに関連付けられたこれらの音声を特定することを含みうる。
【００７３】
動作３２０Ｃで、ビデオゲーム機能モジュール２７０は音声セグメントを生成しうる。音声セグメントの継続期間は映像フレームの継続期間に及んでもよいし、いくつかの実施形態では音声セグメントは映像フレームよりも少ない頻度で生成されてもよいし、他の実施形態では音声セグメントは映像フレームよりも高い頻度で生成されてもよい。
【００７４】
動作３３０Ｃで、音声セグメントは例えば音声符号化器により符号化され得、符号化音声セグメントが得られる。音声符号化器は、音声圧縮または展開アルゴリズムを可能にする、実行する、または定義する装置（または命令セット）であってもよい。音声圧縮は、（徐々に振幅及び位相が変化する音波として表現される）デジタル音声のオリジナルストリームを、より少ないビットを使用するが実質的に同一の情報を伝送するデジタル音声データの出力ストリームに変換しうる。あらゆる適切な圧縮アルゴリズムが用いられてよい。音声圧縮に加え、特定の音声セグメントの符号化に用いられる符号化処理は暗号化を適用してもよいし、しなくてもよい。
【００７５】
いくつかの実施形態において、音声セグメントは計算サーバ２００Ｃ（図２Ａ）またはハイブリッドサーバ２００Ｈ（図２Ｂ）のいずれかの専用ハードウェア（例えばサウンドカード）により生成されてもよいことは理解されるべきである。図２Ａの分散型構成に適用可能な代替的実施形態において、音声セグメントはビデオゲーム機能モジュール２７０によりスピーチパラメータ（例えばＬＰＣパラメータ）にパラメータ化されてもよく、スピーチパラメータは描画サーバ２００Ｒにより、配信先のクライアント装置（例えばクライアント装置１２０またはクライアント装置１２０Ａ）に再配信されうる。
【００７６】
上述した方式で生成された符号化された音声は、インターネット１３０を介して送信される。非限定的な例示を目的として、符号化された音声入力は、各々がヘッダ及びペイロードを有するパケットに分解及び形式化されうる。ヘッダは、音声生成処理が実行される参加者に関連付けられたクライアント装置のアドレスを伝送してもよく、ペイロードは符号化された音声を含んでいてもよい。非限定的な実施形態において、任意の音声セグメントの符号化に用いられる圧縮アルゴリズムの身元及び／またはバージョンは、該任意のセグメントを伝送する１以上のパケットのコンテンツ内に符号化されてもよい。符号化された音声を送信する他の手法は、本技術分野に属する当業者には思い当たるかもしれない。
【００７７】
以下、非限定的な例示を目的として、クライアント装置１２０またはクライアント装置１２０Ａであってよい、任意の参加者に関連付けられたクライアント装置の動作を示す図４Ｂを参照する。
【００７８】
動作４１０Ｂで、符号化された音声セグメントが（実施形態に応じて）計算サーバ２００Ｃ、描画サーバ２００Ｒ、またはハイブリッドサーバ２００Ｈから受信されうる。動作４２０Ｂで、符号化処理に用いられた圧縮アルゴリズムを補間する展開アルゴリズムに従って、符号化された音声は復号されうる。非限定的な実施形態において、音声セグメントの符号化に用いられた圧縮アルゴリズムの身元またはバージョンは、音声セグメントを伝送する１以上のパケットのコンテンツ内で特定されてもよい。
【００７９】
動作４３０Ｂで、（復号された）音声セグメントが処理されうる。これは、バッファ内への復号された音声セグメントの配置、誤り訂正の実行、複数の連続する波形合成等を含みうる。該結果は、毎フレーム基準でユーザに提示される最終音声となり得る。
【００８０】
動作４４０Ｂで、最終的に生成された音声は、クライアント装置の出力機構を介して出力されうる。例えば、音声はクライアント装置のサウンドカードまたはスピーカを介して再生されうる。
【００８１】
《９．非限定的な実施形態の具体的開示》
以下、本発明の所定の非限定的な実施形態のより詳細な説明が提供される。
【００８２】
発明のある非限定的な実施形態の非限定的な説明の提示目的で、ビデオゲーム内の２以上の参加者（プレイヤまたは観戦者）が、同一の位置及びカメラ投影を有するものとする。即ち、同一のシーンが２以上の参加者により鑑賞される。例えば、１人の参加者はプレイヤであってよく、他の参加者は個々の観戦者であってよい。シーンは様々なオブジェクトを含むものとする。本発明の非限定的な実施形態において、これらのオブジェクトのいくつか（所謂「一般」オブジェクト）は一度描画されて共有され、故に参加者の各々に同一の描画表現がもたらされる。また、シーン内の１以上のオブジェクト（所謂「カスタマイズ可能」オブジェクト）は、カスタマイズされた方法で描画される。故に、これらは全ての参加者についてシーン内の共通の位置を占有するが、カスタマイズ可能オブジェクトは観戦者間で様々な描画表現をもたらす。結果として、描画されたシーンの画像は、全ての参加者について同一である、一般オブジェクトを含む第１の領域と、観戦者間で変化し得る、カスタマイズ可能オブジェクトを含む第２の領域とを含む。以下では、「参加者」との文言は、「ユーザ」との文言と同一の意味で用いられうる。
【００８３】
図５は、参加者Ａ、Ｂ、Ｃについて生成され得る、映像／画像データにより表される複数の画像５１０Ａ、５１０Ｂ、５１０Ｃを概念的に示している。本例では３人の参加者Ａ、Ｂ及びＣが存在するが、任意の実装において、参加者の数がいずれであってもよいことは理解されよう。画像５１０Ａ、５１０Ｂ、５１０Ｃは、全ての参加者に対し共通であってよいオブジェクト５２０を示す。参照を簡易にするため、オブジェクト５２０は「一般」オブジェクトとして参照される。また、画像５１０Ａ、５１０Ｂ、５１０Ｃは、各参加者についてカスタマイズされ得るオブジェクト５３０を示す。参照を簡易にするため、オブジェクト５３０は「カスタマイズ可能」オブジェクトとして参照される。カスタマイズ可能オブジェクトは、異なる参加者について異なるテクスチャを有するように、カスタマイズされ得るが、これらの参加者間で共通の照明条件が適用される、シーン内のいずれのオブジェクトであってもよい。このように、カスタマイズ可能オブジェクトとは対照的に、一般オブジェクトであってよいオブジェクトのタイプには特定の限定を有しない。一例において、カスタマイズ可能オブジェクトはシーンオブジェクトであってよい。
【００８４】
図示される例では、単一の一般オブジェクト５２０と単一のカスタマイズ可能オブジェクトとが示される。しかしながら、これは限定として考慮されるべきではなく、任意の実装において考慮されるように、あらゆる数の一般オブジェクトとあらゆる数のカスタマイズ可能オブジェクトが存在するものであってもよい。さらに、オブジェクトはいずれのサイズまたは形状であってもよい。
【００８５】
描画される特定のオブジェクトは、一般オブジェクトまたはカスタマイズ可能オブジェクトとして分類され得る。オブジェクトが一般オブジェクトまたはカスタマイズ可能オブジェクトとして考慮されるか否かの決定は、様々な要素に基づきメインゲームプロセス３００Ａによってなされるものであってよい。これらの要素は、シーンにおけるオブジェクトの位置や深度を含むものであってもよいし、単純に任意のオブジェクトが一般またはカスタマイズ可能のいずれであるかをあらかじめ識別されているものであってもよい。図６Ａを参照されるように、一般またはカスタマイズ可能に係るオブジェクトの識別は、オブジェクトデータベース１１２０に格納されていてもよい。オブジェクトデータベース１１２０は、少なくとも一部においてコンピュータメモリを用いる態様であってもよい。実装される態様によって、オブジェクトデータベース１１２０はメインゲームプロセス３００Ａにより維持され、グラフィック制御プロセス３００Ｂ及び／または描画機能モジュール２８０によりアクセス可能であってもよい。
【００８６】
オブジェクトデータベース１１２０は、各オブジェクトについてのレコード１１２２と、該オブジェクトに係る種々の情報を格納する各レコード１１２２のフィールドセット１１２４、１１２６、１１２８を含んでよい。例えば、他者間で、（オブジェクトＩＤお格納する）識別フィールド１１２４、（不図示のテクスチャデータベースの画像ファイルにリンクするテクスチャＩＤを格納する）テクスチャフィールド１１２６、及び（該オブジェクトが一般オブジェクトとカスタマイズ可能オブジェクトのいずれであるかの識別子を格納する）カスタマイズフィールド１１２８があってよい。
【００８７】
あるオブジェクトが（オブジェクトＩＤ「５２０」を有するオブジェクト用であって、カスタマイズフィールド１１２８の内容が「一般」を示すような）一般オブジェクトである場合、対応のテクスチャフィールド１１２６に格納されるテクスチャＩＤにより示されるテクスチャ（この場合「txt.bmp」）が、全ての参加者により鑑賞される最終画像における一般オブジェクトを表すために用いられるものである。テクスチャ自体は、テクスチャデータベース１１９０（図６Ｂ参照）に格納され、テクスチャＩＤ（この場合「txt.bmp」）によりインデックスが付されたファイルを構成する。テクスチャデータベース１１９０は、少なくとも一部にコンピュータメモリを用いる態様であってよい。
【００８８】
あるオブジェクトが（オブジェクトＩＤ「５３０」を有するオブジェクト用であって、カスタマイズフィールド１１２８の内容が「カスタマイズ可能」を示すような）カスタマイズ可能オブジェクトである場合、複数の参加者は該オブジェクトに異なるテクスチャが適用されることを鑑賞し得る。故に、再び図６Ａに関して、予定のテクスチャフィールドは、２以上の参加者の各々について１つである、サブレコードセット１１４２で置き換えられ得、各サブレコードは（参加者ＩＤを格納する）参加者フィールド１１４４と（テクスチャデータベースの画像ファイルにリンクするテクスチャＩＤを格納する）テクスチャフィールド１１４６を含む。テクスチャ事態は、テクスチャデータベース１１９０に格納され、テクスチャＩＤ（この場合「txtA.bmp」、「txtB.bmp」及び「txtC.bmp」が各々参加者Ａ、Ｂ及びＣに関連付けられたテクスチャＩＤである）によりインデックスが付されたファイルを構成しうる。
【００８９】
カスタマイズフィールド１１２８、サブレコード１１４２及びテクスチャフィールド１１４６の使用は、オブジェクトデータベース１１２０のカスタマイズ可能オブジェクト５３０に係る情報を符号化する１つの特定の手法に過ぎず、限定として考慮されるべきでない。
【００９０】
故に、単一のカスタマイズ可能オブジェクトは、複数の参加者の各々に関連付けられた複数のテクスチャに関連付けされ得る。任意のカスタマイズ可能オブジェクトに係るテクスチャと参加者との関係は、種々の要素に依存し得る。これらの要素は、識別情報、財務データ、位置データ、人口統計データ、接続データ等のような、種々の参加者に係る参加者データベース１０に格納される情報を含みうる。
【００９１】
〈実装例〉
図７は、ビデオゲーム機能モジュール２７０から受信した描画命令に基づき、描画機能モジュール２８０により実施されうるグラフィックスパイプライン例を示している。ビデオゲーム機能モジュールが描画機能モジュール２８０として同一の計算装置に存在（図２Ｂ参照）または異なる計算装置に存在（図２Ａ）し得ることが再度認識されるだろう。グラフィックスパイプラインの一部を形成する計算の実行が描画命令により定義される、即ち描画機能ユニット２８０にグラフィックスパイプライン動作を実行させるように、描画命令がビデオゲーム機能モジュール２７０により発行されることが理解されるべきである。この目的を達成するために、ビデオゲーム機能モジュール２７０及び描画機能モジュール２８０は、描画命令を符号化、復号及び解釈に所定のプロトコルを用いる。
【００９２】
図７に示される描画パイプラインは、非限定的な例示手法として用いられる、ＷＡ、レドモンド州のマイクロソフト社のDirect3Dアーキテクチャの一部を形成する。他のシステムがグラフィックスパイプラインにおける変形例を実現し得る。図示されたグラフィックスパイプラインは、以下に列挙及び簡潔に記載される複数のブロック（またはサブプロセス）を含む：
７１０  頂点データ：
未変換のモデル頂点が、頂点メモリバッファに格納される。
７２０  プリミティブデータ
点、線、三角形及び多角形を含む幾何プリミティブが、インデックスバッファを用いて頂点データから参照される。
７３０  テッセレーション：
テッセレータ部は、高次のプリミティブ、置換マップ及びメッシュパッチを頂点位置に変換し、これらの位置を頂点バッファに格納する。
７４０  頂点処理：
Direct3D変形が、頂点バッファに格納された頂点に適用される。
７５０  ジオメトリ処理：
クリッピング、背面カリング、属性評価及びラスタライズが、変形された頂点に適用される。
７６０  テクスチャ適用される面：
Direct3D面に係るテクスチャ座標が、IDirect3DTexture9インタフェースを介してDirect3Dに供給される。
７７０  テクスチャサンプラ：
テクスチャ詳細レベルフィルタリングが、入力テクスチャ値に適用される。
７８０  画素処理
ピクセルシェーダ操作は、入力された頂点及びテクスチャデータを修正するためにジオメトリデータを用い、出力画素値を得る。
７９０  画素描画：
最終描画処理は、アルファ、深度、またはステンシルテストを用いて、あるいは安生らブレンディングやフォグを適用することにより、画素値を修正する。結果である全ての画素値は出力ディスプレイに提示される。
【００９３】
以下、図８を参照し、本発明の非限定的な実施形態に係り適応された、グラフィックスパイプラインにおける画素処理サブプロセス７８０についての更なる詳細を提供する。特に画素処理サブプロセスは、オブジェクトに係る各画素について、受信した描画命令に基づき行われる、ステップ８１０〜８４０を含みうる。ステップ８１０で、拡散、スペキュラ、環境等を含む照明成分の演算を含んでいてよい、放射輝度が演算され得る。ステップ８２０で、該オブジェクトのテクスチャが取得され得る。テクスチャは、拡散色情報を含むものであってよい。ステップ８３０で、拡散色情報及び照明情報に基づき、各画素が画素値に起因する、画素ごとのシェーディングが演算され得る。最終的にステップ８４０で、各画素の画素値がフレームバッファに格納される。
【００９４】
本発明の非限定的な実施形態に係り、該画素処理サブプロセスのステップ８１０〜８４０の実行は、画素が処理されるオブジェクトの種別、即ち、オブジェクトが一般オブジェクトとカスタマイズ可能オブジェクトのいずれであるかに依存するものであってよい。複数の参加者により観賞される一般オブジェクトの描画画素と、複数の参加者により観賞されるカスタマイズ可能オブジェクトの描画画素との違いを、以下により詳細に説明する。実質的には２以上の参加者が存在するものであればよいが、本議論のため、３人の参加者Ａ、Ｂ及びＣが存在するものとする。
【００９５】
特定のオブジェクトに係る任意の画素セットに対していずれの処理ステップセットを提供するかを描画機能モジュール２８０が知るために、描画機能モジュール２８０が該特定のオブジェクトが一般オブジェクトとカスタマイズ可能オブジェクトのいずれであるかを知る必要があることが理解されるだろう。このことは、ビデオゲーム機能モジュール２７０から描画命令を受信することにより理解され得る。例えば、描画命令はオブジェクトＩＤを含んでいてよい。オブジェクトが一般オブジェクトとカスタマイズ可能オブジェクトのいずれであるかを判断するに際し、適切なレコード１１２２を検出するため、描画機能モジュール２８０は該オブジェクトＩＤに基づきオブジェクトデータベース１１２０を閲覧し、該レコード１１２２に係るカスタマイズフィールド１１２８の内容を判断してよい。他の実施形態では、描画命令は、それ自体が特定のオブジェクトが一般オブジェクトとカスタマイズ可能オブジェクトのいずれであるかを特定してもよいし、テクスチャ情報や該情報へのリンクを含むものであってさえよい。
【００９６】
（ｉ）一般オブジェクト５２０に係る画素処理
以下、オブジェクト５２０のような一般オブジェクトである場合の、画素処理サブプロセス７８０におけるステップ８１０〜８４０を示す図９を参照する。これらのステップは、一般オブジェクトの各画素ｐについて実行され、画素処理サブプロセスを介して単一のパスを構成するものであってよい。
【００９７】
ステップ８１０において、描画機能モジュール２８０は、拡散光成分DiffuseLightingp、スペキュラ光成分SpecularLightingp、及び環境光成分AmbientLightingpを含むものであってよい、画素ｐにおける分光放射輝度を演算し得る。ステップ８１０への入力は、原点、方向、強度、描画される視点に影響する色及び／または形状、及び用いられる照明モデルの定義またはパラメータに加え、深度バッファ（「Ｚバッファ」としても言及される）、法線バッファ、スペキュラ要素バッファの内容のような項目を含むものであってよい。このように、放射輝度演算は計算的な集中操作であってもよい。
【００９８】
非限定的な実施形態において、「DiffuseLighitingp」は「DiffuseLighting(p,i)」の（ｉに係る）合計である。ここで「DiffuseLighting(p,i)」は、画素ｐにおける、光源「ｉ」からの拡散項の強度及び色を示す。非限定的な実施形態において、任意の光源「ｉ」に係るDiffuseLighting(p,i)の値は、面法線と光源方向の内積（ｎ・ｌとしても参照される）として演算され得る。また「SpecularLightingp」は、画素ｐにおけるスペキュラ光の強度及び色を表す。非限定的な実施形態において、SpecularLightingpの値は、反射光ベクトルと視線方向の内積（ｒ・ｖとしても参照される）として算出され得る。さらに、「AmbientLightingp」は、画素ｐにおける環境光の強度及び色を示す。また、画素ｐにおけるDiffuseLightingp、SpecularLightingp及びAmbientLightingpを演算するために用いられる的確な数学的アルゴリズムが、本技術分野に属する当業者により周知であることは理解されるべきである。
【００９９】
ステップ８２０において、画素ｐにおける適切な色値を得るために、描画機能モジュール２８０は一般オブジェクト（この場合オブジェクト５２０）のテクスチャを参照しうる。テクスチャは、まずテクスチャＩＤを得るためにオブジェクトＩＤに基づきオブジェクトデータベース１１２０が参照されることにより識別され、そして画素ｐにおける拡散色値を得るために、該得られたテクスチャＩＤに基づきテクスチャデータベース１１９０が参照されるものであってよい。結果である拡散色値は、DiffuseColor_520pで示される。具体的には、DiffuseColor_520pは画素ｐに対応する点におけるオブジェクト５２０のテクスチャのサンプル値（あるいは補間値）で表され得る。
【０１００】
ステップ８３０において、描画機能モジュール２８０は画素ｐに係る画素値を演算し得る。「画素値」との文言が、スカラや複数成分のベクトルを言及し得るものであることは留意されるべきである。非限定的な実施形態において、複数成分のベクトルのような構成要素は、色（または色相、彩度）、彩度（色自身の強度）、及び輝度であってよい。「強度」との文言は、場合によって輝度成分を表すために用いられる。他の非限定的な実施形態において、複数成分の色ベクトルの複数の構成要素は、ＲＧＢ（赤、緑及び青）であってもよい。１つの非限定的な実施形態において、画素ｐについてOutputpで示される画素値は、拡散色に拡散光成分を増殖的に組み合わせ、さらにスペキュラ光成分及び環境光成分を加算することにより演算されるものであってもよい。即ち、
Outputp = (DiffuseColor_520p * DiffuseLightingp) + SpecularLightingp + AmbientLightingp
となる。Outputpが画素ｐの複数成分（例えばＲＧＢ、ＹＣｂＣｒ等）の各々について分離して演算されるものであってもよいことは理解されるべきである。
【０１０１】
そしてステップ８４０において、Outputpで示される画素ｐの画素値が、各参加者のフレームバッファに格納される。具体的には一般オブジェクト５２０に関連付けられた任意の画素は、参加者Ａ、Ｂ及びＣについてのフレームバッファを跨いで同一の画素値を有し、一般オブジェクト５２０に係る全ての画素が描画されると、一般オブジェクト５２０は全ての参加者についてグラフィックスとして同一に現れる。図１１を参照すると、一般オブジェクト５２０は参加者Ａ、Ｂ及びＣについて同一であるように共有されていることが理解されよう。故に、画素値Outputpは一度演算されると、各参加者のフレームバッファに複製され得る。このように、画素値Outputpが全ての参加者Ａ、Ｂ、Ｃ間で共有されるような場合のみ、一般オブジェクト５２０の描画についての演算量の低減が生じ得る。また画素値は、「画像データ」として言及されるものであってもよい。
【０１０２】
（ｉｉ）カスタマイズ可能オブジェクト５３０に係る画素処理
以下、オブジェクト５３０のようなカスタマイズ可能オブジェクトである場合の、画素処理サブプロセス７８０におけるステップ８１０〜８４０を示す図１０Ａ及び１０Ｂを参照する。これらのステップは、カスタマイズ可能オブジェクトの各画素ｐについて実行され、画素処理サブプロセスを介して複数のパスを構成するものであってよい。具体的には図１０Ａは全ての画素について実行され得る第１のパスに関し、図１０Ｂは全ての画素について実行され得る第２のパスに関する。また、第２のパスはいくつかの画素について、第１のパスが他の画素について実行されている際に開始することが可能である。
【０１０３】
ステップ８１０において、描画機能モジュール２８０は、拡散光成分DiffuseLightingq、スペキュラ光成分SpecularLightingq、及び環境光成分AmbientLightingqを含むものであってよい、画素ｐにおける分光放射輝度を演算し得る。図９に示したケースのように、（図１０Ａの）ステップ８１０への入力は、原点、方向、強度、描画される視点に影響する色及び／または形状、及び用いられる照明モデルの定義またはパラメータに加え、深度バッファ（「Ｚバッファ」としても言及される）、法線バッファ、スペキュラ要素バッファの内容のような項目を含むものであってよい。
【０１０４】
非限定的な実施形態において、「DiffuseLighitingq」は「DiffuseLighting(q,i)」の（ｉに係る）合計である。ここで「DiffuseLighting(q,i)」は、画素ｑにおける、光源「ｉ」からの拡散項の強度及び色を示す。非限定的な実施形態において、任意の光源「ｉ」に係るDiffuseLighting(q,i)の値は、面法線と光源方向の内積（ｎ・ｌとしても参照される）として演算され得る。また「SpecularLightingq」は、画素ｑにおけるスペキュラ光の強度及び色を表す。非限定的な実施形態において、SpecularLightingqの値は、反射光ベクトルと視線方向の内積（ｒ・ｖとしても参照される）として算出され得る。さらに、「AmbientLightingq」は、画素ｐにおける環境光の強度及び色を示す。また、画素ｑにおけるDiffuseLightingq、SpecularLightingq及びAmbientLightingqを演算するために用いられる的確な数学的アルゴリズムが、本技術分野に属する当業者により周知であることは理解されるべきである。
【０１０５】
さらに第１のパスの一部を形成するステップ１０１０において、描画機能モジュール２８０は画素ｑについてプリシェーディング値を演算する。非限定的な実施形態において、ステップ１０１０は、カスタマイズ可能オブジェクト５３０のテクスチャ値（拡散色）により乗算されるものと、該乗算結果を加算するものとに照明成分を細分することを含んでもよい。このように、プリシェーディング値の２つの成分、即ち「Output_1q」（乗法性）「Output_2q」（加法性）が、画素ｑについて識別され得る。非限定的な実施形態において、Output_1q = DiffuseLightingq（即ち、「Output_1q」は画素ｑにおける拡散光値を示す）、及びOutput_2q = SpecularLightingq + AmbientLightingq（即ち、「Output_2q」は画素ｑにおけるスペキュラ光値と環境光値の合計を示す）である。無論、環境光成分がない場合や、画素処理サブプロセス７８０内以外において該成分が加算される際はステップ１０１０がいずれの実際の演算も含む必要がない。
【０１０６】
同様に第１のパスの一部を形成するステップ１０２０において、描画機能モジュール２８０は画素ｑに係るプリシェーディング値を一時記憶媒体に格納する。プリシェーディング値は、同一の照明条件化で同一のオブジェクトを観賞する全ての参加者に共有され得る。
【０１０７】
以下、各参加者について実行される第２のパスを示した図１０Ｂを参照する。任意の参加者について実行される第２のパスは、各画素ｑについて実行されるステップ８２０〜８４０を含む。
【０１０８】
まず参加者Ａの例を考慮する。ステップ８２０において、描画機能モジュール２８０は、画素ｑにおける適切な拡散色値を得るために、参加者Ａについてのカスタマイズ可能オブジェクト（この場合オブジェクト５３０）のテクスチャを参照し得る。テクスチャは、まずテクスチャＩＤを得るためにオブジェクトＩＤに基づきオブジェクトデータベース１１２０が参照されることにより識別され、そして画素ｑにおける拡散色値を得るために、該得られたテクスチャＩＤに基づきテクスチャデータベース１１９０が参照されるものであってよい。結果である拡散色値は、DiffuseColor_530Aqで示される。具体的には、DiffuseColor_530_Aqは（参加者Ａについて）画素ｑに対応する点におけるオブジェクト５３０のテクスチャのサンプル値（あるいは補間値）で表され得る。
【０１０９】
ステップ８３０において、描画機能モジュール２８０は画素ｑに係る画素値を演算し得る。「画素値」との文言が、スカラや複数成分のベクトルを言及し得るものであることは留意されるべきである。非限定的な実施形態において、複数成分のベクトルのような構成要素は、色（または色相、彩度）、彩度（色自身の強度）、及び輝度であってよい。「強度」との文言は、場合によって輝度成分を表すために用いられる。他の非限定的な実施形態において、複数成分ベクトルの複数の構成要素は、ＲＧＢ（赤、緑及び青）であってもよい。１つの非限定的な実施形態において、画素ｑについてOutput_Aqで示される画素値は、拡散色に（一時記憶媒体からOutput_1qとして取得される）拡散光成分を増殖的に組み合わせ、さらに（一時記憶媒体からOutput_2qとして取得される）スペキュラ光成分及び環境光成分の和を加算することにより演算されるものであってもよい。即ち、
Output_Ap = (DiffuseColor_530_Aq * Output_1q) + Output_2q
となる。Output_Aqが画素ｑの複数成分（例えばＲＧＢ、ＹＣｂＣｒ等）の各々について分離して演算されるものであってもよいことは理解されるべきである。
【０１１０】
そしてステップ８４０において、参加者Ａについて、Output_Aqで示される画素ｑの画素値が参加者Ａのフレームバッファに格納される。
【０１１１】
同様に、参加者Ｂ及びＣについて、描画機能モジュール２８０はステップ８２０において画素ｑにおける適切な拡散色値を取得するため、各参加者についてのカスタマイズ可能オブジェクト（この場合オブジェクト５３０）のテクスチャにアクセスし得る。テクスチャは、まずテクスチャＩＤを取得するために、オブジェクトＩＤ及び参加者ＩＤに基づきオブジェクトデータベース１１２０を参照することにより識別され、そして画素ｑにおける拡散色値を得るために、該得られたテクスチャＩＤに基づいてテクスチャデータベース１１９０が参照されるものであってよい。参加者Ｂ及びＣについて画素ｑに係る、結果である拡散色値はそれぞれDiffuseColor_530_Bq及びDiffuseColor_530_Cqで示される。
【０１１２】
ステップ８３０において、描画機能モジュール２８０は、画素ｑに係る画素値を演算し得る。非限定的な実施形態において、参加者ＢについてOutput_Bq及び参加者ＣについてOutput_Cqで示される画素値は、拡散色に（一時記憶媒体からOutput_1qとして取得される）拡散光成分と増殖的に組み合わせ、さらに（一時記憶媒体からOutput_2qとして取得される）スペキュラ光成分と環境光成分との和を加算することにより演算されるものであってよい。即ち、
Output_Bq = (DiffuseColor_530_Bq * Output_1q) + Output_2q
であり、
Output_Cq = (DiffuseColor_530_Cq * Output_1q) + Output_2q
となる。Output_Bq及びOutput_Cqの各々が、画素ｑの複数成分（例えばＲＧＢ、ＹＣｂＣｒ等）の各々について分離して演算されるものであってもよいことは理解されるべきである。
【０１１３】
そしてステップ８４０において、参加者Ｂについて演算された画素ｑの画素値Output_Bqが参加者Ｂのフレームバッファに格納され、参加者Ｃと画素値Output_Cqについても同様である。
【０１１４】
画素値Output_Aq、Output_Bq及びOutput_Cqが異なることにより、カスタマイズ可能オブジェクト５３０は参加者Ａ、Ｂ及びＣにつき異なってシェーディングされることが、図１１に示される。
【０１１５】
故に、本発明の実施形態に係り、カスタマイズ可能オブジェクトの画素の計算集約的な放射輝度演算の決定は全ての参加者について一度なされ、画素値は各参加者について異なって終了することは理解されよう。
【０１１６】
カスタマイズ可能オブジェクト５３０に係る放射輝度／照明演算（例えばDiffuseLightingq、SpecularLightingq、AmbientLightingq）は参加者毎というよりはむしろ参加者のグループ毎に、（第１のパスにおいて）一度なされるため、このことはカスタマイズ可能オブジェクト５３０の複数の「配列」の生成において、演算量の低減を導き得る。例えば、カスタマイズ可能オブジェクト５３０の任意の画素ｑの各々について、Output_1q及びOutput_2qは一度演算され、そして共通のOutput_1q及びOutput_2qの値に基づき、参加者Ａ、Ｂ、Ｃの各々について、（第２のパスにおいて）分離してOutputqが演算される。
【０１１７】
［変形例１］
変形例として、ステップ１０２０においてプリシェーディング値が格納される一時記憶媒体は、１人の参加者についての最終画像データが格納されるフレームバッファであってもよい。故に、ステップ１０２０は真の画素値が格納される以外の目的で、画素ｑに対応するフレームバッファのデータ要素を使用することにより実現される。例えば、画素ｑに対応するデータ要素は、色情報（例えばＲ、Ｇ、Ｂ）について通常用意される成分と、透過情報（α）について通常用意される他の成分とを含むものであってよい。
【０１１８】
具体的には、及び非限定的な例では、スペキュラ光及び環境光成分は、輝度（ＹＣｂＣｒ空間において「Ｙ」として参照）のような単一の値（スカラー）に縮小される。この場合、Output_1qは３つの成分を有するが、Output_2qは１つのみを有する。結果として、画素ｑについての単一の４フィールドデータ構造に、画素ｑについてのOutput_1qとOutpuut_2qとを格納することが可能であろう。故に、例えば各画素に４フィールドＲＧＢＡ配列（ここで「Ａ」はαまたは透過成分を表す）が割り当てられる場合、「Ａ」フィールドはOutput_2q値を格納するために取り込まれ得る。さらにこのことは、一般オブジェクトに関係するこれらの画素「ｐ」に係る３次元値のOutputpと、カスタマイズ可能オブジェクトに関係するこれらの画素ｑについて同時に格納する３次元値のOutput_1qと１次元値のOutput_2qとの双方を格納するために、４次元のエントリを用いる単一バッファを許容しうる。
【０１１９】
これを示すために、各参加者Ａ及びＢについて１つである、２つのフレームバッファそれぞれを示す図１２を非限定的に参照する。フレームバッファの各々は、４成分の画素値を有する画素を含む。図１２は、以下のステージにおける、１２００Ａ、１２００Ｂにおいて画素ｐ及びｑの内容の変化を示しており：
１２１０：  一般オブジェクト５２０の描画に加えてステップ８４０の後。なお、オブジェクト５２０についての画素は、オブジェクト５２０に係る最終画素値（強度／色）を含む。これらは一度演算され、両フレームバッファに複製される。
１２２０：  カスタマイズ可能オブジェクト５３０についての第１の処理パスに加えてステップ１０２０の後。なお、オブジェクト５３０についての画素は、オブジェクト５３０に係るプリシェーディング値を含む。これらは一度演算され、両フレームバッファに複製される。
１２３０：  カスタマイズ可能オブジェクト５３０についての第２の処理パスに加えてステップ８４０の後。なお、オブジェクト５３０についての画素は、参加者の各々について異なる、オブジェクト５３０に係る最終画素値（強度／色）を含む。
【０１２０】
従って、処理の重要な部分は共有され得、放射輝度（照明）が演算されてカスタマイズを実行することができれば、放射輝度演算の共有を考慮しないカスタマイズに比べ、演算効率化の観点で潜在的に著しい改良が導かれることは理解されよう。
【０１２１】
［変形例２］
さらに、カスタマイズ可能オブジェクトが全ての参加者についてカスタマイズされる必要がないことは理解されるべきである。また、任意の数の参加者（全ての参加者よりも少なくてよい）の画面描画範囲内のカスタマイズ可能オブジェクトが、これら全ての参加者について異なるようカスタマイズされる必要もない。特に、任意のオブジェクトについて、参加者の第１のサブセットについて１つの手法、参加者の他のサブセットについて他の手法でカスタマイズされる、または複数の異なるオブジェクトについて、任意の観察者と同一の手法でカスタマイズされるようにもできる。例えば、３人の参加者Ａ、Ｂ、Ｃ、１つの一般オブジェクト５２０（手前）及び２つのカスタマイズ可能オブジェクトＥ、Ｆを考慮する。カスタマイズ可能オブジェクトＥが参加者Ａ及びＢについて任意の手法でカスタマイズされるが、参加者Ｃについては異なる手法でカスタマイズされるようにしてもよい。同時に、カスタマイズ可能オブジェクトＦは参加者Ａ及びＣについて任意の手法でカスタマイズされるが、参加者Ｂについては異なる手法でカスタマイズされるようにすることもできる。この場合、カスタマイズ可能オブジェクトＥについての描画処理が、参加者Ａ及びＢについて集約的に実行され、カスタマイズ可能オブジェクトＦについての描画処理が、参加者Ａ及びＣについて集約的に実行される。
【０１２２】
従って、照明効果が保たれている間、カスタマイズされたオブジェクトの描画をより効率的に描画するための方法が開示された。故に、同一の放射輝度を保つカスタマイズの種別は、設定、人口統計、位置等に基づいて異なるテクスチャを用いて異なる参加者に提供するという状況は有用であろう。例えば参加者は、同一の臨場効果を有するが、異なる色や異なるロゴ、フラッグ、デザイン、言語等を有する態様で同一のオブジェクトを観賞することができる。いくつかの態様では、カスタマイズは、例えば年齢や地域基準により訂正される必要である、「グレーアウト」または「暗化（darken）」オブジェクトにも、カスタマイズは用いることができる。このような個人レベルのカスタマイズを用いる場合であっても、参加者により求められ、かつ正確かつ複雑な照明演算に起因するリアリズムは妥協されない。
【０１２３】
［変形例３］
上記説明した態様では、一般オブジェクト及びカスタマイズ可能オブジェクトの各々を、描画機能モジュール２８０が別々に描画する方法について説明した。一方で、照明のようなエフェクトも含めてカスタマイズする場合については、一般オブジェクトには共通のエフェクト、カスタマイズ可能オブジェクトの各々には各観戦者が所望するエフェクトを適用することになる。このような場合、これらの処理により生成された画素で構成された画面は、一部のオブジェクトのみがエフェクトが異なる不自然な画面が生成されうる。極端な例では、一般オブジェクトが大半を占めている場合において、１つのカスタマイズ可能オブジェクトのみが異なる方向からの光源による照明効果を含めて描画された場合、該カスタマイズ可能オブジェクトは画面において観戦者に異質な印象を与えうる。
【０１２４】
従って、本変形例では、カスタマイズ可能オブジェクトについて適用される照明等のエフェクトを一般オブジェクトにも反映させることで、生成される画面における違和感を低減させる方法について説明する。
【０１２５】
具体的にはまず、複数の観戦者に提供する画面の演算量を低減するために、一般オブジェクトについては、上述した実施形態と同様に生成する。その後、例えばカスタマイズ可能オブジェクトについて定義される照明を考慮してカスタマイズ可能オブジェクトを描画する処理を行う際に、該照明を既に描画した一般オブジェクトにも適用した場合に生じるエフェクトに係る演算も行う。一般オブジェクトに適用した場合のエフェクト係る演算は、例えばDeferred Rendering等により描画を行う場合には、描画範囲に係る各種G-Bufferが生成されているため、カスタマイズにより定義された照明による各画素の輝度変化等は容易に演算することができる。故に、カスタマイズ可能オブジェクトの描画とともに既に描画された画素にこれらの輝度変化等による画素値を例えば加算すればよい。
【０１２６】
このようにすることで演算量は多少増加するものの、カスタマイズ可能オブジェクトについて適用されたその他のエフェクトにより画面全体に生じる違和感を低減することもできる。
【０１２７】
なお、一般オブジェクトとカスタマイズ可能オブジェクトに係る描画処理の順番が上述した実施形態や変形例で言及されたが、順番は描画機能モジュール２８０の態様に応じて変化されるものであってよい。例えば、一般オブジェクトに係る描画処理が参加者について集中的に行われ、一般オブジェクトの描画結果が単一のフレームバッファに格納される場合、該処理の終了後、各参加者についてのフレームバッファが該単一のフレームバッファを複製することにより生成されてもよい。この場合、各参加者に依存するカスタマイズ可能オブジェクトに係る描画処理は分離して実行され、カスタマイズ可能オブジェクトについての描画結果は参加者に対応するフレームバッファに格納される。一方で、例えば、一般オブジェクトについての描画結果が（複数の参加者の）複数のフレームバッファの各々に格納される場合、カスタマイズ可能オブジェクトに係る描画処理は、一般オブジェクトについての描画の終了を待たずに実行され得る。即ち、両描画処理は並行して実行され、各参加者についてのゲーム画面が該参加者に対応するフレームバッファに生成される。
【０１２８】
［その他の実施形態］
例示的な実施形態を参照して本発明を説明してきたが、記載した例示的な実施形態に発明が限られるものでないことは理解されよう。以下の特許請求の範囲は、このような変形、等価な構成及び機能の全てを包含するように、広範な解釈を許容されよう。また、本発明に係る情報処理装置及び制御方法は、コンピュータにおいて該手法が実行されるプログラムにより実現可能である。プログラムは、コンピュータ読み取り可能な記録媒体に格納されることで、または電気的な通信回線を介して、提供／配信可能である。
【０１２９】
本出願は、その全体がここに参照により援用される、２０１３年９月１１日に出願された米国仮出願第６１／８７６３１８号の利益を主張するものである。
【図１Ａ】
0006341986.tif 000002
【図１Ｂ】
0006341986.tif 000003
【図２Ａ】
0006341986.tif 000004
【図２Ｂ】
0006341986.tif 000005
【図２Ｃ】
0006341986.tif 000006
【図３Ａ】
0006341986.tif 000007
【図３Ｂ】
0006341986.tif 000008
【図３Ｃ】
0006341986.tif 000009
【図４Ａ】
0006341986.tif 000010
【図４Ｂ】
0006341986.tif 000011
【図５】
0006341986.tif 000012
【図６Ａ】
0006341986.tif 000013
【図６Ｂ】
0006341986.tif 000014
【図７】
0006341986.tif 000015
【図８】
0006341986.tif 000016
【図９】
0006341986.tif 000017
【図１０Ａ】
0006341986.tif 000018
【図１０Ｂ】
0006341986.tif 000019
【図１１】
0006341986.tif 000020
【図１２】
0006341986.tif 000021