JP2006164243A - プレーヤに関するゲームデータを設定するためのシステムおよび方法 - Google Patents

Abstract

【課題】プレーヤに関するゲームデータを設定する。
【解決手段】サービスの使用により情報がシステムのユーザ間で共用される。サービスは、それぞれが、サービスと共用するためにゲームアプリケーションからの情報を定義するコンフィギュレーションファイルを持つ、少なくとも２つの異ったゲームアプリケーションから情報を受け取る。ゲームアプリケーションの１つを実行しているコンピュータ上で実行中の中間プログラムが、コンフィギュレーションファイルによって定義されるようにアプリケーションからの情報を受け取り、アプリケーションから受け取られた情報の少なくとも一部を格納する。情報の少なくとも一部は、中間プログラムがネットワークを介してサービスと通信するときにサービスに送られ、サービスは、サービスによって受け取られた情報に基づき、少なくとも２つの異なったゲームアプリケーションのユーザに関する情報を提供する。
【選択図】図３

Description

本発明は、一般に、ゲームおよびマルチメディア機器の分野に関する。詳細には、本発明は、ゲームアプリケーションとサービスの間でデータを共用する方法を対象とする。

オンラインゲームにおいて、ゲームホスティングサービスおよびゲーム開発者は、オンラインゲーム体験を追跡し、パーソナル化するいくつかの方法を生み出している。既存のシステムの１つの欠点は、それらの機能の多くが相互に無関係に発展していることである。ゲームは、ゲーマに関するデータのブロブを中央サービスとやりとりするが、中央サービスは、そのゲームコンテキストの外部でデータを理解し、集約することができない。ゲームは、独自のＷｅｂサイトをホストとすることができるが、そこに表示されるデータに他のゲームから広く一般にアクセスすることはできない。さらに、サービスは、ゲーマに関して独自の情報を収集するが、その情報を、ゲームプレーの最中に発生することと統合する統一されたプロセスを持たない。

その場合、ある意味で、サービスおよびゲームは、ゲーマにとって、大きな、分離されたリソースを提供する２つの並列のコミュニティを提供する。第１に、ゲームコミュニティにおいて、ゲームをプレーしている間、ゲーマは、その特定のゲームをプレーする他者のコミュニティ、そのゲームのスコアボード、およびそのゲームでの自分の個人成績を見ることができる。ゲームは、ゲーマに、そのサービスデータから、友人がオンライン状態にあるかどうか知らせることができるが、その友人がサービス上で正確に何をしているか、あるいはその友人がいつ対応できるようになるかをゲーマに知らせることはできない。ゲームディスクが取り出されると、そのゲームコミュニティ全体がそのコンソールから消失し、ゲーマの成績(gamer's achievement)は読み取り不能になる。

第２に、サービスコミュニティにおいて、サービスは、ゲーマの履歴、ゲーマがプレーしたゲームすべて、ゲーマがオンラインで費やした時間、ゲーマの友人リストのサイズおよび友人がプレーした、またはプレーしているゲームすべて、送受信された友人勧誘、送受信されたメッセージ、ゲーマがやりとりしたフィードバックすべてを知っている。ゲーマにとって、このデータは、コンソールまたはＰＣ上でコミュニティとして発現するが、ゲームディスクが挿入され、またはゲームプログラムが開始された後、その大部分は見ることができない。

本発明の目的は、上述の問題点に鑑み、プレーヤに関するゲームデータを設定するための改良されたシステムおよび方法を提供することにある。

サービス(a service)の使用により情報がシステムのユーザ間で共用(share)される。このサービスは、それぞれがサービスと共用するためにゲームアプリケーションからの情報を定義するスキーマを持つ、少なくとも２つの異ったゲームアプリケーションから情報を受け取る。前記ゲームアプリケーションの１つを実行しているコンピュータ上で実行中の中間プログラムが、前記スキーマによって定義されるようにアプリケーションから情報を受け取り、そのアプリケーションから受け取られた情報の少なくとも一部を格納する。情報の少なくとも一部は、中間プログラムがネットワークを介してサービスと通信するときにサービスに送られ、サービスは、前記サービスによって受け取られた情報に基づき、前記少なくとも２つの異なったゲームアプリケーションのユーザに関する情報を提供する。

本発明に係るシステムは、ゲーム開発者がカスタムスキーマを作成することを必要とせずに、ゲームのスキーマファイルを生成するツールを用いる。

上記の構成、添付の図面と併せて読むことにより、よりよく理解されるであろう。なお、本発明を説明するため、図面には、本発明の例示的構成が示されているが、本発明は、開示の特定の方法および手段に限定されるものではない。

以下、図面を参照して、本発明を実施するための最良の形態を説明する。

図１は、本発明の諸態様を示すために使用される例示的コンピュータネットワークを示す図である。本図において、コンピュータ１００ａ〜１００ｅは、ゲームやその他のアプリケーションなど、様々なコンピューティングオブジェクトをホスティングし得る。この物理的環境には、接続された機器がコンピュータとして示されているが、そのような図は単なる例示にすぎず、これにはＰＤＡ、ゲームコンソールなど様々なデジタル機器が含まれる。さらに、通信ネットワーク１６０自体も、いくつかのコンピュータ、サーバおよびルータなどのネットワーク機器を含むことができる。

分散コンピューティング環境をサポートする様々なシステム、コンポーネント、およびネットワークコンフィギュレーションがある。例えば、コンピューティングシステムは、有線またはワイヤレスシステムによって、ローカルネットワークまたは広域に分散されたネットワークによって相互に接続される。現在、ネットワークの多くは、広域分散コンピューティングのためのインフラストラクチャを提供し、多くの異なるネットワークを包含するインターネットに結合される。本発明の諸態様は、コンピュータ可読命令、コード断片、アプリケーションなどを様々な分散コンピューティング機器に配布するのに使用可能である。

ネットワークインフラストラクチャは、クライアント／サーバ、ピアツーピア、ハイブリッドアーキテクチャなどのネットワークトポロジのホストを使用可能にする。「クライアント」とは、それが関連していない別のクラスまたはグループのサービスを使用するクラスまたはグループのメンバである。ゆえに、コンピューティングにおいては、クライアントは、別のプログラムによって提供されるサービスを要求するプロセス（すなわち、大まかにいえば１組の命令またはタスク）である。クライアントプロセスは、他方のプログラムまたはサービス自体に関するどんな作業詳細も「知っている」必要なしに、要求されたサービスを利用する。クライアント／サーバアーキテクチャ、特にネットワークで接続されたシステムにおいては、クライアントは、普通、別のコンピュータ（すなわちサーバ）によって提供される共用ネットワークリソースにアクセスするコンピュータである。サーバは、通常、インターネットなどのリモートネットワークを介してアクセス可能なリモートコンピュータシステムである。クライアントプロセスは第１のコンピュータシステムでアクティブであることができ、サーバプロセスは第２のコンピュータシステムでアクティブであることができ、通信媒体を介して相互に通信が行われ、かくして分散された機能が提供され、複数のクライアントがサーバの情報収集機能を利用できるようになる。

クライアントとサーバは、プロトコル層によって提供される機能を利用して相互に通信を行う。例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）は、単に「Ｗｅｂ」ともいう、ワールドワイドウェブ（ＷＷＷ）と併せて使用される共通プロトコルである。通常は、ユニフォームリソースロケータ（ＵＲＬ）やインターネットプロトコル（ＩＰ）アドレスなどのコンピュータネットワークアドレスを使ってサーバまたはクライアントコンピュータが相互に識別される。コンピューティングデバイス間の通信は、通信媒体を介して提供される。特に、クライアントとサーバは、高容量通信のためにＴＣＰ／ＩＰ接続を介して相互に結合される。

一般に、コンピュータネットワークは、ネットワーク環境に配置されたサーバ機器とクライアント機器の両方を含み得る（ピアツーピア環境では、機器はクライアントとサーバの両方となる）。通信ネットワーク１６０は、ＬＡＮ、ＷＡＮ、イントラネットまたはインターネット、あるいはいくつかのコンピューティングデバイス１０ａ〜１０ｅの間の通信を円滑化するこれらのいずれかの組み合わせとすることができる。さらに、通信ネットワーク１６０は、ワイヤレス、有線、またはワイヤレスと有線の組み合わせの接続を含むことができる。さらに、コンピュータネットワークは、分散コンピューティング環境も含む。そのような環境では、コンピューティングタスクは、コンピュータネットワークにおけるアドレス指定可能な要素であるいくつかのコンピューティングデバイスにわたって分散される。

本発明の一態様によれば、通信ネットワーク１６０は、複数のコンピュータ１００ａ〜１００ｅからアクセス可能なサービス１５０をホスティングすることができる。サービス１５０は、このサービスのユーザすべてにコンピューティングサービスを提供するために、情報を収集し、コンピュータ１００ａ〜１００ｅのユーザを追跡する。

図２は、図１のネットワークのコンピュータ１００ａ〜１００ｅとして使用されるマルチメディア／ゲームコンソール１００の機能的構成要素を示す。マルチメディアコンソール１００は、レベル１キャッシュ１０２、レベル２キャッシュ１０４、およびフラッシュＲＯＭ（読み取り専用メモリ）１０６を有する中央処理ユニット（ＣＰＵ）１０１を備える。レベル１キャッシュ１０２およびレベル２キャッシュ１０４は、一時的にデータを格納し、したがって、メモリアクセス回数を減らし、それによって処理速度およびスループットを向上させる。複数のコア、ゆえに、さらなるレベル１およびレベル２キャッシュ１０２、１０４を備えるＣＰＵ１０１も提供される。フラッシュＲＯＭ１０６は、マルチメディアコンソール１００が電源投入されるとブートプロセスの初期段階の間にロードされる実行可能コードを格納することができる。

グラフィックス処理ユニット（ＧＰＵ）１０８およびビデオエンコーダ／ビデオコーデック（コーダ／デコーダ）１１４は、高速高解像度グラフィックス処理のためのビデオ処理パイプラインを形成する。データは、グラフィックス処理ユニット１０８からバスを介してビデオエンコーダ／ビデオコーデック１１４に搬送される。ビデオ処理パイプラインは、テレビまたは他のディスプレイへの送信のためにＡ／Ｖ（オーディオ／ビデオ）ポート１４０にデータを出力する。それだけに限らないが、ＲＡＭ（ランダムアクセスメモリ）などの、様々なタイプのメモリ１１２へのプロセッサアクセスを円滑化するために、ＧＰＵ１０８にメモリコントローラ１１０が接続される。

マルチメディアコンソール１００は、好ましくはモジュール１１８上に実装された、入出力コントローラ１２０、システム管理コントローラ１２２、オーディオ処理ユニット１２３、ネットワークインターフェースコントローラ１２４、第１のＵＳＢホストコントローラ１２６、第２のＵＳＢコントローラ１２８およびフロントパネル入出力サブアセンブリ１３０を含む。ＵＳＢコントローラ１２６および１２８は、周辺コントローラ１４２（１）〜１４２（２）、ワイヤレスアダプタ１４８、外部メモリ装置１４６（フラッシュメモリ、外付けＣＤ／ＤＶＤ−ＲＯＭドライブ、取り外し可能メディアなど）のためのホストとして働く。ネットワークインターフェース１２４および／またはワイヤレスアダプタ１４８は、ネットワーク（インターネット、ホームネットワークなど）へのアクセスを提供し、イーサネット（登録商標）カード、モデム、ブルートゥースモジュール、ケーブルモデムなどを含む多種多様な有線またはワイヤレスアダプタコンポーネントのいずれとすることもできる。

ブートプロセスの間にロードされるアプリケーションデータを格納するためにシステムメモリ１４３が設けられる。メディアドライブ１４４が設けられ、これにはＤＶＤ／ＣＤドライブ、ハードドライブ、または他の取り外し可能メディアドライブなどが含まれる。メディアドライブ１４４は、マルチメディアコンソール１００に内蔵することも、外付けとすることもできる。マルチメディアコンソール１００によって、実行、再生などのために、メディアドライブ１４４を介してアプリケーションデータにアクセスされる。メディアドライブ１４４は、シリアルＡＴＡバスや他の高速接続（例えばＩＥＥＥ１３９４）などのバスを介して入出力コントローラ１２０に接続される。

システム管理コントローラ１２２は、マルチメディアコンソール１００の可用性を保証することに関連する様々なサービス機能を提供する。オーディオ処理ユニット１２３およびオーディオコーデック１３２は、高忠実度ステレオ処理を用いる対応するオーディオ処理パイプラインを形成する。オーディオデータは、オーディオ処理ユニット１２３とオーディオコーデック１３２の間で通信リンクを介して搬送される。オーディオ処理パイプラインは、外部のオーディオ再生装置またはオーディオ機能を有する機器による再生のためにＡ／Ｖポート１４０にデータを出力する。

フロントパネル入出力サブアセンブリ１３０は、電源ボタン１５０およびイジェクトボタン１５２、ならびにマルチメディアコンソール１００の外面に露出しているＬＥＤ（発光ダイオード）または他の指示器の機能をサポートする。システム電源モジュール１３６は、マルチメディアコンソール１００のコンフィギュレーション要素に電力を供給する。ファン１３８は、マルチメディアコンソール１００内の回路を冷却する。

ＣＰＵ１０１、ＧＰＵ１０８、メモリコントローラ１１０、およびマルチメディアコンソール１００内の他の様々なコンフィギュレーション要素は、様々なバスアーキテクチャのいずれかを使用する、シリアルおよびパラレルバス、メモリバス、周辺バス、およびプロセッサまたはローカルバスを含む１つまたは複数のバスを介して相互接続される。例をあげると、そのようなアーキテクチャには、周辺装置相互接続（ＰＣＩ）バス、ＰＣＩエクスプレスバスなどが含まれる。

マルチメディアコンソール１００に電源が投入されると、アプリケーションデータがシステムメモリ１４３からメモリ１１２および／またはキャッシュ１０２、１０４にロードされ、ＣＰＵ１０１上で実行される。アプリケーションは、マルチメディアコンソール１００上で利用可能な様々なタイプのメディアにナビゲートするときに一貫性のあるユーザ体験を提供するグラフィカルユーザインターフェースを提示することができる。動作に際しては、メディアドライブ１４４内に含まれるアプリケーションおよび／または他のメディアがメディアドライブ１４４から起動され、または再生されて、マルチメディアコンソール１００にさらなる機能を提供することができる。

マルチメディアコンソール１００は、単にシステムをテレビまたは他のディスプレイに接続することにより、独立タイプシステムとして操作される。この独立タイプモードでは、マルチメディアコンソール１００は、１人または複数のユーザがシステムと対話したり、映画を見たり、音楽を聴いたりすることを可能にする。しかしながら、ネットワークインターフェース１２４またはワイヤレスアダプタ１４８を介して利用可能とされる広帯域接続を統合すれば、マルチメディアコンソール１００は、さらに、図１に示すより大規模なネットワークコミュニティへの参加者として操作される。

本発明の一態様によれば、コンソール１００上でゲームが実行されると、それは、通信ネットワーク１６０上で動作しているサービスに情報を提供する。サービスは、豊富なユーザ体験を提供するために、サービスに接続されたユーザすべての情報を追跡する。サービスは、ゲーム、コンソール、コンピューティングデバイスなどにまたがってユーザ情報を追跡する。サービスのすべてのユーザの情報を追跡することにより、サービスは、すべてのユーザの統計を集約し、ゲームプレー能力を測定し、友人に関する情報（例えば、友人らがどんなゲームをプレーしているか、どれほどの技能レベルを達成しているかなど）を提供することによってより豊富なユーザ体験を提供し、ユーザ成績を追跡し、大規模なユーザコミュニティにわたって集約されたゲームの統計を広範に測定することができる。

異なるゲームにまたがる一貫性のあるデータセットを提供するために、本発明では、各ゲームが、特定のゲームでのゲームデータを定義するスキーマを生成するスキーマ主導プロセスを考える。ゲームコンフィギュレーションプロセスを介して、ゲームは、サービス定義のスキーマを使って、そのゲームが各ゲームプレーヤに関して生成するデータを記述する。コンフィギュレーションプロセスを使用することにより、サービスは、データがゲームから流れる際にデータを理解することができ、そのデータを、サービスが理解するその他のデータと意味のあるやり方で統合して、サービスの各ユーザの豊富なプロファイルを作成することができる。このプロファイルは、ユーザがそのサービス上のどこに行こうともそのユーザに付随する。すなわち、それはゲームおよび場所に依存しない。プロファイルの一部は、実際、サービスのあらゆるユーザから見ることが可能である。

図３は、ゲーム開発者がサービスと共に使用するためのゲームを設定(configure)できるようにする全体プロセスを示す。ゲーム開発者３０１は、ユーザ３０２がサービスと共に使用するためのゲームを作成しようとしている。そのために、開発者は、以下でより詳細に説明するツールを使って、サービスと共用されることになる１組のゲームコンフィギュレーションデータ３０４を提供する。ツールの使用からの出力は、サービスと通信を行うためにゲームと共に含まれる１組のＡＰＩヘッダファイル３０６、およびサービスと共用されるデータのスキーマを定義する１組のＸＭＬファイル３０８である。次いで、ゲーム開発者３０１は、ＡＰＩ３０６およびＸＭＬスキーマファイル３０８（または同等の表現）を備えるゲームコードを含むゲームディスク３１０を焼き、またはゲームプログラムを作成する。ＸＭＬファイルは、ユーザ３０２がゲーム３１０をオンラインで使用するときに、サービスがゲームからのデータ出力を使ってユーザ３０２のオンラインユーザプロファイル３１２を更新することができるように、サービス３１２にも伝達される。ユーザ３０２がネットワーク接続なしでゲーム３１０を使用するときには、情報が収集され、ハードドライブまたはメモリユニット３１６のユーザオフラインプロファイルに格納される。その後、ユーザ３０２がサービスに接続すると、オンラインとオフラインのプロファイルが同期される。その場合、ユーザ３０２は、ローカルで、すなわちコンソール１００またはＰＣ上でプロファイル情報を見る３１８ことも、サービスにログオンしてユーザプロファイル３１４を見ることもできる。

図４は、さらに、サービスと共に使用するためのＸＭＬファイル３０８を生成するのに使用されるコンフィギュレーションツール４００の流れを示す。最初に、ゲーム開発者３０１は、例えばシューティング、レーシングといった、ゲームジャンル４０２を選択する。次いで、ジャンル選択を使って、そのようなゲームがプレーされるときにサービスによって一般に収集されるはずの事前定義されたデータのタイプを持つ、１組のテンプレートが生成される。次いで、ゲーム開発者３０１は、ステップ４０４、４０６、４０８で、テンプレートによって生成された様々なセッション情報および競技情報を吟味し、編集する。この編集を使って、ツールの基礎をなすＸＭＬファイル３０８が変更される。次いで、ゲーム開発者３０１は、ゲーム４１０によって生成されるプレゼンスデータ、統計４１２、トロフィ成績４１４、ゲーム使用法４１６および競技統計４２０に関して（ツールを介して）ＸＭＬファイルを編集する。それらの編集を完了した後、システムは、未使用ジャンルタグの有無をチェックし、一定レベルのゲーム間のジャンル情報との合致を実現するために代替タグの使用を示唆する（ステップ４２２）。その後、ＸＭＬ定義に基づいてＡＰＩヘッダファイルが自動的に生成され（ステップ４２４）、情報のローカライズ表示（例えば、日本語、スペイン語など）のためのタグのリストが作成される（ステップ４２６）。特定のゲームに定義される成績に特有の１組の識別子が作成され（ステップ４２８）、プロセスが完了する（ステップ４３４）。

事前定義された、ジャンル特有の値は、拡張可能であり、統計、成績、プレゼンス、およびサービスがゲーム内外でのユーザの活動を理解し、示すのに必要とするその他のデータのキービットを取り込む。ゲーム開発者は、これらの値と直接対話する必要はなく、コンフィギュレーションツールを使ってこれらを用いることができる。

コンフィギュレーションツールは、ゲーム開発者に、ツールでの事前定義された値とゲーム独自の拡張された追跡可能な値セットの両方を使って、自社のゲームの記述を入力させる。最後に、ツールは、ツールに入力された値すべてのフォーマット済みの列挙を提供するＸＭＬコンフィギュレーションファイルを生成する。

ツールは５つの主要部分を持つ。

対戦セッションエディタ(match session editor)
ここで、ゲームはコンソールに、対戦相手決定のためのゲームプレーセッションを作成するのにユーザが行う必要のあるステップを知らせる。この定義は、コンソールがゲームセッションの開始点を取り込むことができるように、コンソールが（マップ名から難易度まで）重要なゲーム順列すべてを理解していることを確認する。

ビューエディタ(view editor)
ビューエディタは、ゲーム開発者がサービスに、ゲームデータの特定のビットをどのように使って、統計やプレゼンスなどの重要なサービス機能が構築されるか知らせることを可能にするツール部分である。ビューは、開発者が、文字通り、追跡しようとする統計のタイプ、およびその統計に対してどの集約方法を使用すべきか（例えば、「１マップ当たりの合計撃破数を追跡する」または「１マップ当たりの撃破数／死者数を追跡する」など）を指定することができるようにする。コンフィギュレーションツールは、各ゲームで、最小限の必要な統計およびプレゼンスフィールドのセットが必ず定義されているようにいくつかのデフォルトビューを提供する。

コンテキスト、プロパティ、および成績エディタ(context, property, and achievements editor)
ツールはゲーム開発者に、成績を定義させ、（説明、タイトル、およびトロフィイメージを含めて）それを表示させ、コンテキスト（マップおよびその列挙など）を作成させ、新たなプロパティ（撃破数統計など）を作成させる機構を含む。

多様なプレゼンスモードエディタ(rich presence mode editor)
ゲーム開発者は、多様なプレゼンスモードエディタを使って、静的テキストおよび（ゲーム中に更新されるコンテキストおよびプロパティによって定義される）可変トークンを含む多様なプレゼンスストリングを書く。

開発者用出力(outputs for developers)
ツールは、ＡＰＩヘッダファイル、ローカライズすべきストリングのリスト、ゲーマがそのゲームの外部でセッションを作成するときにゲームがサービスから受け取る「セッション開始」メッセージの形式、および（コンソールクライアントが、オフライン状態でさえ、ゲームから流れるデータを解釈することができるように）ゲームがゲームディスク上に含める必要のあるコンフィギュレーションファイルを出力する。

ゲームは、ＳｅｔＣｏｎｔｅｘｔ ＡＰＩ、ＳｅｔＰｒｏｐｅｒｔｙ ＡＰＩおよびＳｅｓｓｉｏｎ ＡＰＩを用いてサービスと対話する。ゲームの複雑な構造の大部分がコンフィギュレーションツールに取り込まれるため、サービスにデータを書き込むためのＡＰＩは比較的簡単である。実際、サービスがユーザプロファイルを構築できるようにするためにゲームがサービスに知らせる必要のあることは、基本的に３つしかない。

ＳｅｔＣｏｎｔｅｘｔ ゲーム「コンテキスト」は、マップ、乗り物、銃、および、変化することはできるが関連付けられたどのような集約方法も持たない他のゲーム状態のような、別個の列挙値のセットである。その場合、ＳｅｔＣｏｎｔｅｘｔ ＡＰＩは、サービスに、コンテキストがいつ変化したか（およびそれがどのように変化しているか）知らせる。

ＳｅｔＰｒｏｐｅｒｔｙ ゲーム「プロパティ」は、それらに適用される必要のある演算または集約方法を持つゲーム要素またはイベントである。プロパティには、撃破数（加算する）、発射された銃弾数（加算する）、勝利数（加算する）、健康状態（減算または加算する）、あるいは時間（レーシングゲームでは最低時間を取る）などが含まれる。その場合、ＳｅｔＰｒｏｐｅｒｔｙ ＡＰＩは、プロパティがもたらされ、それを適当なやり方で操作する必要があるというサービスへのメッセージである。

ＳｅｔＡｃｈｉｅｖｅｍｅｎｔ ゲーム成績は、ゲームプレー中に獲得されたトロフィである。ＳｅｔＡｃｈｉｅｖｅｍｅｎｔ ＡＰＩは、ユーザが成績を挙げたというサービスへ（またはオフライン記憶）へのメッセージである。

セッション情報 ゲームは、セッションがいつ始まったか、ユーザがいつセッションに加わった（あるいはセッションから退出した）か、およびいつセッションが終了したかをサービスに知らせなければならない。セッション情報は、コンテキストおよびプロパティ情報、ならびにビュー定義と結合され、クライアントソフトウェアが、ゲームにおいてどのプロパティが一緒に集約される必要があるか、それらが誰に属するか、エクスポートするためのデータセットがいつ完全に揃うか知ることができるようにする。

ローカライズ化(localization) 統計、プレゼンス、および成績をコンソール上および世界中のＷｅｂ上で見えるようにするためには、拡張ＸＭＬ値すべてのローカライズ化されたストリング(localized string)提供することが不可欠である。コンフィギュレーションツールは、ゲームに、どのストリングがさらにローカライズされる必要があるか追跡させるローカライズ化ツールを含む。事前定義された値は、すでに、それらに関連付けられたローカライズ化されたストリングを持つ。

読み取りＡＰＩ(read APIs) サービスがゲームに提供するユーザプロファイルデータ機能は、表示または他の目的（統計、成績、対戦相手決定(matchmaking)など）のためにデータを読み戻す関連ＡＰＩ(associated API)を持つ。

このプロセスが完了すると、ゲームはユーザプロファイルデータストリームに接続される。これは、各ゲーマごとの統計、プレゼンス、および成績情報が、ゲームディスクが取り出された後でさえも、コミュニティ全体に公表されることを意味する。これは、ゲームのユーザプロファイルデータを活用する、システムに組み込まれた機能が、ゲームが出荷された後、時間が経つにつれて改善されることを意味する。これは、プレーヤの誰も以前にそのゲームをプレーしたことがない場合でさえも、事実上、それらのプレーヤにぴったり合うことを保証する大量のデータから、ゲームのプレーヤ組み合わせ決定が得られることを意味する。

図５に関連して、以下の各段落では、ゲームによってサービスに送られるこのユーザプロファイルデータのすべてが消費され、ユーザ、ゲーム、およびユーザコミュニティ全体に反映される仕方について詳述する。図５に示すように、コンフィギュレーションツール４００の使用後、ゲームプログラム３１０は、ゲームの使用中に書き込まれ、サービス１５０と共用される情報を記述するコンフィギュレーションファイル３０８ａを持つ。さらに、サービス１５０は、それがゲームから収集するデータポイントを理解するために、ＸＭＬコンフィギュレーションファイルのコピー３０８ｂを持つ。その後、コンソール１００がサービス１５０に接続されると、ゲームは、対戦式オンラインゲームでの典タイプ的なゲームデータを伝達する。この伝達は、クライアント側のデータを集約し、コンフィギュレーションファイル３０８ａに従って収集されるゲームプレー中のユーザに関する情報を伝達するコンソールゲートウェイコンポーネント５０２を介して行われる。このコンソールゲートウェイコンポーネントは、ネットワークが、ゲームプログラムからの過度に頻繁な更新で溢れるのを防ぐ。その情報は、ゲームサービスゲートウェイ５０４を経てサービス１５０に周期的に送られる。

特に、このシステムは、ユーザがオフライン状態にあるときでさえも、ゲームプレーに関するデータが収集され得ることを意図している。様々な情報および統計がメモリユニット１４６に記録され、次いで、コンソール１００がサービス１５０に接続したときにサービス１５０と共用される。同様に、ユーザがオンライン状態にあるときでさえも、収集される情報は、それが効率のよいやり方で（すなわち、必ずしもリアルタイムではなく）サービスにアップロードされるように、メモリユニット１４６にバッファされる。さらに、サービスは、ゲームのＸＭＬコンフィギュレーションファイルを構文解析することにより、そのゲームデータを消費する必要のある１つまたは複数のサービス機能（例えば、それぞれ、ゲーム使用データ、多様なプレゼンス、成績および統計を表す、５１０、５１２、５１４および５１６などのサービス）を決定することができる。以下の段落で、収集される情報の用途についてさらに説明する。

統計サービス(statistics service)５１６は、撃破数、最高ラップタイム、高得点など、多種多様なゲーム中の統計を追跡し、表示するのを支援する。すべての統計は、プロパティ、コンテキストおよびビューの観点で図式化されなければならない。例えば、第１の人物のシューティングゲームでは、「撃破数」プロパティが、各「マップ」コンテキストごとに別個に追跡されると定義しようとすることができる（例えば、Ｂｌｏｏｄ Ｃｒｅｅｋでの撃破数５に対し、Ｂａｔｔｌｅ Ｒａｎｇｅでの撃破数１０など）。これらの統計を（ゲーム中またはＷｅｂ上または他の場所で）表示するのに必要とされる最後のステップは、例えば以下のようにビューを定義することである。

上記の例では、「撃破数」プロパティは、ＳＵＭ集約方法を使って、一連のゲームセッションごとの統計更新をまとめる。ＳＵＭに加えて、システムは、ＭＩＮ、ＭＡＸ、ＥＬＯ、ＬＡＳＴといった他の集約方法もサポートする。

統計ビューとしてゲームのＸＭＬコンフィギュレーションファイルに取り込まれることにより、プロパティがクライアント側で集約され、サービスに設定され、そこでそれらが正しく格納され、フォーマット設定および表示のために利用できるようになる。

各ゲームは、そのゲームの特性にマッチする最小限のプロパティ、コンテキストおよびビューのセットをサポートする必要がある。

成績サービス５１４は、全プレーヤに対する全体ランキング上での個々の進捗および成績（トロフィの場合など）を強調することにより、異なる手法でプレーヤ統計を追跡する。

成績は、チェックポイントの完了、新たな技能レベルへの前進、キャリアマイルストーンの達成、新たなコンテンツの獲得／解除、トーナメントや任意の注目すべきゲーム中のイベントなどの実際のイベントでの順位を追跡するためのものである。成績は、ＸＭＬコンフィギュレーションファイルで明示的に呼び出され、ＳｅｔＡｃｈｉｅｖｅｍｅｎｔ ＡＰＩを介して書き込まれる。

各ゲームタイトルは、「１０時間プレーした」や「１００セッションプレーした」といった、いくつかの事前定義された成績をサポートする必要がある。さらに、各ゲームは、ポイント授与に関連付けられた最低でも５つのゲーム特有の成績を定義する必要がある。

多様なプレゼンスサービス５１２は、すべてのプレーヤのオンラインプレゼンス／状況情報を集める。結果として、ユーザは、自分の友人がオンライン状態であるかどうか、その友人がどのタイトルをプレーしているかだけでなく、その友人がそのゲームのどこにいるか、その得点はどれほどか、および／またはそのゲームでどれほどの時間が残されているかも見分けることができる。

多様なプレゼンスサービス５１２と共に使用するために、ゲームは、ユーザの現在のゲーム状態に関連付けられたコンテキストおよびプロパティを更新する必要がある。各ゲームは、そのゲームのための、カスタマイズされた、ローカライズ可能なコンテキストベースの多様なプレゼンスストリング／パーサを作成することができる。多様なプレゼンスストリングは、事前定義された、ジャンル別のプロパティまたはコンテキストあるいはゲームごとにカスタマイズ可能なプロパティまたはコンテキストから構成される。リッチプレゼンスで使用される同じコンテキストまたはプロパティの一部（例えばマップなど）は、対戦相手決定セッションパラメータの設定にも使用することができる。多様なプレゼンスストリング／パーサ(rich presence string/parser)は、そこにプロパティまたはルックアップが代入されるＰｒｉｎｔｆステートメントであると考えることができる。

クライアントソフトウェアは、友人、グループ、および最近のプレーヤに関するＵＩおよびプレゼンス要件を管理する。クライアントソフトウェアは、オンラインおよびオフライン状態のゲーマのより多様な異なるタイトルにまたがるビューも提供する。ゲームは、ユーザがその状態、オンライン時間、空き状態などをどのように定義するかを処理するコードを持つ必要はない。ゲームは、他の人が自分のゲームからブロードキャストするのに最も重要なコンテキストおよびプロパティを処理するコードさえ持てばよい。

図６〜図８は、さらに、コンソールとサービスの間の通信のためのコンフィギュレーションファイルを生成するのに使用されるツールを示す。一般に、コンフィギュレーションツールは、ゲーム開発者が通信プロセスを標準化するのを容易にする。

図６は、ゲームとサービスの間でどの統計情報が共用されるかを決定するプロセスを示す。この図には、開発者（３０１など）がステップ６２０で統計ビューを選択した後のツールビュー６０２が示されている。その後、ステップ６２４で、開発者は、統計コンフィギュレーションを作成し始める。挿入ボタン６０４ａは、開発者に、ボックス６０４ｂに示す挿入コンテキストメニューから１つまたは複数のコンテキストを指定させ（ステップ６２６）、メイン画面６０２に戻る。ボックス６０８は、開発者に、追跡すべきいくつかのプロパティを設定させる。図の例には、開発者が４つの追跡すべきプロパティを選択していることが示されている。ボックス６１０は、開発者に、プロパティのラベルを付加させる。ボックス６１２は、開発者に、ＳＵＭなどの集約方法を選択させる。ボックス６１６は、開発者に、最小と最大の範囲、例えば２から１００などを設定させる。ボックス６２０は、開発者に、プロパティの形式、例えば数、時間、パーセンテージなどを設定させる。開発者が特定のコンテキストの情報すべてを入力した後、ボタン６１８はそのコンフィギュレーションを保存し、開発者がそのデータを見直し、編集することができるようにする。

図７は、さらに、多様なプレゼンスエディタを示す。ステップ７０４から開始して、ユーザは、多様なプレゼンスを選択し、既存のストリングを編集する（ステップ７０６）か、新たなストリングを作成する（ステップ７０８）か、それとも翻訳すべき既存のプレゼンスストリングを選択する（ステップ７１８）か選択する。ステップ７０６が選択された場合、開発者は、例えばメニューから、編集すべきプレゼンスストリングを選択する。ボックス７０２ａに示すように、開発者はストリングを入力し、挿入ボタン７１６を使ってそれをコンフィギュレーションファイルに挿入する。ステップ７０８が選択された場合、ステップ７１２でプレゼンスＩＤおよびストリングＩＤが生成される。その後ステップ７１４において、開発者は、ストリング名、説明などを記入する。ステップ７１８が選択された場合、開発者は、ボックス７０２ｂに示すようにテキストの翻訳を入力する。

最後に、図８は、コンテキストおよびプロパティエディタをさらに示す。ステップ８０８において、開発者は、新たなコンテキストまたはプロパティを作成しようする。コンテキストが選択された場合、一意のＩＤおよびストリングＩＤが割り当てられる。ステップ８１６において、開発者は、名前、説明、列挙タイプ（ストリングまたは数）を記入する。列挙タイプがストリングに設定された場合、開発者は、ボックス８１８に示すように、ボックス８２０にその列挙を入力する。例えば、開発者は、あるゲームに存在する様々なマップ名を列挙することができる。それぞれが定義される際に、一意のＩＤおよびストリングＩＤが割り当てられる。列挙タイプが数に設定された場合、ボックス８２２は、開発者に、ボックス８２４に数情報を入力させる。ボックス８２８において、開発者は、チェックボックス８２６に示すようにユーザに表示されるメニューにおいてどの列挙がロックされ、どの列挙がデフォルトであるか定義する。

ステップ８０８において、開発者がプロパティを選択した場合、そのプロパティに一意のＩＤおよびストリングＩＤが割り当てられ（ステップ８１０）、開発者は、プロパティ名、説明およびタイプを記入する。

開発者によって入力された情報すべての結果として、様々なコンテキストおよびプロパティを記述する、そのゲームの様々な統計、多様なプレゼンスなどの情報を記述するＸＭＬファイルが生成される。この情報は、ゲートウェイ５０２によって、コンソールがサービスに送る前にどの情報を集約すべきか、どの情報がサービスに未処理で送られるべきか、その情報はどのようにフォーマットされるべきか、その情報にどのように、どんなラベルが表示されるべきかなどを決定するのに使用される。ＸＭＬ出力ファイルの一例を以下に示す。

当然ながら、このＸＭＬは、出力形式の一例にすぎない。他の出力形式も使用され得るはずである。さらに、このＸＭＬは、バイナリファイル形式などの異なる形にも変換することができる。

以上、本発明を様々な図の好ましい実施形態と共に説明したが、本発明から逸脱することなく本発明と同じ機能を実行するために、他の類似の実施形態を使用することもでき、前述の実施形態に変更および追加を行うこともできることを理解すべきである。

本発明の諸態様を実施するための例示的コンピュータネットワーク環境を示すブロック図である。 図１に示したネットワークコンピューティング環境などのネットワークコンピューティング環境に組み込まれる例示的コンソールを示すブロック図である。 ゲームアプリケーションがサービスとやりとりできるようにするスキーマファイルを生成するシステム全体を示す図である。 スキーマの生成を示す流れ図である。 ゲームとサービスの通信のアーキテクチャを示す図である。 開発者によって、ゲームとサービスの間の通信で使用するためのスキーマを生成するのに使用されるツールを示す図である。 開発者によって、ゲームとサービスの間の通信で使用するためのスキーマを生成するのに使用されるツールを示す図である。 開発者によって、ゲームとサービスの間の通信で使用するためのスキーマを生成するのに使用されるツールを示す図である。

符号の説明

１００ マルチメディアコンソール
１０１ 中央処理ユニット
１０２ レベル１キャッシュ
１０４ レベル２キャッシュ
１０８ グラフィックス処理ユニット
１１０ メモリコントローラ
１１２ メモリ
１１４ ビデオエンコーダ／ビデオコーデック
１２０ Ｉ／Ｏコントローラ
１２２ システム管理コントローラ
１２３ オーディオ
１２６ ＵＳＢコントローラ
１２８ ＵＳＢコントローラ
１３０ フロントパネルＩ／Ｏサブアセンブリ
１３２ オーディオコーデック
１３６ システム電源モジュール
１３８ ファン
１４０ Ａ／Ｖポート
１４２（１） コントローラ
１４２（２） コントローラ
１４３ システムメモリ
１４４ メディアドライブ
１４６ メモリユニット
１４８ ワイヤレスアダプタ
１５０ サービス
１６０ 通信ネットワーク
３０１ ゲーム開発者
３０２ ユーザ
３０４ ゲームコンフィギュレーション
３０６ ＡＰＩヘッダファイル
３０８ ＸＭＬファイル／コンフィギュレーションファイル
３１０ ゲームディスク
３１２ サービスオンラインプロファイル
３１４ オンラインプロファイルのビュー
３１６ ＭＵ／ＨＤオフラインプロファイル
３１８ オンラインまたはオフラインプロファイルのビュー

Claims (22)

1. ユーザ間で情報を共用するシステムにおいて、
   少なくとも２つの異ったゲームアプリケーションのコンフィギュレーションファイルであって、該コンフィギュレーションファイルは、サービスと共用するために当該ゲームアプリケーションからの情報を定義するコンフィギュレーションファイルと、
   前記コンフィギュレーションファイルによる定義に従って前記アプリケーションから情報を受け取るサービスであって、該サービスは、該サービスにより受け取られる情報に基づいて前記少なくとも２つの異なったゲームアプリケーションのユーザに関する情報を提供するサービスと、
   を具備したことを特徴とするシステム。
2. 前記サービスは、ネットワークを介して前記アプリケーションから前記情報を受け取る、ことを特徴とする請求項１に記載のシステム。
3. 前記コンフィギュレーションファイルはタグベースのスキーマである、ことを特徴とする請求項１に記載のシステム。
4. 前記タグベースのコンフィギュレーションファイルはＸＭＬに基づく、ことを特徴とする請求項１に記載のシステム。
5. 前記ゲームアプリケーションはコンピュータ上で実行され、前記ゲームアプリケーションは、前記コンフィギュレーションファイルによって定義される前記情報を、前記情報の各部分を前記サービスに対していつ伝達すべきかを決定する中間プログラムに伝達する、ことを特徴とする請求項１に記載のシステム。
6. 前記中間プログラムは、前記コンピュータが前記サービスから切断されるときに前記情報の各部分を格納する、ことを特徴とする請求項５に記載のシステム。
7. 前記情報は成績データを含む、ことを特徴とする請求項１に記載のシステム。
8. 前記情報はプレゼンスデータを含む、ことを特徴とする請求項１に記載のシステム。
9. 前記情報はゲーム統計データを含む、ことを特徴とする請求項１に記載のシステム。
10. ユーザ間で情報を共用する方法において、
    少なくとも２つの異ったゲームアプリケーションのコンフィギュレーションスキーマを提供するステップであって、該コンフィギュレーションスキーマは、サービスと共用するために当該ゲームアプリケーションからの情報を定義するステップと、
    前記スキーマによる定義に従って前記アプリケーションから情報を受け取るステップと、
    前記サービスにより受け取られる情報に基づいて前記少なくとも２つの異なったゲームアプリケーションのユーザに関する情報を提供するステップと、
    を含むことを特徴とする方法。
11. 前記サービスは、ネットワークを介して前記アプリケーションから前記情報を受け取る、ことを特徴とする請求項１０に記載の方法。
12. 前記スキーマはタグベースのスキーマである、ことを特徴とする請求項１０に記載の方法。
13. 前記タグベースのスキーマはＸＭＬに基づく、ことを特徴とする請求項１０に記載の方法。
14. 前記ゲームアプリケーションはコンピュータ上で実行され、前記ゲームアプリケーションは、前記スキーマによって定義される前記情報を、前記情報の各部分を前記サービスに対していつ伝達すべきかを決定する中間プログラムに伝達する、ことを特徴とする請求項１０に記載の方法。
15. 前記コンピュータが前記サービスから切断されるときに前記コンピュータにおいて前記情報の各部分を格納するステップを含む、ことを特徴とする請求項１４に記載の方法。
16. 前記情報は成績データを含む、ことを特徴とする請求項１０に記載の方法。
17. 前記情報はプレゼンスデータを含む、ことを特徴とする請求項１０に記載の方法。
18. 前記情報はゲーム統計データを含む、ことを特徴とする請求項１０に記載の方法。
19. サービスと共用するためにゲームアプリケーションからの情報を定義する少なくとも２つの異ったゲームアプリケーションのコンフィギュレーションファイルを備えたシステムにおいて、ユーザ間で情報を共用する方法であって、
    前記ゲームアプリケーションの１つを実行しているコンピュータ上で実行中の中間プログラムにおいて、前記コンフィギュレーションファイルによる定義に従って前記アプリケーションから情報を受け取るステップと、
    前記アプリケーションから受け取られる前記情報の少なくとも一部を格納するステップと、
    前記中間プログラムがネットワークを介してサービスと通信しているときに前記情報の少なくとも一部を送るステップであって、前記サービスは、前記サービスにより受け取られる情報に基づいて前記少なくとも２つの異なったゲームアプリケーションのユーザに関する情報を提供するステップと、
    を含むことを特徴とする方法。
20. 開発者からの１組の入力に基づいて前記コンフィギュレーションファイルを生成するプログラムを含む、ことを特徴とする請求項１９に記載の方法。
21. 前記プログラムはＸＭＬコンフィギュレーションファイルを生成する、ことを特徴とする請求項１９に記載の方法。
22. 前記中間プログラム、前記ゲームアプリケーションのうち実行中の１つのアプリケーション、および前記サービスは、前記コンフィギュレーションファイルによる定義に従って情報を伝達する、ことを特徴とする請求項１９に記載の方法。
    

Images