JP2016527576A - 情報処理装置、制御方法、プログラム及び記録媒体 - Google Patents

Abstract

情報処理装置は、描画装置に画面を描画させるための描画命令を取得し、取得した描画命令を記録する。また情報処理装置は、記録した描画命令を、画面を描画する描画装置に出力する。

Description

本発明は、情報処理装置、制御方法、プログラム及び記録媒体に関し、特に画面描画のシミュレーション技術に関する。

電子ゲームやソフトウェアアプリケーション等のプログラムは、その開発過程において仕様等により定められた所望の動作や機能が実現されるか否か、あるいは機能実現に係るハードウェアに与える負荷等の試験がなされる。またプログラムの中には、実際に製品としてリリース（販売や配信）されて一般のユーザが使用するまでの間にも、１段階以上のフェーズにおいて、実際に複数人のテストユーザに使用させて同様の項目を試験することがなされる。

後者の試験は、特にＭＭＯＲＰＧ等のサーバを介して提供がなされるサービスに係るプログラムにおいて行われる。通常、後者の試験は、製品の一部の機能を限定的なユーザに自由に操作させることにより行われる所謂「αテスト」、製品の一部または全ての機能を限定的または非限定的なユーザに自由に操作させることにより行われる「βテスト」があり、設定された期間内においてユーザ操作等に起因して生じる挙動が試験される。

ところで、上述したような試験では、所望の動作や機能が実現されなかった場合、あるいは想定外の動作が発見された場合、同一の動作等が再現される状況（操作パターン、負荷状況等）を特定し、必要な修正を行い、再度同一の状況に至った際に改善された（所謂バグフィックス）か否かをチェックする。しかしながら、バグフィックスのチェックのために再度同一の状況に至らしめることは必ずしも容易でない条件を要する場合がある。このため、現実的にはユーザの操作入力等をログ（キーやボタン入力等の履歴）として記録しておき、チェック時には該ログを再生することにより、同一の状況を再現する手法がとられている（特開２０１２−０６３８１８号公報、特開２０１３−１４９１７８号公報）。

しかしながら、このような操作入力のログを使用する場合、同一の状況が再現されない場合がありえる。通常、画面描画を伴うようなプログラムでは、画面の更新頻度（フレームレート）により決定される１フレーム期間内に、画面描画に必要なパラメータの更新処理や描画を行うハードウェアへの命令、及び該ハードウェアによる描画処理を完了させることが理想的である。一方で、画面に描画されるオブジェクト数が多い場合や同時に行われるスレッド数が多い場合等、表示フレームレートと処理フレームレートとが異なる状況が生じうる。つまり、表示更新間隔と各フレームに係る処理が完了する時間間隔とは様々なパラメータによって変動し得る。従って、操作入力のログを記録した際の処理フレームレートと、チェック時の処理フレームレートが異なっていた場合、処理にずれが蓄積していき、同一の状況を再現することが困難であった。特に、画面の描画内容に係るバグフィックスを目的とする試験の場合、描画周りの処理の修正によりバグフィックスしたのか、あるいはフレーム変動を含む別の要因により所望の動作が実現されたのかを特定できない可能性があった。

本発明はこのような従来技術の課題に鑑みてなされたものである。本発明は、同一の描画内容を再現する情報処理装置、制御方法、プログラム及び記録媒体を提供する。

本発明の第１の態様は、描画手段に画面を描画させるための描画命令を取得する取得手段と、取得手段により取得された描画命令を記録する記録手段と、記録手段により記録された描画命令を、画面を描画する描画手段に出力する出力手段と、を有する情報処理装置を提供する。

本発明の第２の態様は、描画手段に画面を描画させるための描画命令を取得する取得工程と、取得工程において取得された描画命令を記録する記録工程と、記録工程において記録された描画命令を、画面を描画する描画手段に出力する出力工程と、を有する情報処理装置の制御方法を提供する。

さらに、本発明の特徴は、（添付の図面を参照して）以下の例示的な実施形態の記載により明らかになるだろう。

添付図面は明細書に含まれ、その一部を構成し、本発明の実施の形態を示し、その記述と共に本発明の原理を説明するために用いられる。

本発明の非限定的な実施形態に係る、サーバシステムを含むクラウド型ビデオゲームシステムアーキテクチャのブロック図 本発明の非限定的な実施形態に係る、ゲームプレイ中におけるデータネットワークを介したクライアント装置のセットとのインタラクションを示した、図１Ａのクラウド型ビデオゲームシステムアーキテクチャのブロック図 本発明の非限定的な実施形態に係る、図１Ｂのアーキテクチャの様々な物理的構成要素を示したブロック図 図２Ａの変形例 図２Ａ及び２Ｂの物理的構成要素により実現され得、かつゲームプレイ中に動作しうる、図１Ｂのアーキテクチャにおけるサーバシステムの様々なモジュールを示したブロック図 、 、 本発明の非限定的な実施形態に係る、描画命令ジェネレータにより行われるビデオゲーム処理セットの実行を示したフローチャート 、 本発明の非限定的な実施形態に係る、受信した映像及び音声の各々を処理するためのクライアント装置の動作を示したフローチャート 少なくとも１つの実施形態に係る描画サーバ２００Ｒの機能構成を簡易的に示したブロック図 少なくとも１つの実施形態の描画サーバ２００Ｒにおいて実行される、画面描画処理を例示したフローチャート

図１Ａは、本発明の非限定的な実施形態に係るクラウド型ビデオゲームシステムアーキテクチャを概略的に示している。該アーキテクチャは、インターネット１３０等のデータネットワークを介してサーバシステム１００のような情報処理装置に接続されたクライアント装置１２０ｎ（ｎは１≦ｎ≦Ｎであり、Ｎはビデオゲームに参加しているユーザ数を示す）を含みうる。クラウド型システムアーキテクチャ内のクライアント装置の数Ｎは特に限定されるものではないことは理解されるべきである。

サーバシステム１００は、複数のクライアント装置のユーザにより同時に観賞され得る仮想空間を提供する。場合によっては、該仮想空間はビデオゲームを示し得、あるいはコミュニケーションをサポートするツールまたはコミュニケーションにおけるユーザ体験を改良するツールとして用いられる視覚的効果を提供し得る。各ユーザは、仮想空間内に配置された対応するアバタを操作し、該空間内を移動できる。ユーザが仮想区間内でアバタを操作する際、該空間内に設定された視点についての画面が、該ユーザのクライアント装置に提供される。該視点は、予め定められた固定の視点から選択される、またはユーザによるアバタの移動操作に係り変更されるものであってよい。

クライアント装置１２０ｎ（１≦ｎ≦Ｎ）の構成は、特に限定されるものではない。いくつかの実施形態において、１以上のクライアント装置１２０ｎ（１≦ｎ≦Ｎ）は、パーソナルコンピュータ（ＰＣ）、家庭用ゲーム機（コンソール）、携帯ゲーム機、スマートテレビ、セットトップボックス（ＳＴＢ）等であってもよい。他の実施形態において、１以上のクライアント装置１２０ｎ（１≦ｎ≦Ｎ）は、携帯電話、電子手帳（ＰＤＡ）、タブレットのような通信または計算装置であってもよい。

クライアント装置１２０ｎ（１≦ｎ≦Ｎ）の各々は、各々のローカルアクセスネットワーク（不図示）を介することを含む、あらゆる好適な方式でインターネット１３０に接続していてもよい。また、サーバシステム１００は、ローカルアクセスネットワーク（不図示）を介してインターネット１３０に接続してもよいが、サーバシステム１００はローカルアクセスネットワークの媒介なく、インターネット１３０と直接接続してよい。サーバシステム１００と１以上のクライアント装置１２０ｎ（１≦ｎ≦Ｎ）との接続は、１以上のチャネルを含んでいてもよい。これらのチャネルは、物理的及び／または論理的リンクによりなされ、無線周波数、光ファイバ、光空間（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）及び／またはバージョンが、該映像データを伝送する１以上のパケットのコンテンツ内に符号化されてもよい。符号化映像データの他の送信手法は、本技術分野に属する当業者には思い当たるかもしれない。

本開示は個々が２Ｄ画像を示す映像データの描画にフォーカスするものであるが、本発明は３次元効果を生成するために、フレームごとに複数の２Ｄ画像を示す映像データの描画の可能性を除外するものではない。

《６．クライアント装置におけるゲーム画面再生》
以下、非限定的な例示の目的で、クライアント装置１２０ｎ（１≦ｎ≦Ｎ）のいずれかであってよい、任意のユーザに関連付けられたクライアント装置により実行されうるクライアント側ビデオゲームアプリケーションの動作を示す図４Ａを参照する。動作にあたり、クライアント側ビデオゲームアプリケーションは、非限定的な２〜３の可能性を挙げると、クライアント装置により直接実行可能であってもよいし、Ｗｅｂブラウザにおいて起動してもよい。

動作４１０Ａで、（グラフィックス出力ストリーム２０６ｎ（１≦ｎ≦Ｎ）のうちの）１つのグラフィックス出力ストリームは、実施形態に応じて描画サーバ２００Ｒ（図２Ａ）から、あるいはハイブリッドサーバ２００Ｈ（図２Ｂ）から、インターネット１３０を介して受信されてもよい。受信されたグラフィックス出力ストリームは複数のフレームに分割されうる圧縮／符号化された映像データを含みうる。

動作４２０で、映像データの圧縮／符号化されたフレームは、符号化／圧縮処理に用いられた符号化／圧縮アルゴリズムを補間する展開アルゴリズムに従って復号／展開される。非限定的な実施形態において、映像データの符号化／圧縮に用いられた符号化／圧縮アルゴリズムの身元またはバージョンは、予め知らされていてもよい。他の実施形態において、映像データの符号化／圧縮に用いられた符号化／圧縮アルゴリズムの身元またはバージョンは、映像データ自体が添付されてもよい。

動作４３０Ａで、映像データの（復号／展開された）フレームが処理されうる。これは、バッファへの映像データの復号／展開されたフレームの配置、誤り訂正、複数の連続するフレームにおけるデータの順序付け及び／または合成、アルファブレンディング、欠損したデータの一部の補間等を含みうる。該結果は、毎フレーム基準でユーザに提示される最終画像を示す映像データとなり得る。

動作４４０Ａで、最終画像がクライアント装置の出力機構を介して出力されうる。例えば、コンポジット映像フレームが、クライアント装置のディスプレイに表示されうる。

《７．音声生成》
以下、音声生成処理として言及される３番目の処理が、図３Ｃを参照して説明される。音声生成処理は、知覚可能な音声ストリームを要求する各ユーザについて、継続的に実行されうる。一実施形態において、音声生成処理はグラフィックス制御プロセス３００Ｂと無関係に実行されてよい。他の実施形態において、音声生成処理及びグラフィックス制御処理の実行が連動されてもよい。

動作３１０Ｃで、描画命令ジェネレータ２７０は、生成される音声を決定しうる。具体的に該動作は、音量（音の強さ）及び／または仮想世界内においてユーザへの近さに応じて、地形音響特性に影響を及ぼす仮想世界内のオブジェクトに関連付けられたこれらの音声を特定することを含みうる。

動作３２０Ｃで、描画命令ジェネレータ２７０は音声セグメントを生成しうる。音声セグメントの継続期間は映像フレームの継続期間に及んでもよいし、いくつかの実施形態では音声セグメントは映像フレームよりも少ない頻度で生成されてもよいし、他の実施形態では音声セグメントは映像フレームよりも高い頻度で生成されてもよい。

動作３３０Ｃで、音声セグメントは例えば音声符号化器により符号化され得、符号化音声セグメントが得られる。音声符号化器は、音声圧縮または展開アルゴリズムを可能にする、実行する、または定義する装置（または命令セット）であってもよい。音声圧縮は、（徐々に振幅及び位相が変化する音波として表現される）デジタル音声のオリジナルストリームを、より少ないビットを使用するが実質的に同一の情報を伝送するデジタル音声データの出力ストリームに変換しうる。あらゆる適切な圧縮アルゴリズムが用いられてよい。音声圧縮に加え、特定の音声セグメントの符号化に用いられる符号化処理は暗号化を適用してもよいし、しなくてもよい。

いくつかの実施形態において、音声セグメントは計算サーバ２００Ｃ（図２Ａ）またはハイブリッドサーバ２００Ｈ（図２Ｂ）のいずれかの専用ハードウェア（例えばサウンドカード）により生成されてもよいことは理解されるべきである。図２Ａの分散型構成に適用可能な代替的実施形態において、音声セグメントは描画命令ジェネレータ２７０によりスピーチパラメータ（例えばＬＰＣパラメータ）にパラメータ化されてもよく、スピーチパラメータは描画サーバ２００Ｒにより、配信先のクライアント装置（例えばクライアント装置１２０またはクライアント装置１２０Ａ）に再配信されうる。

上述した方式で生成された符号化された音声は、インターネット１３０を介して送信される。非限定的な例示を目的として、符号化された音声入力は、各々がヘッダ及びペイロードを有するパケットに分解及び形式化されうる。ヘッダは、音声生成処理が実行されるユーザに関連付けられたクライアント装置のアドレスを伝送してもよく、ペイロードは符号化された音声を含んでいてもよい。非限定的な実施形態において、任意の音声セグメントの符号化に用いられる圧縮アルゴリズムの身元及び／またはバージョンは、該任意のセグメントを伝送する１以上のパケットのコンテンツ内に符号化されてもよい。符号化された音声を送信する他の手法は、本技術分野に属する当業者には思い当たるかもしれない。

以下、非限定的な例示を目的として、クライアント装置１２０ｎ（１≦ｎ≦Ｎ）のいずれかであってよい、任意のユーザに関連付けられたクライアント装置の動作を示す図４Ｂを参照する。

動作４１０Ｂで、符号化された音声セグメントが（実施形態に応じて）計算サーバ２００Ｃ、描画サーバ２００Ｒ、またはハイブリッドサーバ２００Ｈから受信されうる。動作４２０Ｂで、符号化処理に用いられた圧縮アルゴリズムを補間する展開アルゴリズムに従って、符号化された音声は復号されうる。非限定的な実施形態において、音声セグメントの符号化に用いられた圧縮アルゴリズムの身元またはバージョンは、音声セグメントを伝送する１以上のパケットのコンテンツ内で特定されてもよい。

動作４３０Ｂで、（復号された）音声セグメントが処理されうる。これは、バッファ内への復号された音声セグメントの配置、誤り訂正の実行、複数の連続する波形合成等を含みうる。該結果は、毎フレーム基準でユーザに提示される最終音声となり得る。

動作４４０Ｂで、最終的に生成された音声は、クライアント装置の出力機構を介して出力されうる。例えば、音声はクライアント装置のサウンドカードまたはスピーカを介して再生されうる。

《８．非限定的な実施形態の具体的開示》
以下、本発明の例示的な実施形態について、図面を参照して詳細に説明する。なお、以下に説明する一実施形態では簡単のため、図２Ａに示したような、ゲームコンテンツに係る種々の演算を行い描画命令を送出する描画命令ジェネレータ２７０としての計算サーバ２００Ｃと、計算サーバ２００Ｃから送出された描画命令に基づいて画面の描画処理を行う描画機能モジュール２８０としての描画サーバ２００Ｒとの構成に係り、描画サーバ２００Ｒにおいて行われる処理を例に説明する。つまり、以下では情報処理装置の一例としての、取得した描画命令に基づいた画面描画処理を行う描画サーバ２００Ｒに、本発明を適用した例を説明する。しかし、本発明は、図２Ａのような構成に限られるものではなく、画面の描画を行うハードウェアに対して描画命令がなされるものであれば、描画命令を行うエンティティ（描画命令ジェネレータ２７０）と画面の描画を行うエンティティ（描画機能モジュール２８０）とが一体の装置内に設けられるような構成であっても適用可能である。即ち、本発明は、いずれかの手法により描画命令を取得し、該描画命令に基づいた画面描画処理を行う任意の機器に適用可能である。

《描画サーバ２００Ｒの構成》
図５は、本発明の実施形態に係る描画サーバ２００Ｒの機能構成を示すブロック図である。描画サーバ２００Ｒの概要については上述した通りだが、図５では、本実施形態において特徴的な動作をする描画サーバ２００Ｒ内の機能構成について、より簡略的かつ詳細を示したものである。

図５に示されるように、本実施形態において描画サーバ２００Ｒは、図２Ａに示した構成を代替する構成を含む複数の機能構成を有する。図２Ａとの関係においてＣＰＵ５０１はＣＰＵ２２０ＲまたはＣＰＵ２２２Ｒを、メモリ５０３はＲＡＭ２３０Ｒを、ＧＰＵ５０７はＧＰＵ２４０ＲまたはＧＰＵ２５０Ｒを、ＶＲＡＭ５０８はＶＲＡＭ２４６ＲまたはＶＲＡＭ２５６Ｒを、通信部５０４はＮＩＣ２１０Ｒ１または２１０Ｒ２を代替する。

通信部５０４は、描画サーバ２００Ｒが有する外部装置との通信インタフェースである。通信部５０４は、本実施形態では計算サーバ２００Ｃから描画命令、及び該描画命令により描画した画面の送付先（クライアント装置１２０）を特定するための情報とを受信する。また通信部５０４は、対応するクライアント装置１２０に対して描画命令に基づいて描画された画面データをグラフィックス出力２０６として送信する。

記憶媒体５０２は、例えばメモリ５０３とは異なり恒久的にデータを記憶する、不揮発性メモリやＨＤＤ等の記憶装置である。本実施形態では画面の描画に必要な、各種描画オブジェクトに係るデータ（モデルデータ、テクスチャデータ、描画プログラム等）は記憶媒体５０２に予め記憶されているものとして説明する。しかしながら、本発明の実施はこれに限られるものでなくてよく、各種描画オブジェクトに係るデータは、計算サーバ２００Ｃから受信して記憶媒体５０２に格納されるものであってもよいし、特定の外部装置から通信部５０４を介して取得されるものであってもよい。

セレクタ５０５はＣＰＵ５０１の制御の下、描画命令の取得及び伝送先への伝送の動作を制御する。セレクタ５０５は、通信部５０４を介して描画命令を取得した場合、該描画命令を描画機能モジュール２８０であるＣＰＵ５０１あるいはＧＰＵ５０７に伝送する。またこのときセレクタ５０５は、取得した描画命令を蓄積部５０６に伝送する。蓄積部５０６は、計算サーバ２００Ｃから発行された描画命令を、その発行タイミングあるいはその受信タイミング、及び対応する画面の送信先を特定する情報に関連付けて時系列順に蓄積する。言い換えれば、蓄積部５０６は、発行された描画命令のログをクライアント装置１２０ごとに蓄積するデータベースである。一方、描画サーバ２００Ｒにおいてテストモードの実行が選択された場合、通信部５０４が描画命令を取得しないため、セレクタ５０５は、蓄積部５０６に蓄積された描画命令を、時系列順に取得して描画機能モジュール２８０であるＣＰＵ５０１あるいはＧＰＵ５０７に伝送する。なお、本実施形態では簡単のため描画サーバ２００Ｒにおいてテストモードの実行が選択された場合、通信部５０４が描画命令を取得しないものとして説明するが、本発明の実施はこれに限られるものではない。即ち、テストモードはクライアント装置１２０へのサービス提供（画面提供）と並行して実行されてもよく、テストモードにおいても通信部５０４が描画命令を取得してもよいことは理解されよう。本実施形態の描画サーバ２００Ｒでは、このように動作するセレクタ５０５及び蓄積部５０６を設けることにより、一度なされた描画命令と同様の描画処理をテストモードにおいて再現することができる。即ち、上述したように同一の描画内容がなされる状況を再現することができる。従って、例えば描画命令を固定とした上で、描画周りの処理に係るデバッグを行うこともできる。

《画面描画処理》
このような構成をもつ本実施形態の描画サーバ２００Ｒの画面描画処理について、図６のフローチャートを用いて具体的な処理を説明する。該フローチャートに対応する処理は、ＣＰＵ５０１が、例えば記憶媒体５０２に記憶されている対応する処理プログラムを読み出し、メモリ５０３に展開して実行することにより実現することができる。なお、本画面描画処理は、例えば通信部５０４が描画命令を受信した際、あるいはテストモードに描画サーバ２００Ｒが設定された際に開始されるものとして説明する。

Ｓ６０１で、ＣＰＵ５０１は、現在描画サーバ２００Ｒがテストモードに設定されているか否かを判断する。描画サーバ２００Ｒがテストモードに設定されていると判断した場合、ＣＰＵ５０１は処理をＳ６０４に移す。描画サーバ２００Ｒがテストモードに設定されていないと判断した場合、ＣＰＵ５０１は処理をＳ６０２に移す。

Ｓ６０２で、セレクタ５０５はＣＰＵ５０１の制御の下、通信部５０４が受信した描画命令（対象命令）を描画機能モジュール２８０に伝送するとともに、例えば受信タイミング及び対応するクライアント装置１２０（対象機器）を特定する情報を関連付けて対象命令を蓄積部５０６に伝送し、格納させる。

Ｓ６０３で、描画機能モジュール２８０は、ＣＰＵ５０１及びＧＰＵ５０７が連動して、受信した対象命令に基づき、対象機器に送信する画面の描画処理を行う。描画処理の完了後、例えばＧＰＵ５０７は描画した画面に係るデータを出力し、本画面描画処理を完了する。

一方、Ｓ６０１において描画サーバ２００Ｒがテストモードになされていると判断した場合、セレクタ５０５はＳ６０４で、蓄積部５０６から関連付けられている時系列順に対象機器に係る描画命令の順次取得を開始する。なお、本実施形態の画面描画処理では、簡単のため１台の対象機器についての描画命令のログが蓄積部５０６に蓄積されるものとして説明する。しかしながら、本発明の実施はこれに限られるものではなく、例えば複数人により同時プレイされるゲームに係るテストを行う場合、蓄積部５０６には複数のクライアント装置１２０の各々について描画命令のログが蓄積される構成であってよい。

Ｓ６０５で、セレクタ５０５は、取得した描画命令に関連付けられていた受信タイミングの情報に基づいて、順次取得した描画命令を対象命令として描画機能モジュール２８０に伝送する。受信タイミングの情報は、連続して蓄積部５０６に格納された描画命令を描画機能モジュール２８０に送出するタイミングの相対関係を示すために用いられる。即ち、例えば３５ｍｓの間隔で受信した描画命令ＡとＢとは、それらの受信タイミングの差分から３５ｍｓの情報を取得できるため、セレクタ５０５は取得した描画命令Ａを送出した後、不図示の内蔵タイマで３５ｍｓの経過後に描画命令Ｂを送出すればよい。

Ｓ６０６で、描画機能モジュール２８０は、受信した対象命令に基づき、画面の描画処理を行う。描画処理の完了後、例えばＧＰＵ５０７は描画した画面に係るデータを出力する。なお、本ステップにおいて生成する画面は、テストを目的としたものであるため、対象機器へは必ずしも送信される必要はない。

Ｓ６０７で、ＣＰＵ５０１は、セレクタ５０５がまだ送出していない描画命令が蓄積部５０６に存在するか否かを判断する。まだ送出していない描画命令が存在すると判断した場合、ＣＰＵ５０１は処理をＳ６０５に戻す。送出していない描画命令が存在しないと判断した場合、ＣＰＵ５０１は本画面描画処理を完了する。

本処理により、本実施形態の描画サーバ２００Ｒは実際に受信した描画命令を蓄積部５０６に保持し、テストモードにおいて該描画命令を蓄積部５０６から取得し、例えば受信したタイミングに従って描画機能モジュール２８０への描画命令の送出を実現することができる。即ち、従来のクライアント装置１２０によりなされた操作入力のログを記録して処理を行う場合に比べて、同一の描画内容が再現されるように画面描画処理のテストを行うことができる。

さらに、本実施形態で例示したように計算サーバ２００Ｃと描画サーバ２００Ｒ、即ち描画命令ジェネレータ２７０と描画機能モジュール２８０が分離されているシステム構成においては、本実施形態で説明したように描画命令を格納してテストを行うことで、ゲームコンテンツに係る全体処理において生じたバグが、いずれの機器が原因であるかを分離してデバッグすることができる。つまり、描画命令の生成に係る処理あるいはハードウェアに問題があるのか、描画命令に基づいて画面描画処理を行う処理あるいはハードウェアに問題があるかを分別してデバッグを行うことができる。

なお、本実施形態では同一の描画内容の再現を行うために、描画命令を格納するものとして説明したが、格納した描画命令はこれ以外にも利用可能である。例えば、描画サーバ２００Ｒが複数のクライアント装置１２０に係る画面の描画処理を並行実行する際の負荷テストとして、複数のクライアント装置１２０の各々について蓄積部５０６に格納された描画命令を、受信タイミングに応じて並行して描画機能モジュール２８０に送出してもよい。この際、送出した描画命令は同時期に取得されたもの、同一のゲームコンテンツに係り取得されたものに限られる必要はなく、所望の負荷条件に応じて選択されてよい。また、上述したようにαテスト（ゲームプレイ）等では限定的な人数のユーザについてしか描画命令の格納をすることができないが、このような場合であってもゲームプレイ時よりも高い負荷を描画サーバ２００Ｒにおいて実現したい場合、取得した描画命令を複数出力する、即ち取得した１セットの描画命令を３セット等に増加して描画機能モジュール２８０に送出してもよい。これにより、並行して実行される画面の描画処理の数を簡易的に増加させることができるため、負荷発生時の描画サーバ２００Ｒにおける障害発生や描画される成果物である画面の画質への影響等を容易にテストすることができる。

以上説明したように、本実施形態の情報処理装置は同一の描画内容を再現することができる。情報処理装置は、描画装置に画面を描画させるための描画命令を取得し、取得した描画命令を記録する。また情報処理装置は、記録した描画命令を、画面を描画する描画装置に出力する。

［その他の実施形態］
例示的な実施形態を参照して本発明を説明してきたが、記載した例示的な実施形態に発明が限られるものでないことは理解されよう。以下の特許請求の範囲は、このような変形、等価な構成及び機能の全てを包含するように、広範な解釈を許容されよう。また、本発明に係る情報処理装置及び制御方法は、１以上のコンピュータにおいて該手法が実行されるプログラムにより実現可能である。プログラムは、コンピュータ読み取り可能な記録媒体に格納されることで、または電気的な通信回線を介して、提供／配信可能である。

本出願は、その全体がここに参照により援用される、２０１３年８月６日に出願された米国仮出願第６１／８６２５９０号の利益を主張するものである。

Claims (10)

1. 描画手段に画面を描画させるために用いられ、ユーザ入力に基づいて生成された描画命令を取得する取得手段と、
   前記取得手段により取得された描画命令を記録する記録手段と、
   前記記録手段により記録された描画命令を複製し、画面を描画する前記描画手段に該複製した描画命令を出力する出力手段と、を有する情報処理装置。
2. 前記出力手段は、前記取得手段により描画命令が取得されない場合に、前記複製された描画命令を出力する請求項１に記載の情報処理装置。
3. 前記出力手段は、前記複製された描画命令を複数の前記描画手段に並行して出力する請求項１または２に記載の情報処理装置。
4. 前記記録手段は、前記取得された描画命令に関連付けて、該描画命令の生成または取得に対応するタイミング情報を記録し、
   前記出力手段は、関連付けられた前記タイミング情報に基づいて前記複製された描画命令を出力する請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記描画手段は前記情報処理装置に含まれ、
   前記出力手段により出力された前記複製された描画命令に基づいて前記描画手段により描画された画面、及び該画面が描画される際の前記情報処理装置における能力を評価する評価手段をさらに有する請求項１乃至４のいずれか１項に記載の情報処理装置。
6. 前記記録手段は、前記取得手段により取得された描画命令に基づいて前記描画手段により描画された画面の送信先の情報を記録し、
   前記出力手段は、１つの送信先について前記記録された描画命令を複製し、複製された複数の描画命令を前記描画手段に出力する請求項１乃至５のいずれか１項に記載の情報処理装置。
7. 前記取得手段は、外部機器から描画命令を取得する請求項１乃至６のいずれか１項に記載の情報処理装置。
8. 描画手段に画面を描画させるために用いられ、ユーザ入力に基づいて生成された描画命令を取得する取得工程と、
   前記取得工程において取得された描画命令を記録する記録工程と、
   前記記録手段により記録された描画命令を複製し、画面を描画する前記描画手段に該複製した描画命令を出力する出力工程と、を有する情報処理装置の制御方法。
9. 描画手段を有するコンピュータを含む１以上のコンピュータを、請求項１乃至７のいずれか１項に記載の情報処理装置の各手段として機能させるためのプログラム。
10. 請求項９に記載のプログラムを記録したコンピュータが読み取り可能な記録媒体。

Images