【文献】
ドリームキャスト インターネットガイド,日本,ソフトバンクパブリッシング株式会社,2000年 8月28日,初版,第098頁
【文献】
「プレイステーション 4」(PS4(TM))発表,株式会社ソニー・コンピュータエンタテインメント,2013年 2月21日,URL,http://www.scei.co.jp/corporate/release/130221a.html
(58)【調査した分野】(Int.Cl.,DB名)
前記記録手段により記録されたステートセーブデータのリンク情報、または外部装置により提供されたステートセーブデータのリンク情報に基づくアクセス要求を受信する受信手段をさらに有し、
前記実行手段は、前記受信手段によりアクセス要求が受信されたステートセーブデータを取得し、該データに対応するゲーム画面と同一のステートから前記ゲームに係る処理を実行する請求項2に記載のゲーム装置。
前記状況情報は、前記ステートセーブ要求に対応するゲーム画面に係る画面データ、動画データ及びゲームにおける状況を示すテキストデータの少なくともいずれかである請求項2または3に記載のゲーム装置。
前記記録工程において記録されたステートセーブデータのリンク情報、または外部装置により提供されたステートセーブデータのリンク情報に基づくアクセス要求を受信する受信工程をさらに有し、
前記実行工程において、前記受信工程においてアクセス要求が受信されたステートセーブデータが取得され、該データに対応するゲーム画面と同一のステートから前記ゲームに係る処理が実行される請求項9に記載のゲーム装置の制御方法。
前記状況情報は、前記ステートセーブ要求に対応するゲーム画面に係る画面データ、動画データ及びゲームにおける状況を示すテキストデータの少なくともいずれかである請求項9または10に記載のゲーム装置の制御方法。
【発明を実施するための形態】
【0010】
《1.クラウドゲーミングアーキテクチャ》
図1Aは、本発明の非限定的な実施形態に係るクラウド型ビデオゲームシステムアーキテクチャを概略的に示している。該アーキテクチャは、インターネット130等のデータネットワークを介してサーバシステム100に接続されたクライアント装置120、120Aを含みうる。2つのクライアント装置120、120Aのみが示されているが、クラウド型ビデオゲームシステムアーキテクチャ内のクライアント装置の数は特に限定されるものではないことは理解されるべきである。
【0011】
クライアント装置120、120Aの構成は、特に限定されるものではない。いくつかの実施形態において、1以上のクライアント装置120、120Aは、例えばパーソナルコンピュータ(PC)、家庭用ゲーム機(XBOX(登録商標)、PS3(登録商標)、Wii(登録商標)等のコンソール)、携帯ゲーム機、スマートテレビ、セットトップボックス(STB)等であってもよい。他の実施形態において、1以上のクライアント装置120、120Aは、携帯電話、電子手帳(PDA)、タブレットのような通信または計算装置であってもよい。
【0012】
クライアント装置120、120Aの各々は、各々のローカルアクセスネットワーク(不図示)を介することを含む、あらゆる好適な方式でインターネット130に接続していてもよい。また、サーバシステム100は、ローカルアクセスネットワーク(不図示)を介してインターネット130に接続してもよいが、サーバシステム100はローカルアクセスネットワークの媒介なく、インターネット130と直接接続してよい。サーバシステム100と1以上のクライアント装置120、120Aとの接続は、1以上のチャネルを含んでいてもよい。これらのチャネルは、物理的及び/または論理的リンクによりなされ、無線周波数、光ファイバ、光空間(free-space optical)、同軸ケーブル、及びツイストペアを含む様々な物理的媒体を回遊してもよい。チャネルはUDPやTCP/IPのようなプロトコルに従ってもよい。また、1以上のチャネルが、仮想プライベートネットワーク(VPN)でサポートされていてもよい。いくつかの実施形態では、1以上の接続はセッションベースでなされてもよい。
【0013】
サーバシステム100は、クライアント装置120、120Aのユーザが、ビデオゲームを個々に(即ち、シングルプレイヤ用ビデオゲーム)または集団で(即ち、マルチプレイヤ用ビデオゲーム)プレイすることを可能であってもよい。またサーバシステム100は、他のプレイヤによりプレイされるゲームを観戦することを、クライアント装置120、120Aのユーザに可能にさせてもよい。ビデオゲームの非限定的な例は、レジャー、教育及び/またはスポーツについてプレイされるゲームを含みうる。しかし、ビデオゲームは貨幣損益の可能性を参加者に提示する必要はない。
【0014】
またサーバシステム100は、ビデオゲームをテストする、及び/またはサーバシステム100を管理することをクライアント装置120、120Aのユーザに可能にさせてもよい。
【0015】
サーバシステム100は、場合によっては1以上のゲームサーバを含む1以上の演算リソースを含んでもよいし、場合によっては参加者データベース10を含む1以上のデータベースを有するあるいは該データベースにアクセスするものであってもよい。参加者データベース10は、識別データ、財務データ、位置データ、人口統計データ、接続データ等のような、様々な参加者及びクライアント装置120、120Aについてのアカウント情報を格納しうる。ゲームサーバは、共通のハードウェア内に統合される、あるいは場合によってはインターネット130を介することを含む通信リンクを介して接続される異なるサーバ群であってもよい。同様に、データベースはサーバシステム100内に統合される、あるいは場合によってはインターネット130を介する通信リンクを介してサーバシステム100に接続されるものであってもよい。
【0016】
サーバシステム100は、ゲームプレイより前等、ゲーム環境外のクライアント装置120、120Aとのインタラクションを扱うための管理アプリケーションを実装してもよい。例えば、該管理アプリケーションは、ユーザクラス(「プレイヤ」、「観戦者」、「管理者」または「テスター」等)に属する1つのクライアント装置120、120Aのユーザを登録し、インターネットを介してユーザの接続性が追跡され、ゲームのインスタンスを開始する、参加する、終了する、または終了させるために、非限定的ないくつかの機能のうちのユーザコマンドに応答する。該目的の達成のため、管理アプリケーションは参加者データベース10にアクセスする必要があってもよい。
【0017】
管理アプリケーションは、非限定的な2〜3の可能性を挙げると、「プレイヤ」、「観戦者」、「管理者」及び「テスター」を含む異なるユーザクラスのユーザと、異なるインタラクションをしてもよい。
【0018】
故に、一例において管理アプリケーションは、参加者データベース10へのアカウントの設定及びプレイするビデオゲームの選択をプレイヤ(即ち「プレイヤ」ユーザクラスのユーザ)が可能なように、プレイヤとのインタフェースとして機能しうる。該選択に従い、管理アプリケーションはサーバ側ビデオゲームアプリケーションを起動しうる。サーバ側ビデオゲームアプリケーションは、仮想世界内のキャラクタ、アバター、レースカー、コックピット等の制御をプレイヤに可能ならしめる、プレイヤについての機能モジュールセットを実行するコンピュータ読み取り可能な命令により定義されうる。マルチプレイヤ用ビデオゲームの場合、仮想世界は2以上のプレイヤにより共有され得、1人のプレイヤのゲームプレイが他のプレイヤに影響を及ぼし得る。
【0019】
他の例では管理アプリケーションは、参加者データベース10へのアカウントの設定、及びユーザが観戦を所望する進行中のビデオゲームのリストからのビデオゲームの選択を観戦者(即ち「観戦者」ユーザクラスのユーザ)に可能ならしめる、観戦者とのインタフェースとして機能しうる。該選択に従い、管理アプリケーションは、観戦者が他のユーザのゲームプレイを観賞できるが該ゲーム内のアクティブキャラクタの制御はできないように、該観戦者についての機能モジュールセットを起動しうる。(別段の指示がない限り、「参加者」との文言が使用された場合、「プレイヤ」ユーザクラスと「観戦者」ユーザクラスの両方に等しく適用されることを意味する。)
【0020】
更なる例において、管理アプリケーションは、ゲームサーバアプリケーションの様々な機能の変更、更新の実行、及びプレイヤ/管理者アカウントの管理を管理者(即ち「管理者」ユーザクラス)が可能なように、管理者とのインタフェースとして機能しうる。
【0021】
さらに別の例では、ゲームサーバアプリケーションは、テスト用のビデオゲームの選択をテスター(即ち「テスター」ユーザクラスのユーザ)が可能なように、テスターとのインタフェースとして機能しうる。該選択に従い、ゲームサーバアプリケーションは、ビデオゲームのテストをテスターに可能ならしめる、テスター用の機能モジュールセットを起動しうる。
【0022】
図1Bは、「プレイヤ」または「観戦者」ユーザクラスのユーザについての、ゲームプレイ中におけるクライアント装置120、120Aとサーバシステム100との間に生じるインタラクションを示している。
【0023】
いくつかの非限定的な実施形態において、サーバ側ビデオゲームアプリケーションは、クライアント装置120、120Aのようなクライアント装置において実行中のコンピュータ読み取り可能な命令セットにより定義されうるクライアント側ビデオゲームアプリケーションと協働してもよい。クライアント側ビデオゲームアプリケーションの使用は、ゲームをプレイまたは観戦するため及びゲーム機能にアクセスするために、参加者用にカスタマイズされたインタフェースを提供してもよい。他の非限定的な実施形態において、クライアント装置は、該クライアント装置により直接的に実行可能なクライアント側ビデオゲームアプリケーションを特徴づけるものではない。むしろ、Webブラウザがクライアント装置の視点(perspective)からのインタフェースとして使用されてもよい。該Webブラウザは、サーバ側ビデオゲームアプリケーションとのインタラクションを最適化するように、自身のソフトウェア環境におけるクライアント側ビデオゲームアプリケーションのインスタンスを自身で作成してもよい。
【0024】
クライアント装置120、120Aのうちの任意の1つは、該任意のクライアント装置のユーザが入力を提供し、ビデオゲームに参加することを可能ならしめるために、1以上の入力装置(タッチスクリーン、キーボード、ゲームコントローラ、ジョイスティック等)が備えられていてもよいことは理解されるべきである。他の実施形態において、ユーザは身体動作を行う、外部オブジェクトを振る等してもよく、これらの動作はカメラや他のセンサ(例えばKinect(登録商標))により検出され、該任意のクライアント装置で動作するソフトウェアは、ユーザが該任意のクライアント装置に対して入力を提供しようとしているか、もしそうであれば該入力の本質を正確に推測することを試みる。任意のクライアント装置において(独立にまたはブラウザ内で)実行されるクライアント側ビデオゲームアプリケーションは、受信したユーザ入力及び検出されたユーザ動作を、インターネット130を介してサーバシステム100に送信されうる「クライアント装置入力」に変換しうる。
【0025】
図1Bに示されている実施形態では、クライアント装置120はクライアント装置入力140を生成し、クライアント装置120Aはクライアント装置入力140Aを生成してもよい。サーバシステム100は、様々なクライアント装置120、120Aから受信したクライアント装置入力140、140Aを処理し、該様々なクライアント装置120、120Aについての「メディア出力」150、150Aをそれぞれ生成しうる。メディア出力150、150Aは、(スクリーン上に表示された場合に画像を示す)符号化された映像コンテンツのストリーム及び(スピーカを介して再生された場合に音を示す)音声を含みうる。メディア出力150、150Aは、パケットの形でインターネット130を介して送信されうる。クライアント装置120、120Aの特定の1つに向けられたパケットは、インターネット130を介して該装置にルートされるように、このような方法でアドレスされうる。クライアント装置120、120Aの各々は、サーバシステム100から受信したパケット内のメディア出力をバッファして処理する電気回路、画像を表示するためのディスプレイ、及び音声を出力する振動子(例えばスピーカ)を含んでいてもよい。また、追加の出力装置は、動作を誘導するための電気機械システム等を提供してもよい。
【0026】
映像データのストリームは、「フレーム」に分割されうることは理解されるべきである。ここでは、「フレーム」との文言は映像データのフレームと該映像データによりあらわされる画像との間の1対1対応の存在を要求するものではない。即ち、映像データの1つのフレームについて、表示される各画像の全体を示すデータを含めることも可能であるし、映像データの1つのフレームについて、画像の一部のみを示すデータを含めること、及び適切に再構成されて表示されるために、画像についてさらに2以上のフレームを要求することも可能である。同様に、映像データの1つのフレームは、M<NであるN個の画像が映像データのM個のフレームを用いて示される等、1以上の完全な画像を示すデータを含んでいてもよい。
【0027】
《2.サーバシステム100(分散型アーキテクチャ)》
図2Aは、サーバシステム100の構成要素の非限定的な物理的構成の第1の態様を示している。本実施形態では、サーバシステム100の個々のサーバが、専用の機能を実行するよう構成されうる。例えば、計算サーバ200Cは、ユーザ入力に基づいてビデオゲーム内の状態変化の追跡についての役割を担い、描画サーバ200Rは、グラフィック(映像データ)の描画についての役割を担い得る。
【0028】
以下に記載される実施形態の例のために、クライアント装置120及びクライアント装置120Aの両方は、プレイヤまたは参加者としてビデオゲームに参加しているものとする。しかしながら、いくつかのケースでは1人のプレイヤと観戦者なし、複数のプレイヤと1人の観戦者、1人のプレイヤと複数の観戦者、及び複数のプレイヤと複数の観戦者等で構成されてもよいことは理解されるべきである。
【0029】
簡単のため、以下の説明では単一の描画サーバ200Rに単一の計算サーバ200Cが接続されているものとする。しかしながら、1以上の描画サーバ200Rが同一の計算サーバ200Cに接続される、あるいは1以上の計算サーバ200Cが同一の描画サーバ200Rに接続されるものであってもよいことは理解されるべきである。複数の描画サーバ200Rが存在する場合、あらゆる適切な地理的領域に分散されるものであってもよい。
【0030】
図2Aの構成要素の非限定的な物理的構成に示されるように、計算サーバ200Cは1以上の中央演算装置(CPU)220C、222C及びランダムアクセスメモリ(RAM)230Cを有していてもよい。CPU220C、222Cは、例えば通信バスアーキテクチャを介してRAM230Cにアクセス可能である。2つのCPU220C、222Cのみが示されているが、計算サーバ200Cのいくつかの実装例では、より多数のCPUあるいは単一のCPUのみが提供されてもよい。また、計算サーバ200Cは、ビデオゲームに参加しているクライアント装置の各々から、インターネット130を介してクライアント装置入力を受信する、ネットワークインタフェース要素(NIC)210C2を有していてもよい。以下に記載される実施形態の例では、クライアント装置120及び120Aの両方は、ビデオゲームに参加しているものとし、従って、受信したクライアント装置入力はクライアント装置入力140及びクライアント装置入力140Aが含まれうる。
【0031】
さらに計算サーバ200Cは、描画命令セット204を出力する他のネットワークインタフェース要素(NIC)210C1を有していてもよい。NIC210C1を介して計算サーバ200Cから出力された描画命令セット204は、描画サーバ200Rに送信されうる。一実施形態において計算サーバ200Cは、描画サーバ200Rに直接接続されてもよい。他の実施形態では計算サーバ200Cは、インターネット130であってもよいし、その他のネットワークであってもよいネットワーク260を介して描画サーバ200Rに接続されてもよい。仮想プライベートネットワーク(VPN)は、ネットワーク260を介して計算サーバ200Cと描画サーバ200Rとの間に確立されてもよい。
【0032】
描画サーバ200Rにおいて、計算サーバ200Cにより送信された描画命令セット204は、ネットワークインタフェース要素(NIC)210R1において受信され、1以上のCPU220R、222Rに対して導かれうる。CPU220R、222Rは、グラフィック処理装置(GPU)240R、250Rに接続されてもよい。非限定的な例として、GPU240Rは、GPUコア242Rのセット及びビデオランダムアクセスメモリ(VRAM)246Rを含んでもよい。同様に、GPU250RはGPUコア252Rのセット及びビデオランダムアクセスメモリ(VRAM)256Rを含んでもよい。CPU220R、222Rの各々は、GPU240R、250Rの各々に接続されていてもよいし、GPU240R、250Rの集合に接続されていてもよい。CPU220R、222RとGPU240R、250Rとの間の通信は、例えば通信バスアーキテクチャを用いて確立されてよい。2つのCPU及び2つのGPUのみが示されるが、描画サーバ200Rの特定の実装例では、2以上のCPU及びGPUがあってもよいし、単一のCPUまたはGPUだけであってもよい。
【0033】
CPU220R、222Rは、描画命令セット204を参加する各クライアント装置用のグラフィック出力ストリームに変換するために、GPU240R、250Rと協働しうる。本実施形態では、クライアント装置120、120Aの各々について2つのグラフィック出力ストリーム206、206Aがあり得る。このことは、さらに詳細が後述されるだろう。さらに描画サーバ200Rは、これを介してグラフィック出力ストリーム206、206Aがクライアント装置120、120Aの各々に送信されうる、ネットワークインタフェース要素(NIC)210R2を有していてもよい。
【0034】
《3.サーバシステム100(ハイブリッドアーキテクチャ)》
図2Bは、サーバシステム100の構成要素の非限定的な物理的構成の第2の態様を示している。本実施形態ではハイブリッドサーバ200Hは、ユーザ入力に基づいてビデオゲーム内の状態変化の追跡とグラフィック(映像)の描画の両方の役割を担いうる。
【0035】
図2Bの構成要素の非限定的な物理的構成に示されるように、ハイブリッドサーバ200Hは1以上の中央演算装置(CPU)220H、222H及びランダムアクセスメモリ(RAM)230Hを有していてもよい。CPU220H、222Hは、例えば通信バスアーキテクチャを介してRAM230Hにアクセスできる。2つのCPU220H、222Hのみが示されているが、より多数のCPUまたは単一のCPUのみがハイブリッドサーバ200Hのいくつかの実装例において提供されてもよいことは理解されるべきである。またハイブリッドサーバ200Hは、ビデオゲームに参加するクライアント装置の各々からインターネット130を介してクライアント装置入力が受信されるネットワークインタフェース要素(NIC)210Hを有していてもよい。以下に記載される実施形態の例では、クライアント装置120及びクライアント装置120Aの両方は、ビデオゲームに参加しているものとし、故に受信したクライアント装置入力は、クライアント装置入力140及びクライアント装置入力140Aを含んでもよい。
【0036】
また、CPU220H、222Hは、描画処理装置(GPU)240H、250Hに接続されていてもよい。非限定的な例ではGPU240Hは、GPUコア242のセット及びビデオランダムアクセスメモリ(VRAM)246Hを含んでいてもよい。同様にGPU250Hは、GPUコア252Hのセット及びビデオランダムアクセスメモリ(VRAM)256Hを含んでいてもよい。CPU220H、222Hの各々は、GPU240H、250Hの各々またはGPU240H、250Hの集合に接続されていてもよい。CPU220H、222HとGPU240H、250Hとの通信は、例えば通信バスアーキテクチャを用いて確立されてもよい。2つのCPUと2つのGPUのみが示されているが、ハイブリッドサーバ200Hの特定の実装例では、2以上のCPUがあってもよいし、CPUまたはGPUが単一のみであってさえよい。
【0037】
描画命令セット204を、参加している各クライアント装置につき1つであるグラフィック出力ストリームに変換するために、CPU220H、222HはGPU240H、250Hと協働する。本実施形態では、参加しているクライアント装置120、120Aの各々に対して、2つのグラフィック出力ストリーム206、206Aが存在しうる。グラフィック出力ストリーム206、206Aは、NIC210Hを介してクライアント装置120、120Aの各々に送信されうる。
【0038】
《4.サーバシステム100(機能概要)》
ゲームプレイの間、サーバシステム100は、機能モジュールセットで構成されうるサーバ側ビデオゲームアプリケーションを実行する。
図2Cを参照すると、これらの機能モジュールはビデオゲーム機能モジュール270、描画機能モジュール280、及び映像符号化器285を含んでいてよい。これらの機能モジュールは、上述した計算サーバ200Cと描画サーバ200R(
図2A)及び/またはハイブリッドサーバ200H(
図2B)の物理的構成要素により実現されうる。例えば、
図2Aの非限定的な実施形態に関しては、ビデオゲーム機能モジュール270は計算サーバ200Cにより実現され、描画機能モジュール280及び映像符号化器285は描画サーバ200Rにより実現されうる。
図2Bの非限定的な実施形態に関しては、ハイブリッドサーバ200Hはビデオゲーム機能モジュール270、描画機能モジュール280、及び映像符号化器285を実現しうる。
【0039】
本実施形態の例は、図を簡略化するために単一のビデオゲーム機能モジュール270について議論する。しかしながら、サーバシステム100の実際の実装において、ビデオゲーム機能モジュール270と同様の多くのビデオゲーム機能モジュールが平行に実行されうる。したがって、サーバシステム100は、同一のビデオゲームの複数の独立したインスタンス化または複数の異なるビデオゲームの同時のインスタンス化をサポートしうる。また、ビデオゲームは、あらゆる種類の1人プレイヤ用ビデオゲームまたはマルチプレイヤ用ゲームであってもよいことは理解されるべきである。
【0040】
ビデオゲーム機能モジュール270は、計算サーバ200Cまたはハイブリッドサーバ200Hの所定の物理的構成要素により実現されてもよい。具体的には、ビデオゲーム機能モジュール270は、ビデオゲーム機能モジュール270は、(計算サーバ200CのCPU220C、222Cやハイブリッドサーバ200HのCPU220H、222Hのような)CPUにより実行可能なコンピュータ読み取り可能な命令として符号化されうる。該命令は、(計算サーバ200Cの)RAM230C、(ハイブリッドサーバ200Hの)RAM230H、あるいは他の記憶領域に、ビデオゲーム機能モジュール270により使用される定数、変数及び/または他のデータとともに明白に(tangibly)格納されうる。いくつかの実施形態においてビデオゲーム機能モジュール270は、(計算サーバ200CのCPU220C、222Cやハイブリッドサーバ200HのCPU220H、222Hのような)CPUにより実行されているオペレーティングシステムによりサポートされうる、 バーチャルマシンの環境において実行されてもよい。
【0041】
描画機能モジュール280は描画サーバ200R(
図2A)あるいはハイブリッドサーバ200H(
図2B)の所定の物理的構成要素により実現されてもよい。一実施形態において、描画機能モジュール280は、1以上のGPU(
図2Aの240R、250R、
図2Bの240H、250H)が引き受けてもよいし、CPUリソースを利用してもよいししなくてもよい。
【0042】
映像符号化器285は、描画サーバ200R(
図2A)またはハイブリッドサーバ200H(
図2B)の所定の物理的構成要素により実現されてよい。本技術分野に属する当業者は、映像符号化器285を実現する種々の手法があることは容易に理解するだろう。
図2Aの実施形態において、映像符号化器285はCPU220R、222R及び/またはGPU240R、250Rにより実現されうる。
図2Bの実施形態では、映像符号化器285はCPU220H、222H及び/またはGPU240H、250Hにより実現されうる。その他の実施形態では、映像符号化器285は、分離された符号化チップ(不図示)により実現されてもよい。
【0043】
動作において、ビデオゲーム機能モジュール270は、受信したクライアント装置入力に基づいて描画命令セット204を生成しうる。受信したクライアント装置入力は、行き先となるビデオゲーム機能モジュールを示すデータ(例えばアドレス)、及び由来するユーザ及び/またはクライアント装置を示すデータを運ぶものであってよい。クライアント装置120、120Aのユーザは、ビデオゲームに参加(即ちプレイヤまたは観戦者)しており、受信したクライアント装置入力は、クライアント装置120、120Aから受信したクライアント装置入力140、140Aを含みうる。
【0044】
描画命令は、映像データのフレームまたは映像データの一連のフレームを生成するように専用グラフィック生成装置(GPU)に導くために用いられうる命令を示す。
図2Cを参照すると、描画命令セット204は、描画機能モジュール280による映像データのフレームの生成をもたらす。これらのフレームにより示される画像は、ビデオゲーム機能モジュール270にプログラムされた、クライアント装置入力140、140Aに応じた機能として変更されうる。例えば、ビデオゲーム機能モジュール270は、所定の特定の要因に応じてユーザに(将来のインタラクションが異なる、より挑戦的とさせる、あるいはより刺激的とさせる)進行体験を提供するような方法でプログラムされ得、一方で、他の特定の要因への応答は、回帰や終了の体験をユーザに与えるだろう。ビデオゲーム機能モジュール270への指示はバイナリ実行可能なファイルの形式で固定され得るが、クライアント装置入力140、140Aは対応するクライアント装置120、120Aを使用するプレイヤのインタラクション動作があるまで不明である。結果として、提供される特定のクライアント装置入力に応じて、様々な種類の生じ得る結果が存在してもよい。プレイヤ/観戦者とビデオゲーム機能モジュール270の間のクライアント装置120、120Aを介した該インタラクションは、「ゲームプレイ」や「ビデオゲームをプレイしている」等として言及されうる。
【0045】
描画機能モジュール280は、複数の映像データストリーム205を生成するために描画命令セット204を処理しうる。一般に、参加者ごとに(あるいはクライアント装置ごとにも同等)、1つの映像データストリームが存在してよい。描画が実行されている場合、3次元空間(例えば物理オブジェクト)あるいは2次元空間(例えばテキスト)に示される1以上のオブジェクトについてのデータは、特定のGPU240R、250R、240H、250Hのキャッシュメモリ(不図示)に展開される。該データは、GPU240R、250R、240H、250Hにより、適切なVRAM246R、256R、246H、256Hに格納されうる2次元画像を示すデータに変換されうる。このようにして、VRAM246R、256R、246H、256Hは、ゲーム画面についての画素(ピクセル)値の一時的な格納領域を提供しうる。
【0046】
映像符号化器285は、映像データストリーム205の各々に含まれる映像データを、対応する圧縮/符号化された映像データのストリームに圧縮及び符号化しうる。グラフィック出力ストリームとして言及される、圧縮/符号化された映像データの結果であるストリームは、クライアント装置基準で生成されうる。本実施形態の例では映像符号化器285は、クライアント装置120についてのグラフィック出力ストリーム206及びクライアント装置120Aについてのグラフィック出力ストリーム206Aを生成しうる。追加の機能モジュールが、インターネット130を介して送信可能なように映像データをパケット形式にするよう提供されてもよい。映像データストリーム205に含まれる映像データ、及び任意のグラフィック出力ストリームに含まれる圧縮/符号化された映像データは、複数のフレームに分割されうる。
【0047】
《5.描画命令の生成》
以下、ビデオゲーム機能モジュール270による描画命令の生成が、
図2C、3A及び3Bを参照してより詳細に説明される。具体的には、ビデオゲーム機能モジュール270の実行は、いかに詳細が説明されるメインゲームプロセス300Aとグラフィック制御プロセス300Bを含むいくつかのプロセスを伴いうる。
【0048】
《6.メインゲームプロセス》
メインゲームプロセス300Aは、
図3Aを参照して説明される。メインゲームプロセス300Aは、連続的なループとして繰り返し実行しうる。メインゲームプロセス300Aの一部として、実行中、クライアント装置入力が受信されうる動作310Aが提供されうる。ビデオゲームが観戦の可能性がない1人プレイヤ用ビデオゲームである場合、単一のクライアント装置(例えばクライアント装置120)からのクライアント装置入力(例えばクライアント装置入力140)が動作310Aの一部として受信される。ビデオゲームがマルチプレイヤ用ビデオゲームまたは観戦の可能性がある1人プレイヤ用ゲームである場合、1以上のクライアント装置(例えばクライアント装置120及び120A)からのクライアント装置入力(例えばクライアント装置入力140及び140A)が、動作310Aの一部として受信されうる。
【0049】
非限定的な例示の目的で、任意のクライアント装置からの入力は、該任意のクライアント装置のユーザが、制御下にあるキャラクタに対して移動、ジャンプ、キック、旋回、揺動、押す、引く等をさせることを所望していることを伝送しうる。代替的あるいは追加的に、該任意のクライアント装置からの入力は、1以上の音声、映像またはゲームプレイ設定を変更する、ゲームをロード/セーブする、あるいはネットワークセッションの作成やセッションへの参加を行うために、該任意のクリア案と装置のユーザによりなされたメニュー選択を伝送しうる。代替的あるいは追加的に、該任意のクライアント装置からの入力は、該任意のクライアント装置のユーザが特定のカメラ視野(例えば1人称または3人称)の選択、あるいは仮想世界内の視野の再配置を所望していることを伝送しうる。
【0050】
動作320Aで、ゲームステートは、動作310Aにおいて受信したクライアント装置入力の少なくとも一部及び他のパラメータに基づいて更新されうる。ゲームステートの更新は、次の動作を伴いうる。
【0051】
第1に、ゲームステートの更新は、クライアント装置入力が受信されうるクライアント装置に関連付けられた参加者(プレイヤまたは観戦者)の所定の特性(property)を更新することを伴いうる。これらの特性は、参加者データベース10に格納されうる。参加者データベース10に保持されて動作320において更新されうる参加者特性の例は、カメラ視野の選択(例えば1人称、3人称)、プレイモード、選択された音声または映像の設定、スキルレベル、顧客グレード(例えばゲスト、プレミアム等)を含みうる。
【0052】
第2に、ゲームステートの更新は、クライアント装置入力の解釈に基づいて、仮想世界内の所定のオブジェクトの属性を更新することを伴いうる。属性が更新されるオブジェクトは、いくつかのケースでは2次元または3次元モデルにより示されてもよいし、プレイキャラクタ、非プレイキャラクタ及び他のオブジェクトを含みうる。プレイヤキャラクタである場合、更新されうる属性はオブジェクトの位置、強さ、武器/防具、経過した寿命、特殊能力、速さ/方向(速度)、アニメーション視覚的効果、エネルギ、弾薬等を含みうる。他のオブジェクト(背景、植物、建物、乗り物、スコアボード等)である場合、更新されうる属性は、該オブジェクトの位置、速度、アニメーション、ダメージ/体力、視覚的効果、テキスト内容等を含みうる。
【0053】
クライアント装置入力とは別のパラメータは、上述した(参加者の)特性及び(仮想世界オブジェクトの)属性に影響を与えうることは理解されるべきである。例えば、様々なタイマー(経過時間、特定のイベントからの時間、一日の仮想時刻、プレイヤ総数、参加者地理的位置等)が、ゲームステートの様々な態様に影響を及ぼしてもよい。
【0054】
動作320Aの実行に加えてゲームステートが更新されると、メインゲームプロセス300Aは動作310Aに戻ってもよく、前回のメインゲームプロセスを終了してから受信した新たなクライアント装置入力が収集され、処理される。
【0055】
《7.グラフィック制御プロセス》
以下、グラフィック制御プロセスとして言及される第2のプロセスについて、
図3Bを参照して説明する。メインゲームプロセス300Aとは分離されて示されるが、グラフィック制御プロセス300Bはメインゲームプロセス300Aの延長として実行してもよい。グラフィック制御プロセス300Bは継続的に実行し、描画命令セット204の生成をもたらす。観戦の可能性がない1人プレイヤ用ビデオゲームの場合、1人のプレイヤのみが存在し、故に衛星される描画命令セット204の結果は1つのみである。マルチプレイヤ用ビデオゲームの場合、複数の独立した描画命令セットが複数のプレイヤについて生成されることが必要であり、従って各プレイヤについて1つである複数のサブプロセスが並行して実行しうる。観戦の可能性がある1人プレイヤ用ゲームの場合、また単一の描画命令セット204のみが存在し得るが、結果である映像データストリームは、描画機能モジュール280により複数の観戦者にも複製されうる。もちろん、これらはただの実装の例であり、限定として取られるべきものではない。
【0056】
映像データストリーム205の1つを要求する任意の参加者についてのグラフィック制御プロセス300Bの動作を考える。動作310Bにおいて、ビデオゲーム機能モジュール270は該任意の参加者について描画されるオブジェクトを決定しうる。この動作は、以下の種類のオブジェクトを識別することを含んでいてよい。
【0057】
第1に、この動作は、仮想世界から任意の参加者についての「ゲーム画面描画範囲」(「シーン」としても知られる)内にある、これらのオブジェクトを識別することを含みうる。ゲーム画面描画範囲は、任意の参加者のカメラの画角(perspective)から「観ることが可能」な、仮想世界の一部を含みうる。これは、仮想世界内のオブジェクトに関連するカメラの位置及び方向に依るものであってもよい。動作310Bの非限定的な実装例において、錐台が仮想世界に適用され、該錐台内のオブジェクトが保持またはマークされる。錐台は、任意の参加者のカメラの位置に置かれた頂点を有し、該カメラの方向性により規定される方向を有するものであってもよい。
【0058】
第2に、この動作は、仮想世界内に現れないが、それにも関わらず任意の参加者について描画される必要がありうる追加のオブジェクトを識別することを含みうる。例えば、これらの追加のオブジェクトは、非限定的な2〜3の可能性を挙げると、テキストメッセージ、グラフィック警告及びダッシュボードインジケータを含んでもよい。
【0059】
動作320Bで、ビデオゲーム機能モジュール270は、動作310Bにおいて識別されたオブジェクトを、グラフィック(映像データ)に描画するための命令セットを生成しうる。描画は、視野及び適用される照明状態に従って、1つのオブジェクトまたはオブジェクト群の3次元または2次元座標の、表示可能な画像を示すデータへの変換を参照してもよい。これは、例えばここに参照により組み込まれる「"Computer Graphics and Geometric Modelling: Implementation & Algorithms", Max K. Agoston, Springer-Verlag London Limited, 2005」に記載されるような、あらゆるアルゴリズム及び技術を用いて達成されうる。描画命令は、ワシントン州レドモンドのマイクロソフト(登録商標)社の「Direct3D」及びオレゴン州ビーバートンのクロノスグループにより管理される「OpenGL」等の3Dアプリケーション・プログラミング・インタフェース(API)に適合する形式を有するものであってもよい。
【0060】
動作330Bで、動作320Bにおいて生成された描画命令は描画機能モジュール280に出力されうる。これは、描画機能モジュール280に送信する描画命令セット204への、生成された描画命令のパケット化を伴いうる。
【0061】
《8.グラフィック出力の生成》
描画機能モジュール280は、描画命令セット204を解釈し、参加しているクライアント装置ごとに1つである、複数の映像データストリーム205を生成しうる。描画は、(
図2Aの)CPU220R、222Rまたは(
図2Bの)CPU220H、222Hの制御の下、GPU240R、250R、240H、250Hにより実現されうる。1つの参加者のクライアント装置に係る映像データのフレームが生成されるレートは、フレームレートとして参照されうる。
【0062】
N名の参加者が存在する実施形態において、N個の描画命令セット204(各参加者について1つ)が存在し、N個の映像データストリーム205(各参加者について1つの)が存在し得る。この場合、描画機能は参加者間で共有されない。しかしながら、2〜3の描画命令セットが描画機能モジュール280により処理される必要があるように、M個(M<N)の描画命令セット204からN個の映像データストリーム205が生成されてもよい。この場合、少ない数の描画命令セット204からより多い数の映像データストリーム205を生成するために、描画機能モジュール280は共有または複製を行ってもよい。このような共有または複製は、複数の参加者(例えば観戦者)が同一のカメラ画角を観ることを所望した場合に普及するものであってもよい。故に、描画機能モジュール280は、生成された映像データストリームが1以上の観戦者に複製されるように機能を実行してもよい。
【0063】
次に、映像データストリーム205の各々における映像データは、映像符号化器285により符号化され、グラフィック出力ストリームとして参照され得、各クライアント装置に関連付けられた一連の符号化映像データが得られる。
図2A〜2Cの実施形態の例において、クライアント装置120についての一連の符号化映像データはグラフィック出力ストリーム206として参照され、クライアント装置120Aについての一連の符号化映像データはグラフィック出力ストリーム206Aとして参照されてもよい。
【0064】
映像符号化器285は、デジタル映像についての映像圧縮または展開を可能にする、実行する、または定義する装置(またはコンピュータ読み取り可能な命令セット)であってもよい。映像圧縮は、(画素位置、色値等で表現される)デジタル画像データのオリジナルストリームを、より少ないビットを用いるが実質的に同一の情報を伝送するデジタル画像データの出力ストリームに変換しうる。あらゆる適切な圧縮アルゴリズムが用いられてよい。データ圧縮に加え、映像データの特定のフレームの符号化に用いられる符号化処理は、暗号化を伴ってもよいし、伴わなくともよい。
【0065】
上述の手法で生成されたグラフィック出力ストリーム206、206Aは、インターネット130を介して各クライアント装置に送信されうる。非限定的な例示目的で、グラフィック出力ストリームは、各々がヘッダ及びペイロードを有するパケットに、セグメント化あるいは形式化されてもよい。任意の参加者についての映像データに含まれるパケットのヘッダは、該任意の参加者に関連付けられたクライアント装置のネットワークアドレスを含んでもよく、ペイロードは全部または一部として映像データを含んでもよい。非限定的な実施形態において、所定の映像データを符号化するために用いられる圧縮アルゴリズムの身元(identity)及び/またはバージョンが、該映像データを伝送する1以上のパケットのコンテンツ内に符号化されてもよい。符号化映像データの他の送信手法は、本技術分野に属する当業者には思い当たるかもしれない。
【0066】
本開示は個々が2D画像を示す映像データの描画にフォーカスするものであるが、本発明は3次元効果を生成するために、フレームごとに複数の2D画像を示す映像データの描画の可能性を除外するものではない。
【0067】
《9.クライアント装置におけるゲーム画面再生》
以下、非限定的な例示の目的で、クライアント装置120またはクライアント装置120Aたり得る、任意の参加者に関連付けられたクライアント装置により実行されうるクライアント側ビデオゲームアプリケーションの動作を示す
図4Aを参照する。動作にあたり、クライアント側ビデオゲームアプリケーションは、非限定的な2〜3の可能性を挙げると、クライアント装置により直接実行可能であってもよいし、Webブラウザにおいて起動してもよい。
【0068】
動作410Aで、1つのグラフィック出力ストリーム(例えば206、206A)は、実施形態に応じて描画サーバ200R(
図2A)から、あるいはハイブリッドサーバ200H(
図2B)から、インターネット130を介して受信されてもよい。受信されたグラフィック出力ストリームは複数のフレームに分割されうる圧縮/符号化された映像データを含みうる。
【0069】
動作420で、映像データの圧縮/符号化されたフレームは、符号化/圧縮処理に用いられた符号化/圧縮アルゴリズムを補間する展開アルゴリズムに従って復号/展開される。非限定的な実施形態において、映像データの符号化/圧縮に用いられた符号化/圧縮アルゴリズムの身元またはバージョンは、予め知らされていてもよい。他の実施形態において、映像データの符号化/圧縮に用いられた符号化/圧縮アルゴリズムの身元またはバージョンは、映像データ自体が添付されてもよい。
【0070】
動作430Aで、映像データの(復号/展開された)フレームが処理されうる。これは、バッファへの映像データの復号/展開されたフレームの配置、誤り訂正、複数の連続するフレームにおけるデータの順序付け及び/または合成、アルファブレンディング、欠損したデータの一部の補間等を含みうる。該結果は、毎フレーム基準でユーザに提示される最終画像を示す映像データとなり得る。
【0071】
動作440Aで、最終画像がクライアント装置の出力機構を介して出力されうる。例えば、コンポジット映像フレームが、クライアント装置のディスプレイに表示されうる。
【0072】
《10.音声生成》
以下、音声生成処理として言及される3番目の処理が、
図3Cを参照して説明される。音声生成処理は、知覚可能な音声ストリームを要求する各参加者について、継続的に実行されうる。一実施形態において、音声生成処理はグラフィック制御プロセス300Bと無関係に実行されてよい。他の実施形態において、音声生成処理及びグラフィック制御処理の実行が連動されてもよい。
【0073】
動作310Cで、ビデオゲーム機能モジュール270は、生成される音声を決定しうる。具体的に該動作は、音量(音の強さ)及び/または仮想世界内において参加者への近さに応じて、地形音響特性に影響を及ぼす仮想世界内のオブジェクトに関連付けられたこれらの音声を特定することを含みうる。
【0074】
動作320Cで、ビデオゲーム機能モジュール270は音声セグメントを生成しうる。音声セグメントの継続期間は映像フレームの継続期間に及んでもよいし、いくつかの実施形態では音声セグメントは映像フレームよりも少ない頻度で生成されてもよいし、他の実施形態では音声セグメントは映像フレームよりも高い頻度で生成されてもよい。
【0075】
動作330Cで、音声セグメントは例えば音声符号化器により符号化され得、符号化音声セグメントが得られる。音声符号化器は、音声圧縮または展開アルゴリズムを可能にする、実行する、または定義する装置(または命令セット)であってもよい。音声圧縮は、(徐々に振幅及び位相が変化する音波として表現される)デジタル音声のオリジナルストリームを、より少ないビットを使用するが実質的に同一の情報を伝送するデジタル音声データの出力ストリームに変換しうる。あらゆる適切な圧縮アルゴリズムが用いられてよい。音声圧縮に加え、特定の音声セグメントの符号化に用いられる符号化処理は暗号化を適用してもよいし、しなくてもよい。
【0076】
いくつかの実施形態において、音声セグメントは計算サーバ200C(
図2A)またはハイブリッドサーバ200H(
図2B)のいずれかの専用ハードウェア(例えばサウンドカード)により生成されてもよいことは理解されるべきである。
図2Aの分散型構成に適用可能な代替的実施形態において、音声セグメントはビデオゲーム機能モジュール270によりスピーチパラメータ(例えばLPCパラメータ)にパラメータ化されてもよく、スピーチパラメータは描画サーバ200Rにより、配信先のクライアント装置(例えばクライアント装置120またはクライアント装置120A)に再配信されうる。
【0077】
上述した方式で生成された符号化された音声は、インターネット130を介して送信される。非限定的な例示を目的として、符号化された音声入力は、各々がヘッダ及びペイロードを有するパケットに分解及び形式化されうる。ヘッダは、音声生成処理が実行される参加者に関連付けられたクライアント装置のアドレスを伝送してもよく、ペイロードは符号化された音声を含んでいてもよい。非限定的な実施形態において、任意の音声セグメントの符号化に用いられる圧縮アルゴリズムの身元及び/またはバージョンは、該任意のセグメントを伝送する1以上のパケットのコンテンツ内に符号化されてもよい。符号化された音声を送信する他の手法は、本技術分野に属する当業者には思い当たるかもしれない。
【0078】
以下、非限定的な例示を目的として、クライアント装置120またはクライアント装置120Aであってよい、任意の参加者に関連付けられたクライアント装置の動作を示す
図4Bを参照する。
【0079】
動作410Bで、符号化された音声セグメントが(実施形態に応じて)計算サーバ200C、描画サーバ200R、またはハイブリッドサーバ200Hから受信されうる。動作420Bで、符号化処理に用いられた圧縮アルゴリズムを補間する展開アルゴリズムに従って、符号化された音声は復号されうる。非限定的な実施形態において、音声セグメントの符号化に用いられた圧縮アルゴリズムの身元またはバージョンは、音声セグメントを伝送する1以上のパケットのコンテンツ内で特定されてもよい。
【0080】
動作430Bで、(復号された)音声セグメントが処理されうる。これは、バッファ内への復号された音声セグメントの配置、誤り訂正の実行、複数の連続する波形合成等を含みうる。該結果は、毎フレーム基準でユーザに提示される最終音声となり得る。
【0081】
動作440Bで、最終的に生成された音声は、クライアント装置の出力機構を介して出力されうる。例えば、音声はクライアント装置のサウンドカードまたはスピーカを介して再生されうる。
【0082】
《11.非限定的な実施形態の具体的開示》
以下、本発明の所定の非限定的な実施形態のより詳細な説明が提供される。
【0083】
〈ステートセーブ処理〉
このような構成のシステムにおいて実行される、本発明の一態様である実施形態に係るサーバ側(サーバシステム100、計算サーバ200C及び描画サーバ200R、あるいはハイブリッドサーバ200H)でのステートセーブ処理について、
図5のブロック図及び
図6のフローチャートを用いて具体的な処理を説明する。
【0084】
図5は、ステートセーブ処理を含む、クライアント装置に対してメディア出力を提供する際のサーバ側の構成を示したものである。
図5の例では、クライアント装置の各々にメディア出力であるゲーム画面(グラフィック出力206)を提供するゲーム処理が、例えばバーチャルマシンマネージャ550により構築されたバーチャルマシン510〜540において実行される。即ち、各バーチャルマシンは、上述したビデオゲーム機能モジュール270、描画機能モジュール280、及び映像符号化器285に係る処理を実行するエンティティとして設けられている。バーチャルマシンマネージャ550は、例えばクライアント装置からのゲーム画面提供に係る要求を受けた際に、該クライアント装置に係るゲーム処理を実行するバーチャルマシンを構築し、処理を実行させる。また構築したバーチャルマシンの状況を管理する。
【0085】
各バーチャルマシンは、CPU、GPU、VRAM等のハードウェアを仮想的に有しており、これらの仮想的なハードウェアへの命令等を行いながらゲーム処理を実行する。仮想的なハードウェアになされた命令は、バーチャルマシンマネージャ550を介して、サーバ側に設けられた対応するハードウェアへの命令に変換され、現実のハードウェアによって処理される。そしてバーチャルマシンマネージャ550は、現実のハードウェアによる処理の結果を、対応するバーチャルマシンに返却する。このようにすることで、バーチャルマシンは、ゲームコンソール等のような現実のハードウェアと等価な動作を実行する(エミュレーションする)1つのエンティティとして機能できる。
【0086】
図5の例では、現実のハードウェアへの命令伝送は、ハードウェアインタフェースを管理するオペレーティングシステム560を介して行われる。具体的にはバーチャルマシンマネージャ550は、バーチャルマシンにおいて発生した仮想的なハードウェアへの命令を取得すると、オペレーティングシステム560に伝送する。そして対応するハードウェアにおいて命令に係る動作が実行されると、バーチャルマシンマネージャ550はオペレーティングシステム560を介してそれらを受信し、バーチャルマシンに結果を返す。
【0087】
本実施形態ではオペレーティングシステム560は、VRAM246等の画面メモリに展開されている画面をキャプチャする、いわゆるスクリーンショット機能を有する。本実施形態においてキャプチャ対象となる画面は、各バーチャルマシンにおけるゲーム処理の実行により生成されたゲーム画面である。CPU222は、バーチャルマシンにおける処理により生成されたゲーム画面のスクリーンショットを取得する場合には、オペレーティングシステム560の該機能を利用し、対象のゲーム画面の取得を行う。このようにして取得されたゲーム画面のスクリーンショットは、バーチャルマシンマネージャ550によりスクリーンショットデータベース570に格納される。また本実施形態ではスクリーンショットデータベース570は、スクリーンショットに関連付けて、該スクリーンショットに対応するゲームの進行状況を示すステート情報を記録する。
【0088】
本実施形態では、各バーチャルマシンとクライアント装置とのデータ通信を、バーチャルマシンマネージャ550及びオペレーティングシステム560を介して実現するものとして説明するが、本発明の実施はこれに限られるものではない。即ち、バーチャルマシンマネージャ550がオペレーティングシステム560を介さずに直接ハードウェアインタフェースとのデータのやり取りを行ってもよいし、オペレーティングシステム560が各バーチャルマシンと直接データのやり取りを行ってもよい。また、本実施形態では例えば所定のゲームコンソールや実行環境のエミュレータとしてバーチャルマシンを構築してゲーム処理を実行させるものとして説明するが、本発明の実施においてバーチャルマシンの構築は必須ではない。即ち、並列処理等、サーバ側では複数のクライアント装置に対して並行して各クライアント装置に対応するゲーム処理を実行できればよく、バーチャルマシンという概念を構築しなくとも、本発明の実施は可能である。
【0089】
次に、このような構成のサーバ側で行われるステートセーブ処理について、
図6のフローチャートを用いて詳細を説明する。該フローチャートに対応する処理は、CPU222が、例えば記録媒体(不図示)に記憶されている対応する処理プログラムを読み出し、RAM230に展開して実行することにより実現することができる。
【0090】
本ステートセーブ処理は以下の説明において、ステートセーブ要求の一例として、プレイヤによりステートセーブに係るスクリーンショットの記録指示がなされた際に開始されるものとして説明する。具体的には、バーチャルマシンにおいて実行されているゲーム処理において該指示がなされたことを示す通知をバーチャルマシンマネージャ550が出力した場合に、CPU222は本処理を開始するものとする。しかしながら、本処理の実行タイミングはこれに限られるものでなく、所定の時間間隔や実行されるゲームにおいて操作キャラクタや表現される仮想世界(ゲーム世界)のステートが所定の条件(キャラクタレベルアップ、ワールド移動等)を満たした際に実行されるものであってもよい。あるいは、プレイヤに限らず、プレイヤのクライアント装置120に提供されるメディア出力150と同一内容のメディア出力150Aを受信するクライアント装置120Aにおいてプレイ状況を観覧する観戦者からの記録指示に応じて実行されるものであってもよい。
【0091】
S601で、CPU222は、プレイヤからのスクリーンショットの記録指示を受け付けたバーチャルマシン(対象VM)におけるゲーム処理を一時停止させる。具体的にはCPU222は、バーチャルマシンマネージャ550を介して対象VMの仮想CPUに対して、ゲーム処理の一時停止を命令する。
【0092】
S602で、CPU222は、対象VMの仮想VRAMに現在格納されているゲーム処理に係るゲーム画面をスクリーンショットデータとして取得する。具体的にはCPU222は、VRAM246及び256のいずれかに格納されている対応するゲーム画面を読出し、例えばRAM230にスクリーンショットデータとして格納する。
【0093】
S603で、CPU222は、対象VMにおいて実行されるゲーム処理において、ゲームID、プレイヤID及びゲームステートに係る情報を取得してRAM230に格納する。ゲームステートに係る情報とは、該情報を用いてゲーム処理を実行した場合に同様のゲームステートを少なくとも再現し、記録指示に対応するフレームのゲーム画面と同一の画面を生成することができる情報を指す。本実施形態ではゲームステートに係る情報には、
・ステート情報
・リソース展開情報
が含まれるものとして説明する。
【0094】
ここで、ゲームIDはゲーム処理において実行されるゲームを識別する情報である。プレイヤIDは、対象VMにおける処理によって生成されたゲーム画面の提供を受けるクライアント装置120を操作しているプレイヤを識別する情報であり、予め行われる利用者アカウント登録の際等において各プレイヤに設定され、該プレイヤを一意に特定する情報である。ステートは、例えばゲームの進行状況、種々の変数、所定の演算結果等のうち少なくとも1つを含む、対象VMで実行されるゲーム処理において生成される状態をいう。本実施形態ではステートのうち、実行されているゲームの進行状況、種々の変数、所定の演算結果等の、記録指示に対応するフレームのゲーム画面を生成するために少なくとも必要となる情報を含む情報を、ステート情報とする。具体的にはステート情報には、キャラクタの位置や方向、動作等の情報や、キャラクタの体力やレベル、現在のゲームの難易度、現在の得点やハイスコア等の情報が含まれていてよい。該情報は、例えばゲーム処理に係るプログラムにおいて所定のクラスに定義され、該クラスのオブジェクトがステート情報として取り扱われてよい。またリソース展開情報は、記録指示に対応するフレームのゲーム画面を描画する際に必要な描画オブジェクトに係り、GPUメモリ(不図示)に展開される描画リソースデータを示す情報である。リソース展開情報は、GPUメモリにリソースデータが展開される描画オブジェクトを特定する情報で構成されてもよいし、GPUメモリに展開後のリソースデータそのもので構成されてもよい。後者の場合、リソース展開情報は対象VMに係る仮想GPUメモリ空間の全体を記録するものであってもよい。
【0095】
本実施形態では、ゲームステートに係る情報に加えてゲームID及びプレイヤIDを取得するものとして説明するが、本発明の実施はこれに限られるものではない。例えばサーバ側が単一のゲームコンテンツのみを提供する場合、あるいはプレイヤのアカウントがゲームコンテンツごとに作成されるような場合は、ゲームIDを取得する必要がないことは容易に理解されよう。また、ステート情報には上記列挙した情報以外に、例えばゲーム処理の開始からの経過時間等、ゲーム画面の描画には直接的に関係しないデータ等が含まれていてもよい。
【0096】
S604で、バーチャルマシンマネージャ550はCPU222の制御の下、RAM230に格納されたスクリーンショットデータとゲームステートに係る情報とを関連付け、ステートセーブデータとしてスクリーンショットデータベース570に格納する。具体的にはバーチャルマシンマネージャ550は、まずRAM230に格納されたプレイヤIDを参照し、対象VMのプレイヤに係り格納されているステートセーブ情報を読み出す。そしてバーチャルマシンマネージャ550は、ステートセーブ情報のうちのゲームIDに対応する領域に新たなステートセーブデータを1レコードとして追加し、追加後のステートセーブ情報をスクリーンショットデータベース570に格納することでプレイヤに係るステートセーブ情報を更新する。
【0097】
本実施形態のステートセーブ情報は、
図7A及び7Bに示されるような構造を有して構成される。
図7Aは、プレイヤに係るステートセーブ情報のデータ構造を示している。図示されるように、ステートセーブ情報は対応付けられているプレイヤID701とステートセーブ情報702とで構成される。また、ステートセーブ情報702は上述したようにゲームごとにステートセーブデータを管理できるよう、ステートセーブデータを生成したゲームの数だけ、各ゲームのステートセーブデータ(レコード)を格納する領域を有している。各ゲームのステートセーブデータを格納する領域は、例えば
図7Bに示されるように、ゲームID711に関連付けられて設けられる。図示されるように該領域には、記録指示がなされた数、即ち該ゲームについてステートセーブ処理が実行された数のステートセーブデータ712が格納される。ステートセーブデータ712は、追加される際に順次固有のID721が割り振られ、該IDとともにスクリーンショットデータ722とゲームステートに係る情報723とが関連付けられたデータとして格納される。
【0098】
本ステップの説明において、プレイヤに係るステートセーブ情報やゲームに係るステートセーブデータを格納する領域がない場合は、バーチャルマシンマネージャ550は新たに該当の情報を生成して同様に処理すればよい。
【0099】
S605で、CPU222は、S601において一時停止させた対象VMにおけるゲーム処理を再開させ、本ステートセーブ処理を完了する。
【0100】
このようにすることで、本システムでは、スクリーンショットの記録指示に応じてゲームコンテンツに係るゲームステートに係る情報を保存することができる。また保存したゲームステートに係る情報をゲーム処理において使用することで、スクリーンショットの記録指示がなされた際と同等のゲーム画面を生成し、ゲームを再開することができる。例えばプレイヤがスクリーンショットの記録指示を行ったところからゲームの再開を望む場合、対象VMの仮想CPUは、提供しているゲームに係るステートセーブ情報をバーチャルマシンマネージャ550を介して取得し、該情報に従って再開対象のステートを選択する画面を生成してクライアント装置に送信すればよい。このとき、ゲームステートに係る情報にはスクリーンショットデータが関連付けられているため、再開対象のステートを選択する画面にはスクリーンショットデータを含めることができる。即ち、プレイヤはスクリーンショットの記録指示を行うことで、ゲームにおける任意のタイミングから再開可能なセーブデータを作ることができる。また該セーブデータを使用してゲームを再開する際には、プレイヤはセーブデータに対応するスクリーンショットを閲覧することができるため、所望の再開ポイントを容易に認識することができる。
【0101】
〈ステート共有処理〉
本実施形態のシステムではプレイヤは、上述したステートセーブ処理により生成されたステートセーブデータを、自身のゲーム進行の保存/再開のために使用するだけでなく、他のプレイヤとの間で共有することができる。即ち、プレイヤはゲームプレイ中に作成したステートセーブデータを他のプレイヤと共有することで、自身のゲームプレイの続きを他のプレイヤにもプレイさせることができる。あるいは、他のプレイヤが作成したステートセーブデータを用いて、その続きからゲームプレイを行うことができる。
【0102】
以下、このようなステートセーブデータの共有を可能にさせるステート共有処理について
図8のフローチャートを参照して詳細を説明する。該フローチャートに対応する処理は、CPU222が、例えば記録媒体(不図示)に記憶されている対応する処理プログラムを読み出し、RAM230に展開して実行することにより実現することができる。以下の説明において、本ステート共有処理は、ステートセーブデータの共有要求の一例として、ステートセーブデータを、他のプレイヤが使用可能な状態に公開する共有指示がプレイヤよりなされた際に開始されるものとして説明する。具体的には、クライアント装置から該共有指示を受信したと判断した場合に、CPU222は本処理を開始するものとする。しかしながら、本処理の実行タイミングはこれに限られるものでなく、上述したステートセーブ処理により新たなステートセーブデータが生成された場合に実行されるものであってもよい。あるいは、他のプレイヤからなされたステートセーブデータの共有指示に対してプレイヤが同意した場合に実行されるものであってもよい。また、ステートセーブ処理と同様に、ゲームプレイ中にプレイヤにより共有指示がなされた場合に本処理は開始されるものであってもよい。
【0103】
S801で、CPU222は、共有指示の対象であるステートセーブデータ(対象ステートセーブデータ)を取得する。ここで、対象ステートセーブデータは、単一のステートセーブデータに限られるものでなく、複数のステートセーブデータであってよい。具体的にはCPU222は、共有指示に含まれる情報に従って、バーチャルマシンマネージャ550を介してスクリーンショットデータベース570から対象ステートセーブデータを読み出し、RAM230に格納する。
【0104】
共有指示は、例えば
図9に示されるように、ゲームID901、データID902、共有条件903を有して構成されてよい。ここで、データID902は、対象ステートセーブデータを特定する情報であり、ステートセーブ処理においてステートセーブデータに割り当てられたID721であってよい。また共有条件903は、対象ステートセーブデータをどのように他のプレイヤに共有するかを示す情報である。共有条件903は、例えば特定のプレイヤと共有する場合は該プレイヤのプレイヤID、使用可能なプレイヤを制限することなく公開する場合は公開することを示す情報等が含まれていてよい。この他、共有条件903には、SNS(Social Network Service)、インターネット掲示板、メール等の共有に用いる媒体や方法を指定する情報が含まれていてもよい。
【0105】
従って、CPU222は、共有指示に含まれるデータID902の情報に従って、対象ステートセーブデータをスクリーンショットデータベース570から取得し、RAM230に格納する。
【0106】
S802で、CPU222は、共有指示に含まれる共有条件903を参照し、指定される共有方法に従って対象ステートセーブデータの共有を行い、本ステート共有処理を完了する。
【0107】
ここで、具体例として、特定のSNSにおいてプレイヤの投稿として対象ステートセーブデータを公開する場合を考える。CPU222は、RAM230に格納した対象ステートセーブデータのスクリーンショットデータ、ゲームID、ゲームステートに係る情報を参照し、
図10のような公開リストのデータを生成する。
図10の例では、プレイヤにより共有される対象ステートセーブデータが、ステートセーブデータを取得した際のスクリーンショット、ゲーム名、ゲーム中のステージ(ゲーム進行状況)、及び得点が示されている。該公開リストでは、スクリーンショットの画像に、対応するステートセーブデータへのアクセス要求を行うための情報(リンク情報)が関連付けられている。投稿により該リストが公開された後、SNSを利用する他のユーザが例えばスクリーンショットの画像をクリックすることで、該ユーザのクライアント端末はサーバシステム100に接続し、ユーザは対応するゲームを、スクリーンショットに係るステートからプレイすることができる。このとき、CPU222は、該ユーザをプレイヤとするゲームの実行用にバーチャルマシンマネージャ550にバーチャルマシンを構築させる。またバーチャルマシンマネージャ550はCPU222の制御の下、該当のステートセーブデータをスクリーンショットデータベース570から読み出して構築したバーチャルマシンに伝送する。このとき、バーチャルマシンマネージャ550は、読み出したステートセーブデータを伝送先のバーチャルマシンに対応するプレイヤに関連付けられたステートセーブ情報にコピーし、伝送先のプレイヤIDにステートセーブデータを関連付ける。そしてバーチャルマシンの仮想CPUがステートセーブデータに基づいてゲーム処理を行うことで、スクリーンショットに対応するゲーム画面を開始フレームとした連続するゲーム画面がクライアント装置に順次送信される。
【0108】
その他、ステートセーブデータの共有に係る方法は様々な応用例が考えられる。例えば、プレイヤがゲームプレイ中に進行させることが困難なシーンやシナリオに至った場合、プレイヤはスクリーンショットの記録指示によりステートセーブデータを作成し、該データを他のプレイヤに共有し、ゲームの困難なシーンの部分を代わりにプレイしてもらうことができる。そして、困難なシーンの部分のプレイ後にステートセーブデータを作成してもらい、該データを共有してもらうことで、プレイヤは困難なシーンの部分の後からゲームを再開することができる。
【0109】
また例えば、プレイヤはゲームプレイ中に多数の敵キャラクタに包囲されている状況や残存体力がわずかな状況等の特定のゲームの状況を作り出し、ステートセーブデータを作成してもよい。そして、作り出した状況からのゲームクリア等、ゲームプレイを制限するような題目を設定してステートセーブデータを共有し、例えば最高得点や最短プレイ時間でのクリア等を共有したプレイヤ間で競争できるようにシステムを構築してもよい。具体的には例えば、1つのステートセーブデータを用いて開始されたゲームのプレイ結果をCPU222が取得し、所定の期間の集計の結果(ランキング)を特定のサイト等に公開するようにしてもよい。
【0110】
また例えば、プレイヤが所定のゲームを開始したい場合に、キャラクタのレベルが上がった状態やキャラクタの所有する装備が充実している状態にある、他のプレイヤにより作成されたステートセーブデータを使用することで、プレイヤはゲーム進行が容易な状態、即ち難易度を下げた状態でゲームを楽しむこともできる。この他、例えばオークションサイト等でプレイヤ間の売買が可能なように構成され、他のプレイヤに渡った際にプレイヤのステートセーブ情報から該当のステートセーブデータを削除するようにしてもよい。またこの場合、スクリーンショットデータやステート情報から、ステートセーブデータに対応するゲーム状況を容易に確認できるため、プレイヤは安全に取引を行うことができる。
【0111】
これらの応用例は、ステートセーブデータの共有方法として予め用意され、プレイヤがステートセーブデータの共有指示を行う際に選択し、選択した方法を識別する情報が共有条件903に含められるものであってよい。
【0112】
このように、本実施形態のサーバシステムでは、1つのクライアント装置について実行されたゲーム処理において任意のタイミングでステートセーブデータを生成し、そして該データをゲームロードのために使用する、あるいは他のプレイヤと容易に共有することができる。
【0113】
本実施形態では、ビデオメモリに生成されたゲーム画面をスクリーンショットとして格納するものとして説明したが、本発明の実施はこれに限られるものではない。例えば取得したスクリーンショットと直前に格納されたステートセーブデータに含まれるスクリーンショットとの差分を抽出して、差分のデータをスクリーンショットとして格納するものであってもよい。この場合、スクリーンショットデータベース570に格納されるステートセーブデータの容量を低減することができる。
【0114】
また本実施形態では、プレイヤや観戦者からの要求やゲーム進行状況に応じてステートセーブデータを生成する等、プレイヤ等が主体的に行った動作に基づいてステートセーブデータが生成される例について説明したが、本発明の実施はこれに限られるものではない。例えば、クライアント装置の電源断や通信障害等によってクライアント装置とサーバシステム100との通信接続が切断された場合や、クライアント装置においてメール受信等の割り込み処理が発生した場合等、プレイヤ等が意図しない事象によりゲーム処理を停止することが好ましい状況が発生した場合に、ステートセーブデータが生成されるように構成されるものであってもよい。
【0115】
またステートセーブデータの記録指示に係り生成されたスクリーンショットの画像は、該画像を直接閲覧可能なようにアクセス用のリンクを生成し、プレイヤのメールアドレス等に送信してもよい。
【0116】
なお、本実施形態ではステートセーブデータが指し示す状況を明確にするために、スクリーンショットデータを関連付けて記録するものとして説明したが、本発明の実施はこれに限られるものではない。例えばステートセーブデータが指し示す状況を明確にするために、スクリーンショットデータではなく、ステートセーブが行われる前の数フレームのゲーム画面で構成される動画データを記録してもよい。特にクラウドゲーミングシステムでは、ゲーム画面を符号化してクライアント装置に提供するため、その符号化におけるフレーム間予測符号化のために、数フレームにわたってゲーム画面を保持するよう構成されており、動画データをステートセーブデータに含めることは容易である。また動画データの他に、例えばゲームの進行状況や行動履歴等のゲームにおける状態を示すテキストデータ、あるいはその代替データが関連付けられるものであってもよい。また、これらのスクリーンショットデータ、動画データ、及びテキストデータ等が複合的に関連付けられてもよい。
【0117】
また本実施形態では、
図1A、1B、2A、2B、及び2Cを用いて説明したようなクラウドゲーミングシステムにおいて本発明を実現する例について説明したが、本発明の実施はこれに限られるものではない。例えば本発明は、クライアント装置において作成されたステートセーブデータを、他のクライアント装置に共有可能なシステムにも適用可能である。具体的には、クライアント装置においてゲーム処理が実行される場合、該機器のCPUは、同様にスクリーンショットデータ及びゲームステートに係る情報を取得してステートセーブデータを作成することができる。作成されたステートセーブデータは、クライアント装置内あるいは例えばネットワーク上のサーバ等の外部機器に格納され、共有可能となる。共有指示がなされた場合、クライアント装置のCPUは該ステートセーブデータへのリンク情報を取得することができるため、ステートセーブデータへのリンク情報を他のクライアント装置に伝送することにより共有することができる。この場合、リソースは上述した実施形態のように常に固定のハードウェアの記憶領域に展開されるものではなく、クライアント装置によって仕様が異なるハードウェアの記憶領域に展開される。故に、上述した実施形態のようにGPUメモリに展開されたデータそのものをリソース展開情報とした場合にはクライアント装置によっては該情報を使用することができない可能性がある。また、リソースが展開されるGPUメモリの有無や展開先のアドレス、また同一のオブジェクトについて展開されるリソースのデータ量も、ゲーム処理が実行される機器によって変わるものである。従って、クライアント装置において本発明を実現する場合には、リソース展開情報は展開されたリソースの識別情報を示すものであることが好ましい。
【0118】
以上説明したように、本実施形態のゲームシステムは、ステートセーブデータを容易に他の機器に提供することができる。具体的にはゲーム装置は、ステートセーブ要求を受信した場合に、該要求に対応するゲームにおける状況を示す情報と該要求に対応するゲーム画面と同一のステートからゲームを開始するためのステート情報とを取得し、該状況情報とステート情報とを関連付けたステートセーブデータを記録する。ゲーム装置は、ステートセーブデータの共有要求を受信した場合に、記録されたステートセーブデータのリンク情報と該データに係る状況情報とを他の装置に提供する。
【0119】
[その他の実施形態]
例示的な実施形態を参照して本発明を説明してきたが、記載した例示的な実施形態に発明が限られるものでないことは理解されよう。以下の特許請求の範囲は、このような変形、等価な構成及び機能の全てを包含するように、広範な解釈を許容されよう。また、本発明に係る情報処理装置及び制御方法は、コンピュータにおいて該手法が実行されるプログラムにより実現可能である。プログラムは、コンピュータ読み取り可能な記録媒体に格納されることで、または電気的な通信回線を介して、提供/配信可能である。
【0120】
本出願は、その全体がここに参照により援用される、2013年2月6日に出願された米国仮出願第61/761374号の利益を主張するものである。