JP2023166360A - ゲームプログラム、ゲームシステム、およびゲーム処理方法 - Google Patents

Abstract

【課題】他のプレイヤによって自分のプレイが阻害されることを軽減できるゲームプログラム、ゲームシステム、およびゲーム処理方法を提供すること。【解決手段】ゲームステージ内でミスが発生した際に、所定範囲内に他プレイヤオブジェクトが存在していれば、プレイヤオブジェクトをダメージを受けない特殊状態に遷移させる。特殊状態の間に、他プレイヤオブジェクト、または、当該他のプレイヤオブジェクトによってゲームステージ内に配置される配置オブジェクトのいずれかに触れた場合、当該プレイヤオブジェクトを特殊状態から通常状態に戻す。その一方で、特殊状態中に他プレイヤオブジェクトまたは配置オブジェクトのいずれにも触れることができなかった場合は、ゲームステージのプレイを終了させる。【選択図】図４２

Description

本開示は、マルチプレイゲーム処理に関する。

従来から、マルチプレイゲームを行うためのゲームシステムが知られている（例えば、非特許文献１）。当該ゲームでは、１台のゲーム装置で、４人までのプレイヤが同時にプレイすることができた。また、当該ゲームでは、プレイヤキャラクタが一時的にダメージを受けない状態になる「シャボン」という状態となることができた。そして、あるプレイヤキャラクタが「シャボン」となることで、苦手な場所を他のプレイヤに任せて、自分は「シャボン」のまま運んでもらう、というプレイも可能であった。

任天堂株式会社、"ニュースーパーマリオブラザーズＷｉｉ"、［online］、［令和５年６月５日検索］、インターネット（ＵＲＬ：https://www.nintendo.co.jp/wii/smnj/play/kyouryoku.html）

しかし、先に進みたいプレイヤにとっては、他のプレイヤの手助けをしたりする等で、自分が進んでいた位置まで他のプレイヤが追いつくのを待つ必要が発生する局面があった。そのため、ゲームを進めるテンポが悪くなるとプレイヤに感じさせる虞があった。換言すれば、他のプレイヤによって自分のプレイが阻害され得る可能性があった。

上記課題に鑑みて、例えば以下のような構成例が挙げられる。

（構成１）
構成１は、プレイヤの操作に基づいて移動制御可能なプレイヤオブジェクトと、ネットワークを介して接続された他のゲーム装置から受信した情報に基づいて移動制御される他プレイヤオブジェクトとを含むゲームステージを生成する処理を実行するゲーム装置のコンピュータに実行させる、ゲームプログラムであって、コンピュータを、所定のゲームステージ内でミスによってプレイが終了し得るイベントが発生した際に、プレイヤオブジェクトを前記ゲーム空間内でダメージを受けない特殊状態に遷移させる遷移手段、プレイヤオブジェクトが特殊状態である間に、前記他プレイヤオブジェクトと、前記他のプレイヤオブジェクトによって前記ゲームステージ内に配置される配置オブジェクトとを含む復活補助オブジェクトに触れた場合、ゲームステージのプレイを終了させずに、当該プレイヤオブジェクトを特殊状態から当該ゲームステージ内でダメージを受け得る通常状態に戻す復活手段、プレイヤオブジェクトが特殊状態である間に復活補助オブジェクトに触れないまま所定条件が満たされた場合に、ゲームステージのプレイを終了させる終了手段、として機能させる。

上記構成によれば、他のプレイヤオブジェクトだけでなく、他のプレイヤが配置した配置オブジェクトによっても特殊状態から通常状態への復活が可能となる。これにより、プレイヤオブジェクトと他のプレイヤオブジェクトが離れている状況でも、配置オブジェクトを用いて間接的に上記復活の手助けができる。そのため、配置オブジェクトを配置しておけば、ミスが発生した他のプレイヤオブジェクトが離れている場合でも、特に助けに行かなくてもよく、自分のペースでプレイを進行できる。

（構成２）
構成２は、上記構成１において、プレイヤオブジェクトによって配置された配置オブジェクトに特殊状態であるプレイヤオブジェクトが触れた場合は、当該プレイヤオブジェクトは通常状態には戻さないようにしてもよい。

上記構成によれば、ゲームの難易度を適切なものとすることができ、興趣性が低下することを抑制できる。

（構成３）
構成３は、上記構成１において、ゲームプログラムは、プレイヤオブジェクトが配置オブジェクトを配置した際、当該配置オブジェクトの位置情報を少なくとも含む配置情報を所定のサーバに送信する送信手段として更にコンピュータを機能させてもよい。そして、配置手段は、所定のサーバに保存された上記配置情報に基づいた配置オブジェクトをゲームステージ内に配置してもよい。

上記構成例によれば、同じゲームステージに他のプレイヤがいない場合でも、配置オブジェクトを配置することができる。また、この配置オブジェクトを用いても上記特殊状態から通常状態に復活できるため、プレイヤの利便性を向上できる。

（構成４）
構成４は、上記構成３において、所定のサーバに保存された配置情報に基づき配置された配置オブジェクトは、配置された時点では復活補助オブジェクトとして機能せず、プレイヤオブジェクトが当該配置オブジェクトに接触したときに、復活補助オブジェクトとしての機能が有効化されてもよい。

上記構成によれば、最初は復活補助オブジェクトとして機能しないように制御することで、ゲームバランスを適正化できる。また、サーバに保存された配置情報に基づき配置された配置オブジェクトをチェックポイントとして扱うというプレイを提供でき、ゲームの興趣性を向上できる。

（構成５）
構成５は、上記構成３において、配置手段は、所定のタイミングにおいて、ゲームステージ内に配置オブジェクトが１つも存在しないときに、所定のサーバに保存された配置情報に基づいた配置オブジェクトをゲームステージ内に配置してもよい。

上記構成によれば、同じゲームステージ内に他のプレイヤオブジェクトがいない場合でも、特殊状態から通常状態に戻る機会をプレイヤに与える、あるいは、その機会を増やすことができる。

（構成６）
構成６は、上記構成１において、ゲームプログラムは、所定のゲームステージ内でミスが発生した際に、プレイヤオブジェクトから所定範囲内に復活補助オブジェクトが存在するかどうかを判定する補助オブジェクト判定手段としてコンピュータを更に機能させてもよい。そして、遷移手段は、補助オブジェクト判定手段によってプレイヤオブジェクトから所定範囲内に復活補助オブジェクトが存在すると判定された場合に、プレイヤオブジェクトをゲームステージ内でダメージを受けない特殊状態に遷移させてもよい。

上記構成によれば、ミスが発生したときでも、所定範囲内に復活補助オブジェクトが存在していれば、すぐにはプレイを終了させず、特殊状態に遷移させる。そして、遷移状態において復活補助オブジェクトと接触すれば通常状態に復活できる。そのため、ゲームステージ内において近くに他のプレイヤオブジェクトがいる状況であれば、ミスしてもすぐにプレイ終了とならずにプレイを継続できる機会がプレイヤに与えられることになる。これにより、このような機会を得るために、他のプレイヤと一緒にオンラインでプレイすることへのモチベーションを提供できる。また、他のプレイヤが上記プレイが終了し得るイベントを発生させた際に、プレイヤオブジェクトと当該他のプレイヤオブジェクトとの距離が所定範囲外であれば、そもそも上記復活の機会は得られないことになるため、プレイヤは他のプレイヤのことを必要以上に気にすることなく、自分のペースを維持しながらゲームプレイを継続できる。

（構成７）
構成７は、上記構成６において、プレイヤオブジェクトは、特殊状態の間も操作可能であり、プレイヤオブジェクトが特殊状態である状態は所定時間継続し、終了手段は、プレイヤオブジェクトが特殊状態に遷移した後、所定時間内に復活補助オブジェクトに触れなかった場合、所定のステージのプレイを終了させてもよい。

上記構成によれば、特殊状態でいることに時間制限があるため、プレイに緊張感をもたせて、ゲームの興趣性を向上できる。

（構成８）
構成８は、上記構成７において、同じゲームステージ内において特殊状態への遷移が複数回発生した場合、所定時間は、特殊状態への遷移回数の増加に応じて徐々に短くなってもよい。

上記構成によれば、何度も特殊状態に遷移していると、徐々に復活できる機会が減っていくことになるため、ゲームプレイに緊張感を持たせることができる。

（構成９）
構成９は、上記構成６において、ゲームプログラムは、他のプレイヤのプレイ内容をリプレイするためのリプレイデータに基づいて動作するゴーストキャラクタをゲーム空間内に出現させるゴースト出現手段としてコンピュータを更に機能させてもよい。更に、復活補助オブジェクトには、他のプレイヤに係るゴーストキャラクタも含まれていてもよい。

（構成１０）
構成１０は、上記構成９において、ゲームプログラムは、所定の期間におけるプレイヤオブジェクトの動作内容をリプレイデータとして記録し、所定のタイミングで所定のサーバに当該リプレイデータを送信するリプレイ送信手段と、プレイヤによるゲームステージのプレイが開始された後、所定のタイミングで、他のプレイヤが送信したリプレイデータを所定のサーバから取得するリプレイ取得手段として更にコンピュータを機能させてもよい。更に、ゴースト出現手段は、サーバから取得したリプレイデータに基づいてゴーストキャラクタを動作させてもよい。

上記構成によれば、ゴーストキャラクタを他のプレイヤオブジェクト代わりに出現させることができる。これにより、他のプレイヤとの出会いが無いままプレイを続けているような状況でも、ゴーストキャラクタを出現させることで、あたかも他プレイヤとオンラインで一緒にプレイしている体験を提供できる。

（構成１１）
構成１１は、上記構成６において、他のプレイヤオブジェクトは通常状態のプレイヤオブジェクトに対しては影響を及ぼさないようにしてもよい。

上記構成によれば、通常状態では他のプレイヤキャラから干渉は受けないため、自分のゲームプレイが他のプレイヤのプレイによって阻害されることがない。そのため、ゲームステージの進行自体はプレイヤ自身のペースで進めつつも、プレイが終了し得るイベントが発生したときは他のプレイヤに助けてもらうということが可能となる。これにより、オンラインでプレイすることのメリットを提供し、オンラインプレイを促進できる。

（構成１２）
構成１２は、上記構成１１において、他のプレイヤオブジェクトは、プレイヤオブジェクトが通常状態のときは半透明の態様で表示され、当該プレイヤオブジェクトが特殊状態のときは、不透明の態様で表示されてもよい。

上記構成によれば、プレイヤオブジェクトが特殊状態のとき、他のプレイヤオブジェクトに接触すれば何かが起こるということを直感的にプレイヤに把握させることができる。

（構成１３）
構成１３は、上記構成１２において、プレイヤオブジェクトが特殊状態のときは、復活補助オブジェクトを除き、ゲームステージの彩度を下げた態様でゲーム画面が表示されてもよい。

上記構成によれば、プレイヤオブジェクトが特殊状態のときに、復活対象オブジェクトを視覚的に目立たせることができる。
（構成１４）
構成１４は、上記構成１において、復活手段は、プレイヤオブジェクトを通常状態に戻す際、当該通常状態に戻した直後に上記ミスが発生しないような位置に、通常状態のプレイヤオブジェクトを配置してもよい。

上記構成によれば、特殊状態から通常状態に戻ると同時に、ミスが発生してしまうことを抑制できる。

本開示によれば、プレイヤがミスした場合でも、他プレイヤオブジェクトおよび他のプレイヤオブジェクトによってゲームステージ内に配置される配置オブジェクトとを含む復活補助オブジェクトに触れることができれば、プレイが終了せずに継続することができる。

本実施形態に係るゲームシステムの全体像を示す模式図 ゲームサーバ１のハードウェア構成を示すブロック図 ゲーム装置３のハードウェア構成を示すブロック図 ゲーム画面の一例 ゲーム画面の一例 ゲーム画面の一例 ゲーム画面の一例 ゲーム画面の一例 ゲーム画面の一例 ゲーム画面の一例 ゲーム画面の一例 状態の遷移と説明するための図 復活位置について説明するための図 復活位置について説明するための図 復活位置について説明するための図 復活位置について説明するための図 復活位置について説明するための図 復活位置について説明するための図 復活位置について説明するための図 復活位置について説明するための図 復活位置について説明するための図 特殊状態化のエフェクトの一例 パネルについて説明するための図 パネルについて説明するための図 パネルについて説明するための図 パネルについて説明するための図 ゲームサーバ１の記憶部１２に記憶される各種データの一例を示すメモリマップ ステージ部屋管理データ３０４のデータ構成の一例 リプレイ管理データ３０５のデータ構成の一例 パネル管理データ３０６のデータ構成の一例 ゲーム装置３の記憶部３２に記憶される各種データの一例を示すメモリマップ リモートキャラデータ３６１のデータ構成の一例 プレイヤアクター管理データ３６３のデータ構成の一例 パネルデータ３６４のデータ構成の一例 ゲーム装置３で実行されるゲーム処理の詳細を示すフローチャート ゲーム装置３で実行されるゲーム処理の詳細を示すフローチャート ステージ準備処理の詳細を示すフローチャート 入退室チェック処理の詳細を示すフローチャート 入退室チェック処理の詳細を示すフローチャート リモートパネルチェック処理の詳細を示すフローチャート 通常状態処理の詳細を示すフローチャート 通常状態処理の詳細を示すフローチャート 自パネル配置処理の詳細を示すフローチャート 特殊状態処理の詳細を示すフローチャート リプレイゴースト処理の詳細を示すフローチャート ステージクリア処理の詳細を示すフローチャート リスタート処理の詳細を示すフローチャート ゲームサーバ１で実行されるゲームサーバ処理の詳細を示すフローチャート

以下、本発明の一実施形態について説明する。図１は、本実施形態に係る情報処理システム（ゲームシステム）の全体像を示す模式図である。本実施形態の情報処理システム１００は、ゲームサーバ１と、複数の情報処理端末３とを含む。ゲームサーバ１、情報処理端末３とは、インターネット等のネットワーク１０を介して通信可能に構成されている。本実施形態では、このような構成で、情報処理が実行されるが、以下では、当該情報処理の一例として、ゲーム処理を例として説明する。具体的には、情報処理端末３上にゲームプログラムがインストールされ、必要に応じてゲームサーバ１と通信を行いながら実行されるゲーム処理を例示する。

［ゲームサーバのハードウェア構成］
次に、上記ゲームサーバ１のハードウェア構成について説明する。図２は、ゲームサーバ１のハードウェア構成を示すブロック図である。ゲームサーバ１は、プロセッサ１１と、記憶部１２と、通信部１３とを少なくとも備えている。プロセッサ１１は、各サーバを制御するための各種プログラムを実行する。記憶部には、プロセッサ１１によって実行される各種プログラムおよび利用される各種データが格納される。通信部１３は、有線、または無線通信によってネットワークと接続し、上記情報処理端末３または他のサーバとの間で所定のデータを送受信する。なお、本実施形態では、ゲームサーバ１が１つである例を図示しているが、分散処理を行うサーバ群として構成されていてもよい。

［ゲーム装置のハードウェア構成］
次に、上記情報処理端末３について説明する。当該情報処理端末３は、例えばスマートフォン、据置型または携帯型のゲーム装置、タブレット端末、携帯電話、パーソナルコンピュータ、ウェアラブル端末等である。本実施形態では、据置型ゲーム装置（以下、単にゲーム装置と呼ぶ）を情報処理端末３の一例として説明する。

図３は、本実施形態に係るゲーム装置３のハードウェア構成の一例を示すブロック図である。図３において、ゲーム装置３は、プロセッサ３１を備える。プロセッサ３１は、ゲーム装置３において実行される各種の情報処理を実行する情報処理部であって、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）のみから構成されてもよいし、ＣＰＵ機能、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）機能等の複数の機能を含むＳｏＣ（Ｓｙｓｔｅｍ－ｏｎ－ａ－ｃｈｉｐ）から構成されてもよい。プロセッサ３１は、記憶部３２に記憶される情報処理プログラム（例えば、ゲームプログラム）を実行することによって、各種の情報処理を実行する。なお、記憶部３２は、例えば、フラッシュメモリやＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の内部記憶媒体であってもよいし、図示しないスロットに装着される外部記憶媒体等を利用する構成でもよい。

また、ゲーム装置３は、ゲーム装置３が他のゲーム装置３や上記サーバと無線通信を行うための無線通信部３３を備える。当該無線通信としては、例えば、インターネット通信や近距離無線通信が用いられる。

また、ゲーム装置３は、ゲーム装置３がコントローラ４と有線または無線通信を行うためのコントローラ通信部３４を備える。

また、ゲーム装置３には、画像音声出力部３５を介して表示部５（例えば、テレビ等）が接続される。プロセッサ３１は、（例えば、上記の情報処理の実行によって）生成した画像や音声を、画像音声出力部３５を介して表示部５に出力する。

次に、コントローラ４について説明する。コントローラ４は、方向入力デバイスの一例であるアナログスティック４２を少なくとも１つ備える。当該アナログスティック４２は、方向を入力することが可能な方向入力部として用いることができる。ユーザは、アナログスティック４２を傾倒することによって傾倒方向に応じた方向の入力（および、傾倒した角度に応じた大きさの入力）が可能である。また、コントローラ４は、各種操作ボタンを含むボタン部４３を備える。例えば、コントローラ４は、上記ハウジングの主面上に複数個の操作ボタンを備えていてもよい。

また、コントローラ４は、慣性センサー４４を備える。具体的には、コントローラ４は、慣性センサー４４として、加速度センサー、角速度センサーを備えている。本実施形態においては、加速度センサーは、所定の３軸方向に沿った加速度の大きさを検出する。また、角速度センサーは、所定の３軸回りの角速度を検出する。

また、コントローラ４は、上記コントローラ通信部３４と有線または無線通信を行うための通信部４１も備える。上記アナログスティック４２に対する方向入力内容、ボタン部４３の押下状態を示す情報、および、慣性センサー４４による各種の検出結果は、適宜のタイミングで繰り返し通信部４１へ出力され、ゲーム装置３に送信される。

［本実施形態における情報処理の概要］
次に、本実施形態に係る情報処理の概要を説明する。本実施形態では、情報処理の一例として、仮想空間内に存在するプレイヤキャラクタオブジェクト（以下、プレイヤキャラと呼ぶ）をプレイヤが操作して遊ぶゲーム処理を想定して説明する。より具体的には、本実施形態では、横スクロール型のアクションゲーム（以下、本ゲームと呼ぶ）を想定して説明する。本ゲームでは、プレイの主な舞台となる、「ステージ」と呼ばれる２次元の仮想空間が用意されている。当該ステージには、スタート地点とゴール地点が設定されている。スタート地点からゴール地点までの間には、様々な敵キャラクタや障害物、ジャンプ台や落とし穴等の各種ギミックが配置されている。そして、本ゲームは、これら敵キャラクタ等を倒したり回避したりしながら、プレイヤキャラをゴール地点に到達させるゲームである。なお、当該ステージは、ゲームによっては「コース」や「ラウンド」等と呼ばれることもある。また、本実施形態では、ゲーム画面が２Ｄ画面で表示されるゲームを例示するが、他の実施形態では、上記仮想空間は３次元の仮想空間であり、１人称視点や３人称視点等の３Ｄ画面で表示されるゲームであってもよい。

図４に、上記ステージをプレイ中のゲーム画面（以下、ステージ画面と呼ぶ）の一例を示す。図４の例は、スタート地点付近の画面、すなわち、当該ステージのプレイを開始した直後の画面例である。図４では、プレイヤキャラ２０１と、敵キャラクタ２０２が表示されている。その他、ブロック等の各種地形オブジェクトも表示されている。なお、本ステージでは、ステージの左端付近にスタート地点が設定され、ステージの右端付近にゴール地点が設定されているものとする。そのため、全体的なゲーム進行として、プレイヤキャラ２０１を画面の右方向に向けて進ませていくようなステージ構成となっている。このようなステージ画面において、プレイヤは、プレイヤキャラ２０１を操作して、ゴール地点に向けて移動させていく。プレイヤキャラの移動にあわせて、ステージの別の場所がステージ画面として表示されることになる。そして、プレイヤキャラがゴール地点に到達すれば、当該ステージをクリアしたことになる。

また、上記ステージには、スタート地点とゴール地点の略中間となる位置に「中間地点」が設定されている。当該中間地点には、中間地点であることを示す中間地点オブジェクトが配置されている。プレイヤキャラが当該中間地点オブジェクトに接触すると、それ以降、ゴールするまでの間のプレイにおいてリスタートすることになった場合、当該中間地点からリスタートできるようになる。なお、中間地点到達前は、スタート地点からリスタートする。なお、中間地点として設定する位置については、スタート地点からゴール地点までの略中間となる位置に限らず、スタート地点からゴール地点までの途中の位置であれば、所定の位置を中間地点として設定してもよい。

［オンラインプレイ要素について］
本ゲームの基本的なゲーム進行の流れは上述の通りであり、基本的にはシングルプレイの感覚でゲームがプレイできる。更に、本ゲームでは、マルチプレイも可能である。一例として、本ゲームは、インターネット経由で上記サーバや他のゲーム装置３と接続して他のプレイヤとプレイすることが可能なオンラインプレイ要素も有する。

以下、本ゲームのオンラインプレイ要素に関して説明する。まず、全体的なネットワーク的な構成に関して簡単に説明する。基本的なネットワーク構成については、上記図１で示したような構成となる。そして、本ゲームでは、いわゆるＭＯ（Multiplayer Online）タイプのオンラインゲームにおける通信グループの構成を利用したゲームを提供する。具体的には、各ステージに対応する通信グループ（以下、ステージ部屋と呼ぶ）とが適宜生成および管理され得る。換言すれば、各ステージに相当する仮想空間が用意され、当該仮想空間に、上記ゲームサーバ１によってマッチングされた所定人数のプレイヤが接続するという形態である。また、同じステージについて、複数のステージ部屋が並列に存在し得る。

また、ステージ部屋には入室可能な人数の最大値が設けられている。一例として、本ゲームでは、ステージ部屋は１部屋に４人まで入室可能であるとする。また、本ゲームでは、一例として、同じステージ部屋のゲーム装置３は、Ｐ２Ｐ（Peer to peer）の通信方式で接続されるものとする。他の実施形態では、サーバ経由の通信方式を用いてもよい。

図５は、他のプレイヤが既に入室しているステージ部屋にプレイヤが入室した場合の、当該プレイヤのゲーム装置３から出力されるステージ画面の一例である。図５では、他のプレイヤが操作する他のプレイヤキャラ２０３が、プレイヤが操作するゲーム装置３におけるステージ画面上に表示されている。他のプレイヤはプレイヤよりも先に入室し、ステージプレイを開始しているため、当該他のプレイヤキャラ２０３は、スタート地点よりはゴール地点に向けて少し先に進んだ位置にいる。また、図５において、当該他のプレイヤキャラ２０３は、半透明で表示されているものとする（図面では点線で示している）。

なお、本ゲームでは、プレイヤキャラとして使用できるキャラクタが複数種類用意されている。例えば、各プレイヤは、１２種類の異なるキャラクタの中からいずれかを、自分が使用するプレイヤキャラとして選択できる。そのため、上記他のプレイヤキャラ２０３は、他のプレイヤが選択したキャラクタが表示され、プレイヤキャラ２０１とは異なるキャラクタが表示され得る。

ここで、以下の説明では、同じステージ部屋に入室した他のプレイヤのことを「リモートプレイヤ」と呼び、リモートプレイヤが操作する上記他のプレイヤキャラ２０３のことを「リモートキャラ」と呼ぶ。また、詳細は後述するが、リモートプレイヤに関するプレイヤキャラとして、「リプレイゴースト」というものもステージ画面に出現し得る。また、以下では、プレイヤキャラ、リモートキャラ、リプレイゴーストのことを総称して、「プレイヤアクター」と呼ぶこともある。本ゲームでは、１部屋に４人まで入室可能なので、１部屋に最大で４体のプレイヤアクターが同時に存在し得ることになる。

［リモートキャラについて］
次に、上記リモートキャラに関してより詳しく説明する。本ゲームでは、ステージ部屋で表示されるリモートキャラは、他のプレイヤの操作が反映されて移動はするが、プレイヤのゲーム装置３で実行されているゲームプレイには直接的には干渉せず、影響は与えない。具体的には、あるステージ部屋に接続しているゲーム装置３同士の間では、基本的には、各自のプレイヤキャラの位置情報、および、各プレイヤキャラが生成した所定のオブジェクトの位置情報について共有される。プレイヤキャラが生成した所定のオブジェクトの例としては、後述する「パネル」がある。一方、敵キャラクタ等のその他のオブジェクトの状態や位置情報等は共有されない。例えば、各ゲーム装置３において、ステージプレイにおけるステージオブジェクト等との衝突判定処理については、各ゲーム装置におけるプレイヤキャラ２０１についてのみ行われ、原則的には、リモートキャラについての衝突判定処理は行われない。そのため、プレイヤキャラ２０１がリモートキャラの位置と重なっても、衝突せずにすり抜けて移動するような結果となる（但し、後述する特殊キャラに対しては例外的に衝突判定が行われる）。また、リモートキャラが敵キャラクタと重なった場合も、リモートキャラと敵キャラクタとの衝突判定等は行われず、敵キャラクタがリモートキャラをすり抜けて移動するような結果となる。また、例えば、プレイヤキャラ２０１が敵キャラクタＡを倒した場合も、この敵キャラクタＡの状態が他のゲーム装置３に反映されることはない。他のゲーム装置３において、当該他のゲーム装置の他のプレイヤが当該敵キャラクタＡを倒していなければ、当該敵キャラクタＡは依然として存在している状態で制御される。つまり、ステージプレイの進行管理自体は、各自のゲーム装置上で個別に行われ、この際に、リモートキャラがいる場合は、その表示だけは行う、というような制御となる。また、干渉しない存在であることをわかりやすくするため、リモートキャラは、基本的には、半透明の態様で表示される。そのため、各プレイヤは、基本的には、他のプレイヤの行動の影響を受けることなく、また、他のプレイヤの行動を阻害等することなく、シングルプレイと同様の感覚でステージをプレイできる。換言すれば、１人でゲームを進めつつ、リモートキャラ、換言すれば、他のプレイヤの存在は認識できる、というプレイ感・ゲーム体験が得られる。

また、上記のように、各プレイヤは他のプレイヤからの影響を受けずに個別にゲームを進行できる。そのため、４人のプレイヤが揃わないとステージプレイが開始できないというものではなく、ステージ部屋内にいるプレイヤが１人だけの場合でも、ステージプレイは開始できる。その後、途中参加のような形で、最大４人までは、他プレイヤが入室可能である。例えば、プレイヤＡが、ステージの３分の１程度まで進んだ時点で、プレイヤＢが入室した場合、プレイヤＢのプレイヤキャラはスタート地点から移動を開始することになる。つまり、プレイヤＢからすれば、プレイヤＡのプレイヤキャラがある程度先に進んだ位置に存在している状態で、ステージプレイを開始することになる。また、プレイヤＡからすれば、プレイヤＢの入室によって自身のプレイが阻害されるということもなく、引き続きプレイを継続できる。

［リプレイゴーストについて］
次に、上記リプレイゴーストについて説明する。リプレイゴーストとは、他のプレイヤのリプレイデータをゴーストとして再生するものである。本実施形態では、上記中間地点からゴール地点までの間のプレイをリプレイデータとして、上記ゲームサーバ１に保存しておく。そして、ゲームステージのプレイが一定の進行度に到達している場合に、リプレイゴーストを出現させる。より具体的には、ステージ部屋に入室しているのがプレイヤ１人のみの状態で中間地点まで進んだ場合、つまり、中間地点まで他のプレイヤとのマッチングが発生することなく進んだ場合、上記ゲームサーバ１からリプレイデータをダウンロードして、再生する。これにより、リプレイデータに基づく他のプレイヤキャラクタがゴーストとして表示され得る。これが、リプレイゴーストである。また、当該リプレイゴーストは、リプレイを再生するため、結果的に、上記リモートキャラと同様にふるまう。これにより、中間地点まで他のプレイヤが入室して来なかった場合、他プレイヤのゴーストと一緒にプレイするという状況を作り出すことができる。そのため、ステージによっては、他のプレイヤとのマッチングが中々発生しないことで、オンラインで遊んでいる意義が薄いとプレイヤに感じさせてしまうことを抑制できる。

ここで、上記リプレイゴーストは、基本的には、その見た目は上記リモートキャラと見分けがつかない。例えば、図６に、リプレイゴーストが表示されている画面例を示す。図６では、３体のリプレイゴーストが表示されている、これらは、上記リモートキャラと同様に、半透明で表示されている。また、その見た目も、リモートキャラとは変わらないものとなっている。そして、上記リモートキャラについては、生身の人間が操作していることから、例えば、感情を示す顔画像等のエモート表示を行う操作が可能である。そのため、各ゲーム装置３で個別にプレイ管理しているとは言え、このような操作によって、プレイヤ同士である程度のコミュニケーションは取れる。一方、リプレイゴーストについては、このようなコミュニケーションは取れない。そのため、リモートキャラとリプレイゴーストとの区別がつくようにしておいてもよい。例えば、リモートキャラに近づくと、それがリモートキャラであることが分かるような標識画像、例えばユーザ名等を表示してもよい。一方、リプレイゴーストについては、近づいてもこのような標識画像を表示しないようにしてもよい。これにより、当該標識画像の有無によって、プレイヤは、リモートキャラであるかリプレイゴーストであるかを判別できる。

なお、本実施形態において、より正確には、上記中間地点オブジェクトにプレイヤキャラ２０１が接触した場合に、リプレイゴーストを出現させる。これは、中間地点を通過したことをきっかけとしてリプレイゴーストが出現するということがプレイヤにわかりやすいためである。また、本例では、プレイの進行度として、中間地点を通過した場合を例に説明するが、他の実施形態では、例えば、ステージプレイ開始からの経過時間やステージ内イベントの達成度に基づいて、上記リプレイゴーストを出現させるトリガーとする進行度を判定してもよい。

以下、リプレイゴーストについて、より詳細に説明する。

［リプレイの記録について］
まず、リプレイデータの記録に関して説明する。本実施形態では、プレイヤキャラ２０１が上記中間地点オブジェジェクトに接触する（以下ではこのことを「中間地点を通過する」と表現することもある）ことで、リプレイデータの記録が開始される。そして、プレイヤキャラ２０１がゴール地点に到達することで、当該記録が停止される。その後、ステージのクリア処理に伴って、リプレイデータが上記ゲームサーバ１に送信される。

なお、中間地点オブジェクトへの接触と、ゴール地点の到達をリプレイデータの記録開始および停止のタイミングとするのは、プレイヤキャラ２０１の自然な行動で記録の開始、停止ができるからである。また、リプレイデータの記録制御のための専用のオブジェクトを別途配置しなくてもよい、等の理由によるものである。

また、中間地点の通過後ゴールするまでの間に、「ミスイベント」が発生した場合も、その時点でリプレイデータの記録は一旦停止する。当該ミスイベントについては後述するが、例えばプレイヤキャラ２０１が敵キャラクタに倒された場合等である。また、ミスイベントが発生した場合、所定の条件が揃うと、プレイが一旦中断され、プレイヤキャラ２０１の残数（いわゆる残機）が減らされた上で、中間地点からリスタートする。この場合、基本的には、リスタート前のリプレイデータが破棄され、リスタートした時点から、改めてリプレイデータの記録が開始される。但し、本実施形態では、この際、一定の確率で、リスタート前のリプレイデータは破棄せずに保持しておき、リスタートした時点からのリプレイデータの記録を行わないようにする。上記のように、ゴールすることでリプレイデータがサーバに送信されるが、上記のような制御により、プレイの途中でリスタートが発生していた場合、次のような２種類のリプレイデータが送信され得る。１つめは、ゴールまで到達した内容のリプレイデータ、すなわち、ステージをクリアした内容のリプレイデータである。そして、２つめは、途中でミスイベントが発生した内容のリプレイデータ、すなわち、ステージがクリアできなかったリプレイデータである。これにより、リプレイデータの内容を多様なものとすることができる。

また、本実施形態では、中間地点が１つだけ設定されている場合を想定して説明するが、中間地点が２つ以上設定されているステージがあってもよい。この場合は、最初に通過した中間地点から記録が開始される。また、途中でミスイベントが発生した場合は、最後に通過した中間地点からリスタートする。そして、リスタートに係るリプレイデータの記録については、この最後に通過した中間地点から改めて記録を開始する。

［リプレイのダウンロードおよび再生について］
次に、リプレイデータのダウンロード、および、再生に関して説明する。上記のようにしてゲームサーバ１にリプレイデータが送信されるが、本実施形態では、ゲームサーバ１において、上記中間地点オブジェクト（上記ステージ）毎に上記リプレイデータが紐付けられて管理される。より具体的には、ゲームサーバ１において、ステージ毎に、直近３０件分のリプレイデータが保持されている。

そして、プレイヤキャラ２０１が中間地点を通過したタイミングで、ゲーム装置３からゲームサーバ１にリプレイデータのリクエストが送信される。ゲームサーバ１からは、そのステージに対応した直近３０件分のリプレイデータが送られてくるので、ゲーム装置３でこれが受信される。ゲーム装置３では、受信した３０件分のデータの中から、ランダムで、最大３件まで（ステージ部屋の定員が４人の例のため）、リプレイゴーストとして用いるリプレイデータを選出する。この際、リプレイデータの送信元が、上記リクエストを送ったプレイヤと同じであるリプレイデータについては、選出対象から除外する。つまり、自分のリプレイデータは選出されないようにする。

そして、選出されたリプレイデータをリプレイゴーストとして再生開始する。この際、複数体のリプレイゴーストを使う場合は、再生開始タイミングを数秒毎にばらけさせるようにする。例えば、３体のリプレイゴーストを使う場合、３体同時に生成して出現させるのではなく、２体目は１体目のリプレイゴーストを出現させてから５秒後、３体目は２体目の出現から更に５秒後に出現させる、等である。

また、リプレイデータをダウンロードして再生を開始する際に、もしリモートキャラが存在していた場合は、リプレイは再生しない。例えば、中間地点通過とほぼ同じタイミングで、他のプレイヤが入室してきた場合等である。これは、リモートキャラが存在するのであれば、リモートキャラとコミュニケーションを取ってもらいたい、という観点によるものである。

また、ミスイベントの発生により、中間地点からリスタートする場合は、再度、リプレイデータのダウンロードからやり直す。そのため、リスタートした場合は、リスタート前と後とで、異なるリプレイゴーストが出現し得る。但し、前回のダウンロード完了から所定時間以上経過していない場合は、ダウンロード済みのデータを流用してもよい。もちろん、経過時間に関わらず毎回ダウンロードしなおしてもよいし、逆に、経過時間に関わらず、最初にダウンロードしたデータを流用するようにしてもよい。

［リプレイゴーストの個数、同期について］
次に、リプレイゴーストの個数管理と他のゲーム装置３との同期に関して説明する。
上記のように、本ゲームでは、各自のゲーム装置で個別にゲームの進行管理が行われ、共有する情報は、基本的には、各自のプレイヤキャラの位置情報のみとなっている。そして、リプレイゴーストについても、他のゲーム装置３との同期は行わず、各ゲーム装置３においてローカルで管理される。ここで、既にリプレイゴーストが出現している状況で、他のプレイヤが入室してきた場合を想定する。この場合、ステージ内の上記プレイヤアクターが４体以下になるような調整が行われる。例えば、プレイヤＡが３体のリプレイゴーストとプレイしている状況で、プレイヤＢが入室してきた場合を想定する。この場合、プレイヤＡのゲーム装置３では、次のような処理が行われる。まず、プレイヤキャラ２０１の現在位置から最も遠くの位置にいるリプレイゴーストが消去される。これにより、プレイヤアクターの枠が１枠空く。次に、プレイヤＢに係るリモートキャラが生成され、ステージ内に出現させる。この際、当該リモートキャラと同じキャラクタのリプレイゴーストがいる場合、このリプレイゴーストも消去する。そのため、この例の場合は、新規入室人数が１人に対して、２体のリプレイゴーストが消去されることもあり得る。この場合は、プレイヤアクターの総数が３体の状態となる。

一方、プレイヤＢのゲーム装置３におけるゲーム処理では、リプレイゴーストは存在せずに、リモートキャラとしてプレイヤＡのプレイヤキャラ２０１がステージ内に存在しているとして、ゲーム進行が管理されることになる。

［協力要素について］
上記のように、基本的には、各プレイヤは他のプレイヤからの影響を受けずに個別にゲームを進行できる。但し、本ゲームでは、以下の点で、協力プレイ的な要素を持たせている。具体的には、本ゲームでは、ミスしたプレイヤを助けることができる「復活補助」という機能によって、他プレイヤとの間で影響を及ぼすことが可能である。

以下、復活補助の具体例を説明する。まず、プレイヤキャラ２０１について、ミスイベントが発生した場合を想定する。当該ミスイベントとは、本実施形態では、プレイヤキャラの残数が減る（残機を失う）ことになるようなゲーム内イベントである。具体的には、例えば図７に示すように、プレイヤキャラ２０１が敵キャラクタ２０２と接触する等した場合であり、オフラインでシングルプレイをしていると仮定した場合は、現在使用しているプレイヤキャラ２０１によるプレイが一旦終了し、プレイヤキャラ２０１の残数が１体減る（以下、このことを「ロスト」と呼ぶ）ようなゲーム内イベントである。そして、ロストした後、所定の地点からリスタートする、あるいは、そのままゲームオーバーになることに繋がるようなゲーム内イベントである。ミスイベントの他の例としては、例えばＨＰやライフが０となって、ロストとなるような場合、落とし穴に落ちる等でステージ外に出てしまった場合、等がある。なお、ダメージを受けてもまだＨＰやライフが残っている等の場合は、まだロストは発生しないため、ここでいうミスイベントには該当しないものとする（単なる被ダメージとして扱う）。

本ゲームでは、オフラインのシングルプレイの場合は、上記ミスイベントの発生は上記のようなロストに直結するが、オンラインに接続した状態でプレイしている場合は、ミスイベントが発生しても、所定の条件を満たしている場合は、すぐにはロストとはならない。本実施形態では、当該所定の条件は、プレイヤキャラ２０１から所定範囲内に、後述する「復活補助オブジェクト」が存在していることである。当該所定の条件を満たしていれば、所定時間の間、プレイヤキャラ２０１が、図８に示すような、見た目が異なるキャラクタオブジェクトに変化する。以下、当該変化したキャラクタオブジェクトのことを「特殊キャラ」と呼ぶ。また、特殊キャラに変化しているプレイヤキャラ２０１の状態のことを「特殊状態」と呼び、この変化が発生していないプレイヤキャラ２０１の状態のことを「通常状態」と呼ぶ。なお、特殊状態の間は、リモートキャラ２０３は半透明ではなく不透明の態様で表示されるが、この点については後述する。

上記特殊キャラについては、復活補助オブジェクト以外のオブジェクトとの衝突判定が行われない。そのため、特殊キャラは、敵キャラクタ等からダメージを受けることがなく、また、敵キャラクタ２０２や地形オブジェクトをすり抜けて移動できる。また、特殊キャラである間は、仮想空間内の重力にとらわれずに空中移動が可能となる。つまり、プレイヤは、特殊キャラについては衝突判定を気にせずに自由に移動させることが可能となる。例えば、復活補助オブジェクトを目指して一直線に特殊キャラを移動させるようなことも可能となる。但し、特殊キャラの状態では、ゴール地点に到達してもゴールしたとはみなされず、ステージクリアもできない。

なお、上記特殊キャラに関して、他の実施形態では、復活補助オブジェクト以外のオブジェクトとも衝突判定が行われるようにしてもよい。また、移動制御に関しても、仮想空間内の重力の影響を受けた移動制御を行ってもよい。

プレイヤキャラ２０１が特殊キャラに変化した後、図９に示すように上記復活補助オブジェクト（ここでは、リモートキャラ２０３）に向けて特殊キャラを移動させたとする。その結果、所定時間が経過する前に、図１０に示すように、リモートキャラ２０３の位置と当該特殊キャラの位置とが重なったとする。つまり、復活補助オブジェクトと特殊キャラとが接触したとする。すると、図１１に示すように、プレイヤキャラ２０１のロストを発生させずに、プレイヤキャラ２０１を通常状態に戻すことができる。すなわち、ミスイベントが発生したプレイヤキャラ２０１をロストさせることなく「復活」させることが可能である。以下の説明では、上記所定時間のことを「復活可能時間」と呼ぶ。なお、特殊キャラと復活補助オブジェクトとを接触させることに限らず、近接あるいは隣接させることで復活させてもよい。

一方、ミスイベントが発生した際に、上記所定範囲内に復活補助オブジェクトが存在していない場合は、特殊状態への変化は発生せずに上記ロストが確定し、その結果、リスタートまたはゲームオーバーとなる。

また、本実施形態では、プレイヤキャラが特殊キャラに変化している間は、復活補助オブジェクトを除いて、ゲーム画面がモノクロ化して表示する。すなわち、地形オブジェクトや敵キャラクタ等の彩度を低くして表示される。

なお、上記所定範囲は、例えば、通常状態のプレイヤキャラ２０１が上記復活可能時間だけ移動したとして、復活補助オブジェクトの位置に到達または近接できることを想定した距離の上限値と同じか、またはこれより短い距離となる範囲である。つまり、ミスイベントが発生した位置から見て、復活可能時間内に特殊状態から通常状態への復活が間に合う程度の範囲を想定したものである。

そのため、例えば、プレイヤキャラ２０１およびリモートキャラ同士である程度固まって移動するようにすれば、シングルプレイ感覚でプレイしつつも、ミスイベント発生時のリカバリが容易になる。つまり、オフラインでのシングルプレイゲームの場合にはない、オンラインを活かした利点が得られる。また、特殊状態となるのは、シングルプレイをしている場合であれば「ミスイベント」～「ロスト」扱いとなってプレイが中断するような状況であるところ、オンラインであれば、このような中断も発生せず、プレイヤのプレイを阻害することにもならない。このような協力プレイ要素を持たせることで、特定の局面で他プレイヤと協力する余地ができる。これにより、基本的にはシングルプレイとしてゲームを進行させつつ、マッチングによってステージ部屋に複数のプレイヤが入室していれば、他のプレイヤと協力しやすくなる、という状況を生み出すことができる。

また、上記のような所定範囲を設けることで、プレイヤキャラ２０１が特殊状態になった場合に、遠くにいるリモートキャラ等に助けを求めて、大きな距離を移動するという状況の発生を抑制できる。例えば、ある程度ステージを進んでいたにも関わらず、リモートキャラがいるスタート地点付近まで戻るとすると、ゲームを進めるテンポが悪くなってしまう。また、逆に、自分より先に進んでいるリモートキャラの位置まで、途中のステージの各種ギミックを飛ばして移動可能とすると、ゲームの興趣性が失われる。このような状況を防ぐために、上記のように所定範囲内に所定範囲内に復活補助オブジェクトが存在しているときのみ、特殊状態へ移行させている。

図１２に、上記のような通常状態、特殊状態、およびロストの状態遷移の関係をまとめた図を示す。図１２において、まず、通常状態のときにミスイベントが発生すると、所定範囲内に復活補助オブジェクトがいるかどうかが判定される。そして、いる場合は、特殊状態に変化する。特殊状態において、復活補助オブジェクトの位置に移動できれば、通常状態に復活することになる。一方、所定範囲内に復活補助オブジェクトがいない場合は、ロストとなる。この場合は、プレイヤキャラ２０１の残数が残っていれば、残数を１つ減らした上で、通常状態となって、所定のリスタート地点からプレイがリスタートする。プレイヤキャラ２０１の残数が残っていなければ、ゲームオーバーとなり、ステージ部屋から退室させられる。

なお、本実施形態では、上記復活可能時間は、特殊状態に変化した回数に応じて変化し得る。具体的には、１回分のプレイ（例えばプレイ開始からプレイヤキャラ２０１を１体ロストするまでの間）において、特殊状態に変化する回数が多くなるほど、上記復活可能時間が段階的に短くなっていく。例えば、上記復活可能時間として、１０カウントを行う場合を想定する。そして、最初に特殊状態に変化したときは、当該１０カウントについて２秒間隔でカウントする（復活可能時間＝２０秒）。その後、復活し、再度特殊状態に変化した場合は、１．５秒間隔でカウントする（復活可能時間＝１５秒）。更に、３度目に特殊状態に変化した場合は１秒間隔でカウントし（復活可能時間＝１０秒）、４度目に特殊状態に変化した場合は０．５秒間隔でカウントする（復活可能時間＝５秒）。そして、カウントする間隔がある程度短くなれば、それ以上は短くしないようにする。例えば、０．５秒間隔を下限値とする、等である。これにより、プレイヤが何度もミスイベントを発生させていると、徐々に復活しにくくなるため、ゲームプレイにある程度緊張感をもたせることができる。

ここで、上記復活機能によって復活するときの復活位置に関して補足する。ここでは、特殊状態になったほうのゲーム装置３における処理を基準に考える。すなわち、特殊キャラを操作しているほうのゲーム画面を基準に考える。まず、特殊キャラと復活対象オブジェクトとが、共に地形外にいる場合を想定する。この場合、両者の位置が重なれば、重なった位置でプレイヤキャラ２０１が復活する。次に、図１３に示すような、特殊キャラが地形内に位置しており、復活対象オブジェクト、図１３ではリモートキャラ２０３が地形外にいる場合を想定する。上記のように、特殊キャラの間は地形オブジェクト等との衝突判定がないため、このような状況も発生し得る。この場合は、図１４に示すように、リモートキャラのいる位置に、プレイヤキャラ２０１が復活する。

次に、図１５に示すように、特殊キャラが地形外、復活対象オブジェクト（リモートキャラ２０３）が地形内にいる場合を想定する。これは、次のような場合に起こり得る。上記のように、本ゲームは、ゲーム進行管理自体は各自のゲーム装置で行われる。そして、例えば破壊可能な地形オブジェクトがあった場合、例えば、プレイヤＡのゲームプレイ上ではまだ破壊されていないが、プレイヤＢのゲームプレイ上では破壊されている、という状況があり得る。例えば図１５の特殊キャラのプレイヤがプレイヤＡとして、リモートキャラ２０３のプレイヤがプレイヤＢであるとする。この場合、上記図１５の状況に対応する、上記プレイヤＢが見ているゲーム画面は、図１６のようなゲーム画面となる。プレイヤＢのゲーム画面では、地形オブジェクトは破壊済みであり、その跡地にプレイヤＢのプレイヤキャラ２０１がいる状態である。また、上記のようにリモートキャラは、位置情報を共有するだけで、プレイヤＡのゲーム装置３においては、地形との衝突判定は行われない。そのため、プレイヤＡから見た場合は、上記図１５のような画面になり得る。そして、この状態でプレイヤＢがリモートキャラを特殊キャラに向けてジャンプさせた場合を想定する。その結果、図１７に示すように、リモートキャラと特殊キャラとが接触したような状態となる。この場合は、図１８に示すように、プレイヤキャラ２０１は、その場で復活する。

次に、特殊キャラのプレイヤの画面において、図１９に示すように、特殊キャラと復活対象オブジェクトとが共に地形内に位置しているような場合を想定する。そして、地形内で両者の位置が重なったとする。この場合は、プレイヤキャラ２０１が復活可能な地点（地形外となる地点）が検索される。例えば、図２０に示すように、不可視の検索用ポインタを、特殊キャラから螺旋状に拡がっていくように移動させながら、地形外となる位置を検索する。そして、最初に見つかった地形外の位置にプレイヤキャラ２０１を復活させる。その結果、図２１に示すような位置でプレイヤキャラ２０１が復活することになる。

なお、上記のような復活位置に、敵キャラクタ等の通常状態のプレイヤキャラと衝突するとミスイベントが発生し得るオブジェクトがいる状況の場合は、当該敵キャラクタと衝突しないような位置に復活位置を更にずらすように制御してもよい。つまり、最終的には、地形オブジェクトや敵キャラクタ等の障害物がない位置を復活位置として決定すればよい。

［復活補助オブジェクトについて］
次に、上記復活補助オブジェクトについて説明する。本実施形態では、上記復活補助オブジェクトは、以下の３種類のオブジェクトである。
（１）リモートキャラ
（２）リプレイゴースト
（３）パネル
また、上記パネルは更に、「リモートパネル」と「サーバパネル」の２種類に分けられる。以下、それぞれについて説明する。

［復活補助オブジェクト：リモートキャラ］
まず、リモートキャラについては、上述したものであるため詳細な説明は割愛するが、その表示態様に関して補足する。上記のように、基本的にはリモートキャラが半透明の表示態様で表示される。但し、プレイヤキャラ２０１が特殊キャラに変化している間は、半透明表示ではなく、不透明の態様で表示される。また、リモートキャラが不透明の態様で表示されている間は、リモートキャラと特殊キャラとの衝突判定が行われる状態となる。いわば、特殊状態となっている間は、リモートキャラが実体化しているように見せかける。また、このときのリモートキャラは、上記のようにプレイヤキャラ２０１を復活させるという形で、プレイヤキャラ２０１に直接的に影響を及ぼし得る状態にもなっている。また、上述したように、本実施形態では、プレイヤキャラ２０１が特殊キャラに変化している間は、復活補助オブジェクトを除いてゲーム画面をモノクロ化して表示する。そのため、モノクロ画像の中で、不透明で色彩がついているリモートキャラが表示されることになり、リモートキャラの存在をより目立たせることができる。これにより、プレイヤに、当該リモートキャラと接触すれば何かが起こる、あるいは、復活できる、ということを想起させ、どこに向かえばよいかをプレイヤに視覚的にわかりやすく示すことができる。

なお、上記ミスイベントが発生してプレイヤキャラ２０１が特殊キャラに変化する際、最も近くの復活補助オブジェクトから、図２２に示すように、光の玉をプレイヤキャラ２０１に飛ばすような演出を加えてもよい。そして、この光の玉を受けたプレイヤキャラ２０１が特殊キャラに変化するような見せ方をしてもよい。これにより、光の玉を出した復活補助オブジェクトに接触すれば助かるかもしれない、ということをプレイヤに想起させることができる。換言すれば、復活補助オブジェクトと特殊キャラへの変化との因果関係をプレイヤに認識させることができる。

［復活補助オブジェクト：リプレイゴースト］
次に、上記リプレイゴーストも、復活補助オブジェクトとして機能する。上記のように、リプレイゴーストはリモートキャラと同様のふるまいをするためである。そのため、復活補助オブジェクトとしてのリプレイゴーストは上記リモートキャラの場合と同様の制御が行われる。従って、ミスイベントの発生時、上記リモートキャラ、またはリプレイゴーストがプレイヤキャラ２０１の所定範囲内にいれば、特殊キャラに変化できることになる。

［パネルについて］
次に、上記パネルの概要を説明する。当該パネルは、プレイヤキャラ２０１が配置でき、また、プレイヤキャラ２０１が接触できるオブジェクトである。また、当該プレイヤがステージ部屋から退室した後も、そのステージ部屋に残り続ける性質のオブジェクトである。例えば、図２３に示すようなゲーム画面でプレイヤがパネル配置操作を行うと、図２４に示すようなパネルを配置できる。当該プレイヤが配置したパネルは、その後ステージ部屋に入室してきた他のプレイヤのゲーム画面にも表示されるものである。逆に言えば、プレイヤのゲーム画面には、他のプレイヤ（リモートキャラ）が配置したパネルが表示され、接触することも可能である。また、当該パネルは、上記復活補助オブジェクトとして機能する。そのため、特殊キャラのときに上記復活可能時間内にパネルに接触することで、プレイヤキャラ２０１を復活させることができる。但し、本実施形態では、自分が配置したパネルについては、特殊キャラは接触できない。つまり、特殊キャラが接触できるパネルは、リモートキャラが配置したパネルであるリモートパネルと、後述のサーバパネルだけとなっている。これは、パネルが上記復活補助オブジェクトとして機能するところ、自分の配置したパネルを復活補助オブジェクトとして扱うと、例えばゲームが簡単になりすぎる等で、ゲームの難易度が適切なバランスにならない可能性があるためである。そのため、本実施形態では、自身が配置したパネルについては接触できない（復活補助オブジェクトとして利用できない）ようにしている。

なお、本実施形態では。プレイヤキャラ２０１がパネルを配置できる場所については、足場があるところに限られ、例えば空中にパネルを配置することはできないものとする。

また、上記のパネルのようなデザインは一例であり、その外観についてはパネルのような外観でなくてもよい。

［パネルの配置可能数について］
本実施形態では、１ステージに最大で４つまでパネルが配置可能であるとする。また、１プレイヤにつき１つまでしかパネルは配置できないものとする。そのため、プレイヤが一旦パネルを配置した後、別の場所で新たにパネル配置操作を行った場合は、前に配置したパネルが消去され、当該別の場所にパネルが配置されることになる。

［他ゲーム装置とのパネルの同期について］
また、上記のように自分が配置したパネルは他のプレイヤのゲーム画面上にも表示される。つまり、本実施形態では、配置されたパネルの位置についても共有される。具体的には、パネルを配置したプレイヤのゲーム装置３から、他のゲーム装置に対して、「パネルを配置したこと」と、その配置位置（座標）を示す「配置イベント情報」が送信される。これを受信した他のゲーム装置３では、ローカルのゲーム処理において、パネルを配置する処理が行われる。但し、このような同期を行うのは、パネルを配置したときだけであり、その後のパネルの消去等に関しては、各ゲーム装置３でローカルに管理される。そのため、例えば、新たなパネルが配置された際は、そのパネルの配置について同期されるが、その後の各ゲーム装置におけるゲームプレイの展開によっては、あるゲーム装置では上記パネルが残っているが、違うゲーム装置では当該パネルが消去されている、という状況も起こり得る。

［復活補助オブジェクト：リモートパネル］
次に、上記パネルのうち、リモートパネルについて説明する。上記のように、リモートパネルは、上記リモートキャラが配置したパネルである。プレイヤキャラ２０１が通常状態のときに当該リモートパネルに接触すると、パネルが揺れるリアクションが行われ、当該パネルを配置したリモートプレイヤ名が表示される。また、プレイヤキャラ２０１が特殊状態のときに、上記復活可能時間内に接触すると、リモートキャラの場合と同様に復活できる。このことは、換言すれば、プレイヤ自身がパネルを配置することで、これが他のプレイヤから見た場合のリモートパネルとなり、自分が同じ画面内にいなくても、間接的に他プレイヤを助けることができる、ということになる。例えば、上記ミスイベントが多発するであろうとプレイヤが考える場所にパネルを配置しておくことで、間接的に他のプレイヤを助けとなることが期待できる。

［復活補助オブジェクト：サーバパネル］
次に、サーバパネルについて説明する。本実施形態に係るゲームでは、多数の様々なステージが用意されており、プレイヤはこの中からプレイしたいステージを選んでプレイできる。ただ、多数のステージが用意されている反面、ステージによっては、プレイするプレイヤの数が相対的に少なく、上記パネルがあまり配置されない可能性がある。そこで、本実施形態では、各プレイヤが配置したパネルに関する情報（以下、パネル情報）を上記ゲームサーバ１に保持しておく。そして、当該パネルの情報を、新規にステージ部屋が作成された際等に使用することで、ステージ上にパネルが配置されている状態を作りだす。このようなゲームサーバ１に保持されているパネル情報に基づいて配置されたパネルが、サーバパネルである。以下、サーバパネルの詳細について説明する。

［サーバへの情報送信について］
まず、パネル情報のゲームサーバ１への送信に関して説明する。本実施形態では、プレイヤがステージ部屋から退室するときに、そのプレイヤが配置したパネルについてのパネル情報をゲームサーバ１に送信する。ステージ部屋からの退室は、例えばゴールした場合や、ゲームオーバー等でクリアすることなくリタイアする場合等である。当該パネル情報には、パネルを配置したステージと配置位置とを示す情報が少なくとも含まれている。但し、プレイヤがステージ部屋から退室するときに、当該プレイヤが配置したパネルが既に消去されている場合は、パネル情報は送信されない。また、そのステージにおいて、既にプレイヤ自身が配置したパネル情報がゲームサーバ１に保持されていた場合は、既存のパネル情報が削除され、新たに登録される。これは、例えば、あまりプレイされていないステージにおいて、あるプレイヤが１人で「ステージに入室し、パネルを配置し、退室する」ことを繰り返すことで、そのステージに関するパネルが全て同一プレイヤに係るパネルで埋められるという状況の発生を抑制するためである。

［サーバパネルの受信および配置について］
次に、上記のようにしてゲームサーバ１に送信されたパネル情報の利用に関して説明する。まず、プレイヤがステージ部屋に入室した際に、ステージに配置されているパネル数が０個の状態だった場合に、ゲームサーバ１からパネル情報を取得する。入室した際にパネル数が０個という状況は、例えば次のような状況である。まず、ステージ部屋が新規作成された場合である。次に、既存のステージ部屋に入室したときに、その時点でステージ内にパネルが１つも配置されていなかった場合である。換言すれば、プレイヤが入室した時点でステージ内にパネルが１つも無いという状況の場合にのみ、サーバパネルが配置され得ることになる。

また、ゲームサーバ１からパネル情報を取得する点について、本実施形態では、そのステージに紐付けられているパネル情報の、直近３０件分をゲームサーバ１から取得する。なお、上記のように、同一ステージで同一プレイヤが複数回パネル情報を送信した場合は、最新のパネル情報のみがゲームサーバ１に保持される。そのため、当該取得したパネル情報群に同一プレイヤに係るパネル情報が複数含まれているということはない。そして、この中から、最大で４つまでパネル情報が選出される。なお、本実施形態では、ステージ部屋の定員が最大４人の例であるため、この人数に合わせて最大４つとしているが、選出数は４つ以上でも４つ以下でもよいことはいうまでもない。また、選出手法は、例えばランダムで選出すればよい。

次に、上記選出したパネル情報に基づいて、サーバパネルが生成される。そして、各パネル情報で示される位置にサーバパネルがそれぞれ配置される。ここで、ステージに入室したときに過去にプレイヤ自身が配置したパネルがサーバパネルとして存在する場合も考えられる。この場合は、当該過去にプレイヤ自身が配置したサーバパネルはプレイヤのパネルであると判断し、その後、プレイヤが新たにパネルを配置した場合は、当該サーバパネルを消滅させる。

［サーバパネルの有効化について］
次に、サーバパネルの有効化について説明する。上記のようにしてサーバパネルは配置され得るが、サーバパネルは初期状態として無効状態になっている。つまり、配置された時点では、上述した復活補助オブジェクトとして機能していない状態である。図２５に、無効状態のサーバパネルの例を示す。図２５に示すように、無効状態のサーバパネルは、黒塗りの表示態様で表示される。なお、無効状態であることを示す表示態様は、黒塗りに限らず、どのような表示態様でもよい。そして、当該無効状態のサーバパネルにプレイヤキャラ２０１が接触することで、図２６に示すように、当該サーバパネルを有効化できる。図２６では、黒塗りの表示態様が解除され、通常と同様の表示態様でサーバパネルが表示されていることを示している。このように、有効化されたサーバパネルだけが、上述した復活補助オブジェクトとして機能する。そのため、無効状態のサーバパネルの近くでミスイベントが発生した場合は、上記のような特殊キャラに変化すること無く、ロストとなる。

また、一旦有効化したサーバパネルについては、プレイヤキャラ２０１がそのサーバパネルから離れたとしても、その後も有効であり続ける。また、リスタートした場合も、一旦有効化したサーバパネルが再度無効化されることはなく、有効であり続ける。

なお、上記のような最初は無効状態で、プレイヤキャラ２０１の接触で有効化させるのは、以下のような理由による。まず、上記のように特殊キャラになると、敵キャラクタや地形との衝突判定が行われない状態となる。そのため、もしサーバパネルが最初から有効だとすると、サーバパネルの配置位置の関係によっては、プレイヤがわざと特殊キャラに変化し、通常状態としてはまだ到達していない先の場所（サーバパネルがある場所）まで特殊キャラのまま移動することが起こりえる。すなわち、本来はまだ進めていない位置までショートカットできてしまうということが考えられる。このような状況の発生を抑制するために、初期状態ではサーバパネルは無効状態としている。なお、これは、他のプレイヤがいないステージ部屋についての話である。例えばリモートキャラがリアルタイムで配置したリモートパネルについては、オンラインプレイのメリットや協力プレイ的な要素をプレイヤに感じさせるために、上記のようなショートカットは許容する。そのため、上記リモートパネルについては、配置した時点から有効な状態である。

またその他、サーバパネル自体を、チェックポイントのように通過するということ自体を一種の遊び方として提供するという観点で、初期状態を無効状態としている。

次に、ゲーム装置３、および、ゲームサーバ１で用いられる各種データと、それぞれで行われる処理の詳細を説明する。

［ゲームサーバ１で用いられるデータについて］
まず、ゲームサーバ１で用いられるデータに関して説明する。図２７は、ゲームサーバ１の記憶部１２に記憶される各種データの一例を示すメモリマップである。ゲームサーバ１の記憶部１２には、ゲームサーバプログラム３０１、プレイヤデータベース３０２、ステージ部屋管理データ３０４、リプレイ管理データ３０５、パネル管理データ３０６が少なくとも記憶されている。

ゲームサーバプログラム３０１は、上述したようなゲーム処理を実現するためにゲームサーバ１を機能させるプログラムである。

プレイヤデータベース３０２は、本実施形態に係るゲームをプレイする各プレイヤに関するデータベースである。データベースには、複数のプレイヤデータ３０３が含まれている。各プレイヤデータ３０３には、例えば、各プレイヤを識別するためのプレイヤＩＤ３０７、各プレイヤのプレイヤ名３０８等が含まれる。

ステージ部屋管理データ３０４は、上記ステージ部屋を管理するためのデータベースである。図２８に、ステージ部屋管理データ３０４のデータ構成の一例を示す。図２８において、ステージ部屋管理データ３０４には、各ステージを特定するステージ番号３１１毎に、ステージ部屋情報３１２が含まれている。当該ステージ部屋情報３１２は、１つのステージに対して複数含まれ得る。当該ステージ部屋情報３１２のひとつひとつが上記ステージ部屋に対応する情報である。各ステージ部屋情報３１２には、部屋ＩＤ３１３、入室プレイヤ情報３１４等が含まれる。部屋ＩＤ３１３は、そのステージ部屋を一意に特定するためのＩＤである。入室プレイヤ情報３１４は、そのステージ部屋に現在入室しているプレイヤに関する情報である。例えば、入室プレイヤ情報３１４には、上記プレイヤＩＤ３０７が格納される。

図２７に戻り、リプレイ管理データ３０５は、上述したような、ゲーム装置３から送信されてくる上記リプレイデータを保存したものである。図２９に、リプレイ管理データのデータ構成の一例を示す。リプレイ管理データ３０５には、ステージ番号３２１毎に、１つ以上のリプレイデータ３２２が含まれている。各リプレイデータ３２２には、登録日時３２３、登録プレイヤ情報３２４、リプレイ内容３２５が少なくとも含まれる。登録日時３２３は、そのリプレイデータがゲームサーバ１に登録された日時を示す。登録プレイヤ情報３２４は、そのリプレイデータを生成したプレイヤに関する情報である。登録プレイヤ情報３２４には、例えば、上記プレイヤＩＤ３０７等が含まれている。リプレイ内容３２５は、リプレイの内容を示すためのデータである。例えば、リプレイ内容３２５は、リプレイに係るキャラクタの位置情報や状態を示す情報が時系列に並べられて格納されたデータである。また、リプレイ内容３２５は、例えばキーデータ等であってもよい。つまり、リプレイ内容３２５は、プレイヤの操作履歴が把握できるようなデータであれば、どのようなデータ内容であってもよい。

図２７に戻り、パネル管理データ３０６は、上記のようにゲーム装置３から送信されるパネル情報を保存したものである。図３０に、パネル管理データ３０６のデータ構成の一例を示す。パネル管理データ３０６には、ステージ番号３３１毎に、１つ以上のパネル情報３３２が含まれている。各パネル情報３３２には、登録日時３３３、配置プレイヤ情報３３４、配置位置３３５が少なくとも含まれる。登録日時３３３は、そのパネル情報３３２がゲームサーバ１に登録された日時を示す。配置プレイヤ情報３３４は、パネル情報３３２に係るパネルを配置したプレイヤに関する情報である。配置位置３３５は、パネル情報３３２に係るパネルの配置位置を示す情報である。

また、図示は省略するが、プレイヤのマッチング処理等を行うために必要な各種データも、記憶部１２に適宜記憶され得る。

［ゲーム装置３で用いられるデータについて］
次に、ゲーム装置３で用いられるデータに関して説明する。図３１は、ゲーム装置３の記憶部３２に記憶される各種データの一例を示すメモリマップである。ゲーム装置３の記憶部３２には、ゲームプログラム３５１、ステージデータ３５２、オブジェクトデータ３５３、プレイヤキャラデータ３５４、リモートキャラデータ３６１、リプレイゴーストデータ３６２、プレイヤアクター管理データ３６３、パネルデータ３６４、操作データ３６５、選出済みフラグ３６６、配置完了フラグ３６７が少なくとも記憶されている。

ゲームプログラム３５１は、ゲーム装置３において、本実施形態におけるゲーム処理を実行するためのプログラムである。

ステージデータ３５２は、プレイするステージを構築するためのデータが含まれている。具体的には、ステージデータ３５２には、ステージ毎に、スタート地点、ゴール地点の位置情報、中間地点オブジェクト等のステージ内に配置される各種オブジェクトを示すデータが含まれる。

オブジェクトデータ３５３は、ステージ内に配置される各種オブジェクトと、リモートキャラやリプレイゴーストとして表示されるキャラクタオブジェクトの外観を示すマスタデータである。具体的には、オブジェクトデータ３５３には、各オブジェクトのモデルデータやテクスチャデータ等が含まれている。

プレイヤキャラデータ３５４は、プレイヤの操作対象となる上記プレイヤキャラ２０１に関するデータである。プレイヤキャラデータ３５４には、プレイヤ位置情報３５５、特殊状態フラグ３５６、特殊状態化回数３５７、中間通過フラグ３５８、リプレイ記録用データ３５９、ロスト発生フラグ３６０等のデータが含まれる。プレイヤ位置情報３５５は、プレイするステージにおけるプレイヤキャラ２０１の位置を示すデータである。特殊状態化回数３５７は、プレイヤキャラ２０１が上記特殊キャラに変化した回数を記録するためのカウンタである。特殊状態フラグ３５６は、オンの場合は特殊状態、オフの場合は通常状態であることを示すフラグである。特殊状態化回数３５７は、プレイヤキャラ２０１が特殊キャラに変化する度に１回分カウントアップされる。また、上記ロストが発生した際に、リセットされる。中間通過フラグ３５８は、プレイヤキャラ２０１が上記中間地点オブジェクトに接触したか否かを示すためのフラグである。中間地点オブジェクトに接触するとオンに設定される。リプレイ記録用データ３５９は、プレイヤキャラ２０１のリプレイ用のデータを記録するためのデータである。ロスト発生フラグ３６０は、上述したロストとなる状況が発生したことを示すためのフラグである。オンであれば、ロストとなる状況が発生したことを示す。

次に、リモートキャラデータ３６１は、同じステージ部屋に入室しているリモートプレイヤに係るリモートキャラのデータである。図３２に、リモートキャラデータ３６１のデータ構成の一例を示す。本例では、ステージ部屋は最大４人まで入室可能という例であるため、リモートキャラデータ３６１には、最大で３体分のリモートキャラのデータが格納される。また、各データは、リモートプレイヤの入室に伴い生成され、退室に伴って適宜削除される。各データには、識別名３７１、リモートプレイヤ情報３７２、使用キャラクタ情報３７３、リモート位置情報３７４が少なくとも含まれる。識別名３７１は、各リモートキャラを一意に識別するための識別子である。リモートプレイヤ情報３７２は、各リモートキャラを操作しているリモートプレイヤを特定するための情報である。使用キャラクタ情報３７３は、リモートキャラとして画面に表示されるキャラクタを指定する情報である。つまり、各リモートプレイヤがプレイヤキャラとして用いているキャラクタを示す情報である。リモート位置情報３７４は、そのリモートキャラのステージ内での位置を示す情報である。

図３１に戻り、次に、リプレイゴーストデータ３６２は、上記リプレイゴーストについてのデータである。具体的には、リプレイゴーストデータ３６２には、リプレイゴーストとして用いられる上記リプレイデータ３２２が最大で３件分、格納される。

プレイヤアクター管理データ３６３は、プレイヤアクターの枠と、リモートキャラ、リプレイゴーストの割り当て関係を管理するためのデータである。図３３に、プレイヤアクター管理データ３６３のデータ構成の一例を示す。アクター枠番号３８１は、プレイヤアクターの枠番号である。本例では、プレイヤアクターの枠は４つ用意されている場合を例に説明する。割り当て対象３８２は、その枠に割り当てたプレイヤアクターを特定するための情報である。まず、１枠分は、プレイヤキャラ２０１に割り当てられる。そのため、残り３枠分について、リモートキャラまたはリプレイゴーストのいずれかを特定するための情報が格納される。また、リモートキャラやリプレイゴーストが割り当てられていない状態のときは、Ｎｕｌｌ値が設定される。

図３１に戻り、次に、パネルデータ３６４は、上述したパネルを管理するためのデータである。図３４に、パネルデータ３６４のデータ構成の一例を示す。パネルデータ３６４には、自パネルデータ３９１、リモートパネルデータ３９４、サーバパネルデータ４００とが含まれている。また、本例では、リモートパネルデータ３９４およびサーバパネルデータ４００はそれぞれ３件分用意されておる。自パネルデータ３９１は、プレイヤキャラ２０１が配置したパネル（以下、自パネル）に関する情報である。自パネルデータ３９１には、自パネル配置位置３９２、自パネル配置日時３９３が含まれる。自パネル配置位置３９２は、自パネルの配置位置を示し、自パネル配置日時３９３は、自パネルが配置された日時を示す。また、複数回のパネル配置が行われた場合は、最新の配置内容が自パネルデータ３９１に保存される。

リモートパネルデータ３９４は、リモートキャラが配置したパネルに関する情報である。リモートパネルデータ３９４には、リモートパネル配置位置３９６、配置プレイヤ情報３９７、リモートパネル配置日時３９８が含まれる。リモートパネル配置位置３９６は、リモートパネルの配置位置を示し、リモートパネル配置日時３９８は、リモートパネルが配置された日時を示す。配置プレイヤ情報３９７は、そのリモートパネルを配置した他のプレイヤに関する情報である。

サーバパネルデータ４００は、上記サーバパネルに関するデータである。サーバパネルデータ４００には、サーバパネル配置位置４０２、有効化フラグ４０３が含まれる。サーバパネル配置位置４０２は、そのサーバパネルが配置されている位置を示す。有効化フラグ４０３は、そのサーバパネルが有効化されているか否かを示すフラグである。有効化フラグ４０３の初期値はオフであり、有効化されるとオンに設定される。

なお、図３４で示されるように、パネルデータ３６４には、自パネル、リモートパネル、サーバパネルを合計して７つ分のパネルデータが記憶可能ではある。但し、上記のように、パネルは最大で４つまでしかステージ内に配置できないため、実際に用いられるデータとしては、上記７つ分のパネルのデータのうち最大で４つまでのデータとなる。つまり、パネル配置の発生に伴って、パネル数が最大で４つとなるように、各データの中身の削除と生成が適宜行われる。

図３１に戻り、操作データ３６５は、プレイヤが操作するコントローラ４から得られるデータである。すなわち、プレイヤが行った操作内容を示すデータである。

選出済みフラグ３６６および配置完了フラグ３６７は、リプレイゴーストを配置する処理において用いられるフラグである。選出済みフラグ３６６は、ダウンロードしたリプレイデータからのリプレイゴーストの選出が済んだか否かを示すためのフラグである。配置完了フラグ３６７は、選出したリプレイゴーストをステージ内に全ては位置したか否かを示すためのフラグである。

その他、図示は省略するが他のゲーム装置に各種データを送信するための送信用データや、他のゲーム装置３から受信した受信データ、サーバからダウンロードしたリプレイデータ等、ゲーム処理に必要となる各種データも必要に応じて生成され、記憶部３２に記憶され得る。

次に、本実施形態におけるゲーム処理の詳細を説明する。まず、ゲーム装置３で行われる処理の詳細を説明し、その後、ゲームサーバ１における処理について説明する。

［ゲーム装置３のプロセッサ３１が実行する処理の詳細］
図３５～図３６は、ゲーム装置３のプロセッサ３１が実行するゲーム装置側処理の詳細を示すフローチャートである。本実施形態では、１以上のプロセッサが１以上のメモリに記憶された上記プログラムを読み込んで実行することにより、以下に示すフローチャートが実現される。なお、以下に示すフローチャートは、処理過程の単なる一例にすぎない。そのため、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよい。また、変数の値や、判定ステップで利用される閾値も、単なる一例であり、必要に応じて他の値を採用してもよい。

ゲーム装置３において、プレイヤによって所定のステージをプレイすることが指示されると、まず、ステップＳ１で、プロセッサ３１は、ステージ開始処理を実行する。図３７は、当該ステージ準備処理の詳細を示すフローチャートである。図３７において、まず、ステップＳ２１で、プロセッサ３１は、ステージ部屋への入室処理を行う。具体的には、まず、プロセッサ３１は、ゲームサーバ１にマッチング処理をリクエストする。そして、プロセッサ３１は、そのマッチング結果に基づき決定されたステージ部屋への入室処理を実行する。この際、既存の部屋に入室する場合は、入室済みのプレイヤに係るゲーム装置３に、自分がプレイヤキャラ２０１として用いるキャラクタの情報も送信する。

次に、ステップＳ２２で、プロセッサ３１は、今回プレイするステージ（仮想空間）を、ステージデータ３５２に基づいて生成する。更に、既存のステージ部屋に入室した場合は、リモートキャラおよびリモートパネルの情報を他のゲーム装置３から受信する。そして、各種キャラクタをステージ内に配置する。

次に、ステップＳ２３で、プロセッサ３１は、ステージ内のパネル数が０か否かを判定する。当該判定の結果、０ではない場合は（ステップＳ２３でＮＯ）、後述するステップＳ２７に処理が進められる。一方、０の場合は（ステップＳ２３でＹＥＳ）、ステップＳ２４で、プロセッサ３１は、直近３０件分のパネル情報をゲームサーバ１から取得する。次に、ステップＳ２５で、プロセッサ３１は、取得したパネル情報からランダムで４つのパネル情報を選出する。そして、プロセッサ３１は、選出したパネル情報をサーバパネルデータ４００として記憶する。この際、過去にプレイヤ自身が配置したパネルの情報が含まれていた場合は、これについては自パネルデータ３９１として記憶する。そして、プロセッサ３１は、パネルデータ３６４に基づき、サーバパネルを配置する。

次に、ステップＳ２６で、プロセッサ３１は、ステージ部屋に他のプレイヤがいる場合は、配置したサーバパネル（場合によっては自パネルデータも）の情報を他のゲーム装置に送信する。つまり、サーバパネルの情報を同じステージ部屋のリモートプレイヤと共有する。なお、例えばほぼ同じタイミングで２人のプレイヤが入室し、共にサーバパネルに関する処理を行った場合は、いずれか１人のサーバパネルの情報を優先する。

次に、ステップＳ２７で、プロセッサ３１は、ゲーム画面を生成し、表示部５に表示する。これにより、ステージプレイが開始されることになる。

図３５に戻り、次に、ステップＳ２で、プロセッサ３１は、入退室チェック処理を実行する。これは、プレイヤが入室した後に発生した他のプレイヤの入退室をチェックするための処理である。図３８～図３９は、入退室チェック処理の詳細を示すフローチャートである。まず、ステップＳ３１で、プロセッサ３１は、対応するリモートキャラが存在していない新たなプレイヤの入室が発生したか否かを判定する。当該判定の結果、新たな入室者がいない場合は（ステップＳ３１でＮＯ）、プロセッサ３１は、後述のステップＳ３９に処理を進める。一方、新たなプレイヤの入室が発生した場合は（ステップＳ３１でＹＥＳ）、ステップＳ３２で、プロセッサ３１は、当該入室してきたプレイヤのゲーム装置３に対して、その時点で設置済みのサーバパネルとリモートパネルに関する情報を、必要に応じて送信する。なお、当該情報の送信処理は、先に入室済みのプレイヤのいずれかのゲーム装置３で行われればよい。

次に、ステップＳ３３で、プロセッサ３１は、部屋内のプレイヤ人数が４人になったか否かを判定する。当該判定の結果、４人になっていない場合は（ステップＳ３３でＮＯ）、後述のステップＳ３６に処理が進められる。一方、４人になった場合は（ステップＳ３３でＹＥＳ）、ステップＳ３４で、プロセッサ３１は、プレイヤアクター管理データ３６３を参照し、プレイヤアクターの枠に空きがあるか否かを判定する。当該判定の結果、空きが無い場合は（ステップＳ３４でＮＯ）、リプレイゴーストが存在している状態と考えられる。そのため、ステップＳ３５で、プロセッサ３１は、プレイヤキャラ２０１から最も遠くの位置にいるリプレイゴーストを削除する。すなわち、当該リプレイゴーストに係るデータを、リプレイゴーストデータ３６２およびプレイヤアクター管理データ３６３から削除する。その後、ステップＳ３６に処理が進められる。一方、上記判定の結果、プレイヤアクターの枠に空きがある場合は（ステップＳ３４でＹＥＳ）、上記ステップＳ３５の処理はスキップされる。

次に、ステップＳ３６で、プロセッサ３１は、入室してきたプレイヤのゲーム装置から受信した情報に基づき、入室してきたプレイヤに対応するリモートキャラのデータをリモートキャラデータ３６１に追加する。そして、リモートキャラデータ３６１に基づき、入室してきたプレイヤに対応するリモートキャラを配置する。

次に、ステップＳ３７で、プロセッサ３１は、今回配置したリモートキャラと同じプレイヤのリプレイゴーストが存在するか否かを判定する。当該判定の結果、存在する場合は（ステップＳ３７でＹＥＳ）、ステップＳ３８で、プロセッサ３１は、同プレイヤのリプレイゴーストを削除する。すなわち、プロセッサ３１は、リプレイゴーストデータ３６２から当該リプレイゴーストのデータを削除する。一方、同プレイヤのリプレイゴーストが存在していなければ（ステップＳ３７でＮＯ）、上記ステップＳ３８の処理はスキップされる。

次に、図３９のステップＳ３９で、プロセッサ３１は、いずれかのリモートプレイヤの退室が発生したか否かを判定する。また、これに併せて、プロセッサ３１は、そのときに存在しているリプレイゴーストの再生が終了したか否かも判定する。当該判定の結果、リモートプレイヤの退室、または、リプレイゴーストの再生終了が発生した場合は（ステップＳ３９でＹＥＳ）、ステップＳ４０で、プロセッサ３１は、退室したプレイヤに係るリモートキャラを削除する。あるいは、再生が終了したリプレイゴーストおよび、対応するリプレイデータを削除する。

一方、リモートプレイヤの退室、リプレイゴーストの再生終了のいずれも発生していない場合は（ステップＳ３９でＮＯ）、上記ステップＳ４０の処理はスキップされる。その後、プロセッサ３１は、入退室チェック処理を終了する。

図３５に戻り、次に、ステップＳ３で、プロセッサ３１は、リモートパネルチェック処理を実行する。これは、リモートプレイヤがパネルを設置した場合に、これを自分のゲーム処理に反映させるための処理である。図４０は、リモートパネルチェック処理の詳細を示すフローチャートである。まず、ステップＳ５１で、プロセッサ３１は、他のゲーム装置３から、上記配置イベント情報を受信したか否かを判定する。当該判定の結果、受信した場合は（ステップＳ５１でＹＥＳ）、ステップＳ５２で、プロセッサ３１は、当該配置イベント情報に基づき、パネルデータ３６４の内容を更新する。例えば、同じプレイヤがパネルを再設置した場合は、既に設置済みのパネルを削除して新たなパネルのデータに置き換える処理が行われる。また、新たにパネルが設置された場合、そのパネルに係るデータが新たに作成される。そして、プロセッサ３１は、パネルデータ３６４に基づいてリモートパネルを適宜設置する。一方、上記判定の結果、配置イベント情報を受信していなければ、上記ステップＳ５２の処理はスキップされる。その後、リモートパネルチェック処理は終了する。

図３５に戻り、次に、ステップＳ４で、プロセッサ３１は、特殊状態フラグ３５６を参照し、プレイヤキャラ２０１が特殊状態か否かを判定する。当該判定の結果、特殊状態ではない場合は（ステップＳ４でＮＯ）、ステップＳ５で、プロセッサ３１は、通常状態処理を実行する。一方、特殊状態の場合は（ステップＳ４でＹＥＳ）、ステップＳ６で、プロセッサ３１は、特殊状態処理を実行する。以下、各処理について説明する。

[通常状態の時の処理]
図４１～図４２は、通常状態処理の詳細を示すフローチャートである。図４１において、まず、ステップＳ６１で、プロセッサ３１は、操作データ３６５を取得する。次に、ステップＳ６２で、プロセッサ３１は、パネル配置操作が行われたか否かを判定する。当該判定の結果、パネル配置操作が行われた場合は（ステップＳ６２でＹＥＳ）、ステップＳ６４で、プロセッサ３１は、自パネル配置処理を実行する。図４３は、当該自パネル配置処理の詳細を示すフローチャートである。まず、ステップＳ８１で、プロセッサ３１は、パネルデータ３６４を参照し、既存の自パネルが存在するか否かを判定する。存在している場合は（ステップＳ８１でＹＥＳ）、ステップＳ８２で、プロセッサ３１は、既存の自パネルのデータをパネルデータ３６４から消去する。一方、存在していなければ（ステップＳ８１でＮＯ）、上記ステップＳ８２の処理はスキップされる。

次に、ステップＳ８３で、プロセッサ３１は、パネル配置操作が行われた位置に自パネルを配置する。すなわち、プロセッサ３１は、当該自パネルにかかるデータをパネルデータ３６４に生成し、当該データに基づいて自パネルをステージ内に配置する。

次に、ステップＳ８４で、プロセッサ３１は、自パネルに係る配置イベント情報を生成して、他のゲーム装置３に送信する。以上で、自パネル配置処理は終了する。

図４１に戻り、上記ステップＳ６２の判定の結果、パネル配置操作が行われていない場合は（ステップＳ６２でＮＯ）、ステップＳ６３で、プロセッサ３１は、操作データ３６５で示される操作内容に基づいて、プレイヤキャラ２０１の動作を制御する。更に、プロセッサ３１は、プレイヤキャラ２０１の位置情報、および、通常状態である特殊状態であるかを示す状態情報を他のゲーム装置３に送信する。

次に、ステップＳ６５で、プロセッサ３１は、他のゲーム装置３からリモートキャラに関する情報を受信し、リモートキャラを移動させる。当該リモートキャラに関する情報は、リモートキャラの位置情報および状態を示す情報である。なお、位置情報の代わりに、例えば、リモートプレイヤが行った操作情報を受信するようにしてもよい。この場合は、当該受信した操作情報に基づいてリモートキャラが移動制御されればよい。また、リプレイゴーストが存在している場合は、プロセッサ３１は、リプレイデータに基づく再生を継続する。これにより、当該リプレイゴーストが移動制御される。

次に、ステップＳ６６で、プロセッサ３１は、敵キャラクタ等の動作を制御する。更に、プロセッサ３１は、プレイヤキャラ２０１と敵キャラクタやリモートパネル等との衝突判定を行い、その結果に応じたゲーム処理を適宜実行する。例えば、リモートパネルに接触した場合は、そのリモートパネルを配置したリモートプレイヤ名を一時的に表示する処理が行われる。また、例えば、敵キャラクタに接触した場合、敵キャラクタにダメージを与える処理、あるいは、プレイヤキャラ２０１がダメージを受ける処理が行われる、また、このゲーム処理の結果、上述したミスイベントが発生し得る。

次に、ステップＳ６７で、プロセッサ３１は、プレイヤキャラ２０１が中間地点オブジェクトに接触したか否かを判定する。当該判定の結果、接触した場合は（ステップＳ６７でＹＥＳ）、ステップＳ６８で、プロセッサ３１は、中間通過フラグ３５８をオンに設定する。これに伴い、これ以降のリスタート地点を中間地点オブジェクトの位置とする設定も行われる。次に、ステップＳ６９で、プロセッサ３１は、リプレイ記録用データ３５９を用いて、プレイヤキャラ２０１に係るリプレイデータの記録を開始する。この際、中間地点からリスタートした状況である場合は、上述のように一定確率でリプレイデータの記録を開始しないように制御してもよい。

一方、上記ステップＳ６７の判定の結果、中間地点オブジェクトに接触していない場合は（ステップＳ６７でＮＯ）、上記ステップＳ６８およびＳ６９の処理はスキップされる。

次に、図４２のステップＳ７０で、プロセッサ３１は、プレイヤキャラ２０１が無効状態のサーバパネルに接触したか否かを判定する。当該判定の結果、接触した場合は（ステップＳ７０でＹＥＳ）、ステップＳ７１で、プロセッサ３１は、接触したサーバパネルの有効化フラグ４０３にオンを設定する。一方、接触していない場合は（ステップＳ７０でＮＯ）、上記ステップＳ７１の処理はスキップされる。

次に、ステップＳ７２で、プロセッサ３１は、上記ミスイベントが発生したか否かを判定する。当該判定の結果、発生した場合は（ステップＳ７２でＹＥＳ）、ステップＳ７３で、プロセッサ３１は、リプレイデータの記録を停止する。次に、ステップＳ７４で、プロセッサ３１は、プレイヤキャラ２０１が特殊状態になるための条件が満たされているか否かを判定する。すなわち、プロセッサ３１は、プレイヤキャラ２０１から所定範囲内にいずれかの復活補助オブジェクトが存在するか否かを判定する。当該判定の結果、特殊状態になるための条件が満たされている場合は（ステップＳ７４でＹＥＳ）、ステップＳ７５で、プロセッサ３１は、プレイヤキャラ２０１を特殊状態とするための設定、および、これに伴う各種設定を行う。具体的には、プロセッサ３１は、特殊状態フラグ３５６にオンを設定する。更に、プロセッサ３１は、プレイヤキャラ２０１を特殊キャラに変更する。更に、プロセッサ３１は、特殊状態化回数３５７に１を加算する。更に、プロセッサ３１は、復活補助オブジェクトを除いてゲーム画面がモノクロで表示されるようにゲーム画面の表示設定を行う。その後、通常状態処理は終了する。

一方、特殊状態になるための条件が満たされていない場合は（ステップＳ７４でＮＯ）、ステップＳ７６で、プロセッサ３１は、ロスト発生フラグ３６０にオンを設定する。その後、通常状態処理は終了する。

一方、上記ステップＳ７２の判定の結果、ミスイベントが発生していない場合は（ステップＳ７０でＮＯ）、通常状態処理は終了する。

[特殊状態のときの処理]
次に、上記特殊状態処理について説明する。図４４は、当該特殊状態処理の詳細を示すフローチャートである。まず、ステップＳ９１で、プロセッサ３１は、操作データ３６５を取得する。次に、ステップＳ９２で、プロセッサ３１は、操作データに基づき、特殊キャラを移動させる。上記のように、特殊キャラの間は、地形や敵キャラクタとの衝突判定は行われない。

次に、ステップＳ９３で、プロセッサ３１は、リモートキャラを制御する。プレイヤキャラ２０１が特殊状態の間は、上記のように、リモートキャラは半透明ではなく、不透明で表示されるよう制御される。また、リモートキャラと特殊キャラとの衝突判定が行われるよう制御される。また、リプレイゴーストが存在している場合は、リプレイゴーストについても上記リモートキャラと同様の制御を行う。

次に、ステップＳ９４で、プロセッサ３１は、敵キャラクタ等の動作制御を行い、これに伴う各種のゲーム処理を行う。

次に、ステップＳ９５で、プロセッサ３１は、上記特殊状態から復活可能な時間をカウントするための特殊カウンタのカウントを進める。この際、プロセッサ３１は、特殊状態化回数３５７に基づいて、１カウントに係る時間間隔を適宜変化させた上で、カウントを進める。

次に、ステップＳ９６で、プロセッサ３１は、特殊カウンタのカウントが終了したか否かを判定する。当該判定の結果、まだカウントが終了していない場合は（ステップＳ９６でＮＯ）、ステップＳ９７で、プロセッサ３１は、復活条件が満たされたか否かを判定する。すなわち、上記復活可能時間内に特殊キャラが復活対象オブジェクトとのいずれかと接触できたか否かを判定する。当該判定の結果、満たされた場合は（ステップＳ９７でＹＥＳ）、ステップＳ９８で、プロセッサ３１は、特殊状態フラグ３５６にオフを設定する。更に、プロセッサ３１は、特殊キャラを通常状態のプレイヤキャラ２０１に変更する。更に、プロセッサ３１は、ゲーム画面のモノクロ表示設定を解除し、通常の表示となるよう設定する。次に、ステップＳ９９で、所定の復活位置にプレイヤキャラ２０１を配置する。復活位置の決め方については、例えば、接触した復活対象オブジェクトから特殊キャラに対し打てレイを飛ばし、地形に当たるか否かを判定する。地形に当たった場合は、復活補助オブジェクトの位置を復活位置とする。当たらなかった場合は、特殊キャラの位置を復活位置とする。これにより、上記図１３～図１８で示したような位置が復活位置として決定される。但し、上記図１９で示したように、双方とも地形内にいる場合は、上記検索用ポインタを螺旋状に拡げるようにして、復活位置が検索される。なお、上記決定または検索された復活位置に敵キャラクタ等が存在している状況の場合は、当該敵キャラクタと接触しないような位置に当該復活位置がずらされてもよい。つまり、通常状態に戻した直後にミスイベントが発生しないような位置が復活位置として決定されて、プレイヤキャラ２０１が配置されてもよい。

また、復活位置の決定に際しては、通常状態に戻したプレイヤキャラのサイズも考慮して、復活位置が決定される。つまり、通常状態に戻したプレイヤキャラが障害物等にめり込まないようなスペースが十分に確保されている位置を復活位置として決定する。例えば、小さいサイズのプレイヤキャラであれば配置可能であるが、大きいサイズのプレイヤキャラの場合はスペースが足りていないような、障害物の隙間等の位置を想定する。この場合は、このような隙間位置が見つかったとしても、プレイヤキャラのサイズを考慮して、スペースが足りないと判断された場合は、他の位置の検索が継続される。一方、スペースが足りていると判断された場合は、この隙間位置が復活位置として決定されることになる。

一方、上記ステップＳ９６の判定の結果、特殊カウンタのカウントが終了した場合は（ステップＳ９６でＹＥＳ）、ステップＳ１００で、プロセッサ３１は、ロスト発生フラグ３６０にオンを設定する。その後、特殊状態処理は終了する。

図３５に戻り、次に、ステップＳ７で、プロセッサ３１は、ロスト発生フラグ３６０がオンか否かを判定する。オンではない場合（ステップＳ７でＮＯ）、ステップＳ８で、プロセッサ３１は、中間通過フラグ３５８に基づき、プレイヤキャラ２０１が中間地点オブジェクトに接触済みか否かを判定する。当該判定の結果、まだ接触していない場合は（ステップＳ８でＮＯ）、後述のステップＳ１０に処理が進められる。一方、接触済みの場合は（ステップＳ８でＹＥＳ）、ステップＳ９で、プロセッサ３１は、リプレイゴースト処理を実行する。

図４５は、上記リプレイゴースト処理の詳細を示すフローチャートである。まず、ステップＳ１１１で、プロセッサ３１は、配置完了フラグ３６７がオンか否かを判定する。オンの場合は（ステップＳ１１１でＹＥＳ）、プロセッサ３１は、リプレイゴースト処理を終了する。一方、オフの場合は（ステップＳ１１１でＮＯ）、ステップＳ１１２で、プロセッサ３１は、選出済みフラグ３６６がオンか否かを判定する。オンの場合は（ステップＳ１１２でＹＥＳ）、後述するステップＳ１１７に処理が進められる。オフの場合は（ステップＳ１１２でＮＯ）、ステップＳ１１３で、プロセッサ３１は、リプレイデータのゲームサーバ１からのダウンロードが完了したか否かを判定する。当該判定の結果、まだ完了していない場合は（ステップＳ１１３でＮＯ）、ステップＳ１１５で、プロセッサ３１は、ゲームサーバ１からリプレイデータのダウンロードを開始する。または、既に開始済みの場合は、プロセッサ３１は、ダウンロードを継続する。その後、リプレイゴースト処理は終了する。

一方、リプレイデータのダウンロードが完了した場合は（ステップＳ１１３でＹＥＳ）、次に、ステップＳ１１４で、プロセッサ３１は、この時点でリモートプレイヤが存在するか否かを判定する。当該判定の結果、リモートプレイヤが存在する場合は（ステップＳ１１４でＹＥＳ）、ステップＳ１１９で、プロセッサ３１は、配置完了フラグ３６７にオンを設定する。この場合、例えば、ダウンロード中にリモートプレイヤが入室してきた場合に、リプレイデータのダウンロードが完了しても、実際にリプレイゴーストの配置は行われないことになる。その後、リプレイゴースト処理は終了する。

一方、リモートプレイヤが存在しない場合は（ステップＳ１１４でＮＯ）、ステップＳ１１６で、プロセッサ３１は、ダウンロードしたリプレイデータの中から、リプレイゴーストとして用いるリプレイデータをランダムで最大３件まで選出する。この際、自分のリプレイデータについては選出対象から除外する。そして、プロセッサ３１は、選出済みフラグ３６６にオンを設定する。

次に、ステップＳ１１７で、プロセッサ３１は、選出したリプレイゴーストを全てステージ内に配置したか否かを判定する。まだ全て配置していない場合は（ステップＳ１１７でＮＯ）、ステップＳ１１８で、プロセッサ３１は、リプレイゴーストを１体生成して、ステージ内に配置する。この際、上記のように、配置するタイミングを少しずらしながら、１体ずつリプレイゴーストを配置するよう制御される。

一方、選出したリプレイゴーストを全てステージ内に配置したら（ステップＳ１１７でＹＥＳ）、上記ステップＳ１１９に処理が進められ、配置完了フラグ３６７にオンが設定される。その後、リプレイゴースト処理は終了する。

次に、図３６のステップＳ１０で、プロセッサ３１は、プレイヤキャラ２０１がゴールしたか否かを判定する。当該判定の結果、まだゴールしていない場合は（ステップＳ１０でＮＯ）、ステップＳ１１で、プロセッサ３１は、上記の処理が反映されたゲーム画面を生成して表示する。その後、上記ステップＳ２に戻り、処理が繰り返される。

一方、ゴールした場合は（ステップＳ１０でＹＥＳ）、ステップＳ１２で、プロセッサ３１は、ステージクリア処理を実行する。図４６は、ステージクリア処理の詳細を示すフローチャートである。まず、ステップＳ１４１で、プロセッサ３１は、リプレイ記録用データ３５９へのリプレイデータの記録を停止する。次に、ステップＳ１４２で、プロセッサ３１は、ステージクリアの演出を表示を行う。次に、ステップＳ１４３で、プロセッサ３１は、リプレイ記録用データ３５９をゲームサーバ１に送信する。その後、ステージクリア処理を終了する。

図３６に戻り、次に、ステップＳ１３で、プロセッサ３１は、自身が配置した自パネルがステージに残っている場合、自パネルデータ３９１をゲームサーバ１に送信する。

次に、ステップＳ１４で、プロセッサ３１は、ステージ部屋から退室する処理を行う。その後、ステージ処理は終了する。

次に、上記ステップＳ７の判定の結果、ロスト発生フラグ３６０がオンの場合の処理について説明する（ステップＳ７でＹＥＳ）。この場合は、まず、ステップＳ１５で、プロセッサ３１は、プレイヤキャラ２０１の残数から１を減らす。次に、ステップＳ１６で、プロセッサ３１は、プレイヤキャラ２０１の残数が０か否かを判定する。当該判定の結果、０ではない場合は（ステップＳ１６でＮＯ）、ステップＳ１７で、プロセッサ３１は、リスタート処理を実行する。

図４７は、上記リスタート処理の詳細を示すフローチャートである。図４７において、まず、ステップＳ１３１で、プロセッサ３１は、ロスト発生フラグ３６０にオフを設定する。また、この際、特殊状態化回数３５７も０に設定する。つまり、リスタートに伴い、特殊状態への変化回数のカウントをリセットする。この点、他の実施形態では、リセットせずにリスタート後も特殊状態化回数３５７引き継ぐようにしてもよい。

次に、ステップＳ１３２で、プロセッサ３１は、上記選出済みフラグ３６６および配置完了フラグ３６７を初期化する。これにより、中間地点からリスタートした場合、再度リプレイデータのダウンロードおよび新たなリプレイゴーストの再配置が行われ得る。

次に、ステップＳ１３３で、プロセッサ３１は、所定のリスタート地点にプレイヤキャラ２０１を配置する。また、これに併せて、仮想カメラもプレイヤキャラ２０１が撮像範囲に入るような位置に移動される。次に、ステップＳ１３４で、プロセッサ３１は、ゲーム画面を生成して表示する。以上で、リスタート処理は終了する。

図３６に戻り、リスタート処理が終われば、上記ステップＳ２に戻り、処理が繰り返される。

一方、上記ステップＳ１６の判定の結果、プレイヤキャラ２０１の残数が０の場合は（ステップＳ１６でＹＥＳ）、ステップＳ１８で、プロセッサ３１は、ゲームオーバーの演出を表示する。その後、上記ステップＳ１３に処理が進められる。この場合は、自パネルの情報をゲームサーバ１に送信してからステージ部屋から退室する流れとなる。

以上で、ステージプレイ処理の詳細説明を終了する。

［ゲームサーバ１の処理］
次に、ゲームサーバ１で実行される処理の詳細について説明する。図４８は、ゲームサーバ１に係る処理の詳細を示すフローチャートである。図４８において、まず、ステップＳ１５１で、ゲームサーバ１のプロセッサ１１は、マッチング処理を実行する。この処理では、プレイヤからのステージプレイの開始要求に応じて、プレイヤ同士のマッチング、すなわち、各プレイヤが入室するステージ部屋を決定する処理が実行される。また、その結果をゲーム装置３に送信する処理も実行される。

次に、ステップＳ１５２で、プロセッサ３１は、ステージ部屋を管理する処理を行う。この処理では、新たな部屋を作成する処理、プレイヤの補填を行う処理、プレイヤがいなくなった部屋を削除する処理等、ステージ部屋管理データ３０４を適宜更新して各ステージ部屋を管理する処理が行われる。

次に、ステップＳ１５３で、プロセッサ３１は、パネル情報を管理する処理を実行する。この処理では、各ゲーム装置３から送信されてい自パネルデータ３９１を受信し、上記パネル管理データ３０６への登録や更新が行われる。また、必要に応じて、所定のゲーム装置３からの要求に応じて、上記サーバパネルの基となるパネル情報３３２を送信する処理も実行される。

次に、ステップＳ１５４で、プロセッサ３１は、リプレイデータを管理する処理を行う。この処理では、各ゲーム装置３から受信したリプレイデータに基づいてリプレイ管理データ３０５への登録や更新が行われる。

その後、プロセッサ１１は、上記ステップＳ１５１に戻り、処理を繰り返す。以上で、ゲームサーバ１に係る処理の詳細説明は終了する。

このように、本実施形態では、プレイヤキャラ２０１にミスイベントが発生した場合、近くに復活補助オブジェクトであるリモートキャラがいる場合は、プレイヤキャラ２０１をロストさせずに、プレイヤキャラ２０１を一旦特殊状態に変化させる。そして、復活可能時間中にリモートキャラに接触することで、通常状態に復活することができる。これにより、シングルプレイの感覚でゲームを進行させつつ、オンラインでプレイすることのメリットをプレイヤに提供できる。そのため、オンラインマルチでゲームプレイすることを促進できる。

また、リモートキャラだけでなく、各リモートキャラが配置したリモートパネルや上記サーバパネルも上記復活補助オブジェクトとして機能させている。そのため、あるプレイヤは、リモートパネルを配置しておけば、これが自分の代わりに他のプレイヤの手助けとして機能することを期待できる。これにより、例えば、あるプレイヤが他のプレイヤの復活を補助することを意識して自分のペースでゲームが進行できなくなることを抑制できる。

また、本実施形態では、上記のように、ステージの中間地点を通過したことに応じて、リプレイゴーストを出現させている。当該リプレイゴーストは、一見しただけでは、上記リモートキャラとの見分けがつかないものとなっている。また、当該リプレイゴーストも、上記復活補助オブジェクトとして機能する。そのため、ステージの途中まで他のプレイヤとの出会いが無かった場合でも、ステージ後半については他のプレイヤとオンラインで繋がっており、同じステージ部屋で一緒に遊んでいるプレイ体験をプレイヤに提供できる。つまり、ステージプレイの開始から中間地点に到達するまでは、他のプレイヤと出会えることへの期待感を与える。例えばステージ前半であれば、後から入室してきたプレイヤのリモートキャラが追いついてくることは十分考えられる。そのため、ステージプレイ開始後にすぐにゴーストは出現させずに、しばらくの間は、他のプレイヤの入室およびリモートキャラの出現を待つようにしている。その一方で、ステージのプレイ開始から中間地点に到達しても他のプレイヤが入室してこないような場合は、リプレイゴーストを出現させることで、あたかもリモートキャラと一緒にステージを進んでいるようなプレイ体験を提供する。これにより、オンラインでプレイすることの意義を与え、プレイヤが積極的にオンラインでプレイすることを促進できる。また、リプレイゴースト出現後に他のプレイヤが入室してきた場合は、入室した人数に応じてリプレイゴーストを消去してリモートキャラを出現させている。そのため、コミュニケーションを取ることが可能なリモートキャラとのプレイを優先することもできる。

［変形例］
なお、上記リプレイゴーストに関して、例えば、プレイヤがプレイヤキャラ２０１として使用しているキャラクタと同じキャラクタが上記リプレイゴーストとして選出されることもあり得る。この場合、リプレイゴーストに係るキャラクタの外観については他のキャラクタの外観に変更してもよい。プレイヤキャラ２０１と同じキャラクタであるリプレイゴーストがいると、場合によっては見分けがつきにくく、プレイヤに不要な混乱を与えることを抑制するためである。

また、上記の例では、リプレイゴーストを出現させるタイミングについて、プレイヤキャラが上記中間地点に到達した場合を例に挙げた。この点、特定のステージでは、スタート地点からリプレイゴーストを出現させるようにしてもよい。この場合は、当該特定のステージにおいてはリプレイデータの記録もスタート地点から開始するようにすればよい。

また、上記の例では、リプレイゴーストの見た目はリモートキャラと変わらない場合を例示した。この点、他の実施形態では、リモートキャラであるかリプレイゴーストであるのかをプレイヤが区別可能なように、その見た目を異ならせるようにしてもよい。

また、上記の例では、リモートキャラが存在する場合はリプレイゴーストを出現させない（リプレイの再生をしない）という例を挙げた。他の実施形態では、リモートキャラが存在している場合でも、リプレイゴーストを出現させてもよい。例えばステージ部屋の定員の空きの分だけリプレイゴーストを出現させてもよい。更に、この場合は、いずれかのゲーム装置で出現させたリプレイゴーストの情報を他のゲーム装置との間で共有してもよい。例えば、ゲーム装置Ａのゲーム処理においてリプレイゴーストを出現させる処理が行われた場合、位置情報を共有したり、リプレイデータそのものを共有する等して、同じステージ部屋の他のゲーム装置でも、同じリプレイゴーストが出現するようにしてもよい。

また、上記実施形態では、所定条件下でミスイベントが発生したときにプレイヤキャラ２０１が特殊状態に変化する例を挙げた。この点、他の実施形態では、プレイヤが所定の操作を行うことで、自発的に上記特殊状態に変化できるようにしてもよい。但し、特殊状態から通常状態への復活は自発的な操作では行えず、上記のように復活補助オブジェクトに復活可能時間内に接触する必要があるようにしてもよい。これにより、プレイヤはステージを攻略する上で、戦略的にわざと特殊状態となって、ステージ上の難所を抜けてから復活する、というようなプレイが可能となる。そのため、オンラインプレイによるメリットを恒常しつつ、プレイの幅を広げることも可能となる。

また、上記リモートパネルに関して、他の実施形態では、退室したプレイヤが配置したリモートパネルについては、退室後所定の時間が経過したら自動的に消去するように制御してもよい。

また、上記パネル情報をゲームサーバ１に送信するタイミングについて、上記の例ではステージ部屋から退室する時に送信する例を挙げた。他の実施形態では、配置がおこなわれる都度、ゲームサーバ１へのパネル情報の送信が行われてもよい。また、同一プレイヤについての複数のパネル情報をゲームサーバ１に登録可能としてもよい。

また、上記実施形態では、通常状態のプレイヤキャラ２０１とリモートキャラとの衝突判定は行われないという例で説明した。この点、他の実施形態では、衝突判定自体は行うが、リモートキャラがプレイヤのゲームプレイに直接影響は及ぼさないような処理を行ってもよい。例えば、通常状態のプレイヤキャラ２０１が（半透明の）リモートキャラと接触したとき、リモートキャラが少し押されるような反応を演出的に表示しつつ、リモートキャラに係るリモートプレイヤ名を一時的に表示するような処理を行ってもよい。

また、上記実施形態では、各ゲーム装置でプレイするプレイヤ数が１人である場合を想定して説明していた。この点、１台のゲーム装置について例えば２人のプレイヤが同時にステージプレイに参加できるようにしてもよい。例えば、ゲーム装置Ａにおいて、プレイヤＡとプレイヤＢが２人同時プレイ（ローカルマルチプレイ）の態様で、同じゲーム画面内で各自のプレイヤキャラであるプレイヤキャラＡおよびプレイヤキャラＢが表示されるようにしてもよい。また、この場合は、プレイヤキャラＡおよびプレイヤキャラＢについては、リモートキャラのような半透明表示は行わず、双方とも不透明の態様で表示すればよい。また、プレイヤキャラＡおよびプレイヤキャラＢはお互いに復活補助オブジェクトとして機能させればよい。また、上記パネル配置については、お互いに相手が配置したパネルを上記リモートパネルとして扱ってもよい。あるいは、いずれか一方のプレイヤキャラが配置したものだけを上記リモートパネルとして扱ってもよい。

なお、上記のようなローカルマルチプレイの場合、サーバに送信するパネル情報については、いずれか１人のプレイヤが配置したパネル情報のみ送信するようにしても良よい。
上述したサーバパネルについては、最大で２つまで配置されるようにすればよい。

また、上記リプレイゴーストについては、プレイヤアクター数が１部屋で最大４つまでとなるように調整されるため、最大で２体分までの配置とすればよい。

また、ローカルマルチプレイに係るプレイヤキャラが全て通常状態ではなくなった場合は、特殊キャラがいなければ、その時点で、当該ローカルマルチプレイに係るプレイヤキャラについて上記ロストが発生する。一方、いずれかが特殊キャラになっていた場合は、この時点ではまだロストは発生しない。例えば上記リモートキャラやリモートパネルによって復活できる可能性があるためである。

また、上記実施形態では、特殊キャラであるときに復活可能時間内に復活補助オブジェクトに接触できれば、プレイヤキャラの残数を減らさずに復活させる例を挙げた。この点、他の実施形態では、残数を減らしたうえで復活させるようにしてもよい。この場合でも、復活する位置は復活補助オブジェクトの近くの位置になるため、リスタート地点まで戻されて復活する場合よりは、プレイヤにとって有利になる。

１ ゲームシステム
３ 情報処理端末（ゲーム装置）
４ コントローラ
３１ プロセッサ
３２ 記憶部
３３ 無線通信部
３４ コントローラ通信部

Claims (16)

1. プレイヤの操作に基づいて移動制御可能なプレイヤオブジェクトと、ネットワークを介して接続された他のゲーム装置から受信した情報に基づいて移動制御される他プレイヤオブジェクトとを含むゲームステージを生成する処理を実行するゲーム装置のコンピュータに実行させるゲームプログラムであって、
   前記コンピュータを、
   所定のゲームステージ内でミスが発生した際に、前記プレイヤオブジェクトを前記ゲームステージ内でダメージを受けない特殊状態に遷移させる遷移手段、
   前記プレイヤオブジェクトが前記特殊状態である間に、前記他プレイヤオブジェクトと、前記他のプレイヤオブジェクトによって前記ゲームステージ内に配置される配置オブジェクトとを含む復活補助オブジェクトに触れた場合、前記ゲームステージのプレイを終了させずに、当該プレイヤオブジェクトを前記特殊状態から当該ゲームステージ内でダメージを受け得る通常状態に戻す復活手段、
   前記プレイヤオブジェクトが特殊状態である間に復活補助オブジェクトに触れなかった場合に、前記ゲームステージのプレイを終了させる終了手段、
   として機能させる、ゲームプログラム。
2. 前記プレイヤオブジェクトによって配置された前記配置オブジェクトに前記特殊状態である前記プレイヤオブジェクトが触れた場合は、当該プレイヤオブジェクトは前記通常状態には戻さない、請求項１に記載のゲームプログラム。
3. 前記ゲームプログラムは、
   前記プレイヤオブジェクトが前記配置オブジェクトを配置した際、当該配置オブジェクトの位置情報を少なくとも含む配置情報を所定のサーバに送信する送信手段として更にコンピュータを機能させ、
   前記配置手段は、前記所定のサーバに保存された前記配置情報に基づいた前記配置オブジェクトを前記ゲームステージ内に配置し、
   前記復活補助オブジェクトには、前記所定のサーバに保存された前記配置情報に基づき配置された前記配置オブジェクトも含まれる、請求項１に記載のゲームプログラム。
4. 前記所定のサーバに保存された前記配置情報に基づき配置された前記配置オブジェクトは、配置された時点では前記復活補助オブジェクトとして機能せず、プレイヤオブジェクトが当該配置オブジェクトに接触したときに、前記復活補助オブジェクトとしての機能が有効化される、請求項３に記載のゲームプログラム。
5. 前記配置手段は、所定のタイミングにおいて、前記ゲームステージ内に配置オブジェクトが１つも存在しないときに、前記所定のサーバに保存された前記配置情報に基づいた前記配置オブジェクトを前記ゲームステージ内に配置する、請求項３に記載のゲームプログラム。
6. 前記ゲームプログラムは、
   前記所定のゲームステージ内でミスが発生した際に、前記プレイヤオブジェクトから所定範囲内に前記復活補助オブジェクトが存在するかどうかを判定する補助オブジェクト判定手段として前記コンピュータを更に機能させ、
   前記遷移手段は、前記補助オブジェクト判定手段によってプレイヤオブジェクトから所定範囲内に前記復活補助オブジェクトが存在すると判定された場合に、前記プレイヤオブジェクトを前記ゲームステージ内でダメージを受けない特殊状態に遷移させる、請求項１に記載のゲームプログラム。
7. 前記プレイヤオブジェクトは、前記特殊状態の間も操作可能であり、
   前記プレイヤオブジェクトが特殊状態である状態は所定時間継続し、
   前記終了手段は、前記プレイヤオブジェクトが前記特殊状態に遷移した後、所定時間内に復活補助オブジェクトに触れなかった場合、前記所定のステージのプレイを終了させる、請求項６に記載のゲームプログラム。
8. 同じ前記ゲームステージ内において特殊状態への遷移が複数回発生した場合、前記所定時間は、特殊状態への遷移回数の増加に応じて徐々に短くなる、請求項７に記載のゲームプログラム。
9. 前記ゲームプログラムは、他のプレイヤのプレイ内容をリプレイするためのリプレイデータに基づいて動作するゴーストキャラクタを前記ゲーム空間内に出現させるゴースト出現手段として前記コンピュータを更に機能させ、
   前記復活補助オブジェクトには、前記他プレイヤオブジェクトに加えて、前記他のプレイヤに係る前記ゴーストキャラクタも含まれる、請求項６に記載のゲームプログラム。
10. 前記ゲームプログラムは、
    所定の期間における前記プレイヤオブジェクトの動作内容を前記リプレイデータとして記録し、所定のタイミングで所定のサーバに当該リプレイデータを送信するリプレイ送信手段と、
    前記プレイヤによる前記ゲームステージのプレイが開始された後、所定のタイミングで、他のプレイヤが送信した前記リプレイデータを前記所定のサーバから取得するリプレイ取得手段として更に前記コンピュータを機能させ、
    前記ゴースト出現手段は、前記サーバから取得した前記リプレイデータに基づいて前記ゴーストキャラクタを動作させる、請求項９に記載のゲームプログラム。
11. 前記他のプレイヤオブジェクトは前記通常状態の前記プレイヤオブジェクトに対しては影響を及ぼさない、請求項６に記載のゲームプログラム。
12. 前記他のプレイヤオブジェクトは、前記プレイヤオブジェクトが通常状態のときは半透明の態様で表示され、当該プレイヤオブジェクトが前記特殊状態のときは、不透明の態様で表示される、請求項１１に記載のゲームプログラム。
13. 前記プレイヤオブジェクトが前記特殊状態のときは、前記復活補助オブジェクトを除き、前記ゲームステージの彩度を下げた態様でゲーム画面が表示される、請求項１２に記載のゲームプログラム。
14. 前記復活手段は、前記プレイヤオブジェクトを前記通常状態に戻す際、当該通常状態に戻した直後に前記ミスが発生しないような位置に、前記通常状態のプレイヤオブジェクトを配置する、請求項１に記載のゲームプログラム。
15. プレイヤの操作に基づいて移動制御可能なプレイヤオブジェクトと、ネットワークを介して接続された他のゲーム装置から受信した情報に基づいて移動制御される他プレイヤオブジェクトとを含むゲームステージを生成する処理を実行するゲームシステムであって、
    所定のゲームステージ内でミスが発生した際に、前記プレイヤオブジェクトを前記ゲームステージ内でダメージを受けない特殊状態に遷移させる遷移手段、
    前記プレイヤオブジェクトが前記特殊状態である間に、前記他プレイヤオブジェクトと、前記他のプレイヤオブジェクトによって前記ゲームステージ内に配置される配置オブジェクトとを含む復活補助オブジェクトに触れた場合、前記ゲームステージのプレイを終了させずに、当該プレイヤオブジェクトを前記特殊状態から当該ゲームステージ内でダメージを受け得る通常状態に戻す復活手段、
    前記プレイヤオブジェクトが特殊状態である間に復活補助オブジェクトに触れないまま所定条件が満たされた場合に、前記ゲームステージのプレイを終了させる終了手段、
    とを備える、ゲームシステム。
16. プレイヤの操作に基づいて移動制御可能なプレイヤオブジェクトと、ネットワークを介して接続された他のゲーム装置から受信した情報に基づいて移動制御される他プレイヤオブジェクトとを含むゲームステージを生成する処理を実行するゲームシステムのコンピュータに実行させるゲーム処理方向であって、
    前記コンピュータに、
    所定のゲームステージ内でミスが発生した際に、前記プレイヤオブジェクトを前記ゲームステージ内でダメージを受けない特殊状態に遷移させ、
    前記プレイヤオブジェクトが前記特殊状態である間に、前記他プレイヤオブジェクトと、前記他のプレイヤオブジェクトによって前記ゲームステージ内に配置される配置オブジェクトとを含む復活補助オブジェクトに触れた場合、前記ゲームステージのプレイを終了させずに、当該プレイヤオブジェクトを前記特殊状態から当該ゲームステージ内でダメージを受け得る通常状態に戻させ、
    前記プレイヤオブジェクトが特殊状態である間に復活補助オブジェクトに触れないまま所定条件が満たされた場合に、前記ゲームステージのプレイを終了させる、ゲーム処理方法。

Images