(57)【特許請求の範囲】
【請求項１】
少なくとも第１のユーザのパフォーマンスシーケンスを示すパフォーマンスデータを記録できる第１のコンピュータ装置上で、複数のユーザのパフォーマンスシーケンスを当該パフォーマンスデータに基づいてシミュレートする方法であって、
ａ）前記第１のコンピュータ装置を少なくとも１つのサーバに通信ネットワークを介して接続するステップと、
ｂ）前記パフォーマンスデータを少なくとも１つのサーバにアップロードするステップと、
ｃ）前記第１のユーザと所定の関係を有する少なくとも１人の他ユーザを識別する他ユーザ識別データを、前記通信ネットワークを通して送信するステップと、
ｄ）検索クエリーに応じて前記他ユーザのパフォーマンスデータを検索するために、少なくとも１つのサーバが当該少なくとも１つのサーバに付随するデータベースにアクセスできるようにするための検索クエリーを構築するステップと、
ｅ）前記検索クエリーを、当該検索クエリーに合う前記他ユーザのパフォーマンスデータを要求する前記第１のコンピュータ装置によって、少なくとも１つのサーバに前記通信ネットワークを通して送信するステップと、
パフォーマンスデータのためのオプションを前記第１のユーザによって特定するステップとを含み、
前記検索クエリーを構築するステップは、パフォーマンスデータのための前記オプションを使って前記検索クエリーを構築するステップを含む、方法。
【請求項２】
前記検索クエリーに合う他ユーザのパフォーマンスデータのパッケージを通信ネットワークを通して受信するステップを、さらに含む、請求項１に記載の方法。
【請求項３】
前記検索クエリーを構築するステップは、前記第１のユーザが対戦したい他ユーザの識別を含むように前記検索クエリーを構築するステップを含む、請求項１に記載の方法。
【請求項４】
前記他ユーザ識別データをサーバから前記通信ネットワークを通して受信するステップを、さらに含む、請求項１に記載の方法。
【請求項５】
前記他ユーザ識別データは、前記第１のユーザの友人である他ユーザのデータである、請求項１に記載の方法。
【請求項６】
前記検索クエリーを送信するステップは、閾値を越えるパフォーマンスを持つ他ユーザに対して要求を送信するステップを含む、請求項１に記載の方法。
【請求項７】
前記検索クエリーを送信するステップは、前記第１のユーザのパフォーマンスと類似しているパフォーマンスを持つ前記他のユーザのパフォーマンスデータの要求を送信するステップを含む、請求項１に記載の方法。
【請求項８】
前記検索クエリーを送信するステップは、所定の関連性を有する他ユーザ群から成る複数の個人に対して要求を送信するステップを含む、請求項１に記載の方法。
【請求項９】
前記検索クエリーを送信するステップは、他ユーザによって高く評価されているパフォーマンスを持つ他のユーザのパフォーマンスデータの要求を送信するステップを含む、請求項１に記載の方法。
【請求項１０】
前記所定の関連性を有する他ユーザ群は、同じチームのメンバーである、請求項８に記載の方法。
【請求項１１】
前記ユーザのパフォーマンスデータは、シミュレートされた運転シーケンスを記録したデータである、請求項１に記載の方法。
【請求項１２】
前記ユーザのパフォーマンスデータは、ビデオゲームのパフォーマンスシーケンスを記録したデータである、請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチユーザのパフォーマンスシミュレーターに関し、より特定的には、レースゲームにおける「ゴースト」パフォーマンスデータなど、マルチプレイヤビデオゲームで使用されるパフォーマンスデータを選択して描画する改良された方法および装置に関する。
【背景技術】
【０００２】
長年にわたり、レースタイプのビデオゲームが人気を博している。周知のように、このようなビデオゲームにおいては、プレイヤは自身のレースパフォーマンスを表すレースデータを取り込み、取り込んだ「ゴースト」データと後のレースで対戦することができる。
【０００３】
例えば、マリオカート６４では、プレイヤの車両がトラックレースに参戦している間、ゲームプログラムはパフォーマンスにおける各ポイントでの車両位置情報を記録しながらゴーストデータを取り込む。レースが終了したら、プレイヤは再度トラックレースに参戦するか、格納された「ゴーストデータ」を基にプレイヤの過去のパフォーマンスでその位置が表された「ゴースト」車両と対戦するかを選択することができる。
【０００４】
従来のビデオゲームにおいては、あるプレイヤは別のプレイヤにゴーストデータを譲渡することができる。そうすれば、たとえ２人のプレイヤがリアルタイムでレースしていなくても、それら２人のプレイヤはレースを互いに「競い合う」ことができる。例えば、第１のプレイヤはゴーストデータをメモリーカードにコピーし、そのメモリーカードを第２のプレイヤに渡してもよい。上記第２のプレイヤは、このメモリーカードを自身のゲームシステムで使用することにより、第１のプレイヤのゴーストデータといつでも対戦できる。
【０００５】
さらに周知のように、データベースからインターネットを介してゴーストデータをアップロードしたり、ダウンロードしたりできる。このようなゲームの例としては、Ｍｉｃｒｏｓｏｆｔ  Ｘ-Ｂｏｘゲームである「Ｐｒｏｊｅｃｔ  Ｇｏｔｈａｍ  Ｒａｃｉｎｇ  ＩＩ」がある。
【発明の開示】
【課題を解決するための手段】
【０００６】
本実施形態においては、ユーザ自身が一緒にゲームするおよび／あるいは対戦する相手となるリアルユーザまたはコンピュータ生成のユーザを選ぶための数多くのオプションを生成する、より改良されたマルチプレイヤビデオゲーム用の方法および装置が説明されている。
【０００７】
一実施形態において、複数のドライバによるレースゲームをシミュレートするアプリケーションでは、コンピュータ装置のユーザには、インターネットなどの通信ネットワークを通してダウンードできる様々な「ゴーストデータ」パッケージのいずれかを選択するオプションが提示される。例えば、得点がトップ５に入るバディ５人、ユーザ本人と得点が近いバディ５人、様々なチーム／グループ、トップ５に入る対戦相手のベストパフォーマンス、プレイヤの最高記録であるゴーストデータの対戦相手として最も相応しいゴーストデータのトップ５など、各種ゴーストデータパッケージの中から対戦したいパッケージを１つを選ぶオプションがユーザに提示されてもよい。
【０００８】
本実施形態において、あるプレイヤのゴーストデータをダウンロードしたり、あるいは、パフォーマンスを基準として複数のプレイヤ各々のパフォーマンスを組み合わせるのではなく、選択可能なチームあるいはグループと対戦するレースが提供される場合、選択されるチームまたはグループのパッケージは、同じゲーム内容を共有する、つまり全く同じ時間に同じレースコースをリアルタイムで競った複数のプレイヤのパフォーマンスから収集された個人別のゴーストデータが組み合わされたものである。同じ時間に同じゲームを競ったユーザメンバーのパッケージを選択することにより、このゲームに関与する格納済みのゴーストデータではゴースト車両同士が接触する（ゴーストデータが同じコースでも異なるレースに基づいて抽出されていれば、ゴースト車両との接触はほとんどない）。このように、ゴーストデータでは実際のリアルレースで起こった衝突が反映されるため、ゴーストデータがその記録後に表示される際には、ゴースト車両同士の衝突が描写されることになる。
【０００９】
本実施形態によれば、ビデオゲームシステムにおいて、ユーザは選択できる複数のゴーストデータパッケージを１データ群あるいは１データ単位でダウンロードすることができる。
【００１０】
少なくとも一実施形態によれば、ユーザは自身のバディとして登録したプレイヤを様々に組み合わせたゴーストパッケージを選択してもよい。バディの登録は、複数のプレイヤが互いのバディを簡単に認証でき、かつ、競争しがいのある種々多様なレースが簡単に選択できるように行われる。
【００１１】
ユーザはレースにおけるカメラ視点を制御しながら、選択したパフォーマンスを自身のコンピュータ／ビデオゲームシステムで見てもよいし、あるいはカメラに自動的にプレイヤの１人を追わせてもよい。あるいは、ユーザは選択したゴーストパッケージから対戦相手を選んで競い合ってもよい。
【００１２】
一緒にゲームする／あるいは対戦する他のプレイヤ／バディ／チーム／グループを選択する方法は、本実施形態ではレースゲームを例として説明されているが、レースゲーム以外の他のアプリケーションであってもよい。本願で説明される方法は、複数ユーザのアクティビティのシミュレーションにおいて複数のユーザ／バディのパフォーマンスが記録、保存、および使用されるあらゆるビデオゲームなど（しかしこれに限定されない）、各種アクティビティのシミュレーションに適応されてもよい。例えば、本願で説明される方法は、これまで複数のプレイヤで争うことも一般的とされるカーレースから、飛行シミュレーション、陸上競技のスポーツ種目、ポーカ、アドベンチャーゲーム、その他のゲーム／教育用ゲームに及ぶアクティビティを競い合う友人／親族／著名人のありとあらゆる組み合わせを選択するのに使用されてもよい。
【００１３】
少なくとも一実施形態によれば、ゲームシステムの処理能力、関連性のある一秒毎に処理されるポリゴン数の制限、画面の解像度などの制約により、ビデオゲームコンソールが基盤のシステムあるいは小型ゲーム機におけるレースのシミュレーションでは、当初、描画されるオブジェクトやプレイフィールドの複雑度は相対的に低いものであった。ゴースト／パフォーマンスデータが収集され、アップロードされた後、例えばより強力なサーバによって、このようなオブジェクト／プレイフィールドはより高精細に描画される。
【００１４】
このような高精細の描画は、例えば、Ａｕｄｉｏ  Ｖｉｄｅｏ  Ｉｎｔｅｒｌｅａｖｅ（ＡＶＩ）のビデオファイル形式での集約が可能である。ＡＶＩ形式のファイルはＷｅｂ上で見ることもできるし、あるいは、（コンソールにＡＶＩファイルの再生機能があれば）コンソールにダウンロードして見ることもできる。上述の実施形態によれば、非常に多くのポリゴン数のグラフィックモデルを使って描画された車両および背景は、元々記録されたレースのシミュレーションにおける車両や背景の代わりに使用される。
【００１５】
そして、ユーザは非常に高い解像度でゴーストデータパフォーマンスを見てもよい。所望されれば、このような背景および車両は一実施形態において、たとえ（元のゴーストデータに基づいた）プレイヤのパフォーマンスが例えば実質的に同じままであっても、異なる設定場面における異なる背景および車両に完全に代えられてもよい。
【００１６】
例えば、後述のように、ニンテンドーＤＳがレースゲーム用の小型ゲーム機として使用された場合、画像オブジェクトの複雑度は、例えば車１台当たり１００〜５００個のポリゴンが使用される程度でしかない。プレイヤのパフォーマンスデータがインターネットを介してサーバにアップロードされたら、サーバはゴーストデータを処理し、全く異なるオブジェクトを使ってレースを再描画する。上述の実施形態においては、レース用トラック／地形は、ニンテンドーＤＳで使用されたものと実質上同じである。トラックはそっくり元のままであるが、背景の描画ががらりと変わってもよい。例えば、サーバは、元々砂漠であったレースの設定場面を熱帯リゾート地に変更して描画してもよい。上述の実施形態によれば、元々２百個のポリゴンしか使用されていない簡素なゴーカートのモデルは、それとはまるで違うもの、例えば、５千個のポリゴンでシミュレートされたフェラーリに代えられてもよい。
【００１７】
サーバはこのようなデータの描画をリアルタイムで行う必要はない。これにより、超高品質の描画の実現を妨げる制約が１つ解消されることになる。車両の空間での動きは、ゴーストデータの記録元であるレースと同じように維持されなければならない。
【００１８】
サーバは、例えば、レースデータをＭＰＥＧ形式のムービーファイルで描画し、データ要求元であるニンテンドーＤＳに対して描画したムービーファイルをダウンロードしてもよい。あるいは、他の認証ユーザがアクセスできるように、描画をＷｅｂ上に配置することもできる。これにより、例えば、レースチームあるいは友人グループのメンバーが超高品質で描画したレースを見たい場合があってもそれに対応できる。
【００１９】
この実施形態は、上述および本願で説明される様々な実施形態を組み合わせて、複数のゴーストデータパッケージが１つのＡＶＩファイルに描画されるようにしてもよい。同様にこの実施形態もレースアプリケーション以外のあらゆるアプリケーションに適用できる。
【００２０】
本発明のこれらおよび他の特徴、局面、利点は、添付図面と照合して、本発明の以下の詳細な説明により、いっそう明らかとなるであろう。
【発明を実施するための最良の形態】
【００２１】
図１は、本発明に係る方法および装置の非限定的な実施形態を実施するシステムの一例を示す図である。図１に示されるように、４台の携帯ゲーム機２、４、６、および８が使用され、インターネット１０に接続されている。
【００２２】
本実施形態において、上記携帯ゲーム機は、相互に無線通信が可能で、かつインターネット１０とも無線接続できるニンテンドーＤＳの携帯機とする。ここで、ニンテンドーＤＳについての詳細は、２００５年４月２２日に出願された米国出願番号Ｎｏ．１１／１１１，９８５に開示されており、この出願は、本明細書中にその開示内容が参照により組み込まれる。
【００２３】
ニンテンドーＤＳ以外のあらゆるコンピュータ装置が使用できることは言うまでもない。例えば、ゲーム装置２、４、６、および８は、様々なビデオゲーム用コンソール、携帯装置、またはパーソナルコンピュータであってもよい。このような装置には、例えば、その内部に組み込まれるイーサネット（登録商標）チップを一意に識別するためのメディアアクセスコントロール（ＭＡＣ）アドレスが個別に付与されていることが好ましいが、必ずしもそうである必要はない。したがって、例えば、ネットワーク接続が可能であるコンピュータ装置ならいかなるものでも、図１に示される１台以上のニンテンドーＤＳのゲーム機２、４、６、および８に加えて、あるいはゲーム機２、４、６、および８の代わりに使用されてもよい。無線通信が可能であるＤＳのような装置は、便利に持ち運べるので、バディ情報をローカルで容易に交換できる点で特に有利である。
【００２４】
ニンテンドーＤＳの各ゲーム機２、４、６、および８は、シングルプレイヤあるいはマルチプレイヤ用のビデオゲームを実行することができる。例えば、ユーザがシングルプレイヤゲームを行っている場合、ニンテンドーＤＳはインターネットに接続されていない。しかし、ニンテンドーＤＳの各ゲーム機２、４、６、および８は、シングルプレイヤレースゲームが行われている間、プレイヤのゴーストデータを記録してもよい。同様にマルチプレイヤゲームにおいても、ゴーストデータが記録されてもよい。
【００２５】
各ユーザのレースが終了したら、プレイヤはインターネット１０を介して、および、本実施形態ではバディサーバ１２、認証サーバ１６、得点・結果サーバ２０を使って、記録したゴーストデータを後述のようにアップロードすることができる。これらのサーバは、例えば、ビデオゲームのハードウェア／ソフトウェアの製造業者によって提供、管理されてもよい。
【００２６】
本実施形態においては、インターネットを介してゴーストデータをアップロードする際、プレイヤはまず認証サーバ１６に接続する。認証サーバ１６はユーザを認証後、バディサーバ１２および得点・結果サーバ２０に対するアクセス許可を上記プレイヤのニンテンドーＤＳに与える。
【００２７】
サーバコンピュータ１２、１６、および２０に必要な処理能力は、アプリケーションの要求によって異なる。例えば、あるアプリケーションでは、認証サーバ１６はパーソナルコンピュータ（ＰＣ）を含むコンピュータのいずれであってもよい。一実施形態では、バディサーバ１２、認証サーバ１６、得点・結果サーバ２０は、８ＧＢのＲＡＭと２００ＧＢのハードディスクとともに、ＡＭＤ社のＯｐｔｅｒｏｎのなどのデュアルコア２ＧＨｚのＣＰＵを含む。これらのサーバでは、例えば、リナックス社のＯＳであるＲｅｄ  Ｈａｔ  Ｅｎｔｅｒｐｒｉｓｅ  Ｌｉｎｕｘ４が使用され、そのデータベースはＳＱＬ社のデータベース管理ソフトウェアであるＯｒａｃｌｅ  Ｄａｔａｂａｓｅ  １０  Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎにより管理されてもよい。
【００２８】
本実施形態においては、各ニンテンドーＤＳには固有の識別子が関連付けられている。例えば、ニンテンドーＤＳの各ゲーム機２、４、６、および８は、本実施形態において、それぞれに内蔵されているイーサネット（登録商標）チップを一意に識別するためのメディアアクセスコントロール（ＭＡＣ）アドレスによって識別されてもよい。ここで使用されるニンテンドーＤＳの識別子は、プレイヤおよびゲーム機自体に関連する識別子を組み合わせたものであってもよい。
【００２９】
本実施形態によれば、ランダムな数字をＭＡＣアドレスに追加することによって、プレイヤＩＤを作成してもよい。これにより、例えば１台のニンテンドーＤＳを使用している家族における異なる子供を特定することができる。
【００３０】
プレイヤが初めて認証サーバ１６に接続した際、プレイヤＩＤを作成するコマンドが認証サーバ１６に送信される。プレイヤＩＤはニンテンドーＤＳで作成され、ニンテンドーＤＳが作成したユーザパスワードとともに認証サーバ１６で分析されてもよい。その後、例えば、ニンテンドーＤＳ２のユーザがインターネット１０にアクセスした場合、認証サーバ１６はゲーム機２にログオンするように促し、その結果、認証サーバ１６はプレイヤＩＤおよびパスワードを確認する。
【００３１】
認証サーバ１６によってニンテンドーＤＳ２が認証されると、トークンが生成される。本実施形態においては、トークンはニンテンドーＤＳ２と認証サーバ１６間で共有されるキーで暗号化されるビットの列であり、上記トークンは認証サーバ１６によりデジタル署名されている。トークンには有効期限日が関連付けられており、これによってトークンを使用できる期間が定められていてもよい。
【００３２】
例えば、ニンテンドーＤＳ２のユーザが、バディサーバ１２および得点・結果サーバ２０に認証シーケンスの一環としてアクセスしたい場合、ゲーム機２はトークンをこれら他のサーバに渡す。トークンはバディサーバ１２および得点・結果サーバ２０で有効に使われる。これは、トークンを使用することで、バディサーバ１２および得点・結果サーバ２０は、繰り返しユーザデータベース１８にアクセスすることなく、プレイヤの認証を許可できるからである。バディサーバ１２および得点・結果サーバ２０はそれぞれ、関連付けられたデジタル署名を分析することにより、認証サーバ１６がトークンを生成したと判断することができる。
【００３３】
認証サーバ１６にはユーザデータベース１８が付随しており、ユーザデータベース１８には多数のプレイヤＩＤ、パスワード、各プレイヤの認証状態が記憶されている。各プレイヤの認証状態は、例えばプレイヤがシステムへのアクセスを禁止されたことを示す状態情報を記憶するのに使われてもよい。
【００３４】
バディサーバ１２は、あるプレイヤが他のプレイヤを「バディ」として登録することを許可する。この場合、プレイヤはバディサーバ１２を使って、一緒にゲームをする１人以上の友人をオンライン上で探してもよい。例えば、バディサーバ１２を使って、レースで対戦する友人のゴーストデータを探し出してもよい。
【００３５】
ある実施形態においては、ニンテンドーＤＳ２を使用するプレイヤ１とニンテンドーＤＳ４を使用するプレイヤ２とが互いにプレイヤＩＤを交換してもよい。このようなＩＤの交換は、例えばプレイヤが手動で実行する交換処理によって行われてもよい。その後、プレイヤ１はプレイヤ２をバディの１人としてバディサーバ１２に登録してもよい。
【００３６】
これに対して、２人のプレイヤがオフラインで、つまりワイヤレスローカルエリアネットワークモードでゲームを行っている場合、プレイヤＩＤは自動的に交換される。その後、プレイヤ１および２のいずれかがインターネットにアクセスした時に、バディサーバ１２はもう１人のプレイヤのＩＤをバディの１人として登録してもよい。
【００３７】
バディサーバ１２には、バディデータベース１４が付随している。バディデータベース１４は、例えば、そこに格納されているプレイヤＩＤ毎のバディの登録人数を記憶している。バディプレイヤＩＤは、バディプレイヤ０〜ｎとして記憶される。また、様々なバディグループ０〜ｎも記憶されてもよい。あるバディグループは、例えば、プレイヤの友人８人で構成されていてもよい。別のバディグループは親族が集まったチームであってもよいし、さらに別のバディグループはレースチームのメンバーであってもよい。例えば、あるグループでは家族のメンバー、別のグループではレースチームのメンバーといったように、個人が複数のグループに所属していてもよい。
【００３８】
得点・結果サーバ２０には、得点・結果データベース２２およびゴーストデータ記憶データベース２４が付随している。これらのデータベースには、個人の得点と、本実施形態においてはプレイヤＩＤに関連付けられたゴーストデータとが記憶される。例えば、プレイヤ１のレースパフォーマンスが完了したら、認証サーバ１６に接続され、その後認証サーバ１６が生成したトークンが得点・結果サーバ２０に結合される。
【００３９】
得点・結果サーバ２０はトークンが有効であるかを判断し、有効であれば、プレイヤ１に対して得点・結果データベース２２およびゴーストデータ記憶装置２４へのアクセスを許可する。
【００４０】
プレイヤ１が認証されると、プレイヤ１が操作するニンテンドーＤＳはプレイヤ１のパフォーマンスを表すゴーストデータをサーバ２０に送信する。そして、プレイヤＩＤ、レースでプレイヤが獲得した得点、プレイヤがレースで選択した車両、およびプレイヤが選択したドライバを含む記録が生成される。さらに、例えばドライバの名前を特定するスクリーンネームが記憶されてもよい。
【００４１】
ある実施形態においては、ユーザがレースで選択したマップやコース、およびレース条件も記憶される。このような条件には天候条件や走行ラップ数など様々なレース条件が含まれてもよい。さらに、レースゲームの開始日およびレース開始時刻も記憶される。本実施形態では、プレイヤ１がマルチプレイヤゲームに参加していた場合、得点・結果データベース２０はホストＩＤとレースに参加しているプレイヤ全員（プレイヤ１〜プレイヤｎ）のＩＤとを記憶する。
【００４２】
さらに、ゴーストデータＩＤポインタが記憶される。ゴーストＩＤポインタは、関連するゴーストデータが記憶されているゴーストデータ記憶データベース２４内のロケーションを特定する。詳細は後述するが、さらなる実施形態によれば、ムービーファイル関連データも得点・結果サーバ２０に付随するデータベースに記憶される。
【００４３】
次に、ゴーストデータ記憶装置２４には、ゴーストデータを特定するゴーストデータＩＤが記憶される。記憶されているゴーストデータは、時間ｔ（０）からｔ（ｎ）までのｘ，ｙ，ｚ位置データを含む。空間内におけるｘ，ｙ，ｚ位置は、例えば、レース車両の重心を示していてもよい。上記位置データは、例えば、１／６０秒毎にインクリメントされてもよい。また、時間ｔ（０）からｔ（ｎ）までの向き情報も記憶され、車が向いている方向（例えば、前、後ろ、横など）を示すベクトルの向きを特定する。
【００４４】
さらに、車両状態情報も時間ｔ（０）〜ｔ（ｎ）毎に記憶され、例えば、特定の時刻において、車両は良好な状態にあったのか、破損していたのか、あるいはひどく破損していたのかなどを示す。このようなデータは、レース走行中、度々状態が変わる車両を描写するレンダリングエンジンによって使用されてもよい。インターネット経由で受信する多数のクエリー全てを効率よく対処できるように、得点・結果サーバ２０の処理能力は大きいことが好ましい。
【００４５】
図２は、プレイヤがゲームを始める際に実行される操作シーケンスの概要を示すフローチャートである。まず、メインメニューがユーザに表示される（２６）。本実施形態においては、ニンテンドーＤＳが起動したら、ユーザはゲームをするのか、あるいはゴーストデータをダウンロードするのかを選択する（２８）。
【００４６】
そして、ユーザがゲームをすることを選択したか否かが判定される（３０）。プレイヤがゲームをする選択をしている場合、上記プレイヤのレース終了後、図３Ａおよび図３Ｂを参照して後述するように、ゴーストデータを記録、保存および再生する処理がシステムによって実行される（３４）。
【００４７】
一方、プレイヤがゲームをする選択をしていない場合、図５Ａおよび図５Ｂを参照して後述するように、プレイヤは、実施形態において、ゴーストデータをダウンロードしてもよい（３２）。
【００４８】
図３Ａおよび図３Ｂは、ゴーストデータを記録、保存および再生する処理中に実行される操作シーケンスを示すフローチャートである。ゴーストデータを記録、保存、および再生する処理を開始する際（５０）、ユーザは、シングルプレイヤゲーム、あるいは、マルチプレイヤゲームのいずれかを選択せねばならない（５２）。
【００４９】
シングルプレイヤゲームとは、あるプレイヤが、プログラムロジックによって生成され、かつ、人工知能または決定マトリクスによって制御される他のプレイヤと対戦するゲームである（ただし、リアルタイムでゲーム機を操作している他のプレイヤとの対戦はできない）。また、シングルプレイヤゲームにおいて他のプレイヤは、過去に生成された「ゴーストデータ」で表わされている場合もある。上述したように、ゴーストデータはリアルプレイヤのパフォーマンスが記録されたものであり、後に別プレイヤの世界で再生される。通常、プレイヤはゴーストデータを用いて上記世界に描画されたキャラクタと接触したり、衝突したりしない。プレイヤは、上記世界の状態を手動で全て選択するか、あるいは、プレイヤが事前にゴーストデータパッケージを選択している場合は、ゴーストデータが記録された時の状態（例えば、マップ／コース、条件等）がプレイヤ自身のレースのパラメータとなる。しかし、ゴーストデータによる上記世界のパラメータに制限されてはいるものの、プレイヤは自身のキャラクタを選ぶことができる。
【００５０】
シングルプレイヤゲームが選択された場合、一連のメニューがプレイヤに提示され、レースマップやコース、車両、ドライバ、サウンドトラック、天候、ゴーストデータパッケージを選択することができる（６２）。ここで詳細は後述するが、ゴーストデータパッケージとは、例えば、得点がトップ５に入るバディ５人や、得点がプレイヤ本人のものと近いバディ５人など、プレイヤが対戦相手として選択しそうなゴーストデータ群が定義されたものである。
【００５１】
プレイヤが全てのレース条件を選択したら（６２）、レースで対戦するゴーストプレイヤなどのレースパラメータが定義される。本実施形態によれば、プレイヤは、レース中のＢＧＭとして機能するラジオ局やサウンドトラックなど、レースに関するあらゆる条件を選んでもよい。プレイヤはレースのラップ数も同様に選んでもよい。
【００５２】
ここで、ゴーストデータパッケージはユーザが選択できるようにメニュー形式で提示されるが、ゴーストデータパッケージはユーザが選択した条件に対応する機能として生成されてもよい。例えば、天候条件が大雨と定義された場合には、特定のゴーストデータ群が選択されてもよい。
【００５３】
マルチプレイヤゲームが選択されたか否かを判定するブロック５２に戻り、マルチプレイヤゲームが選択された場合、ルーチンは５４のマルチプレイヤ処理に進む。マルチプレイヤゲームのタイプには数種類ある。まず、数人のプレイヤが一台のゲーム機でマルチプレイヤゲームを行う場合がある。例えば、ニンテンドー・ゲームキューブのプラットフォームでは、一台のゲームキューブに接続された４つのコントローラを４人のプレイヤが同時に操作することができる。これに対して、本実施形態の図１に示されるように、４人の友人がニンテンドーＤＳゲーム機２、４、６、および８をそれぞれ一台ずつ持って、同時にゲームを行うこともできる。このようなゲームはワイヤレスローカルエリアネットワーク上で行われてもよいし、あるいは、ニンテンドーＤＳのようなゲーム機を使ってインターネットを介して行われてもよい。本実施形態ではマルチプレイヤゲームはいずれのタイプであってもよく、これは当業者であれば理解できるであろう。各ニンテンドーＤＳを用いて、例えば、各プレイヤはマルチプレイヤゲームに参加している他のプレイヤのプレイヤＩＤを記録する。さらに、好ましくは、各プレイヤはゲームホストのプレイヤＩＤを記録する。この場合、他のプレイヤが所属するチームがすぐに認識されてもよい。全ての適切なマルチプレイヤデータがそれぞれのＤＳゲーム機に記録された後、ゲームが開始されてもよい。
【００５４】
マルチプレイヤゲームが行われる場合（ここでマルチプレイヤゲームとは、リアルタイムで他のリアルプレイヤと対戦するゲームであり、各プレイヤは別々のコントローラを使って同じゲーム機でゲームを行うか、あるいは、各プレイヤがネットワークにつながったゲーム機をそれぞれ使用してゲームを行うものとする）、参加プレイヤのうちの１人がゲームの「ホスト」となる。通常、ホストは参加プレイヤ全員が共有するマップやコース、および、レースでのラップ数、天候条件、照明条件など、レースゲームにおける他の条件を決定する。ホストが選択したパラメータによって制限されてはいるものの、各プレイヤはホストが選択した世界で自身のキャラクタを選択できる。例えば、各プレイヤは自身の車両、ドライバ、サウンドトラックを選択してもよい（５４）。
【００５５】
上述したように、少なくとも各プレイヤ本人が使用するゲーム機には固有のプレイヤＩＤが関連付けられている。各ゲーム機には、ＭＡＣアドレスのように、プレイヤＩＤに関連付けられた固有のＩＤが割り当てられている。このＩＤ番号は各プレイヤを一意に識別するのに使うことができる。マルチプレイヤゲームが行われる場合、各プレイヤのゲーム機には他のプレイヤ全員のプレイヤＩＤが記憶される。各プレイヤのゲーム機は、レースに参加するプレイヤ全員のプレイヤＩＤを最近の対戦相手として記録する（５８）。
【００５６】
レースにおける全てのパラメータが設定されると、プレイヤはレースを開始できる状態となり（６０）、レースのメインループが実行される（６３）。まず、プレイヤ番号を定義するためのループカウンタが設定される（６４）。上記ループカウンタはまず１に設定され、プレイヤ番号１を特定する。
【００５７】
そして、プレイヤ番号１がリアルプレイヤであるか否か、つまり、プレイヤがリアルタイムでニンテンドーＤＳを操作しているのか否かが判定される（６６）。
【００５８】
上記プレイヤがリアルプレイヤである場合、例えば、そのプレイヤがニンテンドーＤＳに対して行ったコントローラ入力が読み出される（６８）。この時、レースゲームプログラムは、アクセルペダルを踏んだ、もしくは、ハンドル操作を行ったことを示すコントロールキーをプレイヤが押下したか否かを判定する。
【００５９】
読み出されたコントローラ入力に基づいて、プレイヤの向きおよび速度情報が更新される（７０）。さらに、上記速度および向き情報に基づいて、プレイヤの位置が更新される（７２）。
【００６０】
プレイヤの位置が更新されたら、プレイヤ番号がインクリメントされ、上記プレイヤ番号は全プレイヤの人数以上か否かが判定される（８２）。４人のプレイヤがゲームに参加していると仮定する場合、プレイヤ１に対する処理の完了とともに、プレイヤ２の処理が開始される。この時、ルーチンはブロック６６に戻り、プレイヤ２がリアルプレイヤであるか否かが判定される。
【００６１】
シングルプレイヤゲームのケースのようにプレイヤ２がリアルプレイヤでない場合、ルーチンはブロック７４へ進み、プレイヤはコンピュータ生成されたバーチャルのプレイヤであるか、あるいは、ゴーストであるかが判定される。
【００６２】
プレイヤ２がコンピュータ生成のプレイヤで、かつ、ゴーストデータパッケージのプレイヤにも含まれていない場合、レースプログラムを実行中のニンテンドーＤＳは、決定木で取るべき動作が決められてもよいコンピュータ生成の人工知能に基づいて、次の動作を算出する。
【００６３】
コンピュータ生成によって次の動作が算出されたら、次の所望の動作に基づいてコントローラデータが生成され（７８）、コンピュータ生成されたプレイヤの向きおよび速度は、生成されたコントローラ入力に基づいて更新される（７０）。その後、コンピュータ生成のプレイヤの位置は、上記速度および向き情報に基づいて更新される（７２）。そして、ルーチンはブロック８２に進む。ブロック８２にて、プレイヤカウンタが再びインクリメントされ、上記プレイヤ番号は全プレイヤの人数以上か否かが判定される。
【００６４】
ブロック７４にてプレイヤがゴーストデータパッケージに含まれると判定された場合、ニンテンドーＤＳは選択されたゴーストデータパッケージにアクセスし、レースの特定の時間ｔ（０）〜ｔ（ｎ）におけるプレイヤの位置、向き、および状態を取得する（８０）。
【００６５】
ブロック６６〜８２で規定されたループの処理は、プレイヤ全員に対する処理が完了するまで続けられる。
【００６６】
ブロック８２にてプレイヤ全員の処理が完了したと判定されたら、図３Ａの下および図３Ｂの上に示される「Ａ」を経由して、図３Ｂのブロック８４に進む。
【００６７】
このように、リアルプレイヤの場合はプレイヤが行ったコントローラ入力、コンピュータ生成のプレイヤの場合はバーチャルのコントローラ動作、ゴーストデータよるプレイヤの場合はゴーストデータに記憶されている位置、向き、および状態に基づいて、レースに参加するプレイヤがリアルプレイヤであっても、コンピュータ生成のバーチャルプレイヤであっても、あるいはゴーストデータが生成したゴーストプレイヤであっても、ゲームプログラムは上記世界における各プレイヤの向き、速度、および位置を更新する。
【００６８】
次に、図３Ｂに示されるルーチン部分は、各プレイヤの衝突を判定するために繰り返し実行される。したがって、時間（ｔ）における３次元空間内での各プレイヤの位置および向きが判定されたら、ゲームプログラムは各プレイヤの状態を確認し、プレイヤが上記世界で衝突オブジェクトと衝突したかどうかを判定する。
【００６９】
図３Ｂに示すように、衝突処理はプレイヤ番号１から開始される（８４）。まず、プレイヤ番号１がゴーストであるか否かが判定される（８６）。
【００７０】
プレイヤがゴーストである場合、衝突の検出は行われない。この場合、ルーチンはブロック８８に進む。ブロック８８にて、プレイヤ番号カウンタがインクリメントされ、上記プレイヤ番号は全プレイヤの人数以上か否かが判定される。上記プレイヤ番号が全プレイヤの人数以上ではないと判定された場合、ルーチンはブロック８６に戻り、次のプレイヤがゴーストであるか否かが判定される。
【００７１】
一方、ブロック８６にてプレイヤ１がゴーストではなく、リアルプレイヤもしくはコンピュータ生成のプレイヤであると判定された場合、衝突が検出されたか否かが判定される（１００）。本実施形態においては、プレイヤの位置データに外接するバウンディングボックスを使った従来の方法で衝突の検出が行われる。ある時点にプレイヤの車両位置が他のオブジェクトと交差したかどうかが判定される。
【００７２】
衝突が検出されなかった場合、ルーチンはブロック１１０に進み、ゴーストデータが記憶される。ここでは、例えばプレイヤ番号から特定されるプレイヤの、時間（ｔ）における車両位置（ｘ，ｙ，ｚ）、向き、車両の状態などのデータが記録される。このような記録はｔ（０）〜ｔ（ｎ）のフレームタイム毎に行われる。
【００７３】
ブロック１００にて衝突が検出され、それがゴースト車両とである場合（１０２）、本実施形態においてその衝突は衝突として定義されない。この場合、処理はブロック１１０に進み、位置および向きデータが上述のように記録される。このように、リアルプレイヤあるいはコンピュータ生成のプレイヤがゴーストデータによる車両と衝突した場合、衝突効果は算出されない。例えば、このようなゴースト車両は画面上では完全に重なって見えるかもしれないが、衝突はシミュレートされない。つまりこの場合、ゴースト車両とはリアルに接触していないため、衝突はなかったものとして上記位置が記録される。
【００７４】
一方、衝突はしたが、ゴースト車両とでない場合、プレイヤは有効な衝突オブジェクトと衝突したことになる（１０４）。そしてルーチンでは、衝突がプレイヤの向きおよび速度ベクトルに与えた物理的影響が算出される。このように、ゴースト車両ではなく、他の車両もしくは石や壁など上記世界に存在する物体に衝突した場合、車両の重量、衝突したオブジェクトの重量、衝突したオブジェクトの動きベクトル（例えば、他の車両あるいは移動中の他のオブジェクトと衝突した場合）、衝突したオブジェクトの材質（ゴム対セメントなど材質の弾力性）などの情報を使って、物理エンジンは衝突がプレイヤの向きおよび速度に与えた物理的影響を算出する。
【００７５】
そして、プログラムは車両の３次元モデルを更新し、車両の衝突を描写する（１０６）。例えば、衝突した箇所がへこんだように上記３次元モデルが変更されてもよい。しかし、上記３次元モデルを変更せずに、３次元モデルにマッピングされたテクスチャを変更することによっても車両の衝突が描写できる。このように、衝突後更新される車両のボディを表す３次元モデルにおいては、シミュレートされた衝突のダメージとして、くぼみの描写／テクスチャの変更が行われていてもよい。
【００７６】
そして、車両の状態が更新される（１０８）。この状態データは、「完全な状態」、「ダメージ有り」、「パフォーマンスが低下」、「パフォーマンスが著しく低下」など、あらゆる時点における車両の状態を示していてもよい。
【００７７】
その後、時間ｔにおけるプレイヤの車両の位置、向き、および状態がゴーストデータとして記録される（１１０）。この時、上述した衝突による物理的影響が考慮されるため、ゴーストデータとして記録されるのは衝突後に変更された位置、向き、および車両の状態である。このような変更データは、図３Ａの処理で述べたように、次の時間に実行される処理でのプレイヤの位置および向きに影響を与える。
【００７８】
図３Ｂの処理は各レース車両に対して繰り返し実行される。このように、プレイヤがゴーストでない場合、プレイヤのｘ、ｙ位置、向き、および状態は、時間ｔにおけるゴーストデータとして記録される。
【００７９】
ブロック８８の判定の結果、各プレイヤに対する衝突処理が全て完了したら、ユーザが操作するコンピュータ装置の表示画面上の三次元世界に、全プレイヤ、背景、およびオブジェクトが描画される（９０）。全てのオブジェクトおよび車両は、現在のカメラ角度から見える状態で、上記３次元世界に描画される。このように、カメラの視野から見えるポリゴン全てが画面上に表示される。
【００８０】
ブロック９０にてゲームプレイの背景およびオブジェクトが画面に描画される際、その描画の質は使用するコンピュータ装置によって異なる。例えばニンテンドーＤＳであれば、リアルタイム描画が行われ、オブジェクトの複雑性は相対的に低い（例えば、１オブジェクトにつき１００〜５００個のポリゴンを使用）。
【００８１】
さらなる実施形態によれば、図４のフローチャートを参照して後述するように、ブロック９６でゴーストデータあるいは他のパフォーマンスデータがサーバにアップロードされた後、サーバは改良された描画を実行する。更新後のゴーストデータあるいは他のパフォーマンスデータを受信すると、上述のように、サーバはこれらのデータを様々なゴースト／パフォーマンスデータパッケージにおいて使用してもよい。
【００８２】
しかしながら、このようなパフォーマンスデータはムービーファイルもしくはＡＶＩファイルに描画されてもよい。改良された描画を行うサーバは、時間ｔ（０）〜ｔ（ｎ）間に受信したゴースト／パフォーマンスデータによって、このような背景およびオブジェクトデータを３次元世界にＤＳと同じ方法で描画する。しかし、描画される背景やオブジェクトの複雑性はＤＳのように相対的に低いものではなく、複雑性の極めて高いものが使用される。例えば、車両は数百個のポリゴンで描画されたゴーカートではなく、何千ものポリゴンで非常に複雑に描画されたフェラーリであってもよい。ＤＳでの描画はリアルタイムで実行されるため、ゲームの続行を妨げずにオブジェクトの描画を完了せねばならず、描画処理にあまり長い時間をかけられない。
【００８３】
所望されれば、リアルタイム描画による制約をサーバ側で解消することで、高度な複雑性を描画処理に導入してもよい。このようなより複雑性の高い描画は視聴用にＤＳにダウンロードされてもよい。あるいは、ダウンロードしたファイルは、要望に応じてプレイヤのパーソナルコンピュータあるいは他のコンピュータ装置に転送されてもよい。
【００８４】
サーバで描画が実行されると、ニンテンドーＤＳでダウンロードできるタイプのムービーファイルに描画を収集してもよい。サーバによるデータの描画法は、かなり柔軟であってもよい。例えば、サーバはレースの一位通過者をカメラが背後に映すプレイヤとして選択し、そのプレイヤから見える３次元ゲーム世界を描画してもよい。あるいは、凄まじい激突などゲーム一番の見どころである接触を強調表示したり、あるいは猛烈に位置変更する車両を追跡したりと、レースの進行に伴ってカメラ角度を変更することもできる。ナレーションをムービーファイルのサウンドトラックに追加することもできる。ナレーションは、描画したムービーの再生を鑑賞中に人が発した言葉を録音した音声であってもよい。
【００８５】
上述の実施形態によれば、得点・結果サーバデータベース２２はムービーファイルに対するポインタ（例えば、ゴーストデータムービー保管ポインタ１〜ゴーストデータムービー保管ポインタＮ）を含んでいてもよい。本実施形態によれば、ゴーストデータ記憶装置２４にはＡＶＩファイルやＭＰＥＧファイルなどのゴーストムービー情報を格納するための保管場所が確保されている。これにより、数多くの異なるゴーストデータやプレイヤパフォーマンスデータ全てをより複雑性の高い描画で取り込むことができる。こういったゴーストデータムービーファイルを格納するためのゴーストデータ保管データベースが別に設けられてもよい。あるいは、ゴーストデータムービーファイルはゴーストデータ記憶装置２４の一部に格納されてもよい。
【００８６】
さらに、効果音およびサウンドトラックが音声システムに描画され、レース中のＢＧＭとしてユーザが選択した音声を出力するのに必要な波形を生成する（９２）。さらに、検出された衝突を表す効果音も生成される。
【００８７】
そして、ブロック９４にてレースが終了したか否かの判定が行われる。これは、例えば、レースに参加した全ての車両がラップ数で決められた回数ゴールしたかどうかを検出することにより判定されてもよい（９４）。
【００８８】
レースが終了していない場合は、ルーチンはメインループに進み（９８）、図３Ａに示されるブロック６３に戻って、次の時間ｔにおける処理が開始される。一方、レースが終了している場合は、ゴーストデータがアップロードされてもよい（９６）。
【００８９】
図４はゴーストデータのアップロード時に実行される操作シーケンスの一例を示すフローチャートである。実施形態においてゴーストデータがアップロードされたかどうかは、特定のプレイヤがゴーストデータのアップロードを選択したかどうかで判定される。自身のパフォーマンスが更新に値するかどうか判断する基準は、各プレイヤによって異なっていてもよい。
【００９０】
ゴーストデータを更新するには（１２０）、例えばプレイヤのニンテンドーＤＳをインターネットに接続せねばならない（１２２）。ブロック１２４に示されるように、プレイヤのコンピュータ装置２、４、６、または８は認証サーバ１６に機能的に接続され、固有のプレイヤＩＤおよびパスワードなどの認証証明情報を認証サーバ１６に送信する。
【００９１】
認証サーバ１６は、この認証証明情報のためにユーザデータベース１８をチェックして、この情報を分析する。情報が有効であれば、認証サーバ１６はトークンをゲーム機に返す（１２６）。トークンは固有のデータ列であり、簡易に認証が行えるようにゲーム機はトークンを他のサーバへ送ることができる。トークンを受け取った他のサーバは、ユーザが認証済みであることを示すデジタル署名分析により、トークンが有効であることを確認できる。
【００９２】
プレイヤのゲーム機２、４、６、または８は、受け取ったトークンを得点・結果サーバ２０に送信する。得点・結果サーバ２０は、トークンが有効であるかを検証する。有効であれば、得点・結果サーバ２０は、ゲーム機のサーバへのアクセスを許可する（１２８）。
【００９３】
本実施形態において、処理はブロック１３０に進み、プレイヤのゲーム機はアップロードするためにあらゆるゴーストデータを収集する。このようなゴーストデータは、例えば、ゲームで使用されたマップ番号、ゲームでプレイヤが使用した車両およびドライバ、プレイヤのスクリーンネーム、ゲームの条件（天候など）、レースの開始日時、ゲームでホストを務めたプレイヤのプレイヤＩＤ（マルチプレイヤゲームの場合。シングルプレイヤゲームの場合はプレイヤ本人のプレイヤＩＤ）、ホストプレイヤＩＤなどゲームに参加した他のプレイヤのプレイヤＩＤ（マルチプレイヤゲームの場合）、プレイヤの最終得点（得点はレース終了までにかかった時間、レース中に披露された「トリック」などで評価されるレースパフォーマンスの評価のいずれであっても、その両方であってもよい）が含まれていてもよい。
【００９４】
ゴーストデータが収集されたら、プレイヤのゲーム機は収集したデータを得点・結果サーバにアップロードする（１３２）。得点・結果サーバ１６はこの条件付きデータを得点・結果データベース２２に、パフォーマンスデータそれ自体（位置／向き／状態データ）をゴーストデータ記憶装置２４にそれぞれ格納し、このゴーストデータに対するポインタ（ＧｈｏｓｔＤａｔａＩＤ）を条件付きデータと共に得点・結果データベース２２に格納する。
【００９５】
得点・結果サーバ２０において、新たな情報が得点・結果データベース２２に記録される。本実施形態においては、ゴーストデータに追加された全ての得点・結果データが得点・結果データベース２２に格納され、全ての位置、向き、および状態情報がゴースト保管データベース２４に格納される。得点・結果サーバ２０は、追加されたゴーストデータに対応するゴーストの位置、向き、および状況データに関連するポインタを作成する。これにより、ゴーストデータをダウンロードしたいプレイヤは、得点・結果サーバ２０およびそれに付随するデータベースにアクセスしてゴーストデータを検索できることになる。
【００９６】
図２に戻り、ブロック３０に示されるように、ユーザはゲームをするか、ゴーストデータをダウンロードするかのいずれかを選択する。ゴーストデータのダウンロードが選択された場合、ゴーストデータのダウンロード処理が開始される（３２）。
【００９７】
図５Ａおよび図５Ｂは、ゴーストデータのダウンロード処理中に実行される操作シーケンスの一例を示すフローチャートである。ゴーストデータのダウンロード処理においては、プレイヤはまずインターネットに接続し（１５２）、認証サーバ１６と認証証明情報を交換する（１５４）。ブロック１５４に示されるように、プレイヤのコンピュータ装置２、４、６、または８は認証サーバ１６に機能的に接続され、固有のプレイヤＩＤおよびパスワードなどの認証証明情報を認証サーバ１６に送信する。
【００９８】
認証サーバ１６は、この認証証明情報のためにユーザデータベース１８をチェックして、この情報を分析する。情報が有効であれば、認証サーバ１６は、トークンをゲーム機に返す（１５６）。上述したように、トークンは固有のデータ列であり、簡易に認証が行えるようにゲーム機はトークンを他のサーバへ送ることができる。トークンを受け取った他のサーバは、ユーザが認証済みであることを示すデジタル署名分析により、トークンが有効であることを確認できる。
【００９９】
プレイヤのゲーム装置２、４、６、または８は、使用認証のために、受け取ったトークンをバディサーバ１２に送る（１５８）。これにより、プレイヤは、過去に保存された自身のバディのパフォーマンスであるゴースト情報をシステム上で検索し、そのバディと対戦することができる。
【０１００】
次に、プレイヤは過去に保存されたバディのプレイヤＩＤを要求する。これまでのゲームで、プレイヤは１人以上のバディのプレイヤＩＤをすでに入力済みであり、現時点でこれらのバディプレイヤＩＤはバディサーバ１２にアップロードされ、バディデータベース１４においてそれらがプレイヤ自身のＩＤと関連付けられている（１６０）。
【０１０１】
その後、プレイヤのゲーム機２、４、６、および８は、まず得点・結果サーバ２０に認証トークンを送信してサーバの利用許可を求め、プレイヤ／コンピュータ装置がサーバにおけるサービスを利用できるかどうかの認証が行われる（１６２）。トークンが有効であれば、得点・結果サーバ２０は、ゲーム機２、４、６、および８がサーバにアクセスする許可を与える。
【０１０２】
そして、数々のオプションがユーザに提示される。オプションの中にはマップなど（例えば、ダウンロードされたゴーストデータロジックで使用のレースコース、様々な条件、他のデータフィルタ）の選択から、ゴーストデータをダウンロードするプレイヤにとって最も相応しい対戦相手となるゴーストデータパッケージ群の選択まで、様々なものが含まれる。このように、ユーザは、１）熱帯パラダイスコース、２）３ラップ走行のコース、３）理想の天候条件、の３つのデータフィルタを選んでもよい（１６４）。
【０１０３】
そして、さらなるメニューがユーザに提示され、これにより、ユーザはありとあらゆる様々なゴーストデータパッケージ群の中からデータパッケージを選択できる（１６６）。ゴーストデータパッケージとは、複数もしくは個人のゴーストデータパフォーマンスが組み合わさって構成されたものである。このようなゴーストデータパッケージには、例えば、以下のようなものが含まれてもよい。
【０１０４】
得点がトップ５に入るプレイヤ５人。得点・結果サーバ２０は、ブロック１６４で選択されたコース／マップおよび他のフィルタにおいて出された得点がトップ５に入るプレイヤ５人のゴーストデータを含むゴーストデータパッケージを生成する。
【０１０５】
得点がトップ５に入るバディ５人。得点・結果サーバ２０は、ブロック１６４で選択されたコース／マップおよび他のフィルタにおける、プレイヤのバディ全員のゴーストデータを確認し、確認した全てのゴーストデータからトップ５のパフォーマンスを含むゴーストデータパッケージを返信する。
【０１０６】
得点がプレイヤ本人のものに近いバディ５人。得点・結果サーバ２０は、ブロック１６４にて選択されたコース／マップおよび他のフィルタにおける、プレイヤのバディ全員のゴーストデータを確認し、プレイヤ自身のゴーストデータと確認したデータを比較する。サーバ２０は、対戦相手としてプレイヤ自身のゴーストデータに最も相応しいバディのパフォーマンスを含むゴーストデータパッケージを返信する（例えば、ゴーストデータをダウンロードするプレイヤ本人と同じくらい運転が下手なバディが集められてもよい）。
【０１０７】
他ユーザによる評価がトップ５に入るパフォーマンス。本実施形態においては、プレイヤはゴーストデータパフォーマンスについてフィードバックを行い、そのフィードバックデータはゴーストデータとともに記憶される（例えば１００点満点での評価。評価点は回答の平均値）。得点・結果サーバ２０は、ブロック１６４で選択されたコース／マップおよび他のフィルタにおける、全てのゴーストデータのプレイヤによるフィードバックを確認し、他のプレイヤによる評価がトップ５に入るパフォーマンスを含むゴーストデータパッケージを返信する。
【０１０８】
チーム／グループレース。得点・結果サーバ２０は、同じユーザのホストで同じレースに参加したプレイヤ各々のゴーストデータ結果（このデータは個人別のゴーストデータに格納されている）を組み合わせてゴーストデータパッケージを作成する。本実施形態において、返信されるゴーストデータパッケージでは、様々なグループがメニュー形式でユーザに提示される。この時、サーバは個人別のゴーストデータにアクセスし、ホストプレイヤＩＤ、レース日およびレース時刻が同じゴーストデータをユーザに提示する。
【０１０９】
トップ５に入る最近の対戦相手のベストパフォーマンス。得点・結果サーバ２０は、１６４で選択されたコース／マップおよび他のフィルタにおいて、プレイヤが最近対戦したプレイヤ全員のゴーストデータを確認し（対戦した各プレイヤのプレイヤＩＤはゲームプログラムによって記憶され、クエリーの一部として得点・結果サーバ２０に渡される）、確認した全てのゴーストデータからトップ５のパフォーマンスを含むゴーストデータパッケージを返信する。これにより、プレイヤはリアルに対戦する可能性のある相手とのレースに備えることができる。
【０１１０】
対戦相手としてプレイヤのゴーストデータに最も相応しいゴーストデータ５つ（バディのものに限らない）。得点・結果サーバ２０は、そのコース／マップで出されたプレイヤ本人のゴーストデータに対戦相手として最も相応しいゴーストデータ５つを探し出し、対戦相手として最も相応しいパフォーマンス５つを含むゴーストデータパッケージを返信する。
【０１１１】
プレイヤがパッケージを選択したら、選択されたパッケージに基づいて、得点・結果サーバ２０に送られるクエリーが構築される。選択されたパッケージが「チーム／グループレース」でなければ、クエリーは得点・結果サーバ２０に送られ、サーバ２０が１個のゴーストデータパッケージを返信すると、ゲームプログラムはそこに格納されているデータをダウンロードする。このパッケージは、シングルプレイヤプレイモードのレースでプレイヤが好みの項目を選択する際に再生することができる。一方、選択されたパッケージが「チーム／グループレース」の場合は、数個のパッケージが返信されることもあるため、クエリーの数種類のパッケージがプレイヤに提示されることとなる。プレイヤは所望のパッケージを選択し、選択したパッケージを取得する要求を得点・結果サーバ２０に送信すると、サーバ２０はプレイヤのゲーム機にパッケージをダウンロードする。
【０１１２】
図５Ａに戻り、ブロック１６８にて上記選択がバディを含むか否かが判定される。バディが含まれる場合、ニンテンドーＤＳはバディ全員のプレイヤＩＤを含むクエリーを構築する（１６９）。本実施形態によれば、ゲーム機（例えば、ニンテンドーＤＳ）はプレイヤのバディを特定するようサーバ２０に通知する。
【０１１３】
そして、ルーチンは図５Ｂのブロック１８４（結合子Ｃで示される）に進み、クエリーが得点・結果サーバ２０に送信される。クエリーでは、検索基準に合うプレイヤ各々のゴーストデータ結果が組み合わさって各データパッケージが構成されるゴーストデータパッケージが要求され、この場合、バディ全員のプレイヤＩＤが検索の対象となる。次に得点・結果サーバ２０は付随のデータベースを検索して検索要求に合うデータを探し出し、個人別のゴーストデータパフォーマンスの中から検索基準に合うゴーストデータを組み合わせ、１つにまとめて送信する。そしてこのようなゴーストデータパッケージは、得点・結果サーバ２０から、例えばニンテンドーＤＳに内蔵されるメモリにダウンロードされる（１８６）。ルーチンは図２に示されるメインメニューに戻る（１８８）。
【０１１４】
一方、ブロック１６８にて、上記選択がバディを含まないと判定された場合、ルーチンは図５Ｂのブロック１７０（結合子Ｂで示される）に進み、ユーザが最近対戦した相手のゴーストパッケージを選択したか否かが判定される。
【０１１５】
最近の対戦相手のゴーストパッケージが選択された場合、ゲーム機はユーザが最近対戦したプレイヤ全員のプレイヤＩＤを含むクエリーを構築し（１８２）、構築されたクエリーは得点・結果サーバ２０に送信される。このクエリーでは、上述のような検索基準に合うプレイヤ各々のゴーストデータ結果が組み合わさって各データパッケージが構成されるゴーストデータパッケージが要求される（１８４）。最近の対戦相手が選択された場合、得点・結果サーバ２０に送られるクエリーは、パフォーマンスのトップ５、最近５人の対戦相手、および将来の対戦候補であるプレイヤＩＤを含んでいてもよい。
【０１１６】
ブロック１７０にて最近の競争相手が選択されていない場合、チーム／グループレースに関するゴーストデータパッケージが選択されているか否かが判定される（１７２）。
【０１１７】
チーム／グループレースが選択されていない場合、ＤＳはプレイヤがメニューで選択した項目に基づいて、プレイヤＩＤなどの変数を考慮せずにクエリーを構築し（１９０）、構築されたクエリーは、上述のように、得点・結果サーバ２０に送信される（１８４）。この場合クエリーは、要求を満たすプレイヤＩＤを一切識別せずに、得点がトップ５に入るプレイヤなど、標準的な検索基準に基づいて構築されてもよい。
【０１１８】
ブロック１７２にてチーム／グループレースが選択されたと判断された場合、ブロック１７４に示すように、ゲーム機（例えば、ニンテンドーＤＳ）は得点・結果サーバ２０にクエリーを送信し、同じユーザのホストで同じレースに参加したプレイヤ各々のゴーストデータ結果を組み合わせて各データパッケージが構成されるゴーストデータパッケージの構築を要求する。このようなクエリーによって、得点・結果サーバ２０は複数の結果を抽出することが可能となり、上記複数の結果のリストはサーバ２０から例えばデータ要求元であるニンテンドーＤＳに送信される（１７６）。そして、得点・結果サーバが送信したリストは、ユーザが使用可能なパッケージとして表示される（１７８）。ユーザは上記リストをスクロールし、所望のパッケージを選択する（１８０）。その後システムは、得点・結果サーバ２０から選択されたゴーストデータをデータ要求元のＤＳにダウンロードし（１８６）、メインメニューに戻る（１８８）。
【０１１９】
上述したように、本発明の実施形態では、ゴースト車両および運転ゲームを例に挙げて説明してきたが、ここで説明される方法はあらゆるアクティビティのシミュレーションに適応されてもよい。このようなアクティビティは、シミュレートされる複数ユーザのアクティビティにおいて複数のユーザ／バディのパフォーマンスが記録、保存、および使用されるあらゆるビデオゲームを含むがこれに限定されない。例えば、一緒にゲームするおよび／あるいは対戦する他のプレイヤ／バディ／チーム／グループを選択する方法は、本実施形態ではレースゲームを例に挙げて説明されているが、レースゲーム以外の他のアプリケーションであってもよい。
【０１２０】
さらに、上述の実施形態では、より複雑性の高いオブジェクトおよび背景を使ってムービーファイルの描画を行っているが、これはレースゲーム以外のあらゆるアプリケーションでも可能である。さらに、このムービーファイルについては、複数のゴーストデータパッケージを１つの、例えば、ＡＶＩファイルに描画し、ユーザが選択できるように提示するなど、上述の様々な実施形態を組み合わせて使用されてもよい。
【０１２１】
他に適応されるムービーファイルアプリケーションとしては、ヘイロー２シリーズのあらゆるファーストパーソン・シューティングゲームが挙げられる。ムービーモードにおいて、ユーザは激しいチーム戦がより複雑に描画された記録画像をダウンロードすることができる。この場合、ユーザがゲームの主要観戦スポットを映す備え付けのカメラ角度から観戦できるように、サーバは画像に処理を施してもよい。つまり、カメラは常時プレイヤを追っている必要はない。
【０１２２】
さらに、例えばより複雑に描画された背景およびオブジェクトなど、ダウンロード済みのムービーファイルは、多人数参加型オンラインゲームに適応されてもよい。ムービーモードにおいては、ゲームシーケンスを記録後、サーバで収集して１個のムービーファイルにまとめることにより、ユーザが激しいチーム戦を観戦できるようにしてもよい。同時に何千人ものプレイヤが参加する多人数参加型オンラインゲームでは、ゲームの主要観戦スポットを映す備え付けのカメラ角度からこのような画像が表示されてもよい。つまり、カメラは常時プレイヤを追っている必要はない。
【０１２３】
さらに、本発明における方法は、例えば、シムシティシリーズの都市建設ゲームなど、あらゆるシミュレーションゲームに適応されてもよい。例えば、さらなる一実施形態においては、各プレイヤには都市の異なる区域の建設が割り当てられている。例えば、都市の異なる区域を建設する各ユーザのデータがゴーストデータとして記録されている。ここでは、各プレイヤがダウンロードしてもよいパッケージは、自身とは異なる都市区域の建設を表すパッケージである。つまり、プレイヤは、例えば、ダウンロードしていない都市部分しか建設することができない。例えば、都市は４分割されているものとする。プレイヤが第１象限を建設するとすれば、第２、３、４象限のパッケージをダウンロードすることになる。この例では、ゴーストデータは都市全体の実データとして使用され、都市全体の基礎構造を表す。プレイヤのコンピュータ装置のシミュレーションは都市全体を網羅している。
【０１２４】
上述の実施形態におけるムービーモードの一例によれば、プレイヤは、一都市あるいは複数都市の建設を微速度で描画するサーバが提供する建設シーケンスをダウンロードしてもよい。
【０１２５】
さらに、上述の方法は教育用ゲームに適応されてもよい。例えば、生徒の個人成績が記録されている。このような成績データは、例えば、ゴルフ、ダンス、演技、あるいはその他諸活動の習得に関するデータであってもよい。個人別成績を総合的に再生することによって、どの分野でどの生徒が他の生徒より優れているのか、また劣っているのかを認識できる。このような総合成績は、例えば、異なる表示ウィンドウで表示されてもよいし、もしくは、要望に応じて各生徒のサムネイル画像を使って表示されてもよい。
【０１２６】
さらに、上述の方法は、ドンキーコンガ、ダンスレボリューション、カラオケレボリューションのようなリズム合わせゲームおよび他の関連ゲームなどの音楽ゲームに適応されてもよい。一実施形態によれば、ゴーストデータは異なる演奏者の楽器演奏がミックスされたものであってもよい。各ゴーストは同じかもしくは違う楽器を演奏する。例えば、あるゴーストがドラムを、別のゴーストがピアノを演奏するといったように、演奏は異なる楽器がミックスされていてもよい。ユーザは例えばギターを演奏する。カラオケレボリューションの場合、合成演奏に調和するようにユーザのボーカルがミックスされる。あるいは、プレイヤは同じ楽器を演奏するゴーストより上手く演奏するために、同じ調子をほぼ完璧なタイミング、かつ、ほぼ完璧な音長および強度で奏でてもよい。
【０１２７】
さらに、上述の方法はあらゆるカードゲームに適応されてもよい。例えば、ある実施形態では、ブラックジャックやテキサス・ホールデム・ポーカーのようなジャンルのカードゲームが行われてもよい。上述の実施形態によれば、リアルプレイヤは、ゴーストプレイヤがゲーム中に引いたカードを除くカード一組を使用する。ゴーストデータを組み合わせる際、サーバは共通のカード一組でゲームをしていない複数のプレイヤのゴーストパフォーマンスを基に、ゲームに使用するカード一組（あるいは数組）を構成できるかどうかを判断してもよい。例えば、一組のカードが使用されるゲームにおいて、２つのゴーストデータパフォーマンスそれぞれで、プレイヤがエースを４枚とも引いたことが示されている場合、これら２つのゴーストデータパフォーマンスを１つのパッケージに組み入れることはできない。この場合のゴーストデータは各ゲームでプレイヤが引いたカードとプレイヤがゲームで負けた状態を示している。
【０１２８】
上述の実施形態において、リアルプレイヤが一組のカードを使用する場合、上記プレイヤが使用するカードは、ゴーストプレイヤがゲーム中に引いたカードを全て除いたカードである。例えば、一組のカードが使われており、ブラックジャックのゲーム中、以下のカードがゴースストデータによって引い抜かれていたとする。
【０１２９】
ハート：Ａ、２、６、９、Ｑ；スペード：３、６、８、４、７；クラブ：Ａ、９、Ｊ、７；ダイヤ：６、３、９。この場合、リアルプレイヤが使用するカードの組は以下で構成される。
【０１３０】
ハート：３、４、５、７、８、１０、Ｊ、Ｋ；スペード：Ａ、２、５、７、９、１０、Ｊ、Ｑ、Ｋ；クラブ：２、３、４、５、６、８、１０、Ｑ、Ｋ；ダイヤ：Ａ、２、４、５、７、８、１０、Ｊ、Ｑ、Ｋ。
【０１３１】
実施形態において、リアルプレイヤは上記のカードを除いたカード組の中から任意のカードを引くことになる。一方、ゴーストが引くカードは、ゴーストデータの記録時に引いたものと同じカードである。
【０１３２】
ブラックジャックの場合、ゴーストプレイヤの持ち札とともに、親の持ち札がゴーストデータに記録されていてもよい。これにより、リアルプレイヤは同じ親と対戦することができる。この場合、親のカードも同様にリアルプレイヤのカード組から除外される。
【０１３３】
さらに、上述の方法はあらゆる個人競技スポーツゲーム（オリンピックゲームのシミュレーションゲームなど）に適応されてもよい。ゲームに参加するために、プレイヤは自身のバディグループを登録するか、あるいは、数々の有名なスポーツ選手や著名人と対戦するかを選択してもよい。実施形態においてこのようなゲームでは、あるプレイヤのパフォーマンスは別のプレイヤのパフォーマンスに対して測定され、得点は各プレイヤの期間を通してのパフォーマンスを反映して算出されてもよい。このようなスポーツ競技のシミュレーションでは、通常、選手同士の衝突は含まれない。また、このようなスポーツゲームでは、より複雑に描画されたプレイヤおよび背景が、例えばムービーモードで記録されていてもよい。このようなスポーツゲームは以下を含むが、これらに限定されない。
−  アーチェリー
−  ダーツ
−  ダイビング
−  シンクロナイズドスイミング（各選手のゴーストが同じ振り付けに合わせようとする）
−  水泳（レーンレース）
−  徒競走
−  高飛び
−  棒高飛び
−  走り幅跳び
−  三段跳び
−  砲丸投げ
−  円盤投げ
−  ハンマー投げ
−  槍投げ
−  カヌー
−  自転車競技（プレイヤ同士の衝突が重要視されるため、チームのムービーを再生するにとどまる可能性もある）
−  馬術・障害飛び越え
−  体操
−  ローイング
−  セーリング
−  ターゲット射撃、クレー
−  重量上げ
−  ホームランダービー
−  ダンクシュートコンテスト
−  フリースローコンテスト
【０１３４】
本発明は、現在最も実用的で好ましいと考えられる実施形態に関連して説明されてきたが、本発明が開示された実施形態に限定されるものではないことは言うまでもなく、クレームの精神および範囲内における様々な変形例や同等の構成を包括するものであることを意図している。
【図面の簡単な説明】
【０１３５】
【図１】より改良されたパフォーマンスデータの描画を実行するためのシステムを示すブロック図
【図２】本実施形態においてプレイヤがゲームを始める際に実行される操作シーケンスの概要を示すフローチャート
【図３Ａ】ゴーストデータを記録、保存および再生する処理中に実行される操作シーケンスを示すフローチャート
【図３Ｂ】ゴーストデータを記録、保存および再生する処理中に実行される操作シーケンスを示すフローチャート
【図４】ゴーストデータのアップロード時に実行される操作シーケンスを示すフローチャート
【図５Ａ】ゴーストデータのダウンロード処理中に実行される操作シーケンスを示すフローチャート
【図５Ｂ】ゴーストデータのダウンロード処理中に実行される操作シーケンスを示すフローチャート
【図１】
0005501616.tif 000002
【図２】
0005501616.tif 000003
【図３Ａ】
0005501616.tif 000004
【図３Ｂ】
0005501616.tif 000005
【図４】
0005501616.tif 000006
【図５Ａ】
0005501616.tif 000007
【図５Ｂ】
0005501616.tif 000008