(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-10-29
(45)【発行日】2024-11-07
(54)【発明の名称】ゲームプログラム、ゲームシステム、およびゲーム処理方法
(51)【国際特許分類】
A63F 13/55 20140101AFI20241030BHJP
A63F 13/53 20140101ALI20241030BHJP
A63F 13/493 20140101ALI20241030BHJP
【ＦＩ】
A63F13/55
A63F13/53
A63F13/493
【請求項の数】
21
(21)【出願番号】P 2023132926
(22)【出願日】2023-08-17
(65)【公開番号】P2023169896
(43)【公開日】2023-11-30
【審査請求日】2023-11-10
(73)【特許権者】
【識別番号】000233778
【氏名又は名称】任天堂株式会社
(74)【代理人】
【識別番号】110001276
【氏名又は名称】弁理士法人小笠原特許事務所
(74)【代理人】
【識別番号】100130269
【弁理士】
【氏名又は名称】石原 盛規
(72)【発明者】
【氏名】松浦 龍平
(72)【発明者】
【氏名】佐々木 誠
(72)【発明者】
【氏名】都築 潤
【審査官】池田 剛志
(56)【参考文献】
【文献】特開２０２０－１７８９７０（ＪＰ，Ａ）
【文献】特開２０１４－１９８１８２（ＪＰ，Ａ）
【文献】米国特許出願公開第２０２１／０３３９１４０（ＵＳ，Ａ１）
【文献】［UE4］なぜかスポーンに失敗する場合，Zenn [online]，2022年03月27日，＜ＵＲＬ：https://zenn.dev/udondev/articles/b223339d1cd090＞，[2024年9月17日検索]
【文献】［Unity］重ならないようにランダムにオブジェクトを配置する，Unityの使い方｜初心者からわかりやすく [online]，2021年06月21日，＜ＵＲＬ：https://www.ame-name.com/archives/12654＞，［2024年9月17日検索］
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ａ６３Ｆ １３／００－１３／９８，
９／２４
(57)【特許請求の範囲】
【請求項1】
ゲーム装置のコンピュータに、ゲーム空間内の所定の位置を所定のキャラクタの出現予定位置として設定させ、
前記出現予定位置が、前記所定のキャラクタが出現可能な位置であった場合、当該出現予定位置に前記キャラクタを出現させ、
前記出現予定位置が、前記所定のキャラクタが出現できない位置であった場合、
当該出現予定位置に探索中オブジェクトを配置させ、
前記所定のキャラクタが出現可能な位置に前記探索中オブジェクトが到達するまでの間、当該探索中オブジェクトを前記ゲーム空間内で所定距離移動させて、当該移動後の位置において前記所定のキャラクタが出現可能か否かを判定する処理を繰り返させ、
前記探索中オブジェクトが、前記所定のキャラクタが出現可能な位置に到達した場合、当該探索中オブジェクトの位置に前記所定のキャラクタを出現させる、
ゲームプログラム。
【請求項2】
前記コンピュータは、前記探索中オブジェクトを配置した位置から離れていくような経路で当該探索中オブジェクトを移動させる、請求項１に記載のゲームプログラム。
【請求項3】
前記コンピュータは、前記所定のキャラクタが出現可能か否かを判定する処理を繰り返すに際して、前記探索中オブジェクトの移動方向を、前回に前記判定する処理を行ったときの移動方向とは異なる方向となるように変更しながら移動させる、請求項１または２に記載のゲームプログラム。
【請求項4】
前記コンピュータは、前記探索中オブジェクトを螺旋状の経路で移動させる、請求項３に記載のゲームプログラム。
【請求項5】
前記コンピュータは、前記所定のキャラクタが出現可能か否かを判定する処理を繰り返すに際して、前記探索中オブジェクト移動後の位置において、当該所定のキャラクタのサイズの応じた空間が確保されているか否かに基づいて、当該所定のキャラクタが出現可能か否かを判定する、請求項１に記載のゲームプログラム。
【請求項6】
前記所定のキャラクタは、プレイヤの操作に基づいて移動制御され、前記ゲーム空間内のオブジェクトとの衝突判定が行われ得るプレイヤキャラクタであり、前記プレイヤキャラクタが移動制御可能な状態で前記出現予定位置にプレイヤキャラクタを出現させる、請求項１に記載のゲームプログラム。
【請求項7】
前記探索中オブジェクトは、前記ゲーム空間内において他のオブジェクトとの衝突判定が行われないオブジェクトである、請求項１に記載のゲームプログラム。
【請求項8】
少なくとも１つのプロセッサを備え、前記プロセッサは、
ゲーム空間内の所定の位置を所定のキャラクタの出現予定位置として設定し、
前記出現予定位置が、前記所定のキャラクタが出現可能な位置であった場合、当該出現予定位置に前記キャラクタを出現させ、
前記出現予定位置が、前記所定のキャラクタが出現できない位置であった場合、
当該出現予定位置に探索中オブジェクトを配置し、
前記所定のキャラクタが出現可能な位置に前記探索中オブジェクトが到達するまでの間、当該探索中オブジェクトを前記ゲーム空間内で所定距離移動させて、当該移動後の位置において前記所定のキャラクタが出現可能か否かを判定する処理を繰り返し、
前記探索中オブジェクトが、前記所定のキャラクタが出現可能な位置に到達した場合、当該探索中オブジェクトの位置に前記所定のキャラクタを出現させる、
ゲームシステム。
【請求項9】
前記プロセッサは、前記探索中オブジェクトを配置した位置から離れていくような経路で当該探索中オブジェクトを移動させる、請求項８に記載のゲームシステム。
【請求項10】
前記プロセッサは、前記所定のキャラクタが出現可能か否かを判定する処理を繰り返すに際して、前記探索中オブジェクトの移動方向を、前回に前記判定する処理を行ったときの移動方向とは異なる方向となるように変更しながら移動させる、請求項８または９に記載のゲームシステム。
【請求項11】
前記プロセッサは、前記探索中オブジェクトを螺旋状の経路で移動させる、請求項１０に記載のゲームシステム。
【請求項12】
前記プロセッサは、前記所定のキャラクタが出現可能か否かを判定する処理を繰り返すに際して、前記探索中オブジェクト移動後の位置において、当該所定のキャラクタのサイズの応じた空間が確保されているか否かに基づいて、当該所定のキャラクタが出現可能か否かを判定する、請求項８に記載のゲームシステム。
【請求項13】
前記所定のキャラクタは、プレイヤの操作に基づいて移動制御され、前記ゲーム空間内のオブジェクトとの衝突判定が行われ得るプレイヤキャラクタであり、前記プレイヤキャラクタが移動制御可能な状態で前記出現予定位置にプレイヤキャラクタを出現させる、請求項８に記載のゲームシステム。
【請求項14】
前記探索中オブジェクトは、前記ゲーム空間内において他のオブジェクトとの衝突判定が行われないオブジェクトである、請求項８に記載のゲームシステム。
【請求項15】
ゲーム装置のコンピュータに実行させるゲーム処理方法であって前記コンピュータに、
ゲーム空間内の所定の位置を所定のキャラクタの出現予定位置として設定させ、
前記出現予定位置が、前記所定のキャラクタが出現可能な位置であった場合、当該出現予定位置に前記キャラクタを出現させ、
前記出現予定位置が、前記所定のキャラクタが出現できない位置であった場合、
当該出現予定位置に探索中オブジェクトを配置させ、
前記所定のキャラクタが出現可能な位置に前記探索中オブジェクトが到達するまでの間、当該探索中オブジェクトを前記ゲーム空間内で所定距離移動させて、当該移動後の位置において前記所定のキャラクタが出現可能か否かを判定する処理を繰り返させ、
前記探索中オブジェクトが、前記所定のキャラクタが出現可能な位置に到達した場合、当該探索中オブジェクトの位置に前記所定のキャラクタを出現させる、
ゲーム処理方法。
【請求項16】
前記コンピュータは、前記探索中オブジェクトを配置した位置から離れていくような経路で当該探索中オブジェクトを移動させる、請求項１５に記載のゲーム処理方法。
【請求項17】
前記コンピュータは、前記所定のキャラクタが出現可能か否かを判定する処理を繰り返すに際して、前記探索中オブジェクトの移動方向を、前回に前記判定する処理を行ったときの移動方向とは異なる方向となるように変更しながら移動させる、請求項１５または１６に記載のゲーム処理方法。
【請求項18】
前記コンピュータは、前記探索中オブジェクトを螺旋状の経路で移動させる、請求項１７に記載のゲーム処理方法。
【請求項19】
前記コンピュータは、前記所定のキャラクタが出現可能か否かを判定する処理を繰り返すに際して、前記探索中オブジェクト移動後の位置において、当該所定のキャラクタのサイズの応じた空間が確保されているか否かに基づいて、当該所定のキャラクタが出現可能か否かを判定する、請求項１５に記載のゲーム処理方法。
【請求項20】
前記所定のキャラクタは、プレイヤの操作に基づいて移動制御され、前記ゲーム空間内のオブジェクトとの衝突判定が行われ得るプレイヤキャラクタであり、前記プレイヤキャラクタが移動制御可能な状態で前記出現予定位置にプレイヤキャラクタを出現させる、請求項１５に記載のゲーム処理方法。
【請求項21】
前記探索中オブジェクトは、前記ゲーム空間内において他のオブジェクトとの衝突判定が行われないオブジェクトである、請求項１５に記載のゲーム処理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、ゲーム空間内の所定の位置に所定のキャラクタを出現させるゲーム処理に関する。
【背景技術】
【0002】
従来から、プレイヤの操作に基づく位置にプレイヤキャラクタをリスポーンさせるゲームが知られていた（例えば特許文献１）。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２０２２－４７４３４号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかし、リスポーン位置がキャラクタが配置できない場所だった場合については、特に考慮されていなかった。
【課題を解決するための手段】
【0005】
上記の点に鑑みて、例えば以下のような構成例が挙げられる。
【0006】
（構成１）
構成１は、ゲーム装置のコンピュータに、
ゲーム空間内の所定の位置を所定のキャラクタの出現予定位置として設定させ、出現予定位置が、所定のキャラクタが出現可能な位置であった場合、当該出現予定位置にキャラクタを出現させる。一方、出現予定位置が、所定のキャラクタが出現できない位置であった場合、当該出現予定位置に探索中オブジェクトを配置させ、所定のキャラクタが出現可能な位置に探索中オブジェクトが到達するまで、当該探索中オブジェクトをゲーム空間内で所定距離移動させて、当該移動後の位置において所定のキャラクタが出現可能か否かを判定する処理を繰り返させる。そして、探索中オブジェクトが、所定のキャラクタが出現可能な位置に到達した場合、当該探索中オブジェクトの位置に所定のキャラクタを出現させる。
構成１は、ゲーム装置のコンピュータに、
ゲーム空間内の所定の位置を所定のキャラクタの出現予定位置として設定させ、出現予定位置が、所定のキャラクタが出現可能な位置であった場合、当該出現予定位置にキャラクタを出現させる。一方、出現予定位置が、所定のキャラクタが出現できない位置であった場合、当該出現予定位置に探索中オブジェクトを配置させ、所定のキャラクタが出現可能な位置に探索中オブジェクトが到達するまで、当該探索中オブジェクトをゲーム空間内で所定距離移動させて、当該移動後の位置において所定のキャラクタが出現可能か否かを判定する処理を繰り返させる。そして、探索中オブジェクトが、所定のキャラクタが出現可能な位置に到達した場合、当該探索中オブジェクトの位置に所定のキャラクタを出現させる。
【0007】
上記構成によれば、簡易な処理によって、所定のキャラクタを出現させるための適切な出現位置を探索できる。また、探索中オブジェクトを移動させることで、探索プロセスを視覚的に提示するため、なぜその位置が出現位置として決められたのかについて、プレイヤに納得感を与えることができる。
【0008】
（構成２）
構成２は、上記構成１において、コンピュータは、探索中オブジェクトを配置した位置から離れていくような経路で当該探索中オブジェクトを移動させてもよい。
構成２は、上記構成１において、コンピュータは、探索中オブジェクトを配置した位置から離れていくような経路で当該探索中オブジェクトを移動させてもよい。
【0009】
上記構成によれば、徐々に範囲を拡げていくような探索が可能となる。また、探索中オブジェクトを配置した位置になるべく近い位置を出現位置として優先的に決めることができる。
【0010】
（構成３）
構成３は、上記構成１または２において、コンピュータは、所定のキャラクタが出現可能か否かを判定する処理を繰り返すに際して、探索中オブジェクトの移動方向を、前回に判定する処理を行ったときの移動方向とは異なる方向となるように変更しながら移動させてもよい。
構成３は、上記構成１または２において、コンピュータは、所定のキャラクタが出現可能か否かを判定する処理を繰り返すに際して、探索中オブジェクトの移動方向を、前回に判定する処理を行ったときの移動方向とは異なる方向となるように変更しながら移動させてもよい。
【0011】
上記構成によれば、移動方向を変えながら探索中オブジェクトを移動させるため、探索効率を向上できる。
【0012】
（構成４）
構成４は、上記構成３において、コンピュータは、探索中オブジェクトを螺旋状の経路で移動させてもよい。
構成４は、上記構成３において、コンピュータは、探索中オブジェクトを螺旋状の経路で移動させてもよい。
【0013】
上記構成によれば、より効率的に出現可能位置を探索できる。
【0014】
（構成５）
構成５は、上記構成１において、コンピュータは、所定のキャラクタが出現可能か否かを判定する処理を繰り返すに際して、探索中オブジェクト移動後の位置において、当該所定のキャラクタのサイズの応じた空間が確保されているか否かに基づいて、当該所定のキャラクタが出現可能か否かを判定してもよい。
構成５は、上記構成１において、コンピュータは、所定のキャラクタが出現可能か否かを判定する処理を繰り返すに際して、探索中オブジェクト移動後の位置において、当該所定のキャラクタのサイズの応じた空間が確保されているか否かに基づいて、当該所定のキャラクタが出現可能か否かを判定してもよい。
【0015】
上記構成によれば、様々なサイズのキャラクタをを出現させるゲームについて、適切な出現位置を決めることができる。
【0016】
（構成６）
構成６は、上記構成１において、所定のキャラクタは、プレイヤの操作に基づいて移動制御され、ゲーム空間内のオブジェクトとの衝突判定が行われ得るプレイヤキャラクタであり、当該プレイヤキャラクタが移動制御可能な状態で出現予定位置にプレイヤキャラクタを出現させてもよい。
構成６は、上記構成１において、所定のキャラクタは、プレイヤの操作に基づいて移動制御され、ゲーム空間内のオブジェクトとの衝突判定が行われ得るプレイヤキャラクタであり、当該プレイヤキャラクタが移動制御可能な状態で出現予定位置にプレイヤキャラクタを出現させてもよい。
【0017】
上記構成によれば、出現後に移動させることができないような位置にプレイヤキャラクタが出現することを防ぎ、適切な位置にプレイヤキャラクタを出現させることができる。
【0018】
（構成７）
構成７は、上記構成１において、探索中オブジェクトは、ゲーム空間内において他のオブジェクトとの衝突判定が行われないオブジェクトであってもよい。
構成７は、上記構成１において、探索中オブジェクトは、ゲーム空間内において他のオブジェクトとの衝突判定が行われないオブジェクトであってもよい。
【0019】
上記構成によれば、処理負荷を軽減し、探索効率を向上できる。
【発明の効果】
【0020】
本開示によれば、所定のキャラクタをゲーム空間内に出現させる際、適切な位置に出現させることができる。
【図面の簡単な説明】
【0021】
【図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】特殊状態処理の詳細を示すフローチャート
【図45】特殊状態処理の詳細を示すフローチャート
【図46】探索処理の詳細を示すフローチャート
【図47】リプレイゴースト処理の詳細を示すフローチャート
【図48】ステージクリア処理の詳細を示すフローチャート
【図49】リスタート処理の詳細を示すフローチャート
【図50】ゲームサーバ１で実行されるゲームサーバ処理の詳細を示すフローチャート
【発明を実施するための形態】
【0022】
以下、本発明の一実施形態について説明する。図１は、本実施形態に係る情報処理システム（ゲームシステム）の全体像を示す模式図である。本実施形態の情報処理システム１００は、ゲームサーバ１と、複数の情報処理端末３とを含む。ゲームサーバ１、情報処理端末３とは、インターネット等のネットワーク１０を介して通信可能に構成されている。本実施形態では、このような構成で、情報処理が実行されるが、以下では、当該情報処理の一例として、ゲーム処理を例として説明する。具体的には、情報処理端末３上にゲームプログラムがインストールされ、必要に応じてゲームサーバ１と通信を行いながら実行されるゲーム処理を例示する。
【0023】
［ゲームサーバのハードウェア構成］
次に、上記ゲームサーバ１のハードウェア構成について説明する。図２は、ゲームサーバ１のハードウェア構成を示すブロック図である。ゲームサーバ１は、プロセッサ１１と、記憶部１２と、通信部１３とを少なくとも備えている。プロセッサ１１は、各サーバを制御するための各種プログラムを実行する。記憶部には、プロセッサ１１によって実行される各種プログラムおよび利用される各種データが格納される。通信部１３は、有線、または無線通信によってネットワークと接続し、上記情報処理端末３または他のサーバとの間で所定のデータを送受信する。なお、本実施形態では、ゲームサーバ１が１つである例を図示しているが、分散処理を行うサーバ群として構成されていてもよい。
次に、上記ゲームサーバ１のハードウェア構成について説明する。図２は、ゲームサーバ１のハードウェア構成を示すブロック図である。ゲームサーバ１は、プロセッサ１１と、記憶部１２と、通信部１３とを少なくとも備えている。プロセッサ１１は、各サーバを制御するための各種プログラムを実行する。記憶部には、プロセッサ１１によって実行される各種プログラムおよび利用される各種データが格納される。通信部１３は、有線、または無線通信によってネットワークと接続し、上記情報処理端末３または他のサーバとの間で所定のデータを送受信する。なお、本実施形態では、ゲームサーバ１が１つである例を図示しているが、分散処理を行うサーバ群として構成されていてもよい。
【0024】
［ゲーム装置のハードウェア構成］
次に、上記情報処理端末３について説明する。当該情報処理端末３は、例えばスマートフォン、据置型または携帯型のゲーム装置、タブレット端末、携帯電話、パーソナルコンピュータ、ウェアラブル端末等である。本実施形態では、据置型ゲーム装置（以下、単にゲーム装置と呼ぶ）を情報処理端末３の一例として説明する。
次に、上記情報処理端末３について説明する。当該情報処理端末３は、例えばスマートフォン、据置型または携帯型のゲーム装置、タブレット端末、携帯電話、パーソナルコンピュータ、ウェアラブル端末等である。本実施形態では、据置型ゲーム装置（以下、単にゲーム装置と呼ぶ）を情報処理端末３の一例として説明する。
【0025】
図３は、本実施形態に係るゲーム装置３のハードウェア構成の一例を示すブロック図である。図３において、ゲーム装置３は、プロセッサ３１を備える。プロセッサ３１は、ゲーム装置３において実行される各種の情報処理を実行する情報処理部であって、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）のみから構成されてもよいし、ＣＰＵ機能、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）機能等の複数の機能を含むＳｏＣ（Ｓｙｓｔｅｍ－ｏｎ－ａ－ｃｈｉｐ）から構成されてもよい。プロセッサ３１は、記憶部３２に記憶される情報処理プログラム（例えば、ゲームプログラム）を実行することによって、各種の情報処理を実行する。なお、記憶部３２は、例えば、フラッシュメモリやＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の内部記憶媒体であってもよいし、図示しないスロットに装着される外部記憶媒体等を利用する構成でもよい。
【0026】
また、ゲーム装置３は、ゲーム装置３が他のゲーム装置３や上記サーバと無線通信を行うための無線通信部３３を備える。当該無線通信としては、例えば、インターネット通信や近距離無線通信が用いられる。
【0027】
また、ゲーム装置３は、ゲーム装置３がコントローラ４と有線または無線通信を行うためのコントローラ通信部３４を備える。
【0028】
また、ゲーム装置３には、画像音声出力部３５を介して表示部５（例えば、テレビ等）が接続される。プロセッサ３１は、（例えば、上記の情報処理の実行によって）生成した画像や音声を、画像音声出力部３５を介して表示部５に出力する。
【0029】
次に、コントローラ４について説明する。コントローラ４は、方向入力デバイスの一例であるアナログスティック４２を少なくとも１つ備える。当該アナログスティック４２は、方向を入力することが可能な方向入力部として用いることができる。プレイヤは、アナログスティック４２を傾倒することによって傾倒方向に応じた方向の入力（および、傾倒した角度に応じた大きさの入力）が可能である。また、コントローラ４は、各種操作ボタンを含むボタン部４３を備える。例えば、コントローラ４は、上記ハウジングの主面上に複数個の操作ボタンを備えていてもよい。
【0030】
また、コントローラ４は、慣性センサー４４を備える。具体的には、コントローラ４は、慣性センサー４４として、加速度センサー、角速度センサーを備えている。本実施形態においては、加速度センサーは、所定の３軸方向に沿った加速度の大きさを検出する。また、角速度センサーは、所定の３軸回りの角速度を検出する。
【0031】
また、コントローラ４は、上記コントローラ通信部３４と有線または無線通信を行うための通信部４１も備える。上記アナログスティック４２に対する方向入力内容、ボタン部４３の押下状態を示す情報、および、慣性センサー４４による各種の検出結果は、適宜のタイミングで繰り返し通信部４１へ出力され、ゲーム装置３に送信される。
【0032】
［本実施形態における情報処理の概要］
次に、本実施形態に係る情報処理の概要を説明する。本実施形態では、情報処理の一例として、仮想空間内に存在するプレイヤキャラクタオブジェクト（以下、プレイヤキャラと呼ぶ）をプレイヤが操作して遊ぶゲーム処理を想定して説明する。より具体的には、本実施形態では、横スクロール型のアクションゲーム（以下、本ゲームと呼ぶ）を想定して説明する。本ゲームでは、プレイの主な舞台となる、「ステージ」と呼ばれる２次元の仮想空間が用意されている。当該ステージには、スタート地点とゴール地点が設定されている。スタート地点からゴール地点までの間には、様々な敵キャラクタや障害物、ジャンプ台や落とし穴等の各種ギミックが配置されている。そして、本ゲームは、これら敵キャラクタ等を倒したり回避したりしながら、プレイヤキャラをゴール地点に到達させるゲームである。なお、当該ステージは、ゲームによっては「コース」や「ラウンド」等と呼ばれることもある。また、本実施形態では、ゲーム画面が２Ｄ画面で表示されるゲームを例示するが、他の実施形態では、上記仮想空間は３次元の仮想空間であり、１人称視点や３人称視点等の３Ｄ画面で表示されるゲームであってもよい。
次に、本実施形態に係る情報処理の概要を説明する。本実施形態では、情報処理の一例として、仮想空間内に存在するプレイヤキャラクタオブジェクト（以下、プレイヤキャラと呼ぶ）をプレイヤが操作して遊ぶゲーム処理を想定して説明する。より具体的には、本実施形態では、横スクロール型のアクションゲーム（以下、本ゲームと呼ぶ）を想定して説明する。本ゲームでは、プレイの主な舞台となる、「ステージ」と呼ばれる２次元の仮想空間が用意されている。当該ステージには、スタート地点とゴール地点が設定されている。スタート地点からゴール地点までの間には、様々な敵キャラクタや障害物、ジャンプ台や落とし穴等の各種ギミックが配置されている。そして、本ゲームは、これら敵キャラクタ等を倒したり回避したりしながら、プレイヤキャラをゴール地点に到達させるゲームである。なお、当該ステージは、ゲームによっては「コース」や「ラウンド」等と呼ばれることもある。また、本実施形態では、ゲーム画面が２Ｄ画面で表示されるゲームを例示するが、他の実施形態では、上記仮想空間は３次元の仮想空間であり、１人称視点や３人称視点等の３Ｄ画面で表示されるゲームであってもよい。
【0033】
図４に、上記ステージをプレイ中のゲーム画面（以下、ステージ画面と呼ぶ）の一例を示す。図４の例は、スタート地点付近の画面、すなわち、当該ステージのプレイを開始した直後の画面例である。図４では、プレイヤキャラ２０１と、敵キャラクタ２０２が表示されている。その他、ブロック等の各種地形オブジェクトも表示されている。なお、本ステージでは、ステージの左端付近にスタート地点が設定され、ステージの右端付近にゴール地点が設定されているものとする。そのため、全体的なゲーム進行として、プレイヤキャラ２０１を画面の右方向に向けて進ませていくようなステージ構成となっている。このようなステージ画面において、プレイヤは、プレイヤキャラ２０１を操作して、ゴール地点に向けて移動させていく。プレイヤキャラの移動にあわせて、ステージの別の場所がステージ画面として表示されることになる。そして、プレイヤキャラがゴール地点に到達すれば、当該ステージをクリアしたことになる。
【0034】
また、上記ステージには、スタート地点とゴール地点の略中間となる位置に「中間地点」が設定されている。当該中間地点には、中間地点であることを示す中間地点オブジェクトが配置されている。プレイヤキャラが当該中間地点オブジェクトに接触すると、それ以降、ゴールするまでの間のプレイにおいてリスタートすることになった場合、当該中間地点からリスタートできるようになる。なお、中間地点到達前は、スタート地点からリスタートする。なお、中間地点として設定する位置については、スタート地点からゴール地点までの略中間となる位置に限らず、スタート地点からゴール地点までの途中の位置であれば、所定の位置を中間地点として設定してもよい。
【0035】
［オンラインプレイ要素について］
本ゲームの基本的なゲーム進行の流れは上述の通りであり、基本的にはシングルプレイの感覚でゲームがプレイできる。更に、本ゲームでは、マルチプレイも可能である。一例として、本ゲームは、インターネット経由で上記サーバや他のゲーム装置３と接続して他のプレイヤとプレイすることが可能なオンラインプレイ要素も有する。
本ゲームの基本的なゲーム進行の流れは上述の通りであり、基本的にはシングルプレイの感覚でゲームがプレイできる。更に、本ゲームでは、マルチプレイも可能である。一例として、本ゲームは、インターネット経由で上記サーバや他のゲーム装置３と接続して他のプレイヤとプレイすることが可能なオンラインプレイ要素も有する。
【0036】
以下、本ゲームのオンラインプレイ要素に関して説明する。まず、全体的なネットワーク的な構成に関して簡単に説明する。基本的なネットワーク構成については、上記図１で示したような構成となる。そして、本ゲームでは、いわゆるＭＯ（Multiplayer Online）タイプのオンラインゲームにおける通信グループの構成を利用したゲームを提供する。具体的には、各ステージに対応する通信グループ（以下、ステージ部屋と呼ぶ）とが適宜生成および管理され得る。換言すれば、各ステージに相当する仮想空間が用意され、当該仮想空間に、上記ゲームサーバ１によってマッチングされた所定人数のプレイヤが接続するという形態である。また、同じステージについて、複数のステージ部屋が並列に存在し得る。
【0037】
また、ステージ部屋には入室可能な人数の最大値が設けられている。一例として、本ゲームでは、ステージ部屋は１部屋に４人まで入室可能であるとする。また、本ゲームでは、一例として、同じステージ部屋のゲーム装置３は、Ｐ２Ｐ（Peer to peer）の通信方式で接続されるものとする。他の実施形態では、サーバ経由の通信方式を用いてもよい。
【0038】
図５は、他のプレイヤが既に入室しているステージ部屋にプレイヤが入室した場合の、当該プレイヤのゲーム装置３から出力されるステージ画面の一例である。図５では、他のプレイヤが操作する他のプレイヤキャラ２０３が、プレイヤが操作するゲーム装置３におけるステージ画面上に表示されている。他のプレイヤはプレイヤよりも先に入室し、ステージプレイを開始しているため、当該他のプレイヤキャラ２０３は、スタート地点よりはゴール地点に向けて少し先に進んだ位置にいる。また、図５において、当該他のプレイヤキャラ２０３は、半透明で表示されているものとする（図面では点線で示している）。
【0039】
なお、本ゲームでは、プレイヤキャラとして使用できるキャラクタが複数種類用意されている。例えば、各プレイヤは、１２種類の異なるキャラクタの中からいずれかを、自分が使用するプレイヤキャラとして選択できる。そのため、上記他のプレイヤキャラ２０３は、他のプレイヤが選択したキャラクタが表示され、プレイヤキャラ２０１とは異なるキャラクタが表示され得る。
【0040】
ここで、以下の説明では、同じステージ部屋に入室した他のプレイヤのことを「リモートプレイヤ」と呼び、リモートプレイヤが操作する上記他のプレイヤキャラ２０３のことを「リモートキャラ」と呼ぶ。また、詳細は後述するが、リモートプレイヤに関するプレイヤキャラとして、「リプレイゴースト」というものもステージ画面に出現し得る。また、以下では、プレイヤキャラ、リモートキャラ、リプレイゴーストのことを総称して、「プレイヤアクター」と呼ぶこともある。本ゲームでは、１部屋に４人まで入室可能なので、１部屋に最大で４体のプレイヤアクターが同時に存在し得ることになる。
【0041】
［リモートキャラについて］
次に、上記リモートキャラに関してより詳しく説明する。本ゲームでは、ステージ部屋で表示されるリモートキャラは、他のプレイヤの操作が反映されて移動はするが、プレイヤのゲーム装置３で実行されているゲームプレイには直接的には干渉せず、影響は与えない。具体的には、あるステージ部屋に接続しているゲーム装置３同士の間では、基本的には、各自のプレイヤキャラの位置情報、および、各プレイヤキャラが生成した所定のオブジェクトの位置情報について共有される。プレイヤキャラが生成した所定のオブジェクトの例としては、後述する「パネル」がある。一方、敵キャラクタ等のその他のオブジェクトの状態や位置情報等は共有されない。例えば、各ゲーム装置３において、ステージプレイにおけるステージオブジェクト等との衝突判定処理については、各ゲーム装置におけるプレイヤキャラ２０１についてのみ行われ、原則的には、リモートキャラについての衝突判定処理は行われない。そのため、プレイヤキャラ２０１がリモートキャラの位置と重なっても、衝突せずにすり抜けて移動するような結果となる（但し、後述する特殊キャラに対しては例外的に衝突判定が行われる）。また、リモートキャラが敵キャラクタと重なった場合も、リモートキャラと敵キャラクタとの衝突判定等は行われず、敵キャラクタがリモートキャラをすり抜けて移動するような結果となる。また、例えば、プレイヤキャラ２０１が敵キャラクタＡを倒した場合も、この敵キャラクタＡの状態が他のゲーム装置３に反映されることはない。他のゲーム装置３において、当該他のゲーム装置の他のプレイヤが当該敵キャラクタＡを倒していなければ、当該敵キャラクタＡは依然として存在している状態で制御される。つまり、ステージプレイの進行管理自体は、各自のゲーム装置上で個別に行われ、この際に、リモートキャラがいる場合は、その表示だけは行う、というような制御となる。また、干渉しない存在であることをわかりやすくするため、リモートキャラは、基本的には、半透明の態様で表示される。そのため、各プレイヤは、基本的には、他のプレイヤの行動の影響を受けることなく、また、他のプレイヤの行動を阻害等することなく、シングルプレイと同様の感覚でステージをプレイできる。換言すれば、１人でゲームを進めつつ、リモートキャラ、換言すれば、他のプレイヤの存在は認識できる、というプレイ感・ゲーム体験が得られる。
次に、上記リモートキャラに関してより詳しく説明する。本ゲームでは、ステージ部屋で表示されるリモートキャラは、他のプレイヤの操作が反映されて移動はするが、プレイヤのゲーム装置３で実行されているゲームプレイには直接的には干渉せず、影響は与えない。具体的には、あるステージ部屋に接続しているゲーム装置３同士の間では、基本的には、各自のプレイヤキャラの位置情報、および、各プレイヤキャラが生成した所定のオブジェクトの位置情報について共有される。プレイヤキャラが生成した所定のオブジェクトの例としては、後述する「パネル」がある。一方、敵キャラクタ等のその他のオブジェクトの状態や位置情報等は共有されない。例えば、各ゲーム装置３において、ステージプレイにおけるステージオブジェクト等との衝突判定処理については、各ゲーム装置におけるプレイヤキャラ２０１についてのみ行われ、原則的には、リモートキャラについての衝突判定処理は行われない。そのため、プレイヤキャラ２０１がリモートキャラの位置と重なっても、衝突せずにすり抜けて移動するような結果となる（但し、後述する特殊キャラに対しては例外的に衝突判定が行われる）。また、リモートキャラが敵キャラクタと重なった場合も、リモートキャラと敵キャラクタとの衝突判定等は行われず、敵キャラクタがリモートキャラをすり抜けて移動するような結果となる。また、例えば、プレイヤキャラ２０１が敵キャラクタＡを倒した場合も、この敵キャラクタＡの状態が他のゲーム装置３に反映されることはない。他のゲーム装置３において、当該他のゲーム装置の他のプレイヤが当該敵キャラクタＡを倒していなければ、当該敵キャラクタＡは依然として存在している状態で制御される。つまり、ステージプレイの進行管理自体は、各自のゲーム装置上で個別に行われ、この際に、リモートキャラがいる場合は、その表示だけは行う、というような制御となる。また、干渉しない存在であることをわかりやすくするため、リモートキャラは、基本的には、半透明の態様で表示される。そのため、各プレイヤは、基本的には、他のプレイヤの行動の影響を受けることなく、また、他のプレイヤの行動を阻害等することなく、シングルプレイと同様の感覚でステージをプレイできる。換言すれば、１人でゲームを進めつつ、リモートキャラ、換言すれば、他のプレイヤの存在は認識できる、というプレイ感・ゲーム体験が得られる。
【0042】
また、上記のように、各プレイヤは他のプレイヤからの影響を受けずに個別にゲームを進行できる。そのため、４人のプレイヤが揃わないとステージプレイが開始できないというものではなく、ステージ部屋内にいるプレイヤが１人だけの場合でも、ステージプレイは開始できる。その後、途中参加のような形で、最大４人までは、他プレイヤが入室可能である。例えば、プレイヤＡが、ステージの３分の１程度まで進んだ時点で、プレイヤＢが入室した場合、プレイヤＢのプレイヤキャラはスタート地点から移動を開始することになる。つまり、プレイヤＢからすれば、プレイヤＡのプレイヤキャラがある程度先に進んだ位置に存在している状態で、ステージプレイを開始することになる。また、プレイヤＡからすれば、プレイヤＢの入室によって自身のプレイが阻害されるということもなく、引き続きプレイを継続できる。
【0043】
［リプレイゴーストについて］
次に、上記リプレイゴーストについて説明する。リプレイゴーストとは、他のプレイヤのリプレイデータをゴーストとして再生するものである。本実施形態では、上記中間地点からゴール地点までの間のプレイをリプレイデータとして、上記ゲームサーバ１に保存しておく。そして、ゲームステージのプレイが一定の進行度に到達している場合に、リプレイゴーストを出現させる。より具体的には、ステージ部屋に入室しているのがプレイヤ１人のみの状態で中間地点まで進んだ場合、つまり、中間地点まで他のプレイヤとのマッチングが発生することなく進んだ場合、上記ゲームサーバ１からリプレイデータをダウンロードして、再生する。これにより、リプレイデータに基づく他のプレイヤキャラクタがゴーストとして表示され得る。これが、リプレイゴーストである。また、当該リプレイゴーストは、リプレイを再生するため、結果的に、上記リモートキャラと同様にふるまう。これにより、中間地点まで他のプレイヤが入室して来なかった場合、他プレイヤのゴーストと一緒にプレイするという状況を作り出すことができる。そのため、ステージによっては、他のプレイヤとのマッチングが中々発生しないことで、オンラインで遊んでいる意義が薄いとプレイヤに感じさせてしまうことを抑制できる。
次に、上記リプレイゴーストについて説明する。リプレイゴーストとは、他のプレイヤのリプレイデータをゴーストとして再生するものである。本実施形態では、上記中間地点からゴール地点までの間のプレイをリプレイデータとして、上記ゲームサーバ１に保存しておく。そして、ゲームステージのプレイが一定の進行度に到達している場合に、リプレイゴーストを出現させる。より具体的には、ステージ部屋に入室しているのがプレイヤ１人のみの状態で中間地点まで進んだ場合、つまり、中間地点まで他のプレイヤとのマッチングが発生することなく進んだ場合、上記ゲームサーバ１からリプレイデータをダウンロードして、再生する。これにより、リプレイデータに基づく他のプレイヤキャラクタがゴーストとして表示され得る。これが、リプレイゴーストである。また、当該リプレイゴーストは、リプレイを再生するため、結果的に、上記リモートキャラと同様にふるまう。これにより、中間地点まで他のプレイヤが入室して来なかった場合、他プレイヤのゴーストと一緒にプレイするという状況を作り出すことができる。そのため、ステージによっては、他のプレイヤとのマッチングが中々発生しないことで、オンラインで遊んでいる意義が薄いとプレイヤに感じさせてしまうことを抑制できる。
【0044】
ここで、上記リプレイゴーストは、基本的には、その見た目は上記リモートキャラと見分けがつかない。例えば、図６に、リプレイゴーストが表示されている画面例を示す。図６では、３体のリプレイゴーストが表示されている、これらは、上記リモートキャラと同様に、半透明で表示されている。また、その見た目も、リモートキャラとは変わらないものとなっている。そして、上記リモートキャラについては、生身の人間が操作していることから、例えば、感情を示す顔画像等のエモート表示を行う操作が可能である。そのため、各ゲーム装置３で個別にプレイ管理しているとは言え、このような操作によって、プレイヤ同士である程度のコミュニケーションは取れる。一方、リプレイゴーストについては、このようなコミュニケーションは取れない。そのため、リモートキャラとリプレイゴーストとの区別がつくようにしておいてもよい。例えば、リモートキャラに近づくと、それがリモートキャラであることが分かるような標識画像、例えばプレイヤ名等を表示してもよい。一方、リプレイゴーストについては、近づいてもこのような標識画像を表示しないようにしてもよい。これにより、当該標識画像の有無によって、プレイヤは、リモートキャラであるかリプレイゴーストであるかを判別できる。
【0045】
なお、本実施形態において、より正確には、上記中間地点オブジェクトにプレイヤキャラ２０１が接触した場合に、リプレイゴーストを出現させる。これは、中間地点を通過したことをきっかけとしてリプレイゴーストが出現するということがプレイヤにわかりやすいためである。また、本例では、プレイの進行度として、中間地点を通過した場合を例に説明するが、他の実施形態では、例えば、ステージプレイ開始からの経過時間やステージ内イベントの達成度に基づいて、上記リプレイゴーストを出現させるトリガーとする進行度を判定してもよい。
【0046】
以下、リプレイゴーストについて、より詳細に説明する。
【0047】
［リプレイの記録について］
まず、リプレイデータの記録に関して説明する。本実施形態では、プレイヤキャラ２０１が上記中間地点オブジェジェクトに接触する（以下ではこのことを「中間地点を通過する」と表現することもある）ことで、リプレイデータの記録が開始される。そして、プレイヤキャラ２０１がゴール地点に到達することで、当該記録が停止される。その後、ステージのクリア処理に伴って、リプレイデータが上記ゲームサーバ１に送信される。
まず、リプレイデータの記録に関して説明する。本実施形態では、プレイヤキャラ２０１が上記中間地点オブジェジェクトに接触する（以下ではこのことを「中間地点を通過する」と表現することもある）ことで、リプレイデータの記録が開始される。そして、プレイヤキャラ２０１がゴール地点に到達することで、当該記録が停止される。その後、ステージのクリア処理に伴って、リプレイデータが上記ゲームサーバ１に送信される。
【0048】
なお、中間地点オブジェクトへの接触と、ゴール地点の到達をリプレイデータの記録開始および停止のタイミングとするのは、プレイヤキャラ２０１の自然な行動で記録の開始、停止ができるからである。また、リプレイデータの記録制御のための専用のオブジェクトを別途配置しなくてもよい、等の理由によるものである。
【0049】
また、中間地点の通過後ゴールするまでの間に、「ミスイベント」が発生した場合も、その時点でリプレイデータの記録は一旦停止する。当該ミスイベントについては後述するが、例えばプレイヤキャラ２０１が敵キャラクタに倒された場合等である。また、ミスイベントが発生した場合、所定の条件が揃うと、プレイが一旦中断され、プレイヤキャラ２０１の残数（いわゆる残機）が減らされた上で、中間地点からリスタートする。この場合、基本的には、リスタート前のリプレイデータが破棄され、リスタートした時点から、改めてリプレイデータの記録が開始される。但し、本実施形態では、この際、一定の確率で、リスタート前のリプレイデータは破棄せずに保持しておき、リスタートした時点からのリプレイデータの記録を行わないようにする。上記のように、ゴールすることでリプレイデータがサーバに送信されるが、上記のような制御により、プレイの途中でリスタートが発生していた場合、次のような２種類のリプレイデータが送信され得る。１つめは、ゴールまで到達した内容のリプレイデータ、すなわち、ステージをクリアした内容のリプレイデータである。そして、２つめは、途中でミスイベントが発生した内容のリプレイデータ、すなわち、ステージがクリアできなかったリプレイデータである。これにより、リプレイデータの内容を多様なものとすることができる。
【0050】
また、本実施形態では、中間地点が１つだけ設定されている場合を想定して説明するが、中間地点が２つ以上設定されているステージがあってもよい。この場合は、最初に通過した中間地点から記録が開始される。また、途中でミスイベントが発生した場合は、最後に通過した中間地点からリスタートする。そして、リスタートに係るリプレイデータの記録については、この最後に通過した中間地点から改めて記録を開始する。
【0051】
［リプレイのダウンロードおよび再生について］
次に、リプレイデータのダウンロード、および、再生に関して説明する。上記のようにしてゲームサーバ１にリプレイデータが送信されるが、本実施形態では、ゲームサーバ１において、上記中間地点オブジェクト（上記ステージ）毎に上記リプレイデータが紐付けられて管理される。より具体的には、ゲームサーバ１において、ステージ毎に、直近３０件分のリプレイデータが保持されている。
次に、リプレイデータのダウンロード、および、再生に関して説明する。上記のようにしてゲームサーバ１にリプレイデータが送信されるが、本実施形態では、ゲームサーバ１において、上記中間地点オブジェクト（上記ステージ）毎に上記リプレイデータが紐付けられて管理される。より具体的には、ゲームサーバ１において、ステージ毎に、直近３０件分のリプレイデータが保持されている。
【0052】
そして、プレイヤキャラ２０１が中間地点を通過したタイミングで、ゲーム装置３からゲームサーバ１にリプレイデータのリクエストが送信される。ゲームサーバ１からは、そのステージに対応した直近３０件分のリプレイデータが送られてくるので、ゲーム装置３でこれが受信される。ゲーム装置３では、受信した３０件分のデータの中から、ランダムで、最大３件まで（ステージ部屋の定員が４人の例のため）、リプレイゴーストとして用いるリプレイデータを選出する。この際、リプレイデータの送信元が、上記リクエストを送ったプレイヤと同じであるリプレイデータについては、選出対象から除外する。つまり、自分のリプレイデータは選出されないようにする。
【0053】
そして、選出されたリプレイデータをリプレイゴーストとして再生開始する。この際、複数体のリプレイゴーストを使う場合は、再生開始タイミングを数秒毎にばらけさせるようにする。例えば、３体のリプレイゴーストを使う場合、３体同時に生成して出現させるのではなく、２体目は１体目のリプレイゴーストを出現させてから５秒後、３体目は２体目の出現から更に５秒後に出現させる、等である。
【0054】
また、リプレイデータをダウンロードして再生を開始する際に、もしリモートキャラが存在していた場合は、リプレイは再生しない。例えば、中間地点通過とほぼ同じタイミングで、他のプレイヤが入室してきた場合等である。これは、リモートキャラが存在するのであれば、リモートキャラとコミュニケーションを取ってもらいたい、という観点によるものである。
【0055】
また、ミスイベントの発生により、中間地点からリスタートする場合は、再度、リプレイデータのダウンロードからやり直す。そのため、リスタートした場合は、リスタート前と後とで、異なるリプレイゴーストが出現し得る。但し、前回のダウンロード完了から所定時間以上経過していない場合は、ダウンロード済みのデータを流用してもよい。もちろん、経過時間に関わらず毎回ダウンロードしなおしてもよいし、逆に、経過時間に関わらず、最初にダウンロードしたデータを流用するようにしてもよい。
【0056】
［リプレイゴーストの個数、同期について］
次に、リプレイゴーストの個数管理と他のゲーム装置３との同期に関して説明する。
上記のように、本ゲームでは、各自のゲーム装置で個別にゲームの進行管理が行われ、共有する情報は、基本的には、各自のプレイヤキャラの位置情報のみとなっている。そして、リプレイゴーストについても、他のゲーム装置３との同期は行わず、各ゲーム装置３においてローカルで管理される。ここで、既にリプレイゴーストが出現している状況で、他のプレイヤが入室してきた場合を想定する。この場合、ステージ内の上記プレイヤアクターが４体以下になるような調整が行われる。例えば、プレイヤＡが３体のリプレイゴーストとプレイしている状況で、プレイヤＢが入室してきた場合を想定する。この場合、プレイヤＡのゲーム装置３では、次のような処理が行われる。まず、プレイヤキャラ２０１の現在位置から最も遠くの位置にいるリプレイゴーストが消去される。これにより、プレイヤアクターの枠が１枠空く。次に、プレイヤＢに係るリモートキャラが生成され、ステージ内に出現させる。この際、当該リモートキャラと同じキャラクタのリプレイゴーストがいる場合、このリプレイゴーストも消去する。そのため、この例の場合は、新規入室人数が１人に対して、２体のリプレイゴーストが消去されることもあり得る。この場合は、プレイヤアクターの総数が３体の状態となる。
次に、リプレイゴーストの個数管理と他のゲーム装置３との同期に関して説明する。
上記のように、本ゲームでは、各自のゲーム装置で個別にゲームの進行管理が行われ、共有する情報は、基本的には、各自のプレイヤキャラの位置情報のみとなっている。そして、リプレイゴーストについても、他のゲーム装置３との同期は行わず、各ゲーム装置３においてローカルで管理される。ここで、既にリプレイゴーストが出現している状況で、他のプレイヤが入室してきた場合を想定する。この場合、ステージ内の上記プレイヤアクターが４体以下になるような調整が行われる。例えば、プレイヤＡが３体のリプレイゴーストとプレイしている状況で、プレイヤＢが入室してきた場合を想定する。この場合、プレイヤＡのゲーム装置３では、次のような処理が行われる。まず、プレイヤキャラ２０１の現在位置から最も遠くの位置にいるリプレイゴーストが消去される。これにより、プレイヤアクターの枠が１枠空く。次に、プレイヤＢに係るリモートキャラが生成され、ステージ内に出現させる。この際、当該リモートキャラと同じキャラクタのリプレイゴーストがいる場合、このリプレイゴーストも消去する。そのため、この例の場合は、新規入室人数が１人に対して、２体のリプレイゴーストが消去されることもあり得る。この場合は、プレイヤアクターの総数が３体の状態となる。
【0057】
一方、プレイヤＢのゲーム装置３におけるゲーム処理では、リプレイゴーストは存在せずに、リモートキャラとしてプレイヤＡのプレイヤキャラ２０１がステージ内に存在しているとして、ゲーム進行が管理されることになる。
【0058】
［協力要素について］
上記のように、基本的には、各プレイヤは他のプレイヤからの影響を受けずに個別にゲームを進行できる。但し、本ゲームでは、以下の点で、協力プレイ的な要素を持たせている。具体的には、本ゲームでは、ミスしたプレイヤを助けることができる「復活補助」という機能によって、他プレイヤとの間で影響を及ぼすことが可能である。
上記のように、基本的には、各プレイヤは他のプレイヤからの影響を受けずに個別にゲームを進行できる。但し、本ゲームでは、以下の点で、協力プレイ的な要素を持たせている。具体的には、本ゲームでは、ミスしたプレイヤを助けることができる「復活補助」という機能によって、他プレイヤとの間で影響を及ぼすことが可能である。
【0059】
以下、復活補助の具体例を説明する。まず、プレイヤキャラ２０１について、ミスイベントが発生した場合を想定する。当該ミスイベントとは、本実施形態では、プレイヤキャラの残数が減る（残機を失う）ことになるようなゲーム内イベントである。具体的には、例えば図７に示すように、プレイヤキャラ２０１が敵キャラクタ２０２と接触する等した場合であり、オフラインでシングルプレイをしていると仮定した場合は、現在使用しているプレイヤキャラ２０１によるプレイが一旦終了し、プレイヤキャラ２０１の残数が１体減る（以下、このことを「ロスト」と呼ぶ）ようなゲーム内イベントである。そして、ロストした後、所定の地点からリスタートする、あるいは、そのままゲームオーバーになることに繋がるようなゲーム内イベントである。ミスイベントの他の例としては、例えばＨＰやライフが０となって、ロストとなるような場合、落とし穴に落ちる等でステージ外に出てしまった場合、等がある。なお、ダメージを受けてもまだＨＰやライフが残っている等の場合は、まだロストは発生しないため、ここでいうミスイベントには該当しないものとする（単なる被ダメージとして扱う）。
【0060】
本ゲームでは、オフラインのシングルプレイの場合は、上記ミスイベントの発生は上記のようなロストに直結するが、オンラインに接続した状態でプレイしている場合は、ミスイベントが発生しても、所定の条件を満たしている場合は、すぐにはロストとはならない。本実施形態では、当該所定の条件は、プレイヤキャラ２０１から所定範囲内に、後述する「復活補助オブジェクト」が存在していることである。当該所定の条件を満たしていれば、所定時間の間、プレイヤキャラ２０１が、図８に示すような、見た目が異なるキャラクタオブジェクトに変化する。以下、当該変化したキャラクタオブジェクトのことを「特殊キャラ」と呼ぶ。また、特殊キャラに変化しているプレイヤキャラ２０１の状態のことを「特殊状態」と呼び、この変化が発生していないプレイヤキャラ２０１の状態のことを「通常状態」と呼ぶ。なお、特殊状態の間は、リモートキャラ２０３は半透明ではなく不透明の態様で表示されるが、この点については後述する。
【0061】
上記特殊キャラについては、復活補助オブジェクト以外のオブジェクトとの衝突判定が行われない。そのため、特殊キャラは、敵キャラクタ等からダメージを受けることがなく、また、敵キャラクタ２０２や地形オブジェクトをすり抜けて移動できる。また、特殊キャラである間は、仮想空間内の重力にとらわれずに空中移動が可能となる。つまり、プレイヤは、特殊キャラについては衝突判定を気にせずに自由に移動させることが可能となる。例えば、復活補助オブジェクトを目指して一直線に特殊キャラを移動させるようなことも可能となる。但し、特殊キャラの状態では、ゴール地点に到達してもゴールしたとはみなされず、ステージクリアもできない。
【0062】
なお、上記特殊キャラに関して、他の実施形態では、復活補助オブジェクト以外のオブジェクトとも衝突判定が行われるようにしてもよい。また、移動制御に関しても、仮想空間内の重力の影響を受けた移動制御を行ってもよい。
【0063】
プレイヤキャラ２０１が特殊キャラに変化した後、図９に示すように上記復活補助オブジェクト（ここでは、リモートキャラ２０３）に向けて特殊キャラを移動させたとする。その結果、所定時間が経過する前に、図１０に示すように、リモートキャラ２０３の位置と当該特殊キャラの位置とが重なったとする。つまり、復活補助オブジェクトと特殊キャラとが接触したとする。すると、図１１に示すように、プレイヤキャラ２０１のロストを発生させずに、プレイヤキャラ２０１を通常状態に戻すことができる。すなわち、ミスイベントが発生したプレイヤキャラ２０１をロストさせることなく「復活」させることが可能である。以下の説明では、上記所定時間のことを「復活可能時間」と呼ぶ。なお、特殊キャラと復活補助オブジェクトとを接触させることに限らず、近接あるいは隣接させることで復活させてもよい。
【0064】
一方、ミスイベントが発生した際に、上記所定範囲内に復活補助オブジェクトが存在していない場合は、特殊状態への変化は発生せずに上記ロストが確定し、その結果、リスタートまたはゲームオーバーとなる。
【0065】
また、本実施形態では、プレイヤキャラが特殊キャラに変化している間は、復活補助オブジェクトを除いて、ゲーム画面がモノクロ化して表示する。すなわち、地形オブジェクトや敵キャラクタ等の彩度を低くして表示される。
【0066】
なお、上記所定範囲は、例えば、通常状態のプレイヤキャラ２０１が上記復活可能時間だけ移動したとして、復活補助オブジェクトの位置に到達または近接できることを想定した距離の上限値と同じか、またはこれより短い距離となる範囲である。つまり、ミスイベントが発生した位置から見て、復活可能時間内に特殊状態から通常状態への復活が間に合う程度の範囲を想定したものである。
【0067】
そのため、例えば、プレイヤキャラ２０１およびリモートキャラ同士である程度固まって移動するようにすれば、シングルプレイ感覚でプレイしつつも、ミスイベント発生時のリカバリが容易になる。つまり、オフラインでのシングルプレイゲームの場合にはない、オンラインを活かした利点が得られる。また、特殊状態となるのは、シングルプレイをしている場合であれば「ミスイベント」～「ロスト」扱いとなってプレイが中断するような状況であるところ、オンラインであれば、このような中断も発生せず、プレイヤのプレイを阻害することにもならない。このような協力プレイ要素を持たせることで、特定の局面で他プレイヤと協力する余地ができる。これにより、基本的にはシングルプレイとしてゲームを進行させつつ、マッチングによってステージ部屋に複数のプレイヤが入室していれば、他のプレイヤと協力しやすくなる、という状況を生み出すことができる。
【0068】
また、上記のような所定範囲を設けることで、プレイヤキャラ２０１が特殊状態になった場合に、遠くにいるリモートキャラ等に助けを求めて、大きな距離を移動するという状況の発生を抑制できる。例えば、ある程度ステージを進んでいたにも関わらず、リモートキャラがいるスタート地点付近まで戻るとすると、ゲームを進めるテンポが悪くなってしまう。また、逆に、自分より先に進んでいるリモートキャラの位置まで、途中のステージの各種ギミックを飛ばして移動可能とすると、ゲームの興趣性が失われる。このような状況を防ぐために、上記のように所定範囲内に所定範囲内に復活補助オブジェクトが存在しているときのみ、特殊状態へ移行させている。
【0069】
図１２に、上記のような通常状態、特殊状態、およびロストの状態遷移の関係をまとめた図を示す。図１２において、まず、通常状態のときにミスイベントが発生すると、所定範囲内に復活補助オブジェクトがいるかどうかが判定される。そして、いる場合は、特殊状態に変化する。特殊状態において、復活補助オブジェクトの位置に移動できれば、通常状態に復活することになる。一方、所定範囲内に復活補助オブジェクトがいない場合は、ロストとなる。この場合は、プレイヤキャラ２０１の残数が残っていれば、残数を１つ減らした上で、通常状態となって、所定のリスタート地点からプレイがリスタートする。プレイヤキャラ２０１の残数が残っていなければ、ゲームオーバーとなり、ステージ部屋から退室させられる。
【0070】
なお、本実施形態では、上記復活可能時間は、特殊状態に変化した回数に応じて変化し得る。具体的には、１回分のプレイ（例えばプレイ開始からプレイヤキャラ２０１を１体ロストするまでの間）において、特殊状態に変化する回数が多くなるほど、上記復活可能時間が段階的に短くなっていく。例えば、上記復活可能時間として、１０カウントを行う場合を想定する。そして、最初に特殊状態に変化したときは、当該１０カウントについて２秒間隔でカウントする（復活可能時間＝２０秒）。その後、復活し、再度特殊状態に変化した場合は、１．５秒間隔でカウントする（復活可能時間＝１５秒）。更に、３度目に特殊状態に変化した場合は１秒間隔でカウントし（復活可能時間＝１０秒）、４度目に特殊状態に変化した場合は０．５秒間隔でカウントする（復活可能時間＝５秒）。そして、カウントする間隔がある程度短くなれば、それ以上は短くしないようにする。例えば、０．５秒間隔を下限値とする、等である。これにより、プレイヤが何度もミスイベントを発生させていると、徐々に復活しにくくなるため、ゲームプレイにある程度緊張感をもたせることができる。
【0071】
ここで、上記復活機能によって復活するときの復活位置に関して補足する。ここでは、特殊状態になったほうのゲーム装置３における処理を基準に考える。すなわち、特殊キャラを操作しているほうのゲーム画面を基準に考える。まず、特殊キャラと復活対象オブジェクトとが、共に地形外にいる場合を想定する。この場合、両者の位置が重なれば、重なった位置でプレイヤキャラ２０１が復活する。次に、図１３に示すような、特殊キャラが地形内に位置しており、復活対象オブジェクト、図１３ではリモートキャラ２０３が地形外にいる場合を想定する。上記のように、特殊キャラの間は地形オブジェクト等との衝突判定がないため、このような状況も発生し得る。この場合は、図１４に示すように、リモートキャラのいる位置に、プレイヤキャラ２０１が復活する。
【0072】
次に、図１５に示すように、特殊キャラが地形外、復活対象オブジェクト（リモートキャラ２０３）が地形内にいる場合を想定する。これは、次のような場合に起こり得る。上記のように、本ゲームは、ゲーム進行管理自体は各自のゲーム装置で行われる。そして、例えば破壊可能な地形オブジェクトがあった場合、例えば、プレイヤＡのゲームプレイ上ではまだ破壊されていないが、プレイヤＢのゲームプレイ上では破壊されている、という状況があり得る。例えば図１５の特殊キャラのプレイヤがプレイヤＡとして、リモートキャラ２０３のプレイヤがプレイヤＢであるとする。この場合、上記図１５の状況に対応する、上記プレイヤＢが見ているゲーム画面は、図１６のようなゲーム画面となる。プレイヤＢのゲーム画面では、地形オブジェクトは破壊済みであり、その跡地にプレイヤＢのプレイヤキャラ２０１がいる状態である。また、上記のようにリモートキャラは、位置情報を共有するだけで、プレイヤＡのゲーム装置３においては、地形との衝突判定は行われない。そのため、プレイヤＡから見た場合は、上記図１５のような画面になり得る。そして、この状態でプレイヤＢがリモートキャラを特殊キャラに向けてジャンプさせた場合を想定する。その結果、図１７に示すように、リモートキャラと特殊キャラとが接触したような状態となる。この場合は、図１８に示すように、プレイヤキャラ２０１は、その場で復活する。
【0073】
次に、特殊キャラのプレイヤの画面において、図１９に示すように、特殊キャラと復活対象オブジェクトとが共に地形内に位置しているような場合を想定する。そして、地形内で両者の位置が重なったとする。この場合、双方とも地形内にいるため、いずれの位置も復活位置としては利用できない。そのため、上記復活位置として利用可能な地点が探索される。本実施形態では、当該復活位置として利用可能な地点は、「地形外（地形オブジェクトの外の空間）となる位置」であり、かつ、「通常状態に戻したプレイヤキャラが配置できるスペースが確保されている位置」である。例えば、通常状態に戻したプレイヤキャラが小さいサイズのプレイヤキャラであれば配置可能であるが、大きいサイズのプレイヤキャラの場合はスペースが足りていないような、障害物の隙間になる位置を想定する。この場合、当該位置は、小さいサイズのプレイヤキャラの場合は復活位置として決定され得るが、大きいサイズのプレイヤキャラの場合は、復活位置としては決定されないことになる。
【0074】
上記復活位置の探索に係る動作の具体例を説明する。本実施形態では、まず、特殊キャラを探索用オブジェクト（例えば光の球）に変更する。当該探索用オブジェクトも、特殊キャラ同様、地形オブジェクトとの衝突判定は行われない。次に、図２０に示すように、当該探索用オブジェクトを現在位置から外側に向けて螺旋状の軌道（経路）で移動させていく。この移動の過程で、探索用オブジェクトの位置が上記のような復活位置の条件を満たすか否かを判定する。そして、復活位置の条件を満たす位置として最初に探索された位置が復活位置として決定され、その位置にプレイヤキャラ２０１を復活させる。その結果、例えば、図２１に示すような地形外となる位置でプレイヤキャラ２０１が復活することになる。
【0075】
なお、上記のような復活位置に、敵キャラクタ等の通常状態のプレイヤキャラと衝突するとミスイベントが発生し得るオブジェクトがいる状況の場合は、当該敵キャラクタと衝突しないような位置に復活位置を更にずらすように制御してもよい。つまり、最終的には、地形オブジェクトや敵キャラクタ等の障害物がない位置を復活位置として決定すればよい。
【0076】
［復活補助オブジェクトについて］
次に、上記復活補助オブジェクトについて説明する。本実施形態では、上記復活補助オブジェクトは、以下の３種類のオブジェクトである。
（１）リモートキャラ
（２）リプレイゴースト
（３）パネル
また、上記パネルは更に、「リモートパネル」と「サーバパネル」の２種類に分けられる。以下、それぞれについて説明する。
次に、上記復活補助オブジェクトについて説明する。本実施形態では、上記復活補助オブジェクトは、以下の３種類のオブジェクトである。
（１）リモートキャラ
（２）リプレイゴースト
（３）パネル
また、上記パネルは更に、「リモートパネル」と「サーバパネル」の２種類に分けられる。以下、それぞれについて説明する。
【0077】
［復活補助オブジェクト：リモートキャラ］
まず、リモートキャラについては、上述したものであるため詳細な説明は割愛するが、その表示態様に関して補足する。上記のように、基本的にはリモートキャラが半透明の表示態様で表示される。但し、プレイヤキャラ２０１が特殊キャラに変化している間は、半透明表示ではなく、不透明の態様で表示される。また、リモートキャラが不透明の態様で表示されている間は、リモートキャラと特殊キャラとの衝突判定が行われる状態となる。いわば、特殊状態となっている間は、リモートキャラが実体化しているように見せかける。また、このときのリモートキャラは、上記のようにプレイヤキャラ２０１を復活させるという形で、プレイヤキャラ２０１に直接的に影響を及ぼし得る状態にもなっている。また、上述したように、本実施形態では、プレイヤキャラ２０１が特殊キャラに変化している間は、復活補助オブジェクトを除いてゲーム画面をモノクロ化して表示する。そのため、モノクロ画像の中で、不透明で色彩がついているリモートキャラが表示されることになり、リモートキャラの存在をより目立たせることができる。これにより、プレイヤに、当該リモートキャラと接触すれば何かが起こる、あるいは、復活できる、ということを想起させ、どこに向かえばよいかをプレイヤに視覚的にわかりやすく示すことができる。
まず、リモートキャラについては、上述したものであるため詳細な説明は割愛するが、その表示態様に関して補足する。上記のように、基本的にはリモートキャラが半透明の表示態様で表示される。但し、プレイヤキャラ２０１が特殊キャラに変化している間は、半透明表示ではなく、不透明の態様で表示される。また、リモートキャラが不透明の態様で表示されている間は、リモートキャラと特殊キャラとの衝突判定が行われる状態となる。いわば、特殊状態となっている間は、リモートキャラが実体化しているように見せかける。また、このときのリモートキャラは、上記のようにプレイヤキャラ２０１を復活させるという形で、プレイヤキャラ２０１に直接的に影響を及ぼし得る状態にもなっている。また、上述したように、本実施形態では、プレイヤキャラ２０１が特殊キャラに変化している間は、復活補助オブジェクトを除いてゲーム画面をモノクロ化して表示する。そのため、モノクロ画像の中で、不透明で色彩がついているリモートキャラが表示されることになり、リモートキャラの存在をより目立たせることができる。これにより、プレイヤに、当該リモートキャラと接触すれば何かが起こる、あるいは、復活できる、ということを想起させ、どこに向かえばよいかをプレイヤに視覚的にわかりやすく示すことができる。
【0078】
なお、上記ミスイベントが発生してプレイヤキャラ２０１が特殊キャラに変化する際、最も近くの復活補助オブジェクトから、図２２に示すように、光の玉をプレイヤキャラ２０１に飛ばすような演出を加えてもよい。そして、この光の玉を受けたプレイヤキャラ２０１が特殊キャラに変化するような見せ方をしてもよい。これにより、光の玉を出した復活補助オブジェクトに接触すれば助かるかもしれない、ということをプレイヤに想起させることができる。換言すれば、復活補助オブジェクトと特殊キャラへの変化との因果関係をプレイヤに認識させることができる。
【0079】
［復活補助オブジェクト：リプレイゴースト］
次に、上記リプレイゴーストも、復活補助オブジェクトとして機能する。上記のように、リプレイゴーストはリモートキャラと同様のふるまいをするためである。そのため、復活補助オブジェクトとしてのリプレイゴーストは上記リモートキャラの場合と同様の制御が行われる。従って、ミスイベントの発生時、上記リモートキャラ、またはリプレイゴーストがプレイヤキャラ２０１の所定範囲内にいれば、特殊キャラに変化できることになる。
次に、上記リプレイゴーストも、復活補助オブジェクトとして機能する。上記のように、リプレイゴーストはリモートキャラと同様のふるまいをするためである。そのため、復活補助オブジェクトとしてのリプレイゴーストは上記リモートキャラの場合と同様の制御が行われる。従って、ミスイベントの発生時、上記リモートキャラ、またはリプレイゴーストがプレイヤキャラ２０１の所定範囲内にいれば、特殊キャラに変化できることになる。
【0080】
［パネルについて］
次に、上記パネルの概要を説明する。当該パネルは、プレイヤキャラ２０１が配置でき、また、プレイヤキャラ２０１が接触できるオブジェクトである。また、当該プレイヤがステージ部屋から退室した後も、そのステージ部屋に残り続ける性質のオブジェクトである。例えば、図２３に示すようなゲーム画面でプレイヤがパネル配置操作を行うと、図２４に示すようなパネルを配置できる。当該プレイヤが配置したパネルは、その後ステージ部屋に入室してきた他のプレイヤのゲーム画面にも表示されるものである。逆に言えば、プレイヤのゲーム画面には、他のプレイヤ（リモートキャラ）が配置したパネルが表示され、接触することも可能である。また、当該パネルは、上記復活補助オブジェクトとして機能する。そのため、特殊キャラのときに上記復活可能時間内にパネルに接触することで、プレイヤキャラ２０１を復活させることができる。但し、本実施形態では、自分が配置したパネルについては、特殊キャラは接触できない。つまり、特殊キャラが接触できるパネルは、リモートキャラが配置したパネルであるリモートパネルと、後述のサーバパネルだけとなっている。これは、パネルが上記復活補助オブジェクトとして機能するところ、自分の配置したパネルを復活補助オブジェクトとして扱うと、例えばゲームが簡単になりすぎる等で、ゲームの難易度が適切なバランスにならない可能性があるためである。そのため、本実施形態では、自身が配置したパネルについては接触できない（復活補助オブジェクトとして利用できない）ようにしている。
次に、上記パネルの概要を説明する。当該パネルは、プレイヤキャラ２０１が配置でき、また、プレイヤキャラ２０１が接触できるオブジェクトである。また、当該プレイヤがステージ部屋から退室した後も、そのステージ部屋に残り続ける性質のオブジェクトである。例えば、図２３に示すようなゲーム画面でプレイヤがパネル配置操作を行うと、図２４に示すようなパネルを配置できる。当該プレイヤが配置したパネルは、その後ステージ部屋に入室してきた他のプレイヤのゲーム画面にも表示されるものである。逆に言えば、プレイヤのゲーム画面には、他のプレイヤ（リモートキャラ）が配置したパネルが表示され、接触することも可能である。また、当該パネルは、上記復活補助オブジェクトとして機能する。そのため、特殊キャラのときに上記復活可能時間内にパネルに接触することで、プレイヤキャラ２０１を復活させることができる。但し、本実施形態では、自分が配置したパネルについては、特殊キャラは接触できない。つまり、特殊キャラが接触できるパネルは、リモートキャラが配置したパネルであるリモートパネルと、後述のサーバパネルだけとなっている。これは、パネルが上記復活補助オブジェクトとして機能するところ、自分の配置したパネルを復活補助オブジェクトとして扱うと、例えばゲームが簡単になりすぎる等で、ゲームの難易度が適切なバランスにならない可能性があるためである。そのため、本実施形態では、自身が配置したパネルについては接触できない（復活補助オブジェクトとして利用できない）ようにしている。
【0081】
なお、本実施形態では。プレイヤキャラ２０１がパネルを配置できる場所については、足場があるところに限られ、例えば空中にパネルを配置することはできないものとする。
【0082】
また、上記のパネルのようなデザインは一例であり、その外観についてはパネルのような外観でなくてもよい。
【0083】
［パネルの配置可能数について］
本実施形態では、１ステージに最大で４つまでパネルが配置可能であるとする。また、１プレイヤにつき１つまでしかパネルは配置できないものとする。そのため、プレイヤが一旦パネルを配置した後、別の場所で新たにパネル配置操作を行った場合は、前に配置したパネルが消去され、当該別の場所にパネルが配置されることになる。
本実施形態では、１ステージに最大で４つまでパネルが配置可能であるとする。また、１プレイヤにつき１つまでしかパネルは配置できないものとする。そのため、プレイヤが一旦パネルを配置した後、別の場所で新たにパネル配置操作を行った場合は、前に配置したパネルが消去され、当該別の場所にパネルが配置されることになる。
【0084】
［他ゲーム装置とのパネルの同期について］
また、上記のように自分が配置したパネルは他のプレイヤのゲーム画面上にも表示される。つまり、本実施形態では、配置されたパネルの位置についても共有される。具体的には、パネルを配置したプレイヤのゲーム装置３から、他のゲーム装置に対して、「パネルを配置したこと」と、その配置位置（座標）を示す「配置イベント情報」が送信される。これを受信した他のゲーム装置３では、ローカルのゲーム処理において、パネルを配置する処理が行われる。但し、このような同期を行うのは、パネルを配置したときだけであり、その後のパネルの消去等に関しては、各ゲーム装置３でローカルに管理される。そのため、例えば、新たなパネルが配置された際は、そのパネルの配置について同期されるが、その後の各ゲーム装置におけるゲームプレイの展開によっては、あるゲーム装置では上記パネルが残っているが、違うゲーム装置では当該パネルが消去されている、という状況も起こり得る。
また、上記のように自分が配置したパネルは他のプレイヤのゲーム画面上にも表示される。つまり、本実施形態では、配置されたパネルの位置についても共有される。具体的には、パネルを配置したプレイヤのゲーム装置３から、他のゲーム装置に対して、「パネルを配置したこと」と、その配置位置（座標）を示す「配置イベント情報」が送信される。これを受信した他のゲーム装置３では、ローカルのゲーム処理において、パネルを配置する処理が行われる。但し、このような同期を行うのは、パネルを配置したときだけであり、その後のパネルの消去等に関しては、各ゲーム装置３でローカルに管理される。そのため、例えば、新たなパネルが配置された際は、そのパネルの配置について同期されるが、その後の各ゲーム装置におけるゲームプレイの展開によっては、あるゲーム装置では上記パネルが残っているが、違うゲーム装置では当該パネルが消去されている、という状況も起こり得る。
【0085】
［復活補助オブジェクト：リモートパネル］
次に、上記パネルのうち、リモートパネルについて説明する。上記のように、リモートパネルは、上記リモートキャラが配置したパネルである。プレイヤキャラ２０１が通常状態のときに当該リモートパネルに接触すると、パネルが揺れるリアクションが行われ、当該パネルを配置したリモートプレイヤ名が表示される。また、プレイヤキャラ２０１が特殊状態のときに、上記復活可能時間内に接触すると、リモートキャラの場合と同様に復活できる。このことは、換言すれば、プレイヤ自身がパネルを配置することで、これが他のプレイヤから見た場合のリモートパネルとなり、自分が同じ画面内にいなくても、間接的に他プレイヤを助けることができる、ということになる。例えば、上記ミスイベントが多発するであろうとプレイヤが考える場所にパネルを配置しておくことで、間接的に他のプレイヤを助けとなることが期待できる。
次に、上記パネルのうち、リモートパネルについて説明する。上記のように、リモートパネルは、上記リモートキャラが配置したパネルである。プレイヤキャラ２０１が通常状態のときに当該リモートパネルに接触すると、パネルが揺れるリアクションが行われ、当該パネルを配置したリモートプレイヤ名が表示される。また、プレイヤキャラ２０１が特殊状態のときに、上記復活可能時間内に接触すると、リモートキャラの場合と同様に復活できる。このことは、換言すれば、プレイヤ自身がパネルを配置することで、これが他のプレイヤから見た場合のリモートパネルとなり、自分が同じ画面内にいなくても、間接的に他プレイヤを助けることができる、ということになる。例えば、上記ミスイベントが多発するであろうとプレイヤが考える場所にパネルを配置しておくことで、間接的に他のプレイヤを助けとなることが期待できる。
【0086】
［復活補助オブジェクト：サーバパネル］
次に、サーバパネルについて説明する。本実施形態に係るゲームでは、多数の様々なステージが用意されており、プレイヤはこの中からプレイしたいステージを選んでプレイできる。ただ、多数のステージが用意されている反面、ステージによっては、プレイするプレイヤの数が相対的に少なく、上記パネルがあまり配置されない可能性がある。そこで、本実施形態では、各プレイヤが配置したパネルに関する情報（以下、パネル情報）を上記ゲームサーバ１に保持しておく。そして、当該パネルの情報を、新規にステージ部屋が作成された際等に使用することで、ステージ上にパネルが配置されている状態を作りだす。このようなゲームサーバ１に保持されているパネル情報に基づいて配置されたパネルが、サーバパネルである。以下、サーバパネルの詳細について説明する。
次に、サーバパネルについて説明する。本実施形態に係るゲームでは、多数の様々なステージが用意されており、プレイヤはこの中からプレイしたいステージを選んでプレイできる。ただ、多数のステージが用意されている反面、ステージによっては、プレイするプレイヤの数が相対的に少なく、上記パネルがあまり配置されない可能性がある。そこで、本実施形態では、各プレイヤが配置したパネルに関する情報（以下、パネル情報）を上記ゲームサーバ１に保持しておく。そして、当該パネルの情報を、新規にステージ部屋が作成された際等に使用することで、ステージ上にパネルが配置されている状態を作りだす。このようなゲームサーバ１に保持されているパネル情報に基づいて配置されたパネルが、サーバパネルである。以下、サーバパネルの詳細について説明する。
【0087】
［サーバへの情報送信について］
まず、パネル情報のゲームサーバ１への送信に関して説明する。本実施形態では、プレイヤがステージ部屋から退室するときに、そのプレイヤが配置したパネルについてのパネル情報をゲームサーバ１に送信する。ステージ部屋からの退室は、例えばゴールした場合や、ゲームオーバー等でクリアすることなくリタイアする場合等である。当該パネル情報には、パネルを配置したステージと配置位置とを示す情報が少なくとも含まれている。但し、プレイヤがステージ部屋から退室するときに、当該プレイヤが配置したパネルが既に消去されている場合は、パネル情報は送信されない。また、そのステージにおいて、既にプレイヤ自身が配置したパネル情報がゲームサーバ１に保持されていた場合は、既存のパネル情報が削除され、新たに登録される。これは、例えば、あまりプレイされていないステージにおいて、あるプレイヤが１人で「ステージに入室し、パネルを配置し、退室する」ことを繰り返すことで、そのステージに関するパネルが全て同一プレイヤに係るパネルで埋められるという状況の発生を抑制するためである。
まず、パネル情報のゲームサーバ１への送信に関して説明する。本実施形態では、プレイヤがステージ部屋から退室するときに、そのプレイヤが配置したパネルについてのパネル情報をゲームサーバ１に送信する。ステージ部屋からの退室は、例えばゴールした場合や、ゲームオーバー等でクリアすることなくリタイアする場合等である。当該パネル情報には、パネルを配置したステージと配置位置とを示す情報が少なくとも含まれている。但し、プレイヤがステージ部屋から退室するときに、当該プレイヤが配置したパネルが既に消去されている場合は、パネル情報は送信されない。また、そのステージにおいて、既にプレイヤ自身が配置したパネル情報がゲームサーバ１に保持されていた場合は、既存のパネル情報が削除され、新たに登録される。これは、例えば、あまりプレイされていないステージにおいて、あるプレイヤが１人で「ステージに入室し、パネルを配置し、退室する」ことを繰り返すことで、そのステージに関するパネルが全て同一プレイヤに係るパネルで埋められるという状況の発生を抑制するためである。
【0088】
［サーバパネルの受信および配置について］
次に、上記のようにしてゲームサーバ１に送信されたパネル情報の利用に関して説明する。まず、プレイヤがステージ部屋に入室した際に、ステージに配置されているパネル数が０個の状態だった場合に、ゲームサーバ１からパネル情報を取得する。入室した際にパネル数が０個という状況は、例えば次のような状況である。まず、ステージ部屋が新規作成された場合である。次に、既存のステージ部屋に入室したときに、その時点でステージ内にパネルが１つも配置されていなかった場合である。換言すれば、プレイヤが入室した時点でステージ内にパネルが１つも無いという状況の場合にのみ、サーバパネルが配置され得ることになる。
次に、上記のようにしてゲームサーバ１に送信されたパネル情報の利用に関して説明する。まず、プレイヤがステージ部屋に入室した際に、ステージに配置されているパネル数が０個の状態だった場合に、ゲームサーバ１からパネル情報を取得する。入室した際にパネル数が０個という状況は、例えば次のような状況である。まず、ステージ部屋が新規作成された場合である。次に、既存のステージ部屋に入室したときに、その時点でステージ内にパネルが１つも配置されていなかった場合である。換言すれば、プレイヤが入室した時点でステージ内にパネルが１つも無いという状況の場合にのみ、サーバパネルが配置され得ることになる。
【0089】
また、ゲームサーバ１からパネル情報を取得する点について、本実施形態では、そのステージに紐付けられているパネル情報の、直近３０件分をゲームサーバ１から取得する。なお、上記のように、同一ステージで同一プレイヤが複数回パネル情報を送信した場合は、最新のパネル情報のみがゲームサーバ１に保持される。そのため、当該取得したパネル情報群に同一プレイヤに係るパネル情報が複数含まれているということはない。そして、この中から、最大で４つまでパネル情報が選出される。なお、本実施形態では、ステージ部屋の定員が最大４人の例であるため、この人数に合わせて最大４つとしているが、選出数は４つ以上でも４つ以下でもよいことはいうまでもない。また、選出手法は、例えばランダムで選出すればよい。
【0090】
次に、上記選出したパネル情報に基づいて、サーバパネルが生成される。そして、各パネル情報で示される位置にサーバパネルがそれぞれ配置される。ここで、ステージに入室したときに過去にプレイヤ自身が配置したパネルがサーバパネルとして存在する場合も考えられる。この場合は、当該過去にプレイヤ自身が配置したサーバパネルはプレイヤのパネルであると判断し、その後、プレイヤが新たにパネルを配置した場合は、当該サーバパネルを消滅させる。
【0091】
［サーバパネルの有効化について］
次に、サーバパネルの有効化について説明する。上記のようにしてサーバパネルは配置され得るが、サーバパネルは初期状態として無効状態になっている。つまり、配置された時点では、上述した復活補助オブジェクトとして機能していない状態である。図２５に、無効状態のサーバパネルの例を示す。図２５に示すように、無効状態のサーバパネルは、黒塗りの表示態様で表示される。なお、無効状態であることを示す表示態様は、黒塗りに限らず、どのような表示態様でもよい。そして、当該無効状態のサーバパネルにプレイヤキャラ２０１が接触することで、図２６に示すように、当該サーバパネルを有効化できる。図２６では、黒塗りの表示態様が解除され、通常と同様の表示態様でサーバパネルが表示されていることを示している。このように、有効化されたサーバパネルだけが、上述した復活補助オブジェクトとして機能する。そのため、無効状態のサーバパネルの近くでミスイベントが発生した場合は、上記のような特殊キャラに変化すること無く、ロストとなる。
次に、サーバパネルの有効化について説明する。上記のようにしてサーバパネルは配置され得るが、サーバパネルは初期状態として無効状態になっている。つまり、配置された時点では、上述した復活補助オブジェクトとして機能していない状態である。図２５に、無効状態のサーバパネルの例を示す。図２５に示すように、無効状態のサーバパネルは、黒塗りの表示態様で表示される。なお、無効状態であることを示す表示態様は、黒塗りに限らず、どのような表示態様でもよい。そして、当該無効状態のサーバパネルにプレイヤキャラ２０１が接触することで、図２６に示すように、当該サーバパネルを有効化できる。図２６では、黒塗りの表示態様が解除され、通常と同様の表示態様でサーバパネルが表示されていることを示している。このように、有効化されたサーバパネルだけが、上述した復活補助オブジェクトとして機能する。そのため、無効状態のサーバパネルの近くでミスイベントが発生した場合は、上記のような特殊キャラに変化すること無く、ロストとなる。
【0092】
また、一旦有効化したサーバパネルについては、プレイヤキャラ２０１がそのサーバパネルから離れたとしても、その後も有効であり続ける。また、リスタートした場合も、一旦有効化したサーバパネルが再度無効化されることはなく、有効であり続ける。
【0093】
なお、上記のような最初は無効状態で、プレイヤキャラ２０１の接触で有効化させるのは、以下のような理由による。まず、上記のように特殊キャラになると、敵キャラクタや地形との衝突判定が行われない状態となる。そのため、もしサーバパネルが最初から有効だとすると、サーバパネルの配置位置の関係によっては、プレイヤがわざと特殊キャラに変化し、通常状態としてはまだ到達していない先の場所（サーバパネルがある場所）まで特殊キャラのまま移動することが起こりえる。すなわち、本来はまだ進めていない位置までショートカットできてしまうということが考えられる。このような状況の発生を抑制するために、初期状態ではサーバパネルは無効状態としている。なお、これは、他のプレイヤがいないステージ部屋についての話である。例えばリモートキャラがリアルタイムで配置したリモートパネルについては、オンラインプレイのメリットや協力プレイ的な要素をプレイヤに感じさせるために、上記のようなショートカットは許容する。そのため、上記リモートパネルについては、配置した時点から有効な状態である。
【0094】
またその他、サーバパネル自体を、チェックポイントのように通過するということ自体を一種の遊び方として提供するという観点で、初期状態を無効状態としている。
【0095】
次に、ゲーム装置３、および、ゲームサーバ１で用いられる各種データと、それぞれで行われる処理の詳細を説明する。
【0096】
［ゲームサーバ１で用いられるデータについて］
まず、ゲームサーバ１で用いられるデータに関して説明する。図２７は、ゲームサーバ１の記憶部１２に記憶される各種データの一例を示すメモリマップである。ゲームサーバ１の記憶部１２には、ゲームサーバプログラム３０１、プレイヤデータベース３０２、ステージ部屋管理データ３０４、リプレイ管理データ３０５、パネル管理データ３０６が少なくとも記憶されている。
まず、ゲームサーバ１で用いられるデータに関して説明する。図２７は、ゲームサーバ１の記憶部１２に記憶される各種データの一例を示すメモリマップである。ゲームサーバ１の記憶部１２には、ゲームサーバプログラム３０１、プレイヤデータベース３０２、ステージ部屋管理データ３０４、リプレイ管理データ３０５、パネル管理データ３０６が少なくとも記憶されている。
【0097】
ゲームサーバプログラム３０１は、上述したようなゲーム処理を実現するためにゲームサーバ１を機能させるプログラムである。
【0098】
プレイヤデータベース３０２は、本実施形態に係るゲームをプレイする各プレイヤに関するデータベースである。データベースには、複数のプレイヤデータ３０３が含まれている。各プレイヤデータ３０３には、例えば、各プレイヤを識別するためのプレイヤＩＤ３０７、各プレイヤのプレイヤ名３０８等が含まれる。
【0099】
ステージ部屋管理データ３０４は、上記ステージ部屋を管理するためのデータベースである。図２８に、ステージ部屋管理データ３０４のデータ構成の一例を示す。図２８において、ステージ部屋管理データ３０４には、各ステージを特定するステージ番号３１１毎に、ステージ部屋情報３１２が含まれている。当該ステージ部屋情報３１２は、１つのステージに対して複数含まれ得る。当該ステージ部屋情報３１２のひとつひとつが上記ステージ部屋に対応する情報である。各ステージ部屋情報３１２には、部屋ＩＤ３１３、入室プレイヤ情報３１４等が含まれる。部屋ＩＤ３１３は、そのステージ部屋を一意に特定するためのＩＤである。入室プレイヤ情報３１４は、そのステージ部屋に現在入室しているプレイヤに関する情報である。例えば、入室プレイヤ情報３１４には、上記プレイヤＩＤ３０７が格納される。
【0100】
図２７に戻り、リプレイ管理データ３０５は、上述したような、ゲーム装置３から送信されてくる上記リプレイデータを保存したものである。図２９に、リプレイ管理データのデータ構成の一例を示す。リプレイ管理データ３０５には、ステージ番号３２１毎に、１つ以上のリプレイデータ３２２が含まれている。各リプレイデータ３２２には、登録日時３２３、登録プレイヤ情報３２４、リプレイ内容３２５が少なくとも含まれる。登録日時３２３は、そのリプレイデータがゲームサーバ１に登録された日時を示す。登録プレイヤ情報３２４は、そのリプレイデータを生成したプレイヤに関する情報である。登録プレイヤ情報３２４には、例えば、上記プレイヤＩＤ３０７等が含まれている。リプレイ内容３２５は、リプレイの内容を示すためのデータである。例えば、リプレイ内容３２５は、リプレイに係るキャラクタの位置情報や状態を示す情報が時系列に並べられて格納されたデータである。また、リプレイ内容３２５は、例えばキーデータ等であってもよい。つまり、リプレイ内容３２５は、プレイヤの操作履歴が把握できるようなデータであれば、どのようなデータ内容であってもよい。
【0101】
図２７に戻り、パネル管理データ３０６は、上記のようにゲーム装置３から送信されるパネル情報を保存したものである。図３０に、パネル管理データ３０６のデータ構成の一例を示す。パネル管理データ３０６には、ステージ番号３３１毎に、１つ以上のパネル情報３３２が含まれている。各パネル情報３３２には、登録日時３３３、配置プレイヤ情報３３４、配置位置３３５が少なくとも含まれる。登録日時３３３は、そのパネル情報３３２がゲームサーバ１に登録された日時を示す。配置プレイヤ情報３３４は、パネル情報３３２に係るパネルを配置したプレイヤに関する情報である。配置位置３３５は、パネル情報３３２に係るパネルの配置位置を示す情報である。
【0102】
また、図示は省略するが、プレイヤのマッチング処理等を行うために必要な各種データも、記憶部１２に適宜記憶され得る。
【0103】
［ゲーム装置３で用いられるデータについて］
次に、ゲーム装置３で用いられるデータに関して説明する。図３１は、ゲーム装置３の記憶部３２に記憶される各種データの一例を示すメモリマップである。ゲーム装置３の記憶部３２には、ゲームプログラム３５１、ステージデータ３５２、オブジェクトデータ３５３、プレイヤキャラデータ３５４、リモートキャラデータ３６１、リプレイゴーストデータ３６２、プレイヤアクター管理データ３６３、パネルデータ３６４、操作データ３６５、選出済みフラグ３６６、配置完了フラグ３６７が少なくとも記憶されている。
次に、ゲーム装置３で用いられるデータに関して説明する。図３１は、ゲーム装置３の記憶部３２に記憶される各種データの一例を示すメモリマップである。ゲーム装置３の記憶部３２には、ゲームプログラム３５１、ステージデータ３５２、オブジェクトデータ３５３、プレイヤキャラデータ３５４、リモートキャラデータ３６１、リプレイゴーストデータ３６２、プレイヤアクター管理データ３６３、パネルデータ３６４、操作データ３６５、選出済みフラグ３６６、配置完了フラグ３６７が少なくとも記憶されている。
【0104】
ゲームプログラム３５１は、ゲーム装置３において、本実施形態におけるゲーム処理を実行するためのプログラムである。
【0105】
ステージデータ３５２は、プレイするステージを構築するためのデータが含まれている。具体的には、ステージデータ３５２には、ステージ毎に、スタート地点、ゴール地点の位置情報、中間地点オブジェクト等のステージ内に配置される各種オブジェクトを示すデータが含まれる。
【0106】
オブジェクトデータ３５３は、ステージ内に配置される各種オブジェクトと、リモートキャラやリプレイゴーストとして表示されるキャラクタオブジェクトの外観を示すマスタデータである。具体的には、オブジェクトデータ３５３には、各オブジェクトのモデルデータやテクスチャデータ等が含まれている。
【0107】
プレイヤキャラデータ３５４は、プレイヤの操作対象となる上記プレイヤキャラ２０１に関するデータである。プレイヤキャラデータ３５４には、プレイヤ位置情報３５５、特殊状態フラグ３５６、特殊状態化回数３５７、中間通過フラグ３５８、リプレイ記録用データ３５９、ロスト発生フラグ３６０、探索フラグ３６８等のデータが含まれる。プレイヤ位置情報３５５は、プレイするステージにおけるプレイヤキャラ２０１の位置を示すデータである。特殊状態化回数３５７は、プレイヤキャラ２０１が上記特殊キャラに変化した回数を記録するためのカウンタである。特殊状態フラグ３５６は、オンの場合は特殊状態、オフの場合は通常状態であることを示すフラグである。特殊状態化回数３５７は、プレイヤキャラ２０１が特殊キャラに変化する度に１回分カウントアップされる。また、上記ロストが発生した際に、リセットされる。中間通過フラグ３５８は、プレイヤキャラ２０１が上記中間地点オブジェクトに接触したか否かを示すためのフラグである。中間地点オブジェクトに接触するとオンに設定される。リプレイ記録用データ３５９は、プレイヤキャラ２０１のリプレイ用のデータを記録するためのデータである。ロスト発生フラグ３６０は、上述したロストとなる状況が発生したことを示すためのフラグである。オンであれば、ロストとなる状況が発生したことを示す。探索フラグ３６８は、上記図２０で説明したような、探索オブジェクトの状態で復活可能な位置を探索している最中か否かを示すフラグである。
【0108】
次に、リモートキャラデータ３６１は、同じステージ部屋に入室しているリモートプレイヤに係るリモートキャラのデータである。図３２に、リモートキャラデータ３６１のデータ構成の一例を示す。本例では、ステージ部屋は最大４人まで入室可能という例であるため、リモートキャラデータ３６１には、最大で３体分のリモートキャラのデータが格納される。また、各データは、リモートプレイヤの入室に伴い生成され、退室に伴って適宜削除される。各データには、識別名３７１、リモートプレイヤ情報３７２、使用キャラクタ情報３７３、リモート位置情報３７４が少なくとも含まれる。識別名３７１は、各リモートキャラを一意に識別するための識別子である。リモートプレイヤ情報３７２は、各リモートキャラを操作しているリモートプレイヤを特定するための情報である。使用キャラクタ情報３７３は、リモートキャラとして画面に表示されるキャラクタを指定する情報である。つまり、各リモートプレイヤがプレイヤキャラとして用いているキャラクタを示す情報である。リモート位置情報３７４は、そのリモートキャラのステージ内での位置を示す情報である。
【0109】
図３１に戻り、次に、リプレイゴーストデータ３６２は、上記リプレイゴーストについてのデータである。具体的には、リプレイゴーストデータ３６２には、リプレイゴーストとして用いられる上記リプレイデータ３２２が最大で３件分、格納される。
【0110】
プレイヤアクター管理データ３６３は、プレイヤアクターの枠と、リモートキャラ、リプレイゴーストの割り当て関係を管理するためのデータである。図３３に、プレイヤアクター管理データ３６３のデータ構成の一例を示す。アクター枠番号３８１は、プレイヤアクターの枠番号である。本例では、プレイヤアクターの枠は４つ用意されている場合を例に説明する。割り当て対象３８２は、その枠に割り当てたプレイヤアクターを特定するための情報である。まず、１枠分は、プレイヤキャラ２０１に割り当てられる。そのため、残り３枠分について、リモートキャラまたはリプレイゴーストのいずれかを特定するための情報が格納される。また、リモートキャラやリプレイゴーストが割り当てられていない状態のときは、Ｎｕｌｌ値が設定される。
【0111】
図３１に戻り、次に、パネルデータ３６４は、上述したパネルを管理するためのデータである。図３４に、パネルデータ３６４のデータ構成の一例を示す。パネルデータ３６４には、自パネルデータ３９１、リモートパネルデータ３９４、サーバパネルデータ４００とが含まれている。また、本例では、リモートパネルデータ３９４およびサーバパネルデータ４００はそれぞれ３件分用意されておる。自パネルデータ３９１は、プレイヤキャラ２０１が配置したパネル（以下、自パネル）に関する情報である。自パネルデータ３９１には、自パネル配置位置３９２、自パネル配置日時３９３が含まれる。自パネル配置位置３９２は、自パネルの配置位置を示し、自パネル配置日時３９３は、自パネルが配置された日時を示す。また、複数回のパネル配置が行われた場合は、最新の配置内容が自パネルデータ３９１に保存される。
【0112】
リモートパネルデータ３９４は、リモートキャラが配置したパネルに関する情報である。リモートパネルデータ３９４には、リモートパネル配置位置３９６、配置プレイヤ情報３９７、リモートパネル配置日時３９８が含まれる。リモートパネル配置位置３９６は、リモートパネルの配置位置を示し、リモートパネル配置日時３９８は、リモートパネルが配置された日時を示す。配置プレイヤ情報３９７は、そのリモートパネルを配置した他のプレイヤに関する情報である。
【0113】
サーバパネルデータ４００は、上記サーバパネルに関するデータである。サーバパネルデータ４００には、サーバパネル配置位置４０２、有効化フラグ４０３が含まれる。サーバパネル配置位置４０２は、そのサーバパネルが配置されている位置を示す。有効化フラグ４０３は、そのサーバパネルが有効化されているか否かを示すフラグである。有効化フラグ４０３の初期値はオフであり、有効化されるとオンに設定される。
【0114】
なお、図３４で示されるように、パネルデータ３６４には、自パネル、リモートパネル、サーバパネルを合計して７つ分のパネルデータが記憶可能ではある。但し、上記のように、パネルは最大で４つまでしかステージ内に配置できないため、実際に用いられるデータとしては、上記７つ分のパネルのデータのうち最大で４つまでのデータとなる。つまり、パネル配置の発生に伴って、パネル数が最大で４つとなるように、各データの中身の削除と生成が適宜行われる。
【0115】
図３１に戻り、操作データ３６５は、プレイヤが操作するコントローラ４から得られるデータである。すなわち、プレイヤが行った操作内容を示すデータである。
【0116】
選出済みフラグ３６６および配置完了フラグ３６７は、リプレイゴーストを配置する処理において用いられるフラグである。選出済みフラグ３６６は、ダウンロードしたリプレイデータからのリプレイゴーストの選出が済んだか否かを示すためのフラグである。配置完了フラグ３６７は、選出したリプレイゴーストをステージ内に全ては位置したか否かを示すためのフラグである。
【0117】
その他、図示は省略するが他のゲーム装置に各種データを送信するための送信用データや、他のゲーム装置３から受信した受信データ、サーバからダウンロードしたリプレイデータ等、ゲーム処理に必要となる各種データも必要に応じて生成され、記憶部３２に記憶され得る。
【0118】
次に、本実施形態におけるゲーム処理の詳細を説明する。まず、ゲーム装置３で行われる処理の詳細を説明し、その後、ゲームサーバ１における処理について説明する。
【0119】
［ゲーム装置３のプロセッサ３１が実行する処理の詳細］
図３５～図３６は、ゲーム装置３のプロセッサ３１が実行するゲーム装置側処理の詳細を示すフローチャートである。本実施形態では、１以上のプロセッサが１以上のメモリに記憶された上記プログラムを読み込んで実行することにより、以下に示すフローチャートが実現される。なお、以下に示すフローチャートは、処理過程の単なる一例にすぎない。そのため、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよい。また、変数の値や、判定ステップで利用される閾値も、単なる一例であり、必要に応じて他の値を採用してもよい。
図３５～図３６は、ゲーム装置３のプロセッサ３１が実行するゲーム装置側処理の詳細を示すフローチャートである。本実施形態では、１以上のプロセッサが１以上のメモリに記憶された上記プログラムを読み込んで実行することにより、以下に示すフローチャートが実現される。なお、以下に示すフローチャートは、処理過程の単なる一例にすぎない。そのため、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよい。また、変数の値や、判定ステップで利用される閾値も、単なる一例であり、必要に応じて他の値を採用してもよい。
【0120】
ゲーム装置３において、プレイヤによって所定のステージをプレイすることが指示されると、まず、ステップＳ１で、プロセッサ３１は、ステージ開始処理を実行する。図３７は、当該ステージ準備処理の詳細を示すフローチャートである。図３７において、まず、ステップＳ２１で、プロセッサ３１は、ステージ部屋への入室処理を行う。具体的には、まず、プロセッサ３１は、ゲームサーバ１にマッチング処理をリクエストする。そして、プロセッサ３１は、そのマッチング結果に基づき決定されたステージ部屋への入室処理を実行する。この際、既存の部屋に入室する場合は、入室済みのプレイヤに係るゲーム装置３に、自分がプレイヤキャラ２０１として用いるキャラクタの情報も送信する。
【0121】
次に、ステップＳ２２で、プロセッサ３１は、今回プレイするステージ（仮想空間）を、ステージデータ３５２に基づいて生成する。更に、既存のステージ部屋に入室した場合は、リモートキャラおよびリモートパネルの情報を他のゲーム装置３から受信する。そして、各種キャラクタをステージ内に配置する。
【0122】
次に、ステップＳ２３で、プロセッサ３１は、ステージ内のパネル数が０か否かを判定する。当該判定の結果、０ではない場合は（ステップＳ２３でＮＯ）、後述するステップＳ２７に処理が進められる。一方、０の場合は（ステップＳ２３でＹＥＳ）、ステップＳ２４で、プロセッサ３１は、直近３０件分のパネル情報をゲームサーバ１から取得する。次に、ステップＳ２５で、プロセッサ３１は、取得したパネル情報からランダムで４つのパネル情報を選出する。そして、プロセッサ３１は、選出したパネル情報をサーバパネルデータ４００として記憶する。この際、過去にプレイヤ自身が配置したパネルの情報が含まれていた場合は、これについては自パネルデータ３９１として記憶する。そして、プロセッサ３１は、パネルデータ３６４に基づき、サーバパネルを配置する。
【0123】
次に、ステップＳ２６で、プロセッサ３１は、ステージ部屋に他のプレイヤがいる場合は、配置したサーバパネル（場合によっては自パネルデータも）の情報を他のゲーム装置に送信する。つまり、サーバパネルの情報を同じステージ部屋のリモートプレイヤと共有する。なお、例えばほぼ同じタイミングで２人のプレイヤが入室し、共にサーバパネルに関する処理を行った場合は、いずれか１人のサーバパネルの情報を優先する。
【0124】
次に、ステップＳ２７で、プロセッサ３１は、ゲーム画面を生成し、表示部５に表示する。これにより、ステージプレイが開始されることになる。
【0125】
図３５に戻り、次に、ステップＳ２で、プロセッサ３１は、入退室チェック処理を実行する。これは、プレイヤが入室した後に発生した他のプレイヤの入退室をチェックするための処理である。図３８～図３９は、入退室チェック処理の詳細を示すフローチャートである。まず、ステップＳ３１で、プロセッサ３１は、対応するリモートキャラが存在していない新たなプレイヤの入室が発生したか否かを判定する。当該判定の結果、新たな入室者がいない場合は（ステップＳ３１でＮＯ）、プロセッサ３１は、後述のステップＳ３９に処理を進める。一方、新たなプレイヤの入室が発生した場合は（ステップＳ３１でＹＥＳ）、ステップＳ３２で、プロセッサ３１は、当該入室してきたプレイヤのゲーム装置３に対して、その時点で設置済みのサーバパネルとリモートパネルに関する情報を、必要に応じて送信する。なお、当該情報の送信処理は、先に入室済みのプレイヤのいずれかのゲーム装置３で行われればよい。
【0126】
次に、ステップＳ３３で、プロセッサ３１は、部屋内のプレイヤ人数が４人になったか否かを判定する。当該判定の結果、４人になっていない場合は（ステップＳ３３でＮＯ）、後述のステップＳ３６に処理が進められる。一方、４人になった場合は（ステップＳ３３でＹＥＳ）、ステップＳ３４で、プロセッサ３１は、プレイヤアクター管理データ３６３を参照し、プレイヤアクターの枠に空きがあるか否かを判定する。当該判定の結果、空きが無い場合は（ステップＳ３４でＮＯ）、リプレイゴーストが存在している状態と考えられる。そのため、ステップＳ３５で、プロセッサ３１は、プレイヤキャラ２０１から最も遠くの位置にいるリプレイゴーストを削除する。すなわち、当該リプレイゴーストに係るデータを、リプレイゴーストデータ３６２およびプレイヤアクター管理データ３６３から削除する。その後、ステップＳ３６に処理が進められる。一方、上記判定の結果、プレイヤアクターの枠に空きがある場合は（ステップＳ３４でＹＥＳ）、上記ステップＳ３５の処理はスキップされる。
【0127】
次に、ステップＳ３６で、プロセッサ３１は、入室してきたプレイヤのゲーム装置から受信した情報に基づき、入室してきたプレイヤに対応するリモートキャラのデータをリモートキャラデータ３６１に追加する。そして、リモートキャラデータ３６１に基づき、入室してきたプレイヤに対応するリモートキャラを配置する。
【0128】
次に、ステップＳ３７で、プロセッサ３１は、今回配置したリモートキャラと同じプレイヤのリプレイゴーストが存在するか否かを判定する。当該判定の結果、存在する場合は（ステップＳ３７でＹＥＳ）、ステップＳ３８で、プロセッサ３１は、同プレイヤのリプレイゴーストを削除する。すなわち、プロセッサ３１は、リプレイゴーストデータ３６２から当該リプレイゴーストのデータを削除する。一方、同プレイヤのリプレイゴーストが存在していなければ（ステップＳ３７でＮＯ）、上記ステップＳ３８の処理はスキップされる。
【0129】
次に、図３９のステップＳ３９で、プロセッサ３１は、いずれかのリモートプレイヤの退室が発生したか否かを判定する。また、これに併せて、プロセッサ３１は、そのときに存在しているリプレイゴーストの再生が終了したか否かも判定する。当該判定の結果、リモートプレイヤの退室、または、リプレイゴーストの再生終了が発生した場合は（ステップＳ３９でＹＥＳ）、ステップＳ４０で、プロセッサ３１は、退室したプレイヤに係るリモートキャラを削除する。あるいは、再生が終了したリプレイゴーストおよび、対応するリプレイデータを削除する。
【0130】
一方、リモートプレイヤの退室、リプレイゴーストの再生終了のいずれも発生していない場合は（ステップＳ３９でＮＯ）、上記ステップＳ４０の処理はスキップされる。その後、プロセッサ３１は、入退室チェック処理を終了する。
【0131】
図３５に戻り、次に、ステップＳ３で、プロセッサ３１は、リモートパネルチェック処理を実行する。これは、リモートプレイヤがパネルを設置した場合に、これを自分のゲーム処理に反映させるための処理である。図４０は、リモートパネルチェック処理の詳細を示すフローチャートである。まず、ステップＳ５１で、プロセッサ３１は、他のゲーム装置３から、上記配置イベント情報を受信したか否かを判定する。当該判定の結果、受信した場合は（ステップＳ５１でＹＥＳ）、ステップＳ５２で、プロセッサ３１は、当該配置イベント情報に基づき、パネルデータ３６４の内容を更新する。例えば、同じプレイヤがパネルを再設置した場合は、既に設置済みのパネルを削除して新たなパネルのデータに置き換える処理が行われる。また、新たにパネルが設置された場合、そのパネルに係るデータが新たに作成される。そして、プロセッサ３１は、パネルデータ３６４に基づいてリモートパネルを適宜設置する。一方、上記判定の結果、配置イベント情報を受信していなければ、上記ステップＳ５２の処理はスキップされる。その後、リモートパネルチェック処理は終了する。
【0132】
図３５に戻り、次に、ステップＳ４で、プロセッサ３１は、特殊状態フラグ３５６を参照し、プレイヤキャラ２０１が特殊状態か否かを判定する。当該判定の結果、特殊状態ではない場合は（ステップＳ４でＮＯ）、ステップＳ５で、プロセッサ３１は、通常状態処理を実行する。一方、特殊状態の場合は（ステップＳ４でＹＥＳ）、ステップＳ６で、プロセッサ３１は、特殊状態処理を実行する。以下、各処理について説明する。
【0133】
[通常状態の時の処理]
図４１～図４２は、通常状態処理の詳細を示すフローチャートである。図４１において、まず、ステップＳ６１で、プロセッサ３１は、操作データ３６５を取得する。次に、ステップＳ６２で、プロセッサ３１は、パネル配置操作が行われたか否かを判定する。当該判定の結果、パネル配置操作が行われた場合は（ステップＳ６２でＹＥＳ）、ステップＳ６４で、プロセッサ３１は、自パネル配置処理を実行する。図４３は、当該自パネル配置処理の詳細を示すフローチャートである。まず、ステップＳ８１で、プロセッサ３１は、パネルデータ３６４を参照し、既存の自パネルが存在するか否かを判定する。存在している場合は（ステップＳ８１でＹＥＳ）、ステップＳ８２で、プロセッサ３１は、既存の自パネルのデータをパネルデータ３６４から消去する。一方、存在していなければ（ステップＳ８１でＮＯ）、上記ステップＳ８２の処理はスキップされる。
図４１～図４２は、通常状態処理の詳細を示すフローチャートである。図４１において、まず、ステップＳ６１で、プロセッサ３１は、操作データ３６５を取得する。次に、ステップＳ６２で、プロセッサ３１は、パネル配置操作が行われたか否かを判定する。当該判定の結果、パネル配置操作が行われた場合は（ステップＳ６２でＹＥＳ）、ステップＳ６４で、プロセッサ３１は、自パネル配置処理を実行する。図４３は、当該自パネル配置処理の詳細を示すフローチャートである。まず、ステップＳ８１で、プロセッサ３１は、パネルデータ３６４を参照し、既存の自パネルが存在するか否かを判定する。存在している場合は（ステップＳ８１でＹＥＳ）、ステップＳ８２で、プロセッサ３１は、既存の自パネルのデータをパネルデータ３６４から消去する。一方、存在していなければ（ステップＳ８１でＮＯ）、上記ステップＳ８２の処理はスキップされる。
【0134】
次に、ステップＳ８３で、プロセッサ３１は、パネル配置操作が行われた位置に自パネルを配置する。すなわち、プロセッサ３１は、当該自パネルにかかるデータをパネルデータ３６４に生成し、当該データに基づいて自パネルをステージ内に配置する。
【0135】
次に、ステップＳ８４で、プロセッサ３１は、自パネルに係る配置イベント情報を生成して、他のゲーム装置３に送信する。以上で、自パネル配置処理は終了する。
【0136】
図４１に戻り、上記ステップＳ６２の判定の結果、パネル配置操作が行われていない場合は（ステップＳ６２でＮＯ）、ステップＳ６３で、プロセッサ３１は、操作データ３６５で示される操作内容に基づいて、プレイヤキャラ２０１の動作を制御する。更に、プロセッサ３１は、プレイヤキャラ２０１の位置情報、および、通常状態である特殊状態であるかを示す状態情報を他のゲーム装置３に送信する。
【0137】
次に、ステップＳ６５で、プロセッサ３１は、他のゲーム装置３からリモートキャラに関する情報を受信し、リモートキャラを移動させる。当該リモートキャラに関する情報は、リモートキャラの位置情報および状態を示す情報である。なお、位置情報の代わりに、例えば、リモートプレイヤが行った操作情報を受信するようにしてもよい。この場合は、当該受信した操作情報に基づいてリモートキャラが移動制御されればよい。また、リプレイゴーストが存在している場合は、プロセッサ３１は、リプレイデータに基づく再生を継続する。これにより、当該リプレイゴーストが移動制御される。
【0138】
次に、ステップＳ６６で、プロセッサ３１は、敵キャラクタ等の動作を制御する。更に、プロセッサ３１は、プレイヤキャラ２０１と敵キャラクタやリモートパネル等との衝突判定を行い、その結果に応じたゲーム処理を適宜実行する。例えば、リモートパネルに接触した場合は、そのリモートパネルを配置したリモートプレイヤ名を一時的に表示する処理が行われる。また、例えば、敵キャラクタに接触した場合、敵キャラクタにダメージを与える処理、あるいは、プレイヤキャラ２０１がダメージを受ける処理が行われる、また、このゲーム処理の結果、上述したミスイベントが発生し得る。
【0139】
次に、ステップＳ６７で、プロセッサ３１は、プレイヤキャラ２０１が中間地点オブジェクトに接触したか否かを判定する。当該判定の結果、接触した場合は（ステップＳ６７でＹＥＳ）、ステップＳ６８で、プロセッサ３１は、中間通過フラグ３５８をオンに設定する。これに伴い、これ以降のリスタート地点を中間地点オブジェクトの位置とする設定も行われる。次に、ステップＳ６９で、プロセッサ３１は、リプレイ記録用データ３５９を用いて、プレイヤキャラ２０１に係るリプレイデータの記録を開始する。この際、中間地点からリスタートした状況である場合は、上述のように一定確率でリプレイデータの記録を開始しないように制御してもよい。
【0140】
一方、上記ステップＳ６７の判定の結果、中間地点オブジェクトに接触していない場合は（ステップＳ６７でＮＯ）、上記ステップＳ６８およびＳ６９の処理はスキップされる。
【0141】
次に、図４２のステップＳ７０で、プロセッサ３１は、プレイヤキャラ２０１が無効状態のサーバパネルに接触したか否かを判定する。当該判定の結果、接触した場合は（ステップＳ７０でＹＥＳ）、ステップＳ７１で、プロセッサ３１は、接触したサーバパネルの有効化フラグ４０３にオンを設定する。一方、接触していない場合は（ステップＳ７０でＮＯ）、上記ステップＳ７１の処理はスキップされる。
【0142】
次に、ステップＳ７２で、プロセッサ３１は、上記ミスイベントが発生したか否かを判定する。当該判定の結果、発生した場合は（ステップＳ７２でＹＥＳ）、ステップＳ７３で、プロセッサ３１は、リプレイデータの記録を停止する。次に、ステップＳ７４で、プロセッサ３１は、プレイヤキャラ２０１が特殊状態になるための条件が満たされているか否かを判定する。すなわち、プロセッサ３１は、プレイヤキャラ２０１から所定範囲内にいずれかの復活補助オブジェクトが存在するか否かを判定する。当該判定の結果、特殊状態になるための条件が満たされている場合は（ステップＳ７４でＹＥＳ）、ステップＳ７５で、プロセッサ３１は、プレイヤキャラ２０１を特殊状態とするための設定、および、これに伴う各種設定を行う。具体的には、プロセッサ３１は、特殊状態フラグ３５６にオンを設定する。更に、プロセッサ３１は、プレイヤキャラ２０１を特殊キャラに変更する。更に、プロセッサ３１は、特殊状態化回数３５７に１を加算する。更に、プロセッサ３１は、復活補助オブジェクトを除いてゲーム画面がモノクロで表示されるようにゲーム画面の表示設定を行う。その後、通常状態処理は終了する。
【0143】
一方、特殊状態になるための条件が満たされていない場合は（ステップＳ７４でＮＯ）、ステップＳ７６で、プロセッサ３１は、ロスト発生フラグ３６０にオンを設定する。その後、通常状態処理は終了する。
【0144】
一方、上記ステップＳ７２の判定の結果、ミスイベントが発生していない場合は（ステップＳ７０でＮＯ）、通常状態処理は終了する。
【0145】
[特殊状態のときの処理]
次に、上記特殊状態処理について説明する。図４４は、当該特殊状態処理の詳細を示すフローチャートである。まず、ステップＳ９１で、プロセッサ３１は、探索フラグ３６８がオンか否か判定する、当該判定の結果、オフの場合は（ステップＳ９１でＮＯ）、次に、ステップＳ９２で、プロセッサ３１は、操作データ３６５を取得する。次に、ステップＳ９３で、プロセッサ３１は、操作データに基づき、特殊キャラを移動させる。上記のように、特殊キャラの間は、地形や敵キャラクタとの衝突判定は行われない。
次に、上記特殊状態処理について説明する。図４４は、当該特殊状態処理の詳細を示すフローチャートである。まず、ステップＳ９１で、プロセッサ３１は、探索フラグ３６８がオンか否か判定する、当該判定の結果、オフの場合は（ステップＳ９１でＮＯ）、次に、ステップＳ９２で、プロセッサ３１は、操作データ３６５を取得する。次に、ステップＳ９３で、プロセッサ３１は、操作データに基づき、特殊キャラを移動させる。上記のように、特殊キャラの間は、地形や敵キャラクタとの衝突判定は行われない。
【0146】
次に、ステップＳ９４で、プロセッサ３１は、上記特殊状態から復活可能な時間をカウントするための特殊カウンタのカウントを進める。この際、プロセッサ３１は、特殊状態化回数３５７に基づいて、１カウントに係る時間間隔を適宜変化させた上で、カウントを進める。
【0147】
次に、ステップＳ９５で、プロセッサ３１は、特殊カウンタのカウントが終了したか否かを判定する。当該判定の結果、まだカウントが終了していない場合は（ステップＳ９５でＮＯ）、ステップＳ９６で、プロセッサ３１は、復活条件が満たされたか否かを判定する。すなわち、上記復活可能時間内に特殊キャラが復活対象オブジェクトとのいずれかと接触できたか否かを判定する。当該判定の結果、満たされた場合は（ステップＳ９６でＹＥＳ）、図４５のステップＳ９７で、プロセッサ３１は、復活位置を探索する必要があるか否かを判定する。すなわち、上記図１９で示したような、特殊キャラと上記接触した復活対象オブジェクトとが共に地形内に位置している状況であるか否かを判定する。当該判定の結果、このような状況と判定された場合は（ステップＳ９７でＹＥＳ）、ステップＳ９８で、プロセッサ３１は、探索フラグ３６８にオンを設定する。次に、ステップＳ９９で、プロセッサ３１は、プレイヤキャラを特殊キャラから上記探索オブジェクトに変更する。その後、後述のステップＳ１０２に処理が進められる。
【0148】
一方、上記ステップＳ９７の判定の結果、復活位置を探索する必要がない場合は（ステップＳ９７でＮＯ）、ステップＳ１００で、プロセッサ３１は、特殊状態フラグ３５６にオフを設定する。更に、プロセッサ３１は、特殊キャラを通常状態のプレイヤキャラ２０１に変更する。更に、プロセッサ３１は、ゲーム画面のモノクロ表示設定を解除し、通常の表示となるよう設定する。次に、ステップＳ１０１で、復活位置にプレイヤキャラ２０１を配置する。この場合の復活位置は、次のようにして決まる。まず、接触した復活対象オブジェクトから特殊キャラに対してレイを飛ばし、地形に当たるか否かを判定する。その結果、地形に当たった場合は、復活補助オブジェクトの位置を復活位置とする。当たらなかった場合は、特殊キャラの位置を復活位置とする。これにより、上記図１３～図１８で示したような位置が復活位置として決定される。その後、後述のステップＳ１０２に処理が進められる。なお、上記決定または検索された復活位置に敵キャラクタ等が存在している状況の場合は、当該敵キャラクタと接触しないような位置に当該復活位置がずらされてもよい。つまり、通常状態に戻した直後にミスイベントが発生しないような位置が復活位置として決定されて、プレイヤキャラ２０１が配置されてもよい。
【0149】
なお、上記でも言及したが、上記復活位置の決定に際しては、通常状態に戻したプレイヤキャラのサイズも考慮して、復活位置が決定される。つまり、通常状態に戻したプレイヤキャラが障害物等にめり込まないようなスペースが十分に確保されている位置が復活位置として決定される。
【0150】
一方、上記ステップＳ９５の判定の結果、特殊カウンタのカウントが終了した場合は（ステップＳ９６でＹＥＳ）、ステップＳ１０３で、プロセッサ３１は、ロスト発生フラグ３６０にオンを設定する。その後、後述のステップＳ１０２に処理が進められる。
【0151】
次に、上記ステップＳ９１の判定の結果、探索フラグ３６８がオンの場合の処理（ステップＳ９１でＹＥＳ）について説明する。この場合は、図４４のステップＳ１０２で、プロセッサ３１は、探索処理を実行する。この処理は、図２０を用いて上述したような復活位置を探索する処理である。図４６は、当該探索処理の詳細を示すフローチャートである。図４６において、まず、ステップＳ１７１で、プロセッサ３１は、上記特殊キャラと復活対象オブジェクトとが接触した位置から螺旋状の軌道で外側に向けて離れるように、探索用オブジェクトを所定の距離だけ移動させる。
【0152】
次に、ステップＳ１７２で、プロセッサ３１は、移動後の位置が、復活位置としての条件を満たすか否かを判定する。具体的には、まず、プロセッサ３１は、上記移動後の位置を復活予定位置として設定する。そして、当該復活予定位置が、「地形外となる位置」であり、かつ、「通常状態に戻したプレイヤキャラが配置できるスペースが確保されている位置」であるか否かが判定される。当該判定の結果、復活位置としての条件を満たす場合は（ステップＳ１７２でＹＥＳ）、ステップＳ１７３で、プロセッサ３１は、探索オブジェクトの現在位置（上記復活予定位置）を復活位置として決定する。次に、ステップＳ１７４で、プロセッサ３１は、探索フラグ３６８にオフを設定する、次に、ステップＳ１７５で、プロセッサ３１は、特殊状態フラグ３５６にオフを設定し、探索オブジェクトを通常状態のプレイヤキャラ２０１に変更する。更に、プロセッサ３１は、ゲーム画面のモノクロ表示設定を解除し、通常の表示となるよう設定する。続くステップＳ１７６で、プロセッサ３１は、当該プレイヤキャラ２０１を上記決定した復活位置に配置する。その後、プロセッサ３１は、探索処理を終了する。
【0153】
一方、上記ステップＳ１７２の判定の結果、移動後の位置が、復活位置としての条件を満たしていない場合は（ステップＳ１７２でＮＯ）、ステップＳ１７７で、プロセッサ３１は、探索オブジェクトが画面端（表示領域の端）となる位置まで移動したか否かを判定する。つまり、螺旋状に移動していった結果、同一画面内のいずれかの端部分に到達したか否かを判定する。なお、他の実施形態では、画面端への到達の代わりに、予め規定された所定の距離まで移動したか否かを判定するようにしてもよい。当該判定の結果、画面端となる位置まで移動した場合は（ステップＳ１７７でＹＥＳ）ステップＳ１７８で、プロセッサ３１は、探索フラグ３６８にオフを設定する。続くステップＳ１７９で、プロセッサ３１は、上記特殊カウントをリセットし、プレイヤキャラを、探索オブジェクトを特殊キャラに変更する。つまり、画面端まで到達しても復活位置としての条件を満たす位置が見つからなかった場合は、一旦そこで探索を打ち切って、特殊キャラに戻すような処理が行われる。その後、探索処理は終了する。
【0154】
一方、上記ステップＳ１７７の判定の結果、画面端となる位置まで移動していない場合は（ステップＳ１７７でＮＯ）、上記ステップＳ１７８～Ｓ１７９の処理はスキップされる。つまり、この場合は、探索が継続されることになる。その後、探索処理は終了する。
【0155】
図４５に戻り、次に、ステップＳ１０２で、プロセッサ３１は、リモートキャラを制御する。プレイヤキャラ２０１が特殊状態の間は、上記のように、リモートキャラは半透明ではなく、不透明で表示されるよう制御される。また、リモートキャラと特殊キャラとの衝突判定が行われるよう制御される。また、リプレイゴーストが存在している場合は、リプレイゴーストについても上記リモートキャラと同様の制御を行う。
【0156】
次に、ステップＳ１０３で、プロセッサ３１は、敵キャラクタ等の動作制御を行い、これに伴う各種のゲーム処理を行う。その後、特殊状態処理は終了する。
【0157】
図３５に戻り、次に、ステップＳ７で、プロセッサ３１は、ロスト発生フラグ３６０がオンか否かを判定する。オンではない場合（ステップＳ７でＮＯ）、ステップＳ８で、プロセッサ３１は、中間通過フラグ３５８に基づき、プレイヤキャラ２０１が中間地点オブジェクトに接触済みか否かを判定する。当該判定の結果、まだ接触していない場合は（ステップＳ８でＮＯ）、後述のステップＳ１０に処理が進められる。一方、接触済みの場合は（ステップＳ８でＹＥＳ）、ステップＳ９で、プロセッサ３１は、リプレイゴースト処理を実行する。
【0158】
図４７は、上記リプレイゴースト処理の詳細を示すフローチャートである。まず、ステップＳ１１１で、プロセッサ３１は、配置完了フラグ３６７がオンか否かを判定する。オンの場合は（ステップＳ１１１でＹＥＳ）、プロセッサ３１は、リプレイゴースト処理を終了する。一方、オフの場合は（ステップＳ１１１でＮＯ）、ステップＳ１１２で、プロセッサ３１は、選出済みフラグ３６６がオンか否かを判定する。オンの場合は（ステップＳ１１２でＹＥＳ）、後述するステップＳ１１７に処理が進められる。オフの場合は（ステップＳ１１２でＮＯ）、ステップＳ１１３で、プロセッサ３１は、リプレイデータのゲームサーバ１からのダウンロードが完了したか否かを判定する。当該判定の結果、まだ完了していない場合は（ステップＳ１１３でＮＯ）、ステップＳ１１５で、プロセッサ３１は、ゲームサーバ１からリプレイデータのダウンロードを開始する。または、既に開始済みの場合は、プロセッサ３１は、ダウンロードを継続する。その後、リプレイゴースト処理は終了する。
【0159】
一方、リプレイデータのダウンロードが完了した場合は（ステップＳ１１３でＹＥＳ）、次に、ステップＳ１１４で、プロセッサ３１は、この時点でリモートプレイヤが存在するか否かを判定する。当該判定の結果、リモートプレイヤが存在する場合は（ステップＳ１１４でＹＥＳ）、ステップＳ１１９で、プロセッサ３１は、配置完了フラグ３６７にオンを設定する。この場合、例えば、ダウンロード中にリモートプレイヤが入室してきた場合に、リプレイデータのダウンロードが完了しても、実際にリプレイゴーストの配置は行われないことになる。その後、リプレイゴースト処理は終了する。
【0160】
一方、リモートプレイヤが存在しない場合は（ステップＳ１１４でＮＯ）、ステップＳ１１６で、プロセッサ３１は、ダウンロードしたリプレイデータの中から、リプレイゴーストとして用いるリプレイデータをランダムで最大３件まで選出する。この際、自分のリプレイデータについては選出対象から除外する。そして、プロセッサ３１は、選出済みフラグ３６６にオンを設定する。
【0161】
次に、ステップＳ１１７で、プロセッサ３１は、選出したリプレイゴーストを全てステージ内に配置したか否かを判定する。まだ全て配置していない場合は（ステップＳ１１７でＮＯ）、ステップＳ１１８で、プロセッサ３１は、リプレイゴーストを１体生成して、ステージ内に配置する。この際、上記のように、配置するタイミングを少しずらしながら、１体ずつリプレイゴーストを配置するよう制御される。
【0162】
一方、選出したリプレイゴーストを全てステージ内に配置したら（ステップＳ１１７でＹＥＳ）、上記ステップＳ１１９に処理が進められ、配置完了フラグ３６７にオンが設定される。その後、リプレイゴースト処理は終了する。
【0163】
次に、図３６のステップＳ１０で、プロセッサ３１は、プレイヤキャラ２０１がゴールしたか否かを判定する。当該判定の結果、まだゴールしていない場合は（ステップＳ１０でＮＯ）、ステップＳ１１で、プロセッサ３１は、上記の処理が反映されたゲーム画面を生成して表示する。その後、上記ステップＳ２に戻り、処理が繰り返される。
【0164】
一方、ゴールした場合は（ステップＳ１０でＹＥＳ）、ステップＳ１２で、プロセッサ３１は、ステージクリア処理を実行する。図４８は、ステージクリア処理の詳細を示すフローチャートである。まず、ステップＳ１４１で、プロセッサ３１は、リプレイ記録用データ３５９へのリプレイデータの記録を停止する。次に、ステップＳ１４２で、プロセッサ３１は、ステージクリアの演出を表示を行う。次に、ステップＳ１４３で、プロセッサ３１は、リプレイ記録用データ３５９をゲームサーバ１に送信する。その後、ステージクリア処理を終了する。
【0165】
図３６に戻り、次に、ステップＳ１３で、プロセッサ３１は、自身が配置した自パネルがステージに残っている場合、自パネルデータ３９１をゲームサーバ１に送信する。
【0166】
次に、ステップＳ１４で、プロセッサ３１は、ステージ部屋から退室する処理を行う。その後、ステージ処理は終了する。
【0167】
次に、上記ステップＳ７の判定の結果、ロスト発生フラグ３６０がオンの場合の処理について説明する（ステップＳ７でＹＥＳ）。この場合は、まず、ステップＳ１５で、プロセッサ３１は、プレイヤキャラ２０１の残数から１を減らす。次に、ステップＳ１６で、プロセッサ３１は、プレイヤキャラ２０１の残数が０か否かを判定する。当該判定の結果、０ではない場合は（ステップＳ１６でＮＯ）、ステップＳ１７で、プロセッサ３１は、リスタート処理を実行する。
【0168】
図４９は、上記リスタート処理の詳細を示すフローチャートである。図４９において、まず、ステップＳ１３１で、プロセッサ３１は、ロスト発生フラグ３６０にオフを設定する。また、この際、特殊状態化回数３５７も０に設定する。つまり、リスタートに伴い、特殊状態への変化回数のカウントをリセットする。この点、他の実施形態では、リセットせずにリスタート後も特殊状態化回数３５７引き継ぐようにしてもよい。
【0169】
次に、ステップＳ１３２で、プロセッサ３１は、上記選出済みフラグ３６６および配置完了フラグ３６７を初期化する。これにより、中間地点からリスタートした場合、再度リプレイデータのダウンロードおよび新たなリプレイゴーストの再配置が行われ得る。
【0170】
次に、ステップＳ１３３で、プロセッサ３１は、所定のリスタート地点にプレイヤキャラ２０１を配置する。また、これに併せて、仮想カメラもプレイヤキャラ２０１が撮像範囲に入るような位置に移動される。次に、ステップＳ１３４で、プロセッサ３１は、ゲーム画面を生成して表示する。以上で、リスタート処理は終了する。
【0171】
図３６に戻り、リスタート処理が終われば、上記ステップＳ２に戻り、処理が繰り返される。
【0172】
一方、上記ステップＳ１６の判定の結果、プレイヤキャラ２０１の残数が０の場合は（ステップＳ１６でＹＥＳ）、ステップＳ１８で、プロセッサ３１は、ゲームオーバーの演出を表示する。その後、上記ステップＳ１３に処理が進められる。この場合は、自パネルの情報をゲームサーバ１に送信してからステージ部屋から退室する流れとなる。
【0173】
以上で、ステージプレイ処理の詳細説明を終了する。
【0174】
［ゲームサーバ１の処理］
次に、ゲームサーバ１で実行される処理の詳細について説明する。図５０は、ゲームサーバ１に係る処理の詳細を示すフローチャートである。図５０において、まず、ステップＳ１５１で、ゲームサーバ１のプロセッサ１１は、マッチング処理を実行する。この処理では、プレイヤからのステージプレイの開始要求に応じて、プレイヤ同士のマッチング、すなわち、各プレイヤが入室するステージ部屋を決定する処理が実行される。また、その結果をゲーム装置３に送信する処理も実行される。
次に、ゲームサーバ１で実行される処理の詳細について説明する。図５０は、ゲームサーバ１に係る処理の詳細を示すフローチャートである。図５０において、まず、ステップＳ１５１で、ゲームサーバ１のプロセッサ１１は、マッチング処理を実行する。この処理では、プレイヤからのステージプレイの開始要求に応じて、プレイヤ同士のマッチング、すなわち、各プレイヤが入室するステージ部屋を決定する処理が実行される。また、その結果をゲーム装置３に送信する処理も実行される。
【0175】
次に、ステップＳ１５２で、プロセッサ３１は、ステージ部屋を管理する処理を行う。この処理では、新たな部屋を作成する処理、プレイヤの補填を行う処理、プレイヤがいなくなった部屋を削除する処理等、ステージ部屋管理データ３０４を適宜更新して各ステージ部屋を管理する処理が行われる。
【0176】
次に、ステップＳ１５３で、プロセッサ３１は、パネル情報を管理する処理を実行する。この処理では、各ゲーム装置３から送信されてい自パネルデータ３９１を受信し、上記パネル管理データ３０６への登録や更新が行われる。また、必要に応じて、所定のゲーム装置３からの要求に応じて、上記サーバパネルの基となるパネル情報３３２を送信する処理も実行される。
【0177】
次に、ステップＳ１５４で、プロセッサ３１は、リプレイデータを管理する処理を行う。この処理では、各ゲーム装置３から受信したリプレイデータに基づいてリプレイ管理データ３０５への登録や更新が行われる。
【0178】
その後、プロセッサ１１は、上記ステップＳ１５１に戻り、処理を繰り返す。以上で、ゲームサーバ１に係る処理の詳細説明は終了する。
【0179】
このように、本実施形態では、プレイヤキャラ２０１にミスイベントが発生した場合、近くに復活補助オブジェクトであるリモートキャラがいる場合は、プレイヤキャラ２０１をロストさせずに、プレイヤキャラ２０１を一旦特殊状態に変化させる。そして、復活可能時間中にリモートキャラに接触することで、通常状態に復活することができる。これにより、シングルプレイの感覚でゲームを進行させつつ、オンラインでプレイすることのメリットをプレイヤに提供できる。そのため、オンラインマルチでゲームプレイすることを促進できる。
【0180】
また、リモートキャラだけでなく、各リモートキャラが配置したリモートパネルや上記サーバパネルも上記復活補助オブジェクトとして機能させている。そのため、あるプレイヤは、リモートパネルを配置しておけば、これが自分の代わりに他のプレイヤの手助けとして機能することを期待できる。これにより、例えば、あるプレイヤが他のプレイヤの復活を補助することを意識して自分のペースでゲームが進行できなくなることを抑制できる。
【0181】
また、本実施形態では、上記のように、ステージの中間地点を通過したことに応じて、リプレイゴーストを出現させている。当該リプレイゴーストは、一見しただけでは、上記リモートキャラとの見分けがつかないものとなっている。また、当該リプレイゴーストも、上記復活補助オブジェクトとして機能する。そのため、ステージの途中まで他のプレイヤとの出会いが無かった場合でも、ステージ後半については他のプレイヤとオンラインで繋がっており、同じステージ部屋で一緒に遊んでいるプレイ体験をプレイヤに提供できる。つまり、ステージプレイの開始から中間地点に到達するまでは、他のプレイヤと出会えることへの期待感を与える。例えばステージ前半であれば、後から入室してきたプレイヤのリモートキャラが追いついてくることは十分考えられる。そのため、ステージプレイ開始後にすぐにゴーストは出現させずに、しばらくの間は、他のプレイヤの入室およびリモートキャラの出現を待つようにしている。その一方で、ステージのプレイ開始から中間地点に到達しても他のプレイヤが入室してこないような場合は、リプレイゴーストを出現させることで、あたかもリモートキャラと一緒にステージを進んでいるようなプレイ体験を提供する。これにより、オンラインでプレイすることの意義を与え、プレイヤが積極的にオンラインでプレイすることを促進できる。また、リプレイゴースト出現後に他のプレイヤが入室してきた場合は、入室した人数に応じてリプレイゴーストを消去してリモートキャラを出現させている。そのため、コミュニケーションを取ることが可能なリモートキャラとのプレイを優先することもできる。
【0182】
また、復活補助オブジェクトによってプレイヤキャラを特殊状態から通常状態に復活位置させる際、上記のような探索オブジェクトを移動させながら、復活位置を探索している。この場合、復活位置の探索に係る毎フレームの処理としては、探索オブジェクトのある位置が復活位置としての条件を満たしているか否かを判定するだけとなる。そのため、例えば、ステージ内の復活可能な位置を探索してから復活させる場合と比べて、各フレームの処理負荷を軽くして復活位置を探索する処理を実行できる。また、探索中オブジェクトを移動させて探索する様子（探索プロセス）をプレイヤに示すことで、プレイヤが復活位置を見つけやすく、かつ、復活位置がなぜその位置になったのかについて、プレイヤに納得感を与えることができる。
【0183】
［変形例］
なお、上記リプレイゴーストに関して、例えば、プレイヤがプレイヤキャラ２０１として使用しているキャラクタと同じキャラクタが上記リプレイゴーストとして選出されることもあり得る。この場合、リプレイゴーストに係るキャラクタの外観については他のキャラクタの外観に変更してもよい。プレイヤキャラ２０１と同じキャラクタであるリプレイゴーストがいると、場合によっては見分けがつきにくく、プレイヤに不要な混乱を与えることを抑制するためである。
なお、上記リプレイゴーストに関して、例えば、プレイヤがプレイヤキャラ２０１として使用しているキャラクタと同じキャラクタが上記リプレイゴーストとして選出されることもあり得る。この場合、リプレイゴーストに係るキャラクタの外観については他のキャラクタの外観に変更してもよい。プレイヤキャラ２０１と同じキャラクタであるリプレイゴーストがいると、場合によっては見分けがつきにくく、プレイヤに不要な混乱を与えることを抑制するためである。
【0184】
また、上記の例では、リプレイゴーストを出現させるタイミングについて、プレイヤキャラが上記中間地点に到達した場合を例に挙げた。この点、特定のステージでは、スタート地点からリプレイゴーストを出現させるようにしてもよい。この場合は、当該特定のステージにおいてはリプレイデータの記録もスタート地点から開始するようにすればよい。
【0185】
また、上記の例では、リプレイゴーストの見た目はリモートキャラと変わらない場合を例示した。この点、他の実施形態では、リモートキャラであるかリプレイゴーストであるのかをプレイヤが区別可能なように、その見た目を異ならせるようにしてもよい。
【0186】
また、上記の例では、リモートキャラが存在する場合はリプレイゴーストを出現させない（リプレイの再生をしない）という例を挙げた。他の実施形態では、リモートキャラが存在している場合でも、リプレイゴーストを出現させてもよい。例えばステージ部屋の定員の空きの分だけリプレイゴーストを出現させてもよい。更に、この場合は、いずれかのゲーム装置で出現させたリプレイゴーストの情報を他のゲーム装置との間で共有してもよい。例えば、ゲーム装置Ａのゲーム処理においてリプレイゴーストを出現させる処理が行われた場合、位置情報を共有したり、リプレイデータそのものを共有する等して、同じステージ部屋の他のゲーム装置でも、同じリプレイゴーストが出現するようにしてもよい。
【0187】
また、上記実施形態では、所定条件下でミスイベントが発生したときにプレイヤキャラ２０１が特殊状態に変化する例を挙げた。この点、他の実施形態では、プレイヤが所定の操作を行うことで、自発的に上記特殊状態に変化できるようにしてもよい。但し、特殊状態から通常状態への復活は自発的な操作では行えず、上記のように復活補助オブジェクトに復活可能時間内に接触する必要があるようにしてもよい。これにより、プレイヤはステージを攻略する上で、戦略的にわざと特殊状態となって、ステージ上の難所を抜けてから復活する、というようなプレイが可能となる。そのため、オンラインプレイによるメリットを恒常しつつ、プレイの幅を広げることも可能となる。
【0188】
また、上記リモートパネルに関して、他の実施形態では、退室したプレイヤが配置したリモートパネルについては、退室後所定の時間が経過したら自動的に消去するように制御してもよい。
【0189】
また、上記パネル情報をゲームサーバ１に送信するタイミングについて、上記の例ではステージ部屋から退室する時に送信する例を挙げた。他の実施形態では、配置がおこなわれる都度、ゲームサーバ１へのパネル情報の送信が行われてもよい。また、同一プレイヤについての複数のパネル情報をゲームサーバ１に登録可能としてもよい。
【0190】
また、上記実施形態では、通常状態のプレイヤキャラ２０１とリモートキャラとの衝突判定は行われないという例で説明した。この点、他の実施形態では、衝突判定自体は行うが、リモートキャラがプレイヤのゲームプレイに直接影響は及ぼさないような処理を行ってもよい。例えば、通常状態のプレイヤキャラ２０１が（半透明の）リモートキャラと接触したとき、リモートキャラが少し押されるような反応を演出的に表示しつつ、リモートキャラに係るリモートプレイヤ名を一時的に表示するような処理を行ってもよい。
【0191】
また、上記実施形態では、各ゲーム装置でプレイするプレイヤ数が１人である場合を想定して説明していた。この点、１台のゲーム装置について例えば２人のプレイヤが同時にステージプレイに参加できるようにしてもよい。例えば、ゲーム装置Ａにおいて、プレイヤＡとプレイヤＢが２人同時プレイ（ローカルマルチプレイ）の態様で、同じゲーム画面内で各自のプレイヤキャラであるプレイヤキャラＡおよびプレイヤキャラＢが表示されるようにしてもよい。また、この場合は、プレイヤキャラＡおよびプレイヤキャラＢについては、リモートキャラのような半透明表示は行わず、双方とも不透明の態様で表示すればよい。また、プレイヤキャラＡおよびプレイヤキャラＢはお互いに復活補助オブジェクトとして機能させればよい。また、上記パネル配置については、お互いに相手が配置したパネルを上記リモートパネルとして扱ってもよい。あるいは、いずれか一方のプレイヤキャラが配置したものだけを上記リモートパネルとして扱ってもよい。
【0192】
なお、上記のようなローカルマルチプレイの場合、サーバに送信するパネル情報については、いずれか１人のプレイヤが配置したパネル情報のみ送信するようにしても良よい。
上述したサーバパネルについては、最大で２つまで配置されるようにすればよい。
上述したサーバパネルについては、最大で２つまで配置されるようにすればよい。
【0193】
また、上記リプレイゴーストについては、プレイヤアクター数が１部屋で最大４つまでとなるように調整されるため、最大で２体分までの配置とすればよい。
【0194】
また、ローカルマルチプレイに係るプレイヤキャラが全て通常状態ではなくなった場合は、特殊キャラがいなければ、その時点で、当該ローカルマルチプレイに係るプレイヤキャラについて上記ロストが発生する。一方、いずれかが特殊キャラになっていた場合は、この時点ではまだロストは発生しない。例えば上記リモートキャラやリモートパネルによって復活できる可能性があるためである。
【0195】
また、上記実施形態では、特殊キャラであるときに復活可能時間内に復活補助オブジェクトに接触できれば、プレイヤキャラの残数を減らさずに復活させる例を挙げた。この点、他の実施形態では、残数を減らしたうえで復活させるようにしてもよい。この場合でも、復活する位置は復活補助オブジェクトの近くの位置になるため、リスタート地点まで戻されて復活する場合よりは、プレイヤにとって有利になる。
【0196】
また、上記実施形態では、上記図１９に示したような状況の場合に、探索オブジェクトを使って復活可能な位置を探索する処理を行っていた。上述したような位置の探索処理については、復活位置に限らず、所定のキャラクタを出現または配置させたい位置を探索する場合にも適用可能である。例えば、ゲーム開始時にプレイヤキャラクタや敵キャラクタを、ゲーム空間内のランダムな位置に出現させたい場合、上述したような探索オブジェクトを用いた出現位置の探索を行ってもよい。また、例えば、ゲーム内ギミックとして、プレイヤキャラクタを現在位置とは異なる位置にワープまたはテレポートさせるギミックがあるとする。このようなワープ／テレポート先を探索する場合に、上記のような探索オブジェクトを用いた出現位置に探索を行ってもよい。
【0197】
また、上記探索処理に関して、上記の例では特殊キャラを探索中オブジェクトに変更する例を示した。他の実施形態では、探索中オブジェクトについては、例えば通常状態のプレイヤキャラの表示態様を変更したものをもちいてもよい。例えば、通常状態のプレイヤキャラを半透明表示にしたものを上記探索中オブジェクトとして用いてもよい。
【符号の説明】
【0198】
１ ゲームシステム
３ 情報処理端末（ゲーム装置）
４ コントローラ
３１ プロセッサ
３２ 記憶部
３３ 無線通信部
３４ コントローラ通信部
３ 情報処理端末（ゲーム装置）
４ コントローラ
３１ プロセッサ
３２ 記憶部
３３ 無線通信部
３４ コントローラ通信部
【図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】
【図45】
【図46】
【図47】
【図48】
【図49】
【図50】