JP2013027731A - パフォーマンスデータを選択および描画する改良された方法および装置 - Google Patents

Abstract

【課題】マルチプレイヤビデオゲームで使用されるパフォーマンスデータを選択して描画する改良された方法および装置を提供する。
【解決手段】レースゲームアプリケーションのシミュレーションにおいて、ユーザには、ダウンロードできる様々な「ゴーストデータ」パッケージのいずれかを選択するオプションが提示される。得点がトップ５に入る、あるいは、ユーザ本人と得点が近いバディ５人、様々なチーム／グループなど、各種ゴーストデータパッケージの中から対戦したいパッケージ１つを選ぶオプションがユーザに提示される。システムの処理能力、ポリゴンの数の制限、画面の解像度などの制約により、シミュレーションゲームでは、当初、描画されるオブジェクトやプレイフィールドの複雑度は相対的に低いものであった。ゴーストデータが収集され、アップロードされた後、サーバによって、このようなオブジェクト／プレイフィールドがより高精細に描画される。
【選択図】図１

Description

本発明は、マルチユーザのパフォーマンスシミュレーターに関し、より特定的には、レースゲームにおける「ゴースト」パフォーマンスデータなど、マルチプレイヤビデオゲームで使用されるパフォーマンスデータを選択して描画する改良された方法および装置に関する。

長年にわたり、レースタイプのビデオゲームが人気を博している。周知のように、このようなビデオゲームにおいては、プレイヤは自身のレースパフォーマンスを表すレースデータを取り込み、取り込んだ「ゴースト」データと後のレースで対戦することができる。

例えば、マリオカート６４では、プレイヤの車両がトラックレースに参戦している間、ゲームプログラムはパフォーマンスにおける各ポイントでの車両位置情報を記録しながらゴーストデータを取り込む。レースが終了したら、プレイヤは再度トラックレースに参戦するか、格納された「ゴーストデータ」を基にプレイヤの過去のパフォーマンスでその位置が表された「ゴースト」車両と対戦するかを選択することができる。

従来のビデオゲームにおいては、あるプレイヤは別のプレイヤにゴーストデータを譲渡することができる。そうすれば、たとえ２人のプレイヤがリアルタイムでレースしていなくても、それら２人のプレイヤはレースを互いに「競い合う」ことができる。例えば、第１のプレイヤはゴーストデータをメモリーカードにコピーし、そのメモリーカードを第２のプレイヤに渡してもよい。上記第２のプレイヤは、このメモリーカードを自身のゲームシステムで使用することにより、第１のプレイヤのゴーストデータといつでも対戦できる。

さらに周知のように、データベースからインターネットを介してゴーストデータをアップロードしたり、ダウンロードしたりできる。このようなゲームの例としては、Ｍｉｃｒｏｓｏｆｔ Ｘ-Ｂｏｘゲームである「Ｐｒｏｊｅｃｔ Ｇｏｔｈａｍ Ｒａｃｉｎｇ
ＩＩ」がある。

本実施形態においては、ユーザ自身が一緒にゲームするおよび／あるいは対戦する相手となるリアルユーザまたはコンピュータ生成のユーザを選ぶための数多くのオプションを生成する、より改良されたマルチプレイヤビデオゲーム用の方法および装置が説明されている。

一実施形態において、複数のドライバによるレースゲームをシミュレートするアプリケーションでは、コンピュータ装置のユーザには、インターネットなどの通信ネットワークを通してダウンードできる様々な「ゴーストデータ」パッケージのいずれかを選択するオプションが提示される。例えば、得点がトップ５に入るバディ５人、ユーザ本人と得点が近いバディ５人、様々なチーム／グループ、トップ５に入る対戦相手のベストパフォーマンス、プレイヤの最高記録であるゴーストデータの対戦相手として最も相応しいゴーストデータのトップ５など、各種ゴーストデータパッケージの中から対戦したいパッケージを１つを選ぶオプションがユーザに提示されてもよい。

本実施形態において、あるプレイヤのゴーストデータをダウンロードしたり、あるいは
、パフォーマンスを基準として複数のプレイヤ各々のパフォーマンスを組み合わせるのではなく、選択可能なチームあるいはグループと対戦するレースが提供される場合、選択されるチームまたはグループのパッケージは、同じゲーム内容を共有する、つまり全く同じ時間に同じレースコースをリアルタイムで競った複数のプレイヤのパフォーマンスから収集された個人別のゴーストデータが組み合わされたものである。同じ時間に同じゲームを競ったユーザメンバーのパッケージを選択することにより、このゲームに関与する格納済みのゴーストデータではゴースト車両同士が接触する（ゴーストデータが同じコースでも異なるレースに基づいて抽出されていれば、ゴースト車両との接触はほとんどない）。このように、ゴーストデータでは実際のリアルレースで起こった衝突が反映されるため、ゴーストデータがその記録後に表示される際には、ゴースト車両同士の衝突が描写されることになる。

本実施形態によれば、ビデオゲームシステムにおいて、ユーザは選択できる複数のゴーストデータパッケージを１データ群あるいは１データ単位でダウンロードすることができる。

少なくとも一実施形態によれば、ユーザは自身のバディとして登録したプレイヤを様々に組み合わせたゴーストパッケージを選択してもよい。バディの登録は、複数のプレイヤが互いのバディを簡単に認証でき、かつ、競争しがいのある種々多様なレースが簡単に選択できるように行われる。

ユーザはレースにおけるカメラ視点を制御しながら、選択したパフォーマンスを自身のコンピュータ／ビデオゲームシステムで見てもよいし、あるいはカメラに自動的にプレイヤの１人を追わせてもよい。あるいは、ユーザは選択したゴーストパッケージから対戦相手を選んで競い合ってもよい。

一緒にゲームする／あるいは対戦する他のプレイヤ／バディ／チーム／グループを選択する方法は、本実施形態ではレースゲームを例として説明されているが、レースゲーム以外の他のアプリケーションであってもよい。本願で説明される方法は、複数ユーザのアクティビティのシミュレーションにおいて複数のユーザ／バディのパフォーマンスが記録、保存、および使用されるあらゆるビデオゲームなど（しかしこれに限定されない）、各種アクティビティのシミュレーションに適応されてもよい。例えば、本願で説明される方法は、これまで複数のプレイヤで争うことも一般的とされるカーレースから、飛行シミュレーション、陸上競技のスポーツ種目、ポーカ、アドベンチャーゲーム、その他のゲーム／教育用ゲームに及ぶアクティビティを競い合う友人／親族／著名人のありとあらゆる組み合わせを選択するのに使用されてもよい。

少なくとも一実施形態によれば、ゲームシステムの処理能力、関連性のある一秒毎に処理されるポリゴン数の制限、画面の解像度などの制約により、ビデオゲームコンソールが基盤のシステムあるいは小型ゲーム機におけるレースのシミュレーションでは、当初、描画されるオブジェクトやプレイフィールドの複雑度は相対的に低いものであった。ゴースト／パフォーマンスデータが収集され、アップロードされた後、例えばより強力なサーバによって、このようなオブジェクト／プレイフィールドはより高精細に描画される。

このような高精細の描画は、例えば、Ａｕｄｉｏ Ｖｉｄｅｏ Ｉｎｔｅｒｌｅａｖｅ（ＡＶＩ）のビデオファイル形式での集約が可能である。ＡＶＩ形式のファイルはＷｅｂ上で見ることもできるし、あるいは、（コンソールにＡＶＩファイルの再生機能があれば）コンソールにダウンロードして見ることもできる。上述の実施形態によれば、非常に多くのポリゴン数のグラフィックモデルを使って描画された車両および背景は、元々記録されたレースのシミュレーションにおける車両や背景の代わりに使用される。

そして、ユーザは非常に高い解像度でゴーストデータパフォーマンスを見てもよい。所望されれば、このような背景および車両は一実施形態において、たとえ（元のゴーストデータに基づいた）プレイヤのパフォーマンスが例えば実質的に同じままであっても、異なる設定場面における異なる背景および車両に完全に代えられてもよい。

例えば、後述のように、ニンテンドーＤＳがレースゲーム用の小型ゲーム機として使用された場合、画像オブジェクトの複雑度は、例えば車１台当たり１００〜５００個のポリゴンが使用される程度でしかない。プレイヤのパフォーマンスデータがインターネットを介してサーバにアップロードされたら、サーバはゴーストデータを処理し、全く異なるオブジェクトを使ってレースを再描画する。上述の実施形態においては、レース用トラック／地形は、ニンテンドーＤＳで使用されたものと実質上同じである。トラックはそっくり元のままであるが、背景の描画ががらりと変わってもよい。例えば、サーバは、元々砂漠であったレースの設定場面を熱帯リゾート地に変更して描画してもよい。上述の実施形態によれば、元々２百個のポリゴンしか使用されていない簡素なゴーカートのモデルは、それとはまるで違うもの、例えば、５千個のポリゴンでシミュレートされたフェラーリに代えられてもよい。

サーバはこのようなデータの描画をリアルタイムで行う必要はない。これにより、超高品質の描画の実現を妨げる制約が１つ解消されることになる。車両の空間での動きは、ゴーストデータの記録元であるレースと同じように維持されなければならない。

サーバは、例えば、レースデータをＭＰＥＧ形式のムービーファイルで描画し、データ要求元であるニンテンドーＤＳに対して描画したムービーファイルをダウンロードしてもよい。あるいは、他の認証ユーザがアクセスできるように、描画をＷｅｂ上に配置することもできる。これにより、例えば、レースチームあるいは友人グループのメンバーが超高品質で描画したレースを見たい場合があってもそれに対応できる。

この実施形態は、上述および本願で説明される様々な実施形態を組み合わせて、複数のゴーストデータパッケージが１つのＡＶＩファイルに描画されるようにしてもよい。同様にこの実施形態もレースアプリケーション以外のあらゆるアプリケーションに適用できる。

本発明のこれらおよび他の特徴、局面、利点は、添付図面と照合して、本発明の以下の詳細な説明により、いっそう明らかとなるであろう。

より改良されたパフォーマンスデータの描画を実行するためのシステムを示すブロック図 本実施形態においてプレイヤがゲームを始める際に実行される操作シーケンスの概要を示すフローチャート ゴーストデータを記録、保存および再生する処理中に実行される操作シーケンスを示すフローチャート ゴーストデータを記録、保存および再生する処理中に実行される操作シーケンスを示すフローチャート ゴーストデータのアップロード時に実行される操作シーケンスを示すフローチャート ゴーストデータのダウンロード処理中に実行される操作シーケンスを示すフローチャート ゴーストデータのダウンロード処理中に実行される操作シーケンスを示すフローチャート

図１は、本発明に係る方法および装置の非限定的な実施形態を実施するシステムの一例を示す図である。図１に示されるように、４台の携帯ゲーム機２、４、６、および８が使用され、インターネット１０に接続されている。

本実施形態において、上記携帯ゲーム機は、相互に無線通信が可能で、かつインターネット１０とも無線接続できるニンテンドーＤＳの携帯機とする。ここで、ニンテンドーＤＳについての詳細は、２００５年４月２２日に出願された米国出願番号Ｎｏ．１１／１１１，９８５に開示されており、この出願は、本明細書中にその開示内容が参照により組み込まれる。

ニンテンドーＤＳ以外のあらゆるコンピュータ装置が使用できることは言うまでもない。例えば、ゲーム装置２、４、６、および８は、様々なビデオゲーム用コンソール、携帯装置、またはパーソナルコンピュータであってもよい。このような装置には、例えば、そ
の内部に組み込まれるイーサネット（登録商標）チップを一意に識別するためのメディアアクセスコントロール（ＭＡＣ）アドレスが個別に付与されていることが好ましいが、必ずしもそうである必要はない。したがって、例えば、ネットワーク接続が可能であるコンピュータ装置ならいかなるものでも、図１に示される１台以上のニンテンドーＤＳのゲーム機２、４、６、および８に加えて、あるいはゲーム機２、４、６、および８の代わりに使用されてもよい。無線通信が可能であるＤＳのような装置は、便利に持ち運べるので、バディ情報をローカルで容易に交換できる点で特に有利である。

ニンテンドーＤＳの各ゲーム機２、４、６、および８は、シングルプレイヤあるいはマルチプレイヤ用のビデオゲームを実行することができる。例えば、ユーザがシングルプレイヤゲームを行っている場合、ニンテンドーＤＳはインターネットに接続されていない。しかし、ニンテンドーＤＳの各ゲーム機２、４、６、および８は、シングルプレイヤレースゲームが行われている間、プレイヤのゴーストデータを記録してもよい。同様にマルチプレイヤゲームにおいても、ゴーストデータが記録されてもよい。

各ユーザのレースが終了したら、プレイヤはインターネット１０を介して、および、本実施形態ではバディサーバ１２、認証サーバ１６、得点・結果サーバ２０を使って、記録したゴーストデータを後述のようにアップロードすることができる。これらのサーバは、例えば、ビデオゲームのハードウェア／ソフトウェアの製造業者によって提供、管理されてもよい。

本実施形態においては、インターネットを介してゴーストデータをアップロードする際、プレイヤはまず認証サーバ１６に接続する。認証サーバ１６はユーザを認証後、バディサーバ１２および得点・結果サーバ２０に対するアクセス許可を上記プレイヤのニンテンドーＤＳに与える。

サーバコンピュータ１２、１６、および２０に必要な処理能力は、アプリケーションの要求によって異なる。例えば、あるアプリケーションでは、認証サーバ１６はパーソナルコンピュータ（ＰＣ）を含むコンピュータのいずれであってもよい。一実施形態では、バディサーバ１２、認証サーバ１６、得点・結果サーバ２０は、８ＧＢのＲＡＭと２００ＧＢのハードディスクとともに、ＡＭＤ社のＯｐｔｅｒｏｎのなどのデュアルコア２ＧＨｚのＣＰＵを含む。これらのサーバでは、例えば、リナックス社のＯＳであるＲｅｄ Ｈａｔ Ｅｎｔｅｒｐｒｉｓｅ Ｌｉｎｕｘ４が使用され、そのデータベースはＳＱＬ社のデータベース管理ソフトウェアであるＯｒａｃｌｅ Ｄａｔａｂａｓｅ １０ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎにより管理されてもよい。

本実施形態においては、各ニンテンドーＤＳには固有の識別子が関連付けられている。例えば、ニンテンドーＤＳの各ゲーム機２、４、６、および８は、本実施形態において、それぞれに内蔵されているイーサネット（登録商標）チップを一意に識別するためのメディアアクセスコントロール（ＭＡＣ）アドレスによって識別されてもよい。ここで使用されるニンテンドーＤＳの識別子は、プレイヤおよびゲーム機自体に関連する識別子を組み合わせたものであってもよい。

本実施形態によれば、ランダムな数字をＭＡＣアドレスに追加することによって、プレイヤＩＤを作成してもよい。これにより、例えば１台のニンテンドーＤＳを使用している家族における異なる子供を特定することができる。

プレイヤが初めて認証サーバ１６に接続した際、プレイヤＩＤを作成するコマンドが認証サーバ１６に送信される。プレイヤＩＤはニンテンドーＤＳで作成され、ニンテンドーＤＳが作成したユーザパスワードとともに認証サーバ１６で分析されてもよい。その後、
例えば、ニンテンドーＤＳ２のユーザがインターネット１０にアクセスした場合、認証サーバ１６はゲーム機２にログオンするように促し、その結果、認証サーバ１６はプレイヤＩＤおよびパスワードを確認する。

認証サーバ１６によってニンテンドーＤＳ２が認証されると、トークンが生成される。本実施形態においては、トークンはニンテンドーＤＳ２と認証サーバ１６間で共有されるキーで暗号化されるビットの列であり、上記トークンは認証サーバ１６によりデジタル署名されている。トークンには有効期限日が関連付けられており、これによってトークンを使用できる期間が定められていてもよい。

例えば、ニンテンドーＤＳ２のユーザが、バディサーバ１２および得点・結果サーバ２０に認証シーケンスの一環としてアクセスしたい場合、ゲーム機２はトークンをこれら他のサーバに渡す。トークンはバディサーバ１２および得点・結果サーバ２０で有効に使われる。これは、トークンを使用することで、バディサーバ１２および得点・結果サーバ２０は、繰り返しユーザデータベース１８にアクセスすることなく、プレイヤの認証を許可できるからである。バディサーバ１２および得点・結果サーバ２０はそれぞれ、関連付けられたデジタル署名を分析することにより、認証サーバ１６がトークンを生成したと判断することができる。

認証サーバ１６にはユーザデータベース１８が付随しており、ユーザデータベース１８には多数のプレイヤＩＤ、パスワード、各プレイヤの認証状態が記憶されている。各プレイヤの認証状態は、例えばプレイヤがシステムへのアクセスを禁止されたことを示す状態情報を記憶するのに使われてもよい。

バディサーバ１２は、あるプレイヤが他のプレイヤを「バディ」として登録することを許可する。この場合、プレイヤはバディサーバ１２を使って、一緒にゲームをする１人以上の友人をオンライン上で探してもよい。例えば、バディサーバ１２を使って、レースで対戦する友人のゴーストデータを探し出してもよい。

ある実施形態においては、ニンテンドーＤＳ２を使用するプレイヤ１とニンテンドーＤＳ４を使用するプレイヤ２とが互いにプレイヤＩＤを交換してもよい。このようなＩＤの交換は、例えばプレイヤが手動で実行する交換処理によって行われてもよい。その後、プレイヤ１はプレイヤ２をバディの１人としてバディサーバ１２に登録してもよい。

これに対して、２人のプレイヤがオフラインで、つまりワイヤレスローカルエリアネットワークモードでゲームを行っている場合、プレイヤＩＤは自動的に交換される。その後、プレイヤ１および２のいずれかがインターネットにアクセスした時に、バディサーバ１２はもう１人のプレイヤのＩＤをバディの１人として登録してもよい。

バディサーバ１２には、バディデータベース１４が付随している。バディデータベース１４は、例えば、そこに格納されているプレイヤＩＤ毎のバディの登録人数を記憶している。バディプレイヤＩＤは、バディプレイヤ０〜ｎとして記憶される。また、様々なバディグループ０〜ｎも記憶されてもよい。あるバディグループは、例えば、プレイヤの友人８人で構成されていてもよい。別のバディグループは親族が集まったチームであってもよいし、さらに別のバディグループはレースチームのメンバーであってもよい。例えば、あるグループでは家族のメンバー、別のグループではレースチームのメンバーといったように、個人が複数のグループに所属していてもよい。

得点・結果サーバ２０には、得点・結果データベース２２およびゴーストデータ記憶データベース２４が付随している。これらのデータベースには、個人の得点と、本実施形態
においてはプレイヤＩＤに関連付けられたゴーストデータとが記憶される。例えば、プレイヤ１のレースパフォーマンスが完了したら、認証サーバ１６に接続され、その後認証サーバ１６が生成したトークンが得点・結果サーバ２０に結合される。

得点・結果サーバ２０はトークンが有効であるかを判断し、有効であれば、プレイヤ１に対して得点・結果データベース２２およびゴーストデータ記憶装置２４へのアクセスを許可する。

プレイヤ１が認証されると、プレイヤ１が操作するニンテンドーＤＳはプレイヤ１のパフォーマンスを表すゴーストデータをサーバ２０に送信する。そして、プレイヤＩＤ、レースでプレイヤが獲得した得点、プレイヤがレースで選択した車両、およびプレイヤが選択したドライバを含む記録が生成される。さらに、例えばドライバの名前を特定するスクリーンネームが記憶されてもよい。

ある実施形態においては、ユーザがレースで選択したマップやコース、およびレース条件も記憶される。このような条件には天候条件や走行ラップ数など様々なレース条件が含まれてもよい。さらに、レースゲームの開始日およびレース開始時刻も記憶される。本実施形態では、プレイヤ１がマルチプレイヤゲームに参加していた場合、得点・結果データベース２０はホストＩＤとレースに参加しているプレイヤ全員（プレイヤ１〜プレイヤｎ）のＩＤとを記憶する。

さらに、ゴーストデータＩＤポインタが記憶される。ゴーストＩＤポインタは、関連するゴーストデータが記憶されているゴーストデータ記憶データベース２４内のロケーションを特定する。詳細は後述するが、さらなる実施形態によれば、ムービーファイル関連データも得点・結果サーバ２０に付随するデータベースに記憶される。

次に、ゴーストデータ記憶装置２４には、ゴーストデータを特定するゴーストデータＩＤが記憶される。記憶されているゴーストデータは、時間ｔ（０）からｔ（ｎ）までのｘ，ｙ，ｚ位置データを含む。空間内におけるｘ，ｙ，ｚ位置は、例えば、レース車両の重心を示していてもよい。上記位置データは、例えば、１／６０秒毎にインクリメントされてもよい。また、時間ｔ（０）からｔ（ｎ）までの向き情報も記憶され、車が向いている方向（例えば、前、後ろ、横など）を示すベクトルの向きを特定する。

さらに、車両状態情報も時間ｔ（０）〜ｔ（ｎ）毎に記憶され、例えば、特定の時刻において、車両は良好な状態にあったのか、破損していたのか、あるいはひどく破損していたのかなどを示す。このようなデータは、レース走行中、度々状態が変わる車両を描写するレンダリングエンジンによって使用されてもよい。インターネット経由で受信する多数のクエリー全てを効率よく対処できるように、得点・結果サーバ２０の処理能力は大きいことが好ましい。

図２は、プレイヤがゲームを始める際に実行される操作シーケンスの概要を示すフローチャートである。まず、メインメニューがユーザに表示される（２６）。本実施形態においては、ニンテンドーＤＳが起動したら、ユーザはゲームをするのか、あるいはゴーストデータをダウンロードするのかを選択する（２８）。

そして、ユーザがゲームをすることを選択したか否かが判定される（３０）。プレイヤがゲームをする選択をしている場合、上記プレイヤのレース終了後、図３Ａおよび図３Ｂを参照して後述するように、ゴーストデータを記録、保存および再生する処理がシステムによって実行される（３４）。

一方、プレイヤがゲームをする選択をしていない場合、図５Ａおよび図５Ｂを参照して後述するように、プレイヤは、実施形態において、ゴーストデータをダウンロードしてもよい（３２）。

図３Ａおよび図３Ｂは、ゴーストデータを記録、保存および再生する処理中に実行される操作シーケンスを示すフローチャートである。ゴーストデータを記録、保存、および再生する処理を開始する際（５０）、ユーザは、シングルプレイヤゲーム、あるいは、マルチプレイヤゲームのいずれかを選択せねばならない（５２）。

シングルプレイヤゲームとは、あるプレイヤが、プログラムロジックによって生成され、かつ、人工知能または決定マトリクスによって制御される他のプレイヤと対戦するゲームである（ただし、リアルタイムでゲーム機を操作している他のプレイヤとの対戦はできない）。また、シングルプレイヤゲームにおいて他のプレイヤは、過去に生成された「ゴーストデータ」で表わされている場合もある。上述したように、ゴーストデータはリアルプレイヤのパフォーマンスが記録されたものであり、後に別プレイヤの世界で再生される。通常、プレイヤはゴーストデータを用いて上記世界に描画されたキャラクタと接触したり、衝突したりしない。プレイヤは、上記世界の状態を手動で全て選択するか、あるいは、プレイヤが事前にゴーストデータパッケージを選択している場合は、ゴーストデータが記録された時の状態（例えば、マップ／コース、条件等）がプレイヤ自身のレースのパラメータとなる。しかし、ゴーストデータによる上記世界のパラメータに制限されてはいるものの、プレイヤは自身のキャラクタを選ぶことができる。

シングルプレイヤゲームが選択された場合、一連のメニューがプレイヤに提示され、レースマップやコース、車両、ドライバ、サウンドトラック、天候、ゴーストデータパッケージを選択することができる（６２）。ここで詳細は後述するが、ゴーストデータパッケージとは、例えば、得点がトップ５に入るバディ５人や、得点がプレイヤ本人のものと近いバディ５人など、プレイヤが対戦相手として選択しそうなゴーストデータ群が定義されたものである。

プレイヤが全てのレース条件を選択したら（６２）、レースで対戦するゴーストプレイヤなどのレースパラメータが定義される。本実施形態によれば、プレイヤは、レース中のＢＧＭとして機能するラジオ局やサウンドトラックなど、レースに関するあらゆる条件を選んでもよい。プレイヤはレースのラップ数も同様に選んでもよい。

ここで、ゴーストデータパッケージはユーザが選択できるようにメニュー形式で提示されるが、ゴーストデータパッケージはユーザが選択した条件に対応する機能として生成されてもよい。例えば、天候条件が大雨と定義された場合には、特定のゴーストデータ群が選択されてもよい。

マルチプレイヤゲームが選択されたか否かを判定するブロック５２に戻り、マルチプレイヤゲームが選択された場合、ルーチンは５４のマルチプレイヤ処理に進む。マルチプレイヤゲームのタイプには数種類ある。まず、数人のプレイヤが一台のゲーム機でマルチプレイヤゲームを行う場合がある。例えば、ニンテンドー・ゲームキューブのプラットフォームでは、一台のゲームキューブに接続された４つのコントローラを４人のプレイヤが同時に操作することができる。これに対して、本実施形態の図１に示されるように、４人の友人がニンテンドーＤＳゲーム機２、４、６、および８をそれぞれ一台ずつ持って、同時にゲームを行うこともできる。このようなゲームはワイヤレスローカルエリアネットワーク上で行われてもよいし、あるいは、ニンテンドーＤＳのようなゲーム機を使ってインターネットを介して行われてもよい。本実施形態ではマルチプレイヤゲームはいずれのタイプであってもよく、これは当業者であれば理解できるであろう。各ニンテンドーＤＳを用
いて、例えば、各プレイヤはマルチプレイヤゲームに参加している他のプレイヤのプレイヤＩＤを記録する。さらに、好ましくは、各プレイヤはゲームホストのプレイヤＩＤを記録する。この場合、他のプレイヤが所属するチームがすぐに認識されてもよい。全ての適切なマルチプレイヤデータがそれぞれのＤＳゲーム機に記録された後、ゲームが開始されてもよい。

マルチプレイヤゲームが行われる場合（ここでマルチプレイヤゲームとは、リアルタイムで他のリアルプレイヤと対戦するゲームであり、各プレイヤは別々のコントローラを使って同じゲーム機でゲームを行うか、あるいは、各プレイヤがネットワークにつながったゲーム機をそれぞれ使用してゲームを行うものとする）、参加プレイヤのうちの１人がゲームの「ホスト」となる。通常、ホストは参加プレイヤ全員が共有するマップやコース、および、レースでのラップ数、天候条件、照明条件など、レースゲームにおける他の条件を決定する。ホストが選択したパラメータによって制限されてはいるものの、各プレイヤはホストが選択した世界で自身のキャラクタを選択できる。例えば、各プレイヤは自身の車両、ドライバ、サウンドトラックを選択してもよい（５４）。

上述したように、少なくとも各プレイヤ本人が使用するゲーム機には固有のプレイヤＩＤが関連付けられている。各ゲーム機には、ＭＡＣアドレスのように、プレイヤＩＤに関連付けられた固有のＩＤが割り当てられている。このＩＤ番号は各プレイヤを一意に識別するのに使うことができる。マルチプレイヤゲームが行われる場合、各プレイヤのゲーム機には他のプレイヤ全員のプレイヤＩＤが記憶される。各プレイヤのゲーム機は、レースに参加するプレイヤ全員のプレイヤＩＤを最近の対戦相手として記録する（５８）。

レースにおける全てのパラメータが設定されると、プレイヤはレースを開始できる状態となり（６０）、レースのメインループが実行される（６３）。まず、プレイヤ番号を定義するためのループカウンタが設定される（６４）。上記ループカウンタはまず１に設定され、プレイヤ番号１を特定する。

そして、プレイヤ番号１がリアルプレイヤであるか否か、つまり、プレイヤがリアルタイムでニンテンドーＤＳを操作しているのか否かが判定される（６６）。

上記プレイヤがリアルプレイヤである場合、例えば、そのプレイヤがニンテンドーＤＳに対して行ったコントローラ入力が読み出される（６８）。この時、レースゲームプログラムは、アクセルペダルを踏んだ、もしくは、ハンドル操作を行ったことを示すコントロールキーをプレイヤが押下したか否かを判定する。

読み出されたコントローラ入力に基づいて、プレイヤの向きおよび速度情報が更新される（７０）。さらに、上記速度および向き情報に基づいて、プレイヤの位置が更新される（７２）。

プレイヤの位置が更新されたら、プレイヤ番号がインクリメントされ、上記プレイヤ番号は全プレイヤの人数以上か否かが判定される（８２）。４人のプレイヤがゲームに参加していると仮定する場合、プレイヤ１に対する処理の完了とともに、プレイヤ２の処理が開始される。この時、ルーチンはブロック６６に戻り、プレイヤ２がリアルプレイヤであるか否かが判定される。

シングルプレイヤゲームのケースのようにプレイヤ２がリアルプレイヤでない場合、ルーチンはブロック７４へ進み、プレイヤはコンピュータ生成されたバーチャルのプレイヤであるか、あるいは、ゴーストであるかが判定される。

プレイヤ２がコンピュータ生成のプレイヤで、かつ、ゴーストデータパッケージのプレイヤにも含まれていない場合、レースプログラムを実行中のニンテンドーＤＳは、決定木で取るべき動作が決められてもよいコンピュータ生成の人工知能に基づいて、次の動作を算出する。

コンピュータ生成によって次の動作が算出されたら、次の所望の動作に基づいてコントローラデータが生成され（７８）、コンピュータ生成されたプレイヤの向きおよび速度は、生成されたコントローラ入力に基づいて更新される（７０）。その後、コンピュータ生成のプレイヤの位置は、上記速度および向き情報に基づいて更新される（７２）。そして、ルーチンはブロック８２に進む。ブロック８２にて、プレイヤカウンタが再びインクリメントされ、上記プレイヤ番号は全プレイヤの人数以上か否かが判定される。

ブロック７４にてプレイヤがゴーストデータパッケージに含まれると判定された場合、ニンテンドーＤＳは選択されたゴーストデータパッケージにアクセスし、レースの特定の時間ｔ（０）〜ｔ（ｎ）におけるプレイヤの位置、向き、および状態を取得する（８０）。

ブロック６６〜８２で規定されたループの処理は、プレイヤ全員に対する処理が完了するまで続けられる。

ブロック８２にてプレイヤ全員の処理が完了したと判定されたら、図３Ａの下および図３Ｂの上に示される「Ａ」を経由して、図３Ｂのブロック８４に進む。

このように、リアルプレイヤの場合はプレイヤが行ったコントローラ入力、コンピュータ生成のプレイヤの場合はバーチャルのコントローラ動作、ゴーストデータよるプレイヤの場合はゴーストデータに記憶されている位置、向き、および状態に基づいて、レースに参加するプレイヤがリアルプレイヤであっても、コンピュータ生成のバーチャルプレイヤであっても、あるいはゴーストデータが生成したゴーストプレイヤであっても、ゲームプログラムは上記世界における各プレイヤの向き、速度、および位置を更新する。

次に、図３Ｂに示されるルーチン部分は、各プレイヤの衝突を判定するために繰り返し実行される。したがって、時間（ｔ）における３次元空間内での各プレイヤの位置および向きが判定されたら、ゲームプログラムは各プレイヤの状態を確認し、プレイヤが上記世界で衝突オブジェクトと衝突したかどうかを判定する。

図３Ｂに示すように、衝突処理はプレイヤ番号１から開始される（８４）。まず、プレイヤ番号１がゴーストであるか否かが判定される（８６）。

プレイヤがゴーストである場合、衝突の検出は行われない。この場合、ルーチンはブロック８８に進む。ブロック８８にて、プレイヤ番号カウンタがインクリメントされ、上記プレイヤ番号は全プレイヤの人数以上か否かが判定される。上記プレイヤ番号が全プレイヤの人数以上ではないと判定された場合、ルーチンはブロック８６に戻り、次のプレイヤがゴーストであるか否かが判定される。

一方、ブロック８６にてプレイヤ１がゴーストではなく、リアルプレイヤもしくはコンピュータ生成のプレイヤであると判定された場合、衝突が検出されたか否かが判定される（１００）。本実施形態においては、プレイヤの位置データに外接するバウンディングボックスを使った従来の方法で衝突の検出が行われる。ある時点にプレイヤの車両位置が他のオブジェクトと交差したかどうかが判定される。

衝突が検出されなかった場合、ルーチンはブロック１１０に進み、ゴーストデータが記憶される。ここでは、例えばプレイヤ番号から特定されるプレイヤの、時間（ｔ）における車両位置（ｘ，ｙ，ｚ）、向き、車両の状態などのデータが記録される。このような記録はｔ（０）〜ｔ（ｎ）のフレームタイム毎に行われる。

ブロック１００にて衝突が検出され、それがゴースト車両とである場合（１０２）、本実施形態においてその衝突は衝突として定義されない。この場合、処理はブロック１１０に進み、位置および向きデータが上述のように記録される。このように、リアルプレイヤあるいはコンピュータ生成のプレイヤがゴーストデータによる車両と衝突した場合、衝突効果は算出されない。例えば、このようなゴースト車両は画面上では完全に重なって見えるかもしれないが、衝突はシミュレートされない。つまりこの場合、ゴースト車両とはリアルに接触していないため、衝突はなかったものとして上記位置が記録される。

一方、衝突はしたが、ゴースト車両とでない場合、プレイヤは有効な衝突オブジェクトと衝突したことになる（１０４）。そしてルーチンでは、衝突がプレイヤの向きおよび速度ベクトルに与えた物理的影響が算出される。このように、ゴースト車両ではなく、他の車両もしくは石や壁など上記世界に存在する物体に衝突した場合、車両の重量、衝突したオブジェクトの重量、衝突したオブジェクトの動きベクトル（例えば、他の車両あるいは移動中の他のオブジェクトと衝突した場合）、衝突したオブジェクトの材質（ゴム対セメントなど材質の弾力性）などの情報を使って、物理エンジンは衝突がプレイヤの向きおよび速度に与えた物理的影響を算出する。

そして、プログラムは車両の３次元モデルを更新し、車両の衝突を描写する（１０６）。例えば、衝突した箇所がへこんだように上記３次元モデルが変更されてもよい。しかし、上記３次元モデルを変更せずに、３次元モデルにマッピングされたテクスチャを変更することによっても車両の衝突が描写できる。このように、衝突後更新される車両のボディを表す３次元モデルにおいては、シミュレートされた衝突のダメージとして、くぼみの描写／テクスチャの変更が行われていてもよい。

そして、車両の状態が更新される（１０８）。この状態データは、「完全な状態」、「ダメージ有り」、「パフォーマンスが低下」、「パフォーマンスが著しく低下」など、あらゆる時点における車両の状態を示していてもよい。

その後、時間ｔにおけるプレイヤの車両の位置、向き、および状態がゴーストデータとして記録される（１１０）。この時、上述した衝突による物理的影響が考慮されるため、ゴーストデータとして記録されるのは衝突後に変更された位置、向き、および車両の状態である。このような変更データは、図３Ａの処理で述べたように、次の時間に実行される処理でのプレイヤの位置および向きに影響を与える。

図３Ｂの処理は各レース車両に対して繰り返し実行される。このように、プレイヤがゴーストでない場合、プレイヤのｘ、ｙ位置、向き、および状態は、時間ｔにおけるゴーストデータとして記録される。

ブロック８８の判定の結果、各プレイヤに対する衝突処理が全て完了したら、ユーザが操作するコンピュータ装置の表示画面上の三次元世界に、全プレイヤ、背景、およびオブジェクトが描画される（９０）。全てのオブジェクトおよび車両は、現在のカメラ角度から見える状態で、上記３次元世界に描画される。このように、カメラの視野から見えるポリゴン全てが画面上に表示される。

ブロック９０にてゲームプレイの背景およびオブジェクトが画面に描画される際、その
描画の質は使用するコンピュータ装置によって異なる。例えばニンテンドーＤＳであれば、リアルタイム描画が行われ、オブジェクトの複雑性は相対的に低い（例えば、１オブジェクトにつき１００〜５００個のポリゴンを使用）。

さらなる実施形態によれば、図４のフローチャートを参照して後述するように、ブロック９６でゴーストデータあるいは他のパフォーマンスデータがサーバにアップロードされた後、サーバは改良された描画を実行する。更新後のゴーストデータあるいは他のパフォーマンスデータを受信すると、上述のように、サーバはこれらのデータを様々なゴースト／パフォーマンスデータパッケージにおいて使用してもよい。

しかしながら、このようなパフォーマンスデータはムービーファイルもしくはＡＶＩファイルに描画されてもよい。改良された描画を行うサーバは、時間ｔ（０）〜ｔ（ｎ）間に受信したゴースト／パフォーマンスデータによって、このような背景およびオブジェクトデータを３次元世界にＤＳと同じ方法で描画する。しかし、描画される背景やオブジェクトの複雑性はＤＳのように相対的に低いものではなく、複雑性の極めて高いものが使用される。例えば、車両は数百個のポリゴンで描画されたゴーカートではなく、何千ものポリゴンで非常に複雑に描画されたフェラーリであってもよい。ＤＳでの描画はリアルタイムで実行されるため、ゲームの続行を妨げずにオブジェクトの描画を完了せねばならず、描画処理にあまり長い時間をかけられない。

所望されれば、リアルタイム描画による制約をサーバ側で解消することで、高度な複雑性を描画処理に導入してもよい。このようなより複雑性の高い描画は視聴用にＤＳにダウンロードされてもよい。あるいは、ダウンロードしたファイルは、要望に応じてプレイヤのパーソナルコンピュータあるいは他のコンピュータ装置に転送されてもよい。

サーバで描画が実行されると、ニンテンドーＤＳでダウンロードできるタイプのムービーファイルに描画を収集してもよい。サーバによるデータの描画法は、かなり柔軟であってもよい。例えば、サーバはレースの一位通過者をカメラが背後に映すプレイヤとして選択し、そのプレイヤから見える３次元ゲーム世界を描画してもよい。あるいは、凄まじい激突などゲーム一番の見どころである接触を強調表示したり、あるいは猛烈に位置変更する車両を追跡したりと、レースの進行に伴ってカメラ角度を変更することもできる。ナレーションをムービーファイルのサウンドトラックに追加することもできる。ナレーションは、描画したムービーの再生を鑑賞中に人が発した言葉を録音した音声であってもよい。

上述の実施形態によれば、得点・結果サーバデータベース２２はムービーファイルに対するポインタ（例えば、ゴーストデータムービー保管ポインタ１〜ゴーストデータムービー保管ポインタＮ）を含んでいてもよい。本実施形態によれば、ゴーストデータ記憶装置２４にはＡＶＩファイルやＭＰＥＧファイルなどのゴーストムービー情報を格納するための保管場所が確保されている。これにより、数多くの異なるゴーストデータやプレイヤパフォーマンスデータ全てをより複雑性の高い描画で取り込むことができる。こういったゴーストデータムービーファイルを格納するためのゴーストデータ保管データベースが別に設けられてもよい。あるいは、ゴーストデータムービーファイルはゴーストデータ記憶装置２４の一部に格納されてもよい。

さらに、効果音およびサウンドトラックが音声システムに描画され、レース中のＢＧＭとしてユーザが選択した音声を出力するのに必要な波形を生成する（９２）。さらに、検出された衝突を表す効果音も生成される。

そして、ブロック９４にてレースが終了したか否かの判定が行われる。これは、例えば、レースに参加した全ての車両がラップ数で決められた回数ゴールしたかどうかを検出す
ることにより判定されてもよい（９４）。

レースが終了していない場合は、ルーチンはメインループに進み（９８）、図３Ａに示されるブロック６３に戻って、次の時間ｔにおける処理が開始される。一方、レースが終了している場合は、ゴーストデータがアップロードされてもよい（９６）。

図４はゴーストデータのアップロード時に実行される操作シーケンスの一例を示すフローチャートである。実施形態においてゴーストデータがアップロードされたかどうかは、特定のプレイヤがゴーストデータのアップロードを選択したかどうかで判定される。自身のパフォーマンスが更新に値するかどうか判断する基準は、各プレイヤによって異なっていてもよい。

ゴーストデータを更新するには（１２０）、例えばプレイヤのニンテンドーＤＳをインターネットに接続せねばならない（１２２）。ブロック１２４に示されるように、プレイヤのコンピュータ装置２、４、６、または８は認証サーバ１６に機能的に接続され、固有のプレイヤＩＤおよびパスワードなどの認証証明情報を認証サーバ１６に送信する。

認証サーバ１６は、この認証証明情報のためにユーザデータベース１８をチェックして、この情報を分析する。情報が有効であれば、認証サーバ１６はトークンをゲーム機に返す（１２６）。トークンは固有のデータ列であり、簡易に認証が行えるようにゲーム機はトークンを他のサーバへ送ることができる。トークンを受け取った他のサーバは、ユーザが認証済みであることを示すデジタル署名分析により、トークンが有効であることを確認できる。

プレイヤのゲーム機２、４、６、または８は、受け取ったトークンを得点・結果サーバ２０に送信する。得点・結果サーバ２０は、トークンが有効であるかを検証する。有効であれば、得点・結果サーバ２０は、ゲーム機のサーバへのアクセスを許可する（１２８）。

本実施形態において、処理はブロック１３０に進み、プレイヤのゲーム機はアップロードするためにあらゆるゴーストデータを収集する。このようなゴーストデータは、例えば、ゲームで使用されたマップ番号、ゲームでプレイヤが使用した車両およびドライバ、プレイヤのスクリーンネーム、ゲームの条件（天候など）、レースの開始日時、ゲームでホストを務めたプレイヤのプレイヤＩＤ（マルチプレイヤゲームの場合。シングルプレイヤゲームの場合はプレイヤ本人のプレイヤＩＤ）、ホストプレイヤＩＤなどゲームに参加した他のプレイヤのプレイヤＩＤ（マルチプレイヤゲームの場合）、プレイヤの最終得点（得点はレース終了までにかかった時間、レース中に披露された「トリック」などで評価されるレースパフォーマンスの評価のいずれであっても、その両方であってもよい）が含まれていてもよい。

ゴーストデータが収集されたら、プレイヤのゲーム機は収集したデータを得点・結果サーバにアップロードする（１３２）。得点・結果サーバ１６はこの条件付きデータを得点・結果データベース２２に、パフォーマンスデータそれ自体（位置／向き／状態データ）をゴーストデータ記憶装置２４にそれぞれ格納し、このゴーストデータに対するポインタ（ＧｈｏｓｔＤａｔａＩＤ）を条件付きデータと共に得点・結果データベース２２に格納する。

得点・結果サーバ２０において、新たな情報が得点・結果データベース２２に記録される。本実施形態においては、ゴーストデータに追加された全ての得点・結果データが得点・結果データベース２２に格納され、全ての位置、向き、および状態情報がゴースト保管
データベース２４に格納される。得点・結果サーバ２０は、追加されたゴーストデータに対応するゴーストの位置、向き、および状況データに関連するポインタを作成する。これにより、ゴーストデータをダウンロードしたいプレイヤは、得点・結果サーバ２０およびそれに付随するデータベースにアクセスしてゴーストデータを検索できることになる。

図２に戻り、ブロック３０に示されるように、ユーザはゲームをするか、ゴーストデータをダウンロードするかのいずれかを選択する。ゴーストデータのダウンロードが選択された場合、ゴーストデータのダウンロード処理が開始される（３２）。

図５Ａおよび図５Ｂは、ゴーストデータのダウンロード処理中に実行される操作シーケンスの一例を示すフローチャートである。ゴーストデータのダウンロード処理においては、プレイヤはまずインターネットに接続し（１５２）、認証サーバ１６と認証証明情報を交換する（１５４）。ブロック１５４に示されるように、プレイヤのコンピュータ装置２、４、６、または８は認証サーバ１６に機能的に接続され、固有のプレイヤＩＤおよびパスワードなどの認証証明情報を認証サーバ１６に送信する。

認証サーバ１６は、この認証証明情報のためにユーザデータベース１８をチェックして、この情報を分析する。情報が有効であれば、認証サーバ１６は、トークンをゲーム機に返す（１５６）。上述したように、トークンは固有のデータ列であり、簡易に認証が行えるようにゲーム機はトークンを他のサーバへ送ることができる。トークンを受け取った他のサーバは、ユーザが認証済みであることを示すデジタル署名分析により、トークンが有効であることを確認できる。

プレイヤのゲーム装置２、４、６、または８は、使用認証のために、受け取ったトークンをバディサーバ１２に送る（１５８）。これにより、プレイヤは、過去に保存された自身のバディのパフォーマンスであるゴースト情報をシステム上で検索し、そのバディと対戦することができる。

次に、プレイヤは過去に保存されたバディのプレイヤＩＤを要求する。これまでのゲームで、プレイヤは１人以上のバディのプレイヤＩＤをすでに入力済みであり、現時点でこれらのバディプレイヤＩＤはバディサーバ１２にアップロードされ、バディデータベース１４においてそれらがプレイヤ自身のＩＤと関連付けられている（１６０）。

その後、プレイヤのゲーム機２、４、６、および８は、まず得点・結果サーバ２０に認証トークンを送信してサーバの利用許可を求め、プレイヤ／コンピュータ装置がサーバにおけるサービスを利用できるかどうかの認証が行われる（１６２）。トークンが有効であれば、得点・結果サーバ２０は、ゲーム機２、４、６、および８がサーバにアクセスする許可を与える。

そして、数々のオプションがユーザに提示される。オプションの中にはマップなど（例えば、ダウンロードされたゴーストデータロジックで使用のレースコース、様々な条件、他のデータフィルタ）の選択から、ゴーストデータをダウンロードするプレイヤにとって最も相応しい対戦相手となるゴーストデータパッケージ群の選択まで、様々なものが含まれる。このように、ユーザは、１）熱帯パラダイスコース、２）３ラップ走行のコース、３）理想の天候条件、の３つのデータフィルタを選んでもよい（１６４）。

そして、さらなるメニューがユーザに提示され、これにより、ユーザはありとあらゆる様々なゴーストデータパッケージ群の中からデータパッケージを選択できる（１６６）。ゴーストデータパッケージとは、複数もしくは個人のゴーストデータパフォーマンスが組み合わさって構成されたものである。このようなゴーストデータパッケージには、例えば
、以下のようなものが含まれてもよい。

得点がトップ５に入るプレイヤ５人。得点・結果サーバ２０は、ブロック１６４で選択されたコース／マップおよび他のフィルタにおいて出された得点がトップ５に入るプレイヤ５人のゴーストデータを含むゴーストデータパッケージを生成する。

得点がトップ５に入るバディ５人。得点・結果サーバ２０は、ブロック１６４で選択されたコース／マップおよび他のフィルタにおける、プレイヤのバディ全員のゴーストデータを確認し、確認した全てのゴーストデータからトップ５のパフォーマンスを含むゴーストデータパッケージを返信する。

得点がプレイヤ本人のものに近いバディ５人。得点・結果サーバ２０は、ブロック１６４にて選択されたコース／マップおよび他のフィルタにおける、プレイヤのバディ全員のゴーストデータを確認し、プレイヤ自身のゴーストデータと確認したデータを比較する。サーバ２０は、対戦相手としてプレイヤ自身のゴーストデータに最も相応しいバディのパフォーマンスを含むゴーストデータパッケージを返信する（例えば、ゴーストデータをダウンロードするプレイヤ本人と同じくらい運転が下手なバディが集められてもよい）。

他ユーザによる評価がトップ５に入るパフォーマンス。本実施形態においては、プレイヤはゴーストデータパフォーマンスについてフィードバックを行い、そのフィードバックデータはゴーストデータとともに記憶される（例えば１００点満点での評価。評価点は回答の平均値）。得点・結果サーバ２０は、ブロック１６４で選択されたコース／マップおよび他のフィルタにおける、全てのゴーストデータのプレイヤによるフィードバックを確認し、他のプレイヤによる評価がトップ５に入るパフォーマンスを含むゴーストデータパッケージを返信する。

チーム／グループレース。得点・結果サーバ２０は、同じユーザのホストで同じレースに参加したプレイヤ各々のゴーストデータ結果（このデータは個人別のゴーストデータに格納されている）を組み合わせてゴーストデータパッケージを作成する。本実施形態において、返信されるゴーストデータパッケージでは、様々なグループがメニュー形式でユーザに提示される。この時、サーバは個人別のゴーストデータにアクセスし、ホストプレイヤＩＤ、レース日およびレース時刻が同じゴーストデータをユーザに提示する。

トップ５に入る最近の対戦相手のベストパフォーマンス。得点・結果サーバ２０は、１６４で選択されたコース／マップおよび他のフィルタにおいて、プレイヤが最近対戦したプレイヤ全員のゴーストデータを確認し（対戦した各プレイヤのプレイヤＩＤはゲームプログラムによって記憶され、クエリーの一部として得点・結果サーバ２０に渡される）、確認した全てのゴーストデータからトップ５のパフォーマンスを含むゴーストデータパッケージを返信する。これにより、プレイヤはリアルに対戦する可能性のある相手とのレースに備えることができる。

対戦相手としてプレイヤのゴーストデータに最も相応しいゴーストデータ５つ（バディのものに限らない）。得点・結果サーバ２０は、そのコース／マップで出されたプレイヤ本人のゴーストデータに対戦相手として最も相応しいゴーストデータ５つを探し出し、対戦相手として最も相応しいパフォーマンス５つを含むゴーストデータパッケージを返信する。

プレイヤがパッケージを選択したら、選択されたパッケージに基づいて、得点・結果サーバ２０に送られるクエリーが構築される。選択されたパッケージが「チーム／グループレース」でなければ、クエリーは得点・結果サーバ２０に送られ、サーバ２０が１個のゴ
ーストデータパッケージを返信すると、ゲームプログラムはそこに格納されているデータをダウンロードする。このパッケージは、シングルプレイヤプレイモードのレースでプレイヤが好みの項目を選択する際に再生することができる。一方、選択されたパッケージが「チーム／グループレース」の場合は、数個のパッケージが返信されることもあるため、クエリーの数種類のパッケージがプレイヤに提示されることとなる。プレイヤは所望のパッケージを選択し、選択したパッケージを取得する要求を得点・結果サーバ２０に送信すると、サーバ２０はプレイヤのゲーム機にパッケージをダウンロードする。

図５Ａに戻り、ブロック１６８にて上記選択がバディを含むか否かが判定される。バディが含まれる場合、ニンテンドーＤＳはバディ全員のプレイヤＩＤを含むクエリーを構築する（１６９）。本実施形態によれば、ゲーム機（例えば、ニンテンドーＤＳ）はプレイヤのバディを特定するようサーバ２０に通知する。

そして、ルーチンは図５Ｂのブロック１８４（結合子Ｃで示される）に進み、クエリーが得点・結果サーバ２０に送信される。クエリーでは、検索基準に合うプレイヤ各々のゴーストデータ結果が組み合わさって各データパッケージが構成されるゴーストデータパッケージが要求され、この場合、バディ全員のプレイヤＩＤが検索の対象となる。次に得点・結果サーバ２０は付随のデータベースを検索して検索要求に合うデータを探し出し、個人別のゴーストデータパフォーマンスの中から検索基準に合うゴーストデータを組み合わせ、１つにまとめて送信する。そしてこのようなゴーストデータパッケージは、得点・結果サーバ２０から、例えばニンテンドーＤＳに内蔵されるメモリにダウンロードされる（１８６）。ルーチンは図２に示されるメインメニューに戻る（１８８）。

一方、ブロック１６８にて、上記選択がバディを含まないと判定された場合、ルーチンは図５Ｂのブロック１７０（結合子Ｂで示される）に進み、ユーザが最近対戦した相手のゴーストパッケージを選択したか否かが判定される。

最近の対戦相手のゴーストパッケージが選択された場合、ゲーム機はユーザが最近対戦したプレイヤ全員のプレイヤＩＤを含むクエリーを構築し（１８２）、構築されたクエリーは得点・結果サーバ２０に送信される。このクエリーでは、上述のような検索基準に合うプレイヤ各々のゴーストデータ結果が組み合わさって各データパッケージが構成されるゴーストデータパッケージが要求される（１８４）。最近の対戦相手が選択された場合、得点・結果サーバ２０に送られるクエリーは、パフォーマンスのトップ５、最近５人の対戦相手、および将来の対戦候補であるプレイヤＩＤを含んでいてもよい。

ブロック１７０にて最近の競争相手が選択されていない場合、チーム／グループレースに関するゴーストデータパッケージが選択されているか否かが判定される（１７２）。

チーム／グループレースが選択されていない場合、ＤＳはプレイヤがメニューで選択した項目に基づいて、プレイヤＩＤなどの変数を考慮せずにクエリーを構築し（１９０）、構築されたクエリーは、上述のように、得点・結果サーバ２０に送信される（１８４）。この場合クエリーは、要求を満たすプレイヤＩＤを一切識別せずに、得点がトップ５に入るプレイヤなど、標準的な検索基準に基づいて構築されてもよい。

ブロック１７２にてチーム／グループレースが選択されたと判断された場合、ブロック１７４に示すように、ゲーム機（例えば、ニンテンドーＤＳ）は得点・結果サーバ２０にクエリーを送信し、同じユーザのホストで同じレースに参加したプレイヤ各々のゴーストデータ結果を組み合わせて各データパッケージが構成されるゴーストデータパッケージの構築を要求する。このようなクエリーによって、得点・結果サーバ２０は複数の結果を抽出することが可能となり、上記複数の結果のリストはサーバ２０から例えばデータ要求元
であるニンテンドーＤＳに送信される（１７６）。そして、得点・結果サーバが送信したリストは、ユーザが使用可能なパッケージとして表示される（１７８）。ユーザは上記リストをスクロールし、所望のパッケージを選択する（１８０）。その後システムは、得点・結果サーバ２０から選択されたゴーストデータをデータ要求元のＤＳにダウンロードし（１８６）、メインメニューに戻る（１８８）。

上述したように、本発明の実施形態では、ゴースト車両および運転ゲームを例に挙げて説明してきたが、ここで説明される方法はあらゆるアクティビティのシミュレーションに適応されてもよい。このようなアクティビティは、シミュレートされる複数ユーザのアクティビティにおいて複数のユーザ／バディのパフォーマンスが記録、保存、および使用されるあらゆるビデオゲームを含むがこれに限定されない。例えば、一緒にゲームするおよび／あるいは対戦する他のプレイヤ／バディ／チーム／グループを選択する方法は、本実施形態ではレースゲームを例に挙げて説明されているが、レースゲーム以外の他のアプリケーションであってもよい。

さらに、上述の実施形態では、より複雑性の高いオブジェクトおよび背景を使ってムービーファイルの描画を行っているが、これはレースゲーム以外のあらゆるアプリケーションでも可能である。さらに、このムービーファイルについては、複数のゴーストデータパッケージを１つの、例えば、ＡＶＩファイルに描画し、ユーザが選択できるように提示するなど、上述の様々な実施形態を組み合わせて使用されてもよい。

他に適応されるムービーファイルアプリケーションとしては、ヘイロー２シリーズのあらゆるファーストパーソン・シューティングゲームが挙げられる。ムービーモードにおいて、ユーザは激しいチーム戦がより複雑に描画された記録画像をダウンロードすることができる。この場合、ユーザがゲームの主要観戦スポットを映す備え付けのカメラ角度から観戦できるように、サーバは画像に処理を施してもよい。つまり、カメラは常時プレイヤを追っている必要はない。

さらに、例えばより複雑に描画された背景およびオブジェクトなど、ダウンロード済みのムービーファイルは、多人数参加型オンラインゲームに適応されてもよい。ムービーモードにおいては、ゲームシーケンスを記録後、サーバで収集して１個のムービーファイルにまとめることにより、ユーザが激しいチーム戦を観戦できるようにしてもよい。同時に何千人ものプレイヤが参加する多人数参加型オンラインゲームでは、ゲームの主要観戦スポットを映す備え付けのカメラ角度からこのような画像が表示されてもよい。つまり、カメラは常時プレイヤを追っている必要はない。

さらに、本発明における方法は、例えば、シムシティシリーズの都市建設ゲームなど、あらゆるシミュレーションゲームに適応されてもよい。例えば、さらなる一実施形態においては、各プレイヤには都市の異なる区域の建設が割り当てられている。例えば、都市の異なる区域を建設する各ユーザのデータがゴーストデータとして記録されている。ここでは、各プレイヤがダウンロードしてもよいパッケージは、自身とは異なる都市区域の建設を表すパッケージである。つまり、プレイヤは、例えば、ダウンロードしていない都市部分しか建設することができない。例えば、都市は４分割されているものとする。プレイヤが第１象限を建設するとすれば、第２、３、４象限のパッケージをダウンロードすることになる。この例では、ゴーストデータは都市全体の実データとして使用され、都市全体の基礎構造を表す。プレイヤのコンピュータ装置のシミュレーションは都市全体を網羅している。

上述の実施形態におけるムービーモードの一例によれば、プレイヤは、一都市あるいは複数都市の建設を微速度で描画するサーバが提供する建設シーケンスをダウンロードして
もよい。

さらに、上述の方法は教育用ゲームに適応されてもよい。例えば、生徒の個人成績が記録されている。このような成績データは、例えば、ゴルフ、ダンス、演技、あるいはその他諸活動の習得に関するデータであってもよい。個人別成績を総合的に再生することによって、どの分野でどの生徒が他の生徒より優れているのか、また劣っているのかを認識できる。このような総合成績は、例えば、異なる表示ウィンドウで表示されてもよいし、もしくは、要望に応じて各生徒のサムネイル画像を使って表示されてもよい。

さらに、上述の方法は、ドンキーコンガ、ダンスレボリューション、カラオケレボリューションのようなリズム合わせゲームおよび他の関連ゲームなどの音楽ゲームに適応されてもよい。一実施形態によれば、ゴーストデータは異なる演奏者の楽器演奏がミックスされたものであってもよい。各ゴーストは同じかもしくは違う楽器を演奏する。例えば、あるゴーストがドラムを、別のゴーストがピアノを演奏するといったように、演奏は異なる楽器がミックスされていてもよい。ユーザは例えばギターを演奏する。カラオケレボリューションの場合、合成演奏に調和するようにユーザのボーカルがミックスされる。あるいは、プレイヤは同じ楽器を演奏するゴーストより上手く演奏するために、同じ調子をほぼ完璧なタイミング、かつ、ほぼ完璧な音長および強度で奏でてもよい。

さらに、上述の方法はあらゆるカードゲームに適応されてもよい。例えば、ある実施形態では、ブラックジャックやテキサス・ホールデム・ポーカーのようなジャンルのカードゲームが行われてもよい。上述の実施形態によれば、リアルプレイヤは、ゴーストプレイヤがゲーム中に引いたカードを除くカード一組を使用する。ゴーストデータを組み合わせる際、サーバは共通のカード一組でゲームをしていない複数のプレイヤのゴーストパフォーマンスを基に、ゲームに使用するカード一組（あるいは数組）を構成できるかどうかを判断してもよい。例えば、一組のカードが使用されるゲームにおいて、２つのゴーストデータパフォーマンスそれぞれで、プレイヤがエースを４枚とも引いたことが示されている場合、これら２つのゴーストデータパフォーマンスを１つのパッケージに組み入れることはできない。この場合のゴーストデータは各ゲームでプレイヤが引いたカードとプレイヤがゲームで負けた状態を示している。

上述の実施形態において、リアルプレイヤが一組のカードを使用する場合、上記プレイヤが使用するカードは、ゴーストプレイヤがゲーム中に引いたカードを全て除いたカードである。例えば、一組のカードが使われており、ブラックジャックのゲーム中、以下のカードがゴースストデータによって引い抜かれていたとする。

ハート：Ａ、２、６、９、Ｑ；スペード：３、６、８、４、７；クラブ：Ａ、９、Ｊ、７；ダイヤ：６、３、９。この場合、リアルプレイヤが使用するカードの組は以下で構成される。

ハート：３、４、５、７、８、１０、Ｊ、Ｋ；スペード：Ａ、２、５、７、９、１０、Ｊ、Ｑ、Ｋ；クラブ：２、３、４、５、６、８、１０、Ｑ、Ｋ；ダイヤ：Ａ、２、４、５、７、８、１０、Ｊ、Ｑ、Ｋ。

実施形態において、リアルプレイヤは上記のカードを除いたカード組の中から任意のカードを引くことになる。一方、ゴーストが引くカードは、ゴーストデータの記録時に引いたものと同じカードである。

ブラックジャックの場合、ゴーストプレイヤの持ち札とともに、親の持ち札がゴーストデータに記録されていてもよい。これにより、リアルプレイヤは同じ親と対戦することが
できる。この場合、親のカードも同様にリアルプレイヤのカード組から除外される。

さらに、上述の方法はあらゆる個人競技スポーツゲーム（オリンピックゲームのシミュレーションゲームなど）に適応されてもよい。ゲームに参加するために、プレイヤは自身のバディグループを登録するか、あるいは、数々の有名なスポーツ選手や著名人と対戦するかを選択してもよい。実施形態においてこのようなゲームでは、あるプレイヤのパフォーマンスは別のプレイヤのパフォーマンスに対して測定され、得点は各プレイヤの期間を通してのパフォーマンスを反映して算出されてもよい。このようなスポーツ競技のシミュレーションでは、通常、選手同士の衝突は含まれない。また、このようなスポーツゲームでは、より複雑に描画されたプレイヤおよび背景が、例えばムービーモードで記録されていてもよい。このようなスポーツゲームは以下を含むが、これらに限定されない。
− アーチェリー
− ダーツ
− ダイビング
− シンクロナイズドスイミング（各選手のゴーストが同じ振り付けに合わせようとする）
− 水泳（レーンレース）
− 徒競走
− 高飛び
− 棒高飛び
− 走り幅跳び
− 三段跳び
− 砲丸投げ
− 円盤投げ
− ハンマー投げ
− 槍投げ
− カヌー
− 自転車競技（プレイヤ同士の衝突が重要視されるため、チームのムービーを再生するにとどまる可能性もある）
− 馬術・障害飛び越え
− 体操
− ローイング
− セーリング
− ターゲット射撃、クレー
− 重量上げ
− ホームランダービー
− ダンクシュートコンテスト
− フリースローコンテスト

本発明は、現在最も実用的で好ましいと考えられる実施形態に関連して説明されてきたが、本発明が開示された実施形態に限定されるものではないことは言うまでもなく、クレームの精神および範囲内における様々な変形例や同等の構成を包括するものであることを意図している。

Claims (44)

1. 複数のユーザのパフォーマンスシーケンスをシミュレートする方法であって、
   ａ）少なくとも第１のユーザのパフォーマンスシーケンスを第１のコンピュータ装置によって記録するステップと、
   ｂ）前記第１のコンピュータ装置を少なくとも１つのサーバコンピュータに通信ネットワークを介して接続するステップと、
   ｃ）前記第１のユーザを認証する識別データを少なくとも１つのサーバに送信するステップと、
   ｄ）他ユーザのパフォーマンスシーケンスを記録した第２のコンピュータ装置を操作する少なくとも１人の他ユーザを識別する他ユーザ識別データを、前記通信ネットワークを通して送信するステップと、
   ｅ）検索クエリーを、前記クエリーに合う他ユーザパフォーマンスデータのパッケージを要求する前記第１のコンピュータ装置によって、少なくとも１つのサーバに前記通信ネットワークを通して送信するステップとを含む、方法。
2. パフォーマンスシーケンスの特徴を前記第１のユーザによって特定するステップをさらに含む、請求項１に記載の方法。
3. 前記検索クエリーを送信するステップは、パフォーマンスシーケンスの特徴を使って前記検索クエリーを構築するステップを含む、請求項２に記載の方法。
4. 前記特徴を特定するステップは、レースビデオゲームで使用されるレースコースを特定するステップを含む、請求項２に記載の方法。
5. 前記特徴を特定するステップは、ビデオゲームで使用される天候条件を特定するステップを含む、請求項２に記載の方法。
6. 前記クエリーに合う他ユーザパフォーマンスデータのパッケージを通信ネットワークを通して受信するステップを、さらに含む、請求項１に記載の方法。
7. 前記第１のコンピュータ装置が記録したオブジェクトよりも１オブジェクトあたりのポリゴン数が多いオブジェクトを使って、少なくとも第１のユーザのパフォーマンスシーケンスを第２のコンピュータ装置で描画するステップを、さらに含む、請求項１に記載の方法。
8. 前記クエリーを送信するステップは、前記第１のユーザが対戦したい他ユーザの識別を含むように前記検索クエリーを構築するステップを含む、請求項１に記載の方法。
9. 他ユーザの識別をサーバから前記通信ネットワークを通して受信するステップを、さらに含む、請求項１に記載の方法。
10. 前記他ユーザ識別データは、前記第１のユーザの複数の友人の識別を含む、請求項１に記載の方法。
11. 前記検索クエリーを送信するステップは、閾値を越えるパフォーマンスを持つユーザの複数の友人に対して要求を送信するステップを含む、請求項１に記載の方法。
12. 前記検索クエリーを送信するステップは、前記第１のユーザのパフォーマンスと類似しているパフォーマンスを持つ前記第１のユーザの複数の友人に対して要求を送信するステ
    ップを含む、請求項１に記載の方法。
13. 前記検索クエリーを送信するステップは、閾値を越えるパフォーマンスを持つ複数の個人に対して要求を送信するステップを含む、請求項１に記載の方法。
14. 前記検索クエリーを送信するステップは、所定の関連する他ユーザ群から成る複数の個人に対して要求を送信するステップを含む、請求項１に記載の方法。
15. 前記検索クエリーを送信するステップは、他ユーザによって高く評価されているパフォーマンスを持つ複数の個人に対して要求を送信するステップを含む、請求項１に記載の方法。
16. 前記関連する個人群は、同じチームのメンバーである、請求項１４に記載の方法。
17. 前記ユーザのパフォーマンスシーケンスは、シミュレートされた運転シーケンスである、請求項１に記載の方法。
18. 前記ユーザのパフォーマンスシーケンスは、ビデオゲームのパフォーマンスシーケンスである、請求項１に記載の方法。
19. 複数のユーザのパフォーマンスシーケンスをシミュレートする方法であって、
    ａ）少なくとも第１のユーザのパフォーマンスシーケンスを第１のコンピュータ装置によって記録するステップと、
    ｂ）前記第１のコンピュータ装置を少なくとも１つのサーバコンピュータに通信ネットワークを介して接続するステップと、
    ｃ）前記第１のユーザを認証する識別データを少なくとも１つのサーバに送信するステップと、
    ｄ）パフォーマンスシーケンスをシミュレートする装置の少なくとも１人の他ユーザを識別する他ユーザ識別データを受信するステップと、
    ｅ）ダウンロードするために第１のユーザが選択できる複数の他ユーザのパフォーマンスパッケージオプションを、前記第１のユーザのディスプレイに表示するステップとを含む、方法。
20. 前記第１のユーザの選択に基づいて、パフォーマンスパラメータを識別するステップと、
    前記少なくとも１つの前記パラメータに応じて、前記他ユーザのパフォーマンスパッケージオプションを選択するステップとを、さらに含む、請求項１９に記載の方法。
21. 前記他ユーザのパフォーマンスパッケージオプションは、前記第１のユーザの複数の友人のパフォーマンスデータを含む、請求項１９に記載の方法。
22. 前記他ユーザのパフォーマンスパッケージオプションは、パフォーマンス閾値を越える前記第１のユーザの複数の友人のパフォーマンスデータを含む、請求項１９に記載の方法。
23. 前記他ユーザのパフォーマンスパッケージオプションは、パフォーマンスが前記第１のユーザのパフォーマンスと類似している前記第１のユーザの複数の友人のパフォーマンスデータを含む、請求項１９に記載に方法。
24. 前記他ユーザのパフォーマンスパッケージオプションは、関連する個人群から成る複数
    の個人のパフォーマンスデータを含む、請求項１９に記載の方法。
25. 前記関連する個人群は、同じチームのメンバーである、請求項２４に記載の方法。
26. 少なくとも１人の対戦相手に関するタスクのパフォーマンスをシミュレートする方法であって、
    ａ）処理能力が相対的に低い第１のコンピュータ装置における少なくとも１人のユーザによるタスクのパフォーマンスをシミュレートするステップと、
    ｂ）前記タスクのパフォーマンスを記録するステップと、
    ｃ）前記タスクのパフォーマンスを表すデータを処理能力が相対的に高い第２のコンピュータに送信するステップと、
    ｄ）前記第２のコンピュータによるタスクを表すパフォーマンスデータを変更するステップと、
    ｅ）前記第１のコンピュータ装置がリアルタイムで生成したオブジェクトよりもポリゴン数が多いオブジェクトを使って、３次元空間における前記タスクのパフォーマンスをシミュレートする表示を生成するステップとを含む、方法。
27. 前記パフォーマンスデータを前記第２のコンピュータによってムービーファイルに描画するステップを、さらに含む、請求項２６に記載の方法。
28. 前記パフォーマンスデータを前記第２のコンピュータによってＡＶＩファイルに描画するステップを、さらに含む、請求項２６に記載の方法。
29. 前記第１のコンピュータ装置が記録するよりも複雑度の高い背景を使って、前記第２のコンピュータ装置によって表示を生成するステップを、さらに含む、請求項２６に記載の方法。
30. 前記変更されたパフォーマンスデータを、前記第２のコンピュータ装置によって、前記第１のコンピュータ装置がダウンロード可能なタイプのムービーファイルに収集するステップを、さらに含む、請求項２６に記載の方法。
31. 前記第１のコンピュータ装置がリアルタイムで生成したオブジェクトよりもポリゴン数が多いオブジェクトを使って、３次元空間における前記タスクのパフォーマンスを表すデータを、前記第２のコンピュータ装置がアクセスできるデータベースに記憶するステップを、さらに含む、請求項２６に記載の方法。
32. 前記タスクのパフォーマンスは、レースビデオゲームにおけるレースのパフォーマンスである、請求項２６に記載の方法。
33. 複数のユーザのパフォーマンスシーケンスをシミュレートするシステムであって、
    少なくとも第１のユーザのパフォーマンスシーケンスを記録し、少なくとも１つのパフォーマンスシーケンスパラメータを識別する表示を生成し、かつ、関連の表示装置を有する第１のコンピュータ装置と、
    通信ネットワークと、
    識別データを前記第１のコンピュータ装置から受信して、前記第１のユーザを認証する認証サーバと、
    前記第１のユーザの対戦相手となる他ユーザの認証に対してアクセス権を与えるバディサーバとを含み、
    前記第１のコンピュータ装置は、前記少なくとも１つのパフォーマンスシーケンスパラメータのユーザの仕様に応じて、ダウンロードするために第１のユーザが選択できる複数
    の他ユーザのパフォーマンスパッケージオプションを前記第１のユーザのディスプレイに表示するパフォーマンスパッケージ表示生成機を含む方法。
34. 前記第１のユーザの選択に応じてパフォーマンスデータパッケージをダウンロードする得点・結果サーバを、さらに含む、請求項３３に記載のシステム。
35. 前記得点・結果サーバに機能的に接続される他ユーザのパフォーマンスデータを記憶するパフォーマンスデータデータベースを、さらに含む、請求項３４に記載のシステム。
36. 前記得点・結果サーバ、他ユーザのパフォーマンスデータを記憶するパフォーマンスデータデータベースに機能的に接続される得点・結果データベースを、さらに含む、請求項３４に記載のシステム。
37. 前記得点・結果データベースは、前記パフォーマンスデータデータベースに対する少なくとも１つのポインタを含む、請求項３６に記載のシステム。
38. 前記他のパッケージオプションは、前記第１のユーザの複数の友人のパフォーマンスデータを含む、請求項３３に記載のシステム。
39. 前記他のパッケージオプションは、パフォーマンスが閾値を超える前記第１のユーザの複数の友人のパフォーマンスデータを含む、請求項３３に記載のシステム。
40. 前記他のパフォーマンスパッケージオプションは、前記第１のユーザのパフォーマンスデータと類似している前記第１のユーザの複数の友人のパフォーマンスデータを含む、請求項３３に記載のシステム。
41. 前記他のパフォーマンスパッケージオプションは、関連する個人群から成る複数の個人のパフォーマンスデータを含む、請求項３３に記載のシステム。
42. 前記関連する個人群は、同じチームのメンバーである、請求項４１に記載のシステム。
43. 前記パフォーマンスシーケンスは、レースビデオゲームのレースである、請求項３３に記載のシステム。
44. 前記パフォーマンスシーケンスは、ビデオゲームで競争するためのタスクである、請求項３３に記載のシステム

Images