(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023166361
(43)【公開日】2023-11-21
(54)【発明の名称】ゲームプログラム、ゲームシステム、およびゲーム処理方法
(51)【国際特許分類】
A63F 13/497 20140101AFI20231114BHJP
A63F 13/30 20140101ALI20231114BHJP
A63F 13/53 20140101ALI20231114BHJP
【FI】
A63F13/497
A63F13/30
A63F13/53
【審査請求】有
【請求項の数】8
【出願形態】OL
【公開請求】
(21)【出願番号】P 2023101002
(22)【出願日】2023-06-20
(71)【出願人】
【識別番号】000233778
【氏名又は名称】任天堂株式会社
(74)【代理人】
【識別番号】110001276
【氏名又は名称】弁理士法人小笠原特許事務所
(74)【代理人】
【識別番号】100130269
【弁理士】
【氏名又は名称】石原 盛規
(72)【発明者】
【氏名】松浦 龍平
(72)【発明者】
【氏名】中尾 一
(72)【発明者】
【氏名】足助 重之
(72)【発明者】
【氏名】毛利 志朗
(57)【要約】
【課題】マルチプレイにおけるゲームの興趣性を向上できるゲームプログラム、ゲームシステム、およびゲーム処理方法を提供すること。
【解決手段】プレイヤの操作に基づいて移動制御可能なプレイヤオブジェクトと、ネットワークを介して接続された他のゲーム装置から受信した情報に基づいて移動制御される他プレイヤオブジェクトとを含むゲームステージを生成する処理を実行するゲーム処理において、所定のゲームステージでのプレイが一定の進行度に到達していると判定された場合に、サーバから取得した、他のゲーム装置のプレイヤとは別のプレイヤの操作履歴に基づいて移動制御されるリプレイオブジェクトをゲームステージに配置して移動制御する。
【選択図】
図45
【特許請求の範囲】
【請求項1】
プレイヤの操作に基づいて移動制御可能なプレイヤオブジェクトと、ネットワークを介して接続された他のゲーム装置から受信した情報に基づいて移動制御される他プレイヤオブジェクトとを含むゲームステージを生成する処理を実行するゲーム装置のコンピュータに実行させる、ゲームプログラムであって、
前記コンピュータを、
所定のゲームステージでのプレイが一定の進行度に到達していることを判定する進行度判定手段、
前記進行度判定手段によって一定の進行度に到達していると判定された場合に、サーバから取得した、前記他のゲーム装置のプレイヤとは別のプレイヤの操作履歴に基づいて移動制御されるリプレイオブジェクトを前記ゲームステージに配置し、移動制御するリプレイオブジェクト再生手段、
として機能させる、ゲームプログラム。
【請求項2】
前記リプレイオブジェクト再生手段は、前記進行度判定手段によって一定の進行度に到達していると判定され、かつ、前記ゲームステージ内の前記他プレイヤオブジェクトの数と前記プレイヤオブジェクトを合計した数が所定数以下である場合に、前記リプレイオブジェクトを前記ゲームステージに配置し、移動制御する、請求項1記載のゲームプログラム。
【請求項3】
前記ゲームプログラムは、
前記進行度判定手段によって一定の進行度に到達していると判定された場合に、当該一定の進行度に到達してから、前記ゲームステージクリアまでの前記プレイヤの操作に基づいた操作履歴を所定のサーバに送信する送信手段として更にコンピュータを機能させる、請求項1に記載のゲームプログラム。
【請求項4】
前記リプレイオブジェクト再生手段は、前記他プレイヤオブジェクトの数と前記リプレイオブジェクトの数を合計した数が前記所定数になるように、複数の前記リプレイオブジェクトを前記ゲームステージに配置し、移動制御する、請求項2記載のゲームプログラム。
【請求項5】
前記他プレイヤオブジェクトと前記リプレイオブジェクトを半透明で描画する、請求項1記載のゲームプログラム。
【請求項6】
前記リプレイオブジェクト再生手段は、複数の前記リプレイオブジェクトを配置する場合は、所定の時間間隔を空けながら当該リプレイオブジェクトを順次配置する、請求項4に記載のゲームプログラム。
【請求項7】
プレイヤの操作に基づいて移動制御可能なプレイヤオブジェクトと、ネットワークを介して接続された他のゲーム装置から受信した情報に基づいて移動制御される他プレイヤオブジェクトとを含むゲームステージを生成する処理を実行するゲームシステムであって、
所定のゲームステージでのプレイが一定の進行度に到達していることを判定する進行度判定手段、
前記進行度判定手段によって一定の進行度に到達していると判定された場合に、サーバから取得した、前記他のゲーム装置のプレイヤとは別のプレイヤの操作履歴に基づいて移動制御されるリプレイオブジェクトを前記ゲームステージに配置し、移動制御するリプレイオブジェクト再生手段、
とを備える、ゲームシステム。
【請求項8】
プレイヤの操作に基づいて移動制御可能なプレイヤオブジェクトと、ネットワークを介して接続された他のゲーム装置から受信した情報に基づいて移動制御される他プレイヤオブジェクトとを含むゲームステージを生成する処理を実行するゲーム装置のコンピュータに実行させる、ゲーム処理方法であって、
前記コンピュータに、
所定のゲームステージでのプレイが一定の進行度に到達していることを判定させ、
一定の進行度に到達していると判定された場合に、サーバから取得した、前記他のゲーム装置のプレイヤとは別のプレイヤの操作履歴に基づいて移動制御されるリプレイオブジェクトを前記ゲームステージに配置し、移動制御させる、ゲーム処理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、マルチプレイゲーム処理に関する。
【背景技術】
【0002】
従来から、レースゲームにおいて、プレイヤ自身の走りを「ゴースト」として記録し、当該ゴーストと併走してレースできるゲームが知られている。(例えば、非特許文献1)。
【先行技術文献】
【非特許文献】
【0003】
【非特許文献1】任天堂株式会社、“マリオカート8デラックス 「タイムアタック」”、[online]、[令和5年6月20日検索]、インターネット(URL:https://www.nintendo.co.jp/switch/aabpa/about/index.html)
【発明の概要】
【発明が解決しようとする課題】
【0004】
上記のゲームでは、自分や他のプレイヤのゴーストとレースを行うという楽しみ方がプレイヤに提供されていた。すなわち、ゴーストとプレイヤキャラクタとで同じタイミングでレースをスタートし、ゴールを目指してゴーストと競争するという楽しみ方が提供されていた。この点につき、マルチプレイにおけるゲームの興趣性を向上すべく、ゴーストを用いた新たな遊び方を提供する余地があった。
【課題を解決するための手段】
【0005】
上記課題に鑑みて、例えば以下のような構成例が挙げられる。
【0006】
(構成1)
構成1は、プレイヤの操作に基づいて移動制御可能なプレイヤオブジェクトと、ネットワークを介して接続された他のゲーム装置から受信した情報に基づいて移動制御される他プレイヤオブジェクトとを含むゲームステージを生成する処理を実行するゲーム装置のコンピュータに実行させる、ゲームプログラムである。当該ゲームプログラムは、コンピュータを、所定のゲームステージでのプレイが一定の進行度に到達していることを判定する進行度判定手段、進行度判定手段によって一定の進行度に到達していると判定された場合に、サーバから取得した、他のゲーム装置のプレイヤとは別のプレイヤの操作履歴に基づいて移動制御されるリプレイオブジェクトをゲームステージに配置し、移動制御するリプレイオブジェクト再生手段、として機能させる。
【0007】
上記構成によれば、他プレイヤと一緒に遊ぶ機会や他プレイヤが入室してくる期待感を提供しつつ、ゲームがある程度進行するまでに他プレイヤとの出会いが無かった場合でも、他プレイヤと一緒にプレイしているかのような体験を提供できる。
【0008】
(構成2)
構成2は、上記構成1において、リプレイオブジェクト再生手段は、進行度判定手段によって一定の進行度に到達していると判定され、かつ、ゲームステージ内の他プレイヤオブジェクトの数とプレイヤオブジェクトとの合計数が所定数以下である場合に、リプレイオブジェクトをゲームステージに配置し、移動制御してもよい。
【0009】
上記構成によれば、ステージ内のプレイヤ数の状況に応じて、リプレイオブジェクトを配置できる。例えば、他のプレイヤオブジェクトが存在していれば、リプレイオブジェクトは配置しないようにして、他のプレイヤとのオンラインプレイを優先して楽しませることが可能となる。
【0010】
(構成3)
構成3は、上記構成1において、ゲームプログラムは、進行度判定手段によって一定の進行度に到達していると判定された場合に、当該一定の進行度に到達してから、ゲームステージクリアまでのプレイヤの操作に基づいた操作履歴を所定のサーバに送信する送信手段として更にコンピュータを機能させてもよい。
【0011】
上記構成によれば、ゲームプレイを進めるうえで自然な流れ・行動で、プレイヤの操作履歴を記録してサーバに送信できる。
【0012】
(構成4)
構成4は、上記構成2において、リプレイオブジェクト再生手段は、他プレイヤオブジェクトの数とリプレイオブジェクトの数を合計した数が上記所定数になるように、複数のリプレイオブジェクトをゲームステージに配置し、移動制御してもよい。
【0013】
上記構成によれば、ゲームステージ内に複数にプレイヤオブジェクトが存在している状況を作り出すことができ、ゲームの興趣性を向上できる。
【0014】
(構成5)
構成5は、上記構成1において、他プレイヤオブジェクトとリプレイオブジェクトを半透明で描画してもよい。
【0015】
上記構成によれば、プレイヤ自身の操作対象となるプレイヤオブジェクトの見分けがつきやすくなる。
【0016】
(構成6)
構成6は、上記構成1において、リプレイオブジェクト再生手段は、複数のリプレイオブジェクトを配置する場合は、所定の時間間隔を空けながらリプレイオブジェクトを順次配置してもよい。
【0017】
上記構成によれば、複数のリプレイオブジェクトが時間差を持って出現するため、他のプレイヤが異なるタイミングで入室してくるというような、人間的な動作感を演出できる。
【発明の効果】
【0018】
本開示によれば、ゲームがある程度進行するまでに他プレイヤとの出会いが無かった場合でも、他プレイヤと一緒にプレイしているかのような体験を提供できる。
。
【図面の簡単な説明】
【0019】
【
図1】本実施形態に係るゲームシステムの全体像を示す模式図
【
図2】ゲームサーバ1のハードウェア構成を示すブロック図
【
図3】ゲーム装置3のハードウェア構成を示すブロック図
【
図27】ゲームサーバ1の記憶部12に記憶される各種データの一例を示すメモリマップ
【
図28】ステージ部屋管理データ304のデータ構成の一例
【
図29】リプレイ管理データ305のデータ構成の一例
【
図30】パネル管理データ306のデータ構成の一例
【
図31】ゲーム装置3の記憶部32に記憶される各種データの一例を示すメモリマップ
【
図32】リモートキャラデータ361のデータ構成の一例
【
図33】プレイヤアクター管理データ363のデータ構成の一例
【
図35】ゲーム装置3で実行されるゲーム処理の詳細を示すフローチャート
【
図36】ゲーム装置3で実行されるゲーム処理の詳細を示すフローチャート
【
図37】ステージ準備処理の詳細を示すフローチャート
【
図38】入退室チェック処理の詳細を示すフローチャート
【
図39】入退室チェック処理の詳細を示すフローチャート
【
図40】リモートパネルチェック処理の詳細を示すフローチャート
【
図43】自パネル配置処理の詳細を示すフローチャート
【
図45】リプレイゴースト処理の詳細を示すフローチャート
【
図46】ステージクリア処理の詳細を示すフローチャート
【
図47】リスタート処理の詳細を示すフローチャート
【
図48】ゲームサーバ1で実行されるゲームサーバ処理の詳細を示すフローチャート
【発明を実施するための形態】
【0020】
以下、本発明の一実施形態について説明する。
図1は、本実施形態に係る情報処理システム(ゲームシステム)の全体像を示す模式図である。本実施形態の情報処理システム100は、ゲームサーバ1と、複数の情報処理端末3とを含む。ゲームサーバ1、情報処理端末3とは、インターネット等のネットワーク10を介して通信可能に構成されている。本実施形態では、このような構成で、情報処理が実行されるが、以下では、当該情報処理の一例として、ゲーム処理を例として説明する。具体的には、情報処理端末3上にゲームプログラムがインストールされ、必要に応じてゲームサーバ1と通信を行いながら実行されるゲーム処理を例示する。
【0021】
[ゲームサーバのハードウェア構成]
次に、上記ゲームサーバ1のハードウェア構成について説明する。
図2は、ゲームサーバ1のハードウェア構成を示すブロック図である。ゲームサーバ1は、プロセッサ11と、記憶部12と、通信部13とを少なくとも備えている。プロセッサ11は、各サーバを制御するための各種プログラムを実行する。記憶部には、プロセッサ11によって実行される各種プログラムおよび利用される各種データが格納される。通信部13は、有線、または無線通信によってネットワークと接続し、上記情報処理端末3または他のサーバとの間で所定のデータを送受信する。なお、本実施形態では、ゲームサーバ1が1つである例を図示しているが、分散処理を行うサーバ群として構成されていてもよい。
【0022】
[ゲーム装置のハードウェア構成]
次に、上記情報処理端末3について説明する。当該情報処理端末3は、例えばスマートフォン、据置型または携帯型のゲーム装置、タブレット端末、携帯電話、パーソナルコンピュータ、ウェアラブル端末等である。本実施形態では、据置型ゲーム装置(以下、単にゲーム装置と呼ぶ)を情報処理端末3の一例として説明する。
【0023】
図3は、本実施形態に係るゲーム装置3のハードウェア構成の一例を示すブロック図である。
図3において、ゲーム装置3は、プロセッサ31を備える。プロセッサ31は、ゲーム装置3において実行される各種の情報処理を実行する情報処理部であって、例えば、CPU(Central Processing Unit)のみから構成されてもよいし、CPU機能、GPU(Graphics Processing Unit)機能等の複数の機能を含むSoC(System-on-a-chip)から構成されてもよい。プロセッサ31は、記憶部32に記憶される情報処理プログラム(例えば、ゲームプログラム)を実行することによって、各種の情報処理を実行する。なお、記憶部32は、例えば、フラッシュメモリやDRAM(Dynamic Random Access Memory)等の内部記憶媒体であってもよいし、図示しないスロットに装着される外部記憶媒体等を利用する構成でもよい。
【0024】
また、ゲーム装置3は、ゲーム装置3が他のゲーム装置3や上記サーバと無線通信を行うための無線通信部33を備える。当該無線通信としては、例えば、インターネット通信や近距離無線通信が用いられる。
【0025】
また、ゲーム装置3は、ゲーム装置3がコントローラ4と有線または無線通信を行うためのコントローラ通信部34を備える。
【0026】
また、ゲーム装置3には、画像音声出力部35を介して表示部5(例えば、テレビ等)が接続される。プロセッサ31は、(例えば、上記の情報処理の実行によって)生成した画像や音声を、画像音声出力部35を介して表示部5に出力する。
【0027】
次に、コントローラ4について説明する。コントローラ4は、方向入力デバイスの一例であるアナログスティック42を少なくとも1つ備える。当該アナログスティック42は、方向を入力することが可能な方向入力部として用いることができる。ユーザは、アナログスティック42を傾倒することによって傾倒方向に応じた方向の入力(および、傾倒した角度に応じた大きさの入力)が可能である。また、コントローラ4は、各種操作ボタンを含むボタン部43を備える。例えば、コントローラ4は、上記ハウジングの主面上に複数個の操作ボタンを備えていてもよい。
【0028】
また、コントローラ4は、慣性センサー44を備える。具体的には、コントローラ4は、慣性センサー44として、加速度センサー、角速度センサーを備えている。本実施形態においては、加速度センサーは、所定の3軸方向に沿った加速度の大きさを検出する。また、角速度センサーは、所定の3軸回りの角速度を検出する。
【0029】
また、コントローラ4は、上記コントローラ通信部34と有線または無線通信を行うための通信部41も備える。上記アナログスティック42に対する方向入力内容、ボタン部43の押下状態を示す情報、および、慣性センサー44による各種の検出結果は、適宜のタイミングで繰り返し通信部41へ出力され、ゲーム装置3に送信される。
【0030】
[本実施形態における情報処理の概要]
次に、本実施形態に係る情報処理の概要を説明する。本実施形態では、情報処理の一例として、仮想空間内に存在するプレイヤキャラクタオブジェクト(以下、プレイヤキャラと呼ぶ)をプレイヤが操作して遊ぶゲーム処理を想定して説明する。より具体的には、本実施形態では、横スクロール型のアクションゲーム(以下、本ゲームと呼ぶ)を想定して説明する。本ゲームでは、プレイの主な舞台となる、「ステージ」と呼ばれる2次元の仮想空間が用意されている。当該ステージには、スタート地点とゴール地点が設定されている。スタート地点からゴール地点までの間には、様々な敵キャラクタや障害物、ジャンプ台や落とし穴等の各種ギミックが配置されている。そして、本ゲームは、これら敵キャラクタ等を倒したり回避したりしながら、プレイヤキャラをゴール地点に到達させるゲームである。なお、当該ステージは、ゲームによっては「コース」や「ラウンド」等と呼ばれることもある。また、本実施形態では、ゲーム画面が2D画面で表示されるゲームを例示するが、他の実施形態では、上記仮想空間は3次元の仮想空間であり、1人称視点や3人称視点等の3D画面で表示されるゲームであってもよい。
【0031】
図4に、上記ステージをプレイ中のゲーム画面(以下、ステージ画面と呼ぶ)の一例を示す。
図4の例は、スタート地点付近の画面、すなわち、当該ステージのプレイを開始した直後の画面例である。
図4では、プレイヤキャラ201と、敵キャラクタ202が表示されている。その他、ブロック等の各種地形オブジェクトも表示されている。なお、本ステージでは、ステージの左端付近にスタート地点が設定され、ステージの右端付近にゴール地点が設定されているものとする。そのため、全体的なゲーム進行として、プレイヤキャラ201を画面の右方向に向けて進ませていくようなステージ構成となっている。このようなステージ画面において、プレイヤは、プレイヤキャラ201を操作して、ゴール地点に向けて移動させていく。プレイヤキャラの移動にあわせて、ステージの別の場所がステージ画面として表示されることになる。そして、プレイヤキャラがゴール地点に到達すれば、当該ステージをクリアしたことになる。
【0032】
また、上記ステージには、スタート地点とゴール地点の略中間となる位置に「中間地点」が設定されている。当該中間地点には、中間地点であることを示す中間地点オブジェクトが配置されている。プレイヤキャラが当該中間地点オブジェクトに接触すると、それ以降、ゴールするまでの間のプレイにおいてリスタートすることになった場合、当該中間地点からリスタートできるようになる。なお、中間地点到達前は、スタート地点からリスタートする。なお、中間地点として設定する位置については、スタート地点からゴール地点までの略中間となる位置に限らず、スタート地点からゴール地点までの途中の位置であれば、所定の位置を中間地点として設定してもよい。
【0033】
[オンラインプレイ要素について]
本ゲームの基本的なゲーム進行の流れは上述の通りであり、基本的にはシングルプレイの感覚でゲームがプレイできる。更に、本ゲームでは、マルチプレイも可能である。一例として、本ゲームは、インターネット経由で上記サーバや他のゲーム装置3と接続して他のプレイヤとプレイすることが可能なオンラインプレイ要素も有する。
【0034】
以下、本ゲームのオンラインプレイ要素に関して説明する。まず、全体的なネットワーク的な構成に関して簡単に説明する。基本的なネットワーク構成については、上記
図1で示したような構成となる。そして、本ゲームでは、いわゆるMO(Multiplayer Online)タイプのオンラインゲームにおける通信グループの構成を利用したゲームを提供する。具体的には、各ステージに対応する通信グループ(以下、ステージ部屋と呼ぶ)とが適宜生成および管理され得る。換言すれば、各ステージに相当する仮想空間が用意され、当該仮想空間に、上記ゲームサーバ1によってマッチングされた所定人数のプレイヤが接続するという形態である。また、同じステージについて、複数のステージ部屋が並列に存在し得る。
【0035】
また、ステージ部屋には入室可能な人数の最大値が設けられている。一例として、本ゲームでは、ステージ部屋は1部屋に4人まで入室可能であるとする。また、本ゲームでは、一例として、同じステージ部屋のゲーム装置3は、P2P(Peer to peer)の通信方式で接続されるものとする。他の実施形態では、サーバ経由の通信方式を用いてもよい。
【0036】
図5は、他のプレイヤが既に入室しているステージ部屋にプレイヤが入室した場合の、当該プレイヤのゲーム装置3から出力されるステージ画面の一例である。
図5では、他のプレイヤが操作する他のプレイヤキャラ203が、プレイヤが操作するゲーム装置3におけるステージ画面上に表示されている。他のプレイヤはプレイヤよりも先に入室し、ステージプレイを開始しているため、当該他のプレイヤキャラ203は、スタート地点よりはゴール地点に向けて少し先に進んだ位置にいる。また、
図5において、当該他のプレイヤキャラ203は、半透明で表示されているものとする(図面では点線で示している)。
【0037】
なお、本ゲームでは、プレイヤキャラとして使用できるキャラクタが複数種類用意されている。例えば、各プレイヤは、12種類の異なるキャラクタの中からいずれかを、自分が使用するプレイヤキャラとして選択できる。そのため、上記他のプレイヤキャラ203は、他のプレイヤが選択したキャラクタが表示され、プレイヤキャラ201とは異なるキャラクタが表示され得る。
【0038】
ここで、以下の説明では、同じステージ部屋に入室した他のプレイヤのことを「リモートプレイヤ」と呼び、リモートプレイヤが操作する上記他のプレイヤキャラ203のことを「リモートキャラ」と呼ぶ。また、詳細は後述するが、リモートプレイヤに関するプレイヤキャラとして、「リプレイゴースト」というものもステージ画面に出現し得る。また、以下では、プレイヤキャラ、リモートキャラ、リプレイゴーストのことを総称して、「プレイヤアクター」と呼ぶこともある。本ゲームでは、1部屋に4人まで入室可能なので、1部屋に最大で4体のプレイヤアクターが同時に存在し得ることになる。
【0039】
[リモートキャラについて]
次に、上記リモートキャラに関してより詳しく説明する。本ゲームでは、ステージ部屋で表示されるリモートキャラは、他のプレイヤの操作が反映されて移動はするが、プレイヤのゲーム装置3で実行されているゲームプレイには直接的には干渉せず、影響は与えない。具体的には、あるステージ部屋に接続しているゲーム装置3同士の間では、基本的には、各自のプレイヤキャラの位置情報、および、各プレイヤキャラが生成した所定のオブジェクトの位置情報について共有される。プレイヤキャラが生成した所定のオブジェクトの例としては、後述する「パネル」がある。一方、敵キャラクタ等のその他のオブジェクトの状態や位置情報等は共有されない。例えば、各ゲーム装置3において、ステージプレイにおけるステージオブジェクト等との衝突判定処理については、各ゲーム装置におけるプレイヤキャラ201についてのみ行われ、原則的には、リモートキャラについての衝突判定処理は行われない。そのため、プレイヤキャラ201がリモートキャラの位置と重なっても、衝突せずにすり抜けて移動するような結果となる(但し、後述する特殊キャラに対しては例外的に衝突判定が行われる)。また、リモートキャラが敵キャラクタと重なった場合も、リモートキャラと敵キャラクタとの衝突判定等は行われず、敵キャラクタがリモートキャラをすり抜けて移動するような結果となる。また、例えば、プレイヤキャラ201が敵キャラクタAを倒した場合も、この敵キャラクタAの状態が他のゲーム装置3に反映されることはない。他のゲーム装置3において、当該他のゲーム装置の他のプレイヤが当該敵キャラクタAを倒していなければ、当該敵キャラクタAは依然として存在している状態で制御される。つまり、ステージプレイの進行管理自体は、各自のゲーム装置上で個別に行われ、この際に、リモートキャラがいる場合は、その表示だけは行う、というような制御となる。また、干渉しない存在であることをわかりやすくするため、リモートキャラは、基本的には、半透明の態様で表示される。そのため、各プレイヤは、基本的には、他のプレイヤの行動の影響を受けることなく、また、他のプレイヤの行動を阻害等することなく、シングルプレイと同様の感覚でステージをプレイできる。換言すれば、1人でゲームを進めつつ、リモートキャラ、換言すれば、他のプレイヤの存在は認識できる、というプレイ感・ゲーム体験が得られる。
【0040】
また、上記のように、各プレイヤは他のプレイヤからの影響を受けずに個別にゲームを進行できる。そのため、4人のプレイヤが揃わないとステージプレイが開始できないというものではなく、ステージ部屋内にいるプレイヤが1人だけの場合でも、ステージプレイは開始できる。その後、途中参加のような形で、最大4人までは、他プレイヤが入室可能である。例えば、プレイヤAが、ステージの3分の1程度まで進んだ時点で、プレイヤBが入室した場合、プレイヤBのプレイヤキャラはスタート地点から移動を開始することになる。つまり、プレイヤBからすれば、プレイヤAのプレイヤキャラがある程度先に進んだ位置に存在している状態で、ステージプレイを開始することになる。また、プレイヤAからすれば、プレイヤBの入室によって自身のプレイが阻害されるということもなく、引き続きプレイを継続できる。
【0041】
[リプレイゴーストについて]
次に、上記リプレイゴーストについて説明する。リプレイゴーストとは、他のプレイヤのリプレイデータをゴーストとして再生するものである。本実施形態では、上記中間地点からゴール地点までの間のプレイをリプレイデータとして、上記ゲームサーバ1に保存しておく。そして、ゲームステージのプレイが一定の進行度に到達している場合に、リプレイゴーストを出現させる。より具体的には、ステージ部屋に入室しているのがプレイヤ1人のみの状態で中間地点まで進んだ場合、つまり、中間地点まで他のプレイヤとのマッチングが発生することなく進んだ場合、上記ゲームサーバ1からリプレイデータをダウンロードして、再生する。これにより、リプレイデータに基づく他のプレイヤキャラクタがゴーストとして表示され得る。これが、リプレイゴーストである。また、当該リプレイゴーストは、リプレイを再生するため、結果的に、上記リモートキャラと同様にふるまう。これにより、中間地点まで他のプレイヤが入室して来なかった場合、他プレイヤのゴーストと一緒にプレイするという状況を作り出すことができる。そのため、ステージによっては、他のプレイヤとのマッチングが中々発生しないことで、オンラインで遊んでいる意義が薄いとプレイヤに感じさせてしまうことを抑制できる。
【0042】
ここで、上記リプレイゴーストは、基本的には、その見た目は上記リモートキャラと見分けがつかない。例えば、
図6に、リプレイゴーストが表示されている画面例を示す。
図6では、3体のリプレイゴーストが表示されている、これらは、上記リモートキャラと同様に、半透明で表示されている。また、その見た目も、リモートキャラとは変わらないものとなっている。そして、上記リモートキャラについては、生身の人間が操作していることから、例えば、感情を示す顔画像等のエモート表示を行う操作が可能である。そのため、各ゲーム装置3で個別にプレイ管理しているとは言え、このような操作によって、プレイヤ同士である程度のコミュニケーションは取れる。一方、リプレイゴーストについては、このようなコミュニケーションは取れない。そのため、リモートキャラとリプレイゴーストとの区別がつくようにしておいてもよい。例えば、リモートキャラに近づくと、それがリモートキャラであることが分かるような標識画像、例えばユーザ名等を表示してもよい。一方、リプレイゴーストについては、近づいてもこのような標識画像を表示しないようにしてもよい。これにより、当該標識画像の有無によって、プレイヤは、リモートキャラであるかリプレイゴーストであるかを判別できる。
【0043】
なお、本実施形態において、より正確には、上記中間地点オブジェクトにプレイヤキャラ201が接触した場合に、リプレイゴーストを出現させる。これは、中間地点を通過したことをきっかけとしてリプレイゴーストが出現するということがプレイヤにわかりやすいためである。また、本例では、プレイの進行度として、中間地点を通過した場合を例に説明するが、他の実施形態では、例えば、ステージプレイ開始からの経過時間やステージ内イベントの達成度に基づいて、上記リプレイゴーストを出現させるトリガーとする進行度を判定してもよい。
【0044】
以下、リプレイゴーストについて、より詳細に説明する。
【0045】
[リプレイの記録について]
まず、リプレイデータの記録に関して説明する。本実施形態では、プレイヤキャラ201が上記中間地点オブジェジェクトに接触する(以下ではこのことを「中間地点を通過する」と表現することもある)ことで、リプレイデータの記録が開始される。そして、プレイヤキャラ201がゴール地点に到達することで、当該記録が停止される。その後、ステージのクリア処理に伴って、リプレイデータが上記ゲームサーバ1に送信される。
【0046】
なお、中間地点オブジェクトへの接触と、ゴール地点の到達をリプレイデータの記録開始および停止のタイミングとするのは、プレイヤキャラ201の自然な行動で記録の開始、停止ができるからである。また、リプレイデータの記録制御のための専用のオブジェクトを別途配置しなくてもよい、等の理由によるものである。
【0047】
また、中間地点の通過後ゴールするまでの間に、「ミスイベント」が発生した場合も、その時点でリプレイデータの記録は一旦停止する。当該ミスイベントについては後述するが、例えばプレイヤキャラ201が敵キャラクタに倒された場合等である。また、ミスイベントが発生した場合、所定の条件が揃うと、プレイが一旦中断され、プレイヤキャラ201の残数(いわゆる残機)が減らされた上で、中間地点からリスタートする。この場合、基本的には、リスタート前のリプレイデータが破棄され、リスタートした時点から、改めてリプレイデータの記録が開始される。但し、本実施形態では、この際、一定の確率で、リスタート前のリプレイデータは破棄せずに保持しておき、リスタートした時点からのリプレイデータの記録を行わないようにする。上記のように、ゴールすることでリプレイデータがサーバに送信されるが、上記のような制御により、プレイの途中でリスタートが発生していた場合、次のような2種類のリプレイデータが送信され得る。1つめは、ゴールまで到達した内容のリプレイデータ、すなわち、ステージをクリアした内容のリプレイデータである。そして、2つめは、途中でミスイベントが発生した内容のリプレイデータ、すなわち、ステージがクリアできなかったリプレイデータである。これにより、リプレイデータの内容を多様なものとすることができる。
【0048】
また、本実施形態では、中間地点が1つだけ設定されている場合を想定して説明するが、中間地点が2つ以上設定されているステージがあってもよい。この場合は、最初に通過した中間地点から記録が開始される。また、途中でミスイベントが発生した場合は、最後に通過した中間地点からリスタートする。そして、リスタートに係るリプレイデータの記録については、この最後に通過した中間地点から改めて記録を開始する。
【0049】
[リプレイのダウンロードおよび再生について]
次に、リプレイデータのダウンロード、および、再生に関して説明する。上記のようにしてゲームサーバ1にリプレイデータが送信されるが、本実施形態では、ゲームサーバ1において、上記中間地点オブジェクト(上記ステージ)毎に上記リプレイデータが紐付けられて管理される。より具体的には、ゲームサーバ1において、ステージ毎に、直近30件分のリプレイデータが保持されている。
【0050】
そして、プレイヤキャラ201が中間地点を通過したタイミングで、ゲーム装置3からゲームサーバ1にリプレイデータのリクエストが送信される。ゲームサーバ1からは、そのステージに対応した直近30件分のリプレイデータが送られてくるので、ゲーム装置3でこれが受信される。ゲーム装置3では、受信した30件分のデータの中から、ランダムで、最大3件まで(ステージ部屋の定員が4人の例のため)、リプレイゴーストとして用いるリプレイデータを選出する。この際、リプレイデータの送信元が、上記リクエストを送ったプレイヤと同じであるリプレイデータについては、選出対象から除外する。つまり、自分のリプレイデータは選出されないようにする。
【0051】
そして、選出されたリプレイデータをリプレイゴーストとして再生開始する。この際、複数体のリプレイゴーストを使う場合は、再生開始タイミングを数秒毎にばらけさせるようにする。例えば、3体のリプレイゴーストを使う場合、3体同時に生成して出現させるのではなく、2体目は1体目のリプレイゴーストを出現させてから5秒後、3体目は2体目の出現から更に5秒後に出現させる、等である。
【0052】
また、リプレイデータをダウンロードして再生を開始する際に、もしリモートキャラが存在していた場合は、リプレイは再生しない。例えば、中間地点通過とほぼ同じタイミングで、他のプレイヤが入室してきた場合等である。これは、リモートキャラが存在するのであれば、リモートキャラとコミュニケーションを取ってもらいたい、という観点によるものである。
【0053】
また、ミスイベントの発生により、中間地点からリスタートする場合は、再度、リプレイデータのダウンロードからやり直す。そのため、リスタートした場合は、リスタート前と後とで、異なるリプレイゴーストが出現し得る。但し、前回のダウンロード完了から所定時間以上経過していない場合は、ダウンロード済みのデータを流用してもよい。もちろん、経過時間に関わらず毎回ダウンロードしなおしてもよいし、逆に、経過時間に関わらず、最初にダウンロードしたデータを流用するようにしてもよい。
【0054】
[リプレイゴーストの個数、同期について]
次に、リプレイゴーストの個数管理と他のゲーム装置3との同期に関して説明する。
上記のように、本ゲームでは、各自のゲーム装置で個別にゲームの進行管理が行われ、共有する情報は、基本的には、各自のプレイヤキャラの位置情報のみとなっている。そして、リプレイゴーストについても、他のゲーム装置3との同期は行わず、各ゲーム装置3においてローカルで管理される。ここで、既にリプレイゴーストが出現している状況で、他のプレイヤが入室してきた場合を想定する。この場合、ステージ内の上記プレイヤアクターが4体以下になるような調整が行われる。例えば、プレイヤAが3体のリプレイゴーストとプレイしている状況で、プレイヤBが入室してきた場合を想定する。この場合、プレイヤAのゲーム装置3では、次のような処理が行われる。まず、プレイヤキャラ201の現在位置から最も遠くの位置にいるリプレイゴーストが消去される。これにより、プレイヤアクターの枠が1枠空く。次に、プレイヤBに係るリモートキャラが生成され、ステージ内に出現させる。この際、当該リモートキャラと同じキャラクタのリプレイゴーストがいる場合、このリプレイゴーストも消去する。そのため、この例の場合は、新規入室人数が1人に対して、2体のリプレイゴーストが消去されることもあり得る。この場合は、プレイヤアクターの総数が3体の状態となる。
【0055】
一方、プレイヤBのゲーム装置3におけるゲーム処理では、リプレイゴーストは存在せずに、リモートキャラとしてプレイヤAのプレイヤキャラ201がステージ内に存在しているとして、ゲーム進行が管理されることになる。
【0056】
[協力要素について]
上記のように、基本的には、各プレイヤは他のプレイヤからの影響を受けずに個別にゲームを進行できる。但し、本ゲームでは、以下の点で、協力プレイ的な要素を持たせている。具体的には、本ゲームでは、ミスしたプレイヤを助けることができる「復活補助」という機能によって、他プレイヤとの間で影響を及ぼすことが可能である。
【0057】
以下、復活補助の具体例を説明する。まず、プレイヤキャラ201について、ミスイベントが発生した場合を想定する。当該ミスイベントとは、本実施形態では、プレイヤキャラの残数が減る(残機を失う)ことになるようなゲーム内イベントである。具体的には、例えば
図7に示すように、プレイヤキャラ201が敵キャラクタ202と接触する等した場合であり、オフラインでシングルプレイをしていると仮定した場合は、現在使用しているプレイヤキャラ201によるプレイが一旦終了し、プレイヤキャラ201の残数が1体減る(以下、このことを「ロスト」と呼ぶ)ようなゲーム内イベントである。そして、ロストした後、所定の地点からリスタートする、あるいは、そのままゲームオーバーになることに繋がるようなゲーム内イベントである。ミスイベントの他の例としては、例えばHPやライフが0となって、ロストとなるような場合、落とし穴に落ちる等でステージ外に出てしまった場合、等がある。なお、ダメージを受けてもまだHPやライフが残っている等の場合は、まだロストは発生しないため、ここでいうミスイベントには該当しないものとする(単なる被ダメージとして扱う)。
【0058】
本ゲームでは、オフラインのシングルプレイの場合は、上記ミスイベントの発生は上記のようなロストに直結するが、オンラインに接続した状態でプレイしている場合は、ミスイベントが発生しても、所定の条件を満たしている場合は、すぐにはロストとはならない。本実施形態では、当該所定の条件は、プレイヤキャラ201から所定範囲内に、後述する「復活補助オブジェクト」が存在していることである。当該所定の条件を満たしていれば、所定時間の間、プレイヤキャラ201が、
図8に示すような、見た目が異なるキャラクタオブジェクトに変化する。以下、当該変化したキャラクタオブジェクトのことを「特殊キャラ」と呼ぶ。また、特殊キャラに変化しているプレイヤキャラ201の状態のことを「特殊状態」と呼び、この変化が発生していないプレイヤキャラ201の状態のことを「通常状態」と呼ぶ。なお、特殊状態の間は、リモートキャラ203は半透明ではなく不透明の態様で表示されるが、この点については後述する。
【0059】
上記特殊キャラについては、復活補助オブジェクト以外のオブジェクトとの衝突判定が行われない。そのため、特殊キャラは、敵キャラクタ等からダメージを受けることがなく、また、敵キャラクタ202や地形オブジェクトをすり抜けて移動できる。また、特殊キャラである間は、仮想空間内の重力にとらわれずに空中移動が可能となる。つまり、プレイヤは、特殊キャラについては衝突判定を気にせずに自由に移動させることが可能となる。例えば、復活補助オブジェクトを目指して一直線に特殊キャラを移動させるようなことも可能となる。但し、特殊キャラの状態では、ゴール地点に到達してもゴールしたとはみなされず、ステージクリアもできない。
【0060】
なお、上記特殊キャラに関して、他の実施形態では、復活補助オブジェクト以外のオブジェクトとも衝突判定が行われるようにしてもよい。また、移動制御に関しても、仮想空間内の重力の影響を受けた移動制御を行ってもよい。
【0061】
プレイヤキャラ201が特殊キャラに変化した後、
図9に示すように上記復活補助オブジェクト(ここでは、リモートキャラ203)に向けて特殊キャラを移動させたとする。その結果、所定時間が経過する前に、
図10に示すように、リモートキャラ203の位置と当該特殊キャラの位置とが重なったとする。つまり、復活補助オブジェクトと特殊キャラとが接触したとする。すると、
図11に示すように、プレイヤキャラ201のロストを発生させずに、プレイヤキャラ201を通常状態に戻すことができる。すなわち、ミスイベントが発生したプレイヤキャラ201をロストさせることなく「復活」させることが可能である。以下の説明では、上記所定時間のことを「復活可能時間」と呼ぶ。なお、特殊キャラと復活補助オブジェクトとを接触させることに限らず、近接あるいは隣接させることで復活させてもよい。
【0062】
一方、ミスイベントが発生した際に、上記所定範囲内に復活補助オブジェクトが存在していない場合は、特殊状態への変化は発生せずに上記ロストが確定し、その結果、リスタートまたはゲームオーバーとなる。
【0063】
また、本実施形態では、プレイヤキャラが特殊キャラに変化している間は、復活補助オブジェクトを除いて、ゲーム画面がモノクロ化して表示する。すなわち、地形オブジェクトや敵キャラクタ等の彩度を低くして表示される。
【0064】
なお、上記所定範囲は、例えば、通常状態のプレイヤキャラ201が上記復活可能時間だけ移動したとして、復活補助オブジェクトの位置に到達または近接できることを想定した距離の上限値と同じか、またはこれより短い距離となる範囲である。つまり、ミスイベントが発生した位置から見て、復活可能時間内に特殊状態から通常状態への復活が間に合う程度の範囲を想定したものである。
【0065】
そのため、例えば、プレイヤキャラ201およびリモートキャラ同士である程度固まって移動するようにすれば、シングルプレイ感覚でプレイしつつも、ミスイベント発生時のリカバリが容易になる。つまり、オフラインでのシングルプレイゲームの場合にはない、オンラインを活かした利点が得られる。また、特殊状態となるのは、シングルプレイをしている場合であれば「ミスイベント」~「ロスト」扱いとなってプレイが中断するような状況であるところ、オンラインであれば、このような中断も発生せず、プレイヤのプレイを阻害することにもならない。このような協力プレイ要素を持たせることで、特定の局面で他プレイヤと協力する余地ができる。これにより、基本的にはシングルプレイとしてゲームを進行させつつ、マッチングによってステージ部屋に複数のプレイヤが入室していれば、他のプレイヤと協力しやすくなる、という状況を生み出すことができる。
【0066】
また、上記のような所定範囲を設けることで、プレイヤキャラ201が特殊状態になった場合に、遠くにいるリモートキャラ等に助けを求めて、大きな距離を移動するという状況の発生を抑制できる。例えば、ある程度ステージを進んでいたにも関わらず、リモートキャラがいるスタート地点付近まで戻るとすると、ゲームを進めるテンポが悪くなってしまう。また、逆に、自分より先に進んでいるリモートキャラの位置まで、途中のステージの各種ギミックを飛ばして移動可能とすると、ゲームの興趣性が失われる。このような状況を防ぐために、上記のように所定範囲内に所定範囲内に復活補助オブジェクトが存在しているときのみ、特殊状態へ移行させている。
【0067】
図12に、上記のような通常状態、特殊状態、およびロストの状態遷移の関係をまとめた図を示す。
図12において、まず、通常状態のときにミスイベントが発生すると、所定範囲内に復活補助オブジェクトがいるかどうかが判定される。そして、いる場合は、特殊状態に変化する。特殊状態において、復活補助オブジェクトの位置に移動できれば、通常状態に復活することになる。一方、所定範囲内に復活補助オブジェクトがいない場合は、ロストとなる。この場合は、プレイヤキャラ201の残数が残っていれば、残数を1つ減らした上で、通常状態となって、所定のリスタート地点からプレイがリスタートする。プレイヤキャラ201の残数が残っていなければ、ゲームオーバーとなり、ステージ部屋から退室させられる。
【0068】
なお、本実施形態では、上記復活可能時間は、特殊状態に変化した回数に応じて変化し得る。具体的には、1回分のプレイ(例えばプレイ開始からプレイヤキャラ201を1体ロストするまでの間)において、特殊状態に変化する回数が多くなるほど、上記復活可能時間が段階的に短くなっていく。例えば、上記復活可能時間として、10カウントを行う場合を想定する。そして、最初に特殊状態に変化したときは、当該10カウントについて2秒間隔でカウントする(復活可能時間=20秒)。その後、復活し、再度特殊状態に変化した場合は、1.5秒間隔でカウントする(復活可能時間=15秒)。更に、3度目に特殊状態に変化した場合は1秒間隔でカウントし(復活可能時間=10秒)、4度目に特殊状態に変化した場合は0.5秒間隔でカウントする(復活可能時間=5秒)。そして、カウントする間隔がある程度短くなれば、それ以上は短くしないようにする。例えば、0.5秒間隔を下限値とする、等である。これにより、プレイヤが何度もミスイベントを発生させていると、徐々に復活しにくくなるため、ゲームプレイにある程度緊張感をもたせることができる。
【0069】
ここで、上記復活機能によって復活するときの復活位置に関して補足する。ここでは、特殊状態になったほうのゲーム装置3における処理を基準に考える。すなわち、特殊キャラを操作しているほうのゲーム画面を基準に考える。まず、特殊キャラと復活対象オブジェクトとが、共に地形外にいる場合を想定する。この場合、両者の位置が重なれば、重なった位置でプレイヤキャラ201が復活する。次に、
図13に示すような、特殊キャラが地形内に位置しており、復活対象オブジェクト、
図13ではリモートキャラ203が地形外にいる場合を想定する。上記のように、特殊キャラの間は地形オブジェクト等との衝突判定がないため、このような状況も発生し得る。この場合は、
図14に示すように、リモートキャラのいる位置に、プレイヤキャラ201が復活する。
【0070】
次に、
図15に示すように、特殊キャラが地形外、復活対象オブジェクト(リモートキャラ203)が地形内にいる場合を想定する。これは、次のような場合に起こり得る。上記のように、本ゲームは、ゲーム進行管理自体は各自のゲーム装置で行われる。そして、例えば破壊可能な地形オブジェクトがあった場合、例えば、プレイヤAのゲームプレイ上ではまだ破壊されていないが、プレイヤBのゲームプレイ上では破壊されている、という状況があり得る。例えば
図15の特殊キャラのプレイヤがプレイヤAとして、リモートキャラ203のプレイヤがプレイヤBであるとする。この場合、上記
図15の状況に対応する、上記プレイヤBが見ているゲーム画面は、
図16のようなゲーム画面となる。プレイヤBのゲーム画面では、地形オブジェクトは破壊済みであり、その跡地にプレイヤBのプレイヤキャラ201がいる状態である。また、上記のようにリモートキャラは、位置情報を共有するだけで、プレイヤAのゲーム装置3においては、地形との衝突判定は行われない。そのため、プレイヤAから見た場合は、上記
図15のような画面になり得る。そして、この状態でプレイヤBがリモートキャラを特殊キャラに向けてジャンプさせた場合を想定する。その結果、
図17に示すように、リモートキャラと特殊キャラとが接触したような状態となる。この場合は、
図18に示すように、プレイヤキャラ201は、その場で復活する。
【0071】
次に、特殊キャラのプレイヤの画面において、
図19に示すように、特殊キャラと復活対象オブジェクトとが共に地形内に位置しているような場合を想定する。そして、地形内で両者の位置が重なったとする。この場合は、プレイヤキャラ201が復活可能な地点(地形外となる地点)が検索される。例えば、
図20に示すように、不可視の検索用ポインタを、特殊キャラから螺旋状に拡がっていくように移動させながら、地形外となる位置を検索する。そして、最初に見つかった地形外の位置にプレイヤキャラ201を復活させる。その結果、
図21に示すような位置でプレイヤキャラ201が復活することになる。
【0072】
なお、上記のような復活位置に、敵キャラクタ等の通常状態のプレイヤキャラと衝突するとミスイベントが発生し得るオブジェクトがいる状況の場合は、当該敵キャラクタと衝突しないような位置に復活位置を更にずらすように制御してもよい。つまり、最終的には、地形オブジェクトや敵キャラクタ等の障害物がない位置を復活位置として決定すればよい。
【0073】
[復活補助オブジェクトについて]
次に、上記復活補助オブジェクトについて説明する。本実施形態では、上記復活補助オブジェクトは、以下の3種類のオブジェクトである。
(1)リモートキャラ
(2)リプレイゴースト
(3)パネル
また、上記パネルは更に、「リモートパネル」と「サーバパネル」の2種類に分けられる。以下、それぞれについて説明する。
【0074】
[復活補助オブジェクト:リモートキャラ]
まず、リモートキャラについては、上述したものであるため詳細な説明は割愛するが、その表示態様に関して補足する。上記のように、基本的にはリモートキャラが半透明の表示態様で表示される。但し、プレイヤキャラ201が特殊キャラに変化している間は、半透明表示ではなく、不透明の態様で表示される。また、リモートキャラが不透明の態様で表示されている間は、リモートキャラと特殊キャラとの衝突判定が行われる状態となる。いわば、特殊状態となっている間は、リモートキャラが実体化しているように見せかける。また、このときのリモートキャラは、上記のようにプレイヤキャラ201を復活させるという形で、プレイヤキャラ201に直接的に影響を及ぼし得る状態にもなっている。また、上述したように、本実施形態では、プレイヤキャラ201が特殊キャラに変化している間は、復活補助オブジェクトを除いてゲーム画面をモノクロ化して表示する。そのため、モノクロ画像の中で、不透明で色彩がついているリモートキャラが表示されることになり、リモートキャラの存在をより目立たせることができる。これにより、プレイヤに、当該リモートキャラと接触すれば何かが起こる、あるいは、復活できる、ということを想起させ、どこに向かえばよいかをプレイヤに視覚的にわかりやすく示すことができる。
【0075】
なお、上記ミスイベントが発生してプレイヤキャラ201が特殊キャラに変化する際、最も近くの復活補助オブジェクトから、
図22に示すように、光の玉をプレイヤキャラ201に飛ばすような演出を加えてもよい。そして、この光の玉を受けたプレイヤキャラ201が特殊キャラに変化するような見せ方をしてもよい。これにより、光の玉を出した復活補助オブジェクトに接触すれば助かるかもしれない、ということをプレイヤに想起させることができる。換言すれば、復活補助オブジェクトと特殊キャラへの変化との因果関係をプレイヤに認識させることができる。
【0076】
[復活補助オブジェクト:リプレイゴースト]
次に、上記リプレイゴーストも、復活補助オブジェクトとして機能する。上記のように、リプレイゴーストはリモートキャラと同様のふるまいをするためである。そのため、復活補助オブジェクトとしてのリプレイゴーストは上記リモートキャラの場合と同様の制御が行われる。従って、ミスイベントの発生時、上記リモートキャラ、またはリプレイゴーストがプレイヤキャラ201の所定範囲内にいれば、特殊キャラに変化できることになる。
【0077】
[パネルについて]
次に、上記パネルの概要を説明する。当該パネルは、プレイヤキャラ201が配置でき、また、プレイヤキャラ201が接触できるオブジェクトである。また、当該プレイヤがステージ部屋から退室した後も、そのステージ部屋に残り続ける性質のオブジェクトである。例えば、
図23に示すようなゲーム画面でプレイヤがパネル配置操作を行うと、
図24に示すようなパネルを配置できる。当該プレイヤが配置したパネルは、その後ステージ部屋に入室してきた他のプレイヤのゲーム画面にも表示されるものである。逆に言えば、プレイヤのゲーム画面には、他のプレイヤ(リモートキャラ)が配置したパネルが表示され、接触することも可能である。また、当該パネルは、上記復活補助オブジェクトとして機能する。そのため、特殊キャラのときに上記復活可能時間内にパネルに接触することで、プレイヤキャラ201を復活させることができる。但し、本実施形態では、自分が配置したパネルについては、特殊キャラは接触できない。つまり、特殊キャラが接触できるパネルは、リモートキャラが配置したパネルであるリモートパネルと、後述のサーバパネルだけとなっている。これは、パネルが上記復活補助オブジェクトとして機能するところ、自分の配置したパネルを復活補助オブジェクトとして扱うと、例えばゲームが簡単になりすぎる等で、ゲームの難易度が適切なバランスにならない可能性があるためである。そのため、本実施形態では、自身が配置したパネルについては接触できない(復活補助オブジェクトとして利用できない)ようにしている。
【0078】
なお、本実施形態では。プレイヤキャラ201がパネルを配置できる場所については、足場があるところに限られ、例えば空中にパネルを配置することはできないものとする。
【0079】
また、上記のパネルのようなデザインは一例であり、その外観についてはパネルのような外観でなくてもよい。
【0080】
[パネルの配置可能数について]
本実施形態では、1ステージに最大で4つまでパネルが配置可能であるとする。また、1プレイヤにつき1つまでしかパネルは配置できないものとする。そのため、プレイヤが一旦パネルを配置した後、別の場所で新たにパネル配置操作を行った場合は、前に配置したパネルが消去され、当該別の場所にパネルが配置されることになる。
【0081】
[他ゲーム装置とのパネルの同期について]
また、上記のように自分が配置したパネルは他のプレイヤのゲーム画面上にも表示される。つまり、本実施形態では、配置されたパネルの位置についても共有される。具体的には、パネルを配置したプレイヤのゲーム装置3から、他のゲーム装置に対して、「パネルを配置したこと」と、その配置位置(座標)を示す「配置イベント情報」が送信される。これを受信した他のゲーム装置3では、ローカルのゲーム処理において、パネルを配置する処理が行われる。但し、このような同期を行うのは、パネルを配置したときだけであり、その後のパネルの消去等に関しては、各ゲーム装置3でローカルに管理される。そのため、例えば、新たなパネルが配置された際は、そのパネルの配置について同期されるが、その後の各ゲーム装置におけるゲームプレイの展開によっては、あるゲーム装置では上記パネルが残っているが、違うゲーム装置では当該パネルが消去されている、という状況も起こり得る。
【0082】
[復活補助オブジェクト:リモートパネル]
次に、上記パネルのうち、リモートパネルについて説明する。上記のように、リモートパネルは、上記リモートキャラが配置したパネルである。プレイヤキャラ201が通常状態のときに当該リモートパネルに接触すると、パネルが揺れるリアクションが行われ、当該パネルを配置したリモートプレイヤ名が表示される。また、プレイヤキャラ201が特殊状態のときに、上記復活可能時間内に接触すると、リモートキャラの場合と同様に復活できる。このことは、換言すれば、プレイヤ自身がパネルを配置することで、これが他のプレイヤから見た場合のリモートパネルとなり、自分が同じ画面内にいなくても、間接的に他プレイヤを助けることができる、ということになる。例えば、上記ミスイベントが多発するであろうとプレイヤが考える場所にパネルを配置しておくことで、間接的に他のプレイヤを助けとなることが期待できる。
【0083】
[復活補助オブジェクト:サーバパネル]
次に、サーバパネルについて説明する。本実施形態に係るゲームでは、多数の様々なステージが用意されており、プレイヤはこの中からプレイしたいステージを選んでプレイできる。ただ、多数のステージが用意されている反面、ステージによっては、プレイするプレイヤの数が相対的に少なく、上記パネルがあまり配置されない可能性がある。そこで、本実施形態では、各プレイヤが配置したパネルに関する情報(以下、パネル情報)を上記ゲームサーバ1に保持しておく。そして、当該パネルの情報を、新規にステージ部屋が作成された際等に使用することで、ステージ上にパネルが配置されている状態を作りだす。このようなゲームサーバ1に保持されているパネル情報に基づいて配置されたパネルが、サーバパネルである。以下、サーバパネルの詳細について説明する。
【0084】
[サーバへの情報送信について]
まず、パネル情報のゲームサーバ1への送信に関して説明する。本実施形態では、プレイヤがステージ部屋から退室するときに、そのプレイヤが配置したパネルについてのパネル情報をゲームサーバ1に送信する。ステージ部屋からの退室は、例えばゴールした場合や、ゲームオーバー等でクリアすることなくリタイアする場合等である。当該パネル情報には、パネルを配置したステージと配置位置とを示す情報が少なくとも含まれている。但し、プレイヤがステージ部屋から退室するときに、当該プレイヤが配置したパネルが既に消去されている場合は、パネル情報は送信されない。また、そのステージにおいて、既にプレイヤ自身が配置したパネル情報がゲームサーバ1に保持されていた場合は、既存のパネル情報が削除され、新たに登録される。これは、例えば、あまりプレイされていないステージにおいて、あるプレイヤが1人で「ステージに入室し、パネルを配置し、退室する」ことを繰り返すことで、そのステージに関するパネルが全て同一プレイヤに係るパネルで埋められるという状況の発生を抑制するためである。
【0085】
[サーバパネルの受信および配置について]
次に、上記のようにしてゲームサーバ1に送信されたパネル情報の利用に関して説明する。まず、プレイヤがステージ部屋に入室した際に、ステージに配置されているパネル数が0個の状態だった場合に、ゲームサーバ1からパネル情報を取得する。入室した際にパネル数が0個という状況は、例えば次のような状況である。まず、ステージ部屋が新規作成された場合である。次に、既存のステージ部屋に入室したときに、その時点でステージ内にパネルが1つも配置されていなかった場合である。換言すれば、プレイヤが入室した時点でステージ内にパネルが1つも無いという状況の場合にのみ、サーバパネルが配置され得ることになる。
【0086】
また、ゲームサーバ1からパネル情報を取得する点について、本実施形態では、そのステージに紐付けられているパネル情報の、直近30件分をゲームサーバ1から取得する。なお、上記のように、同一ステージで同一プレイヤが複数回パネル情報を送信した場合は、最新のパネル情報のみがゲームサーバ1に保持される。そのため、当該取得したパネル情報群に同一プレイヤに係るパネル情報が複数含まれているということはない。そして、この中から、最大で4つまでパネル情報が選出される。なお、本実施形態では、ステージ部屋の定員が最大4人の例であるため、この人数に合わせて最大4つとしているが、選出数は4つ以上でも4つ以下でもよいことはいうまでもない。また、選出手法は、例えばランダムで選出すればよい。
【0087】
次に、上記選出したパネル情報に基づいて、サーバパネルが生成される。そして、各パネル情報で示される位置にサーバパネルがそれぞれ配置される。ここで、ステージに入室したときに過去にプレイヤ自身が配置したパネルがサーバパネルとして存在する場合も考えられる。この場合は、当該過去にプレイヤ自身が配置したサーバパネルはプレイヤのパネルであると判断し、その後、プレイヤが新たにパネルを配置した場合は、当該サーバパネルを消滅させる。
【0088】
[サーバパネルの有効化について]
次に、サーバパネルの有効化について説明する。上記のようにしてサーバパネルは配置され得るが、サーバパネルは初期状態として無効状態になっている。つまり、配置された時点では、上述した復活補助オブジェクトとして機能していない状態である。
図25に、無効状態のサーバパネルの例を示す。
図25に示すように、無効状態のサーバパネルは、黒塗りの表示態様で表示される。なお、無効状態であることを示す表示態様は、黒塗りに限らず、どのような表示態様でもよい。そして、当該無効状態のサーバパネルにプレイヤキャラ201が接触することで、
図26に示すように、当該サーバパネルを有効化できる。
図26では、黒塗りの表示態様が解除され、通常と同様の表示態様でサーバパネルが表示されていることを示している。このように、有効化されたサーバパネルだけが、上述した復活補助オブジェクトとして機能する。そのため、無効状態のサーバパネルの近くでミスイベントが発生した場合は、上記のような特殊キャラに変化すること無く、ロストとなる。
【0089】
また、一旦有効化したサーバパネルについては、プレイヤキャラ201がそのサーバパネルから離れたとしても、その後も有効であり続ける。また、リスタートした場合も、一旦有効化したサーバパネルが再度無効化されることはなく、有効であり続ける。
【0090】
なお、上記のような最初は無効状態で、プレイヤキャラ201の接触で有効化させるのは、以下のような理由による。まず、上記のように特殊キャラになると、敵キャラクタや地形との衝突判定が行われない状態となる。そのため、もしサーバパネルが最初から有効だとすると、サーバパネルの配置位置の関係によっては、プレイヤがわざと特殊キャラに変化し、通常状態としてはまだ到達していない先の場所(サーバパネルがある場所)まで特殊キャラのまま移動することが起こりえる。すなわち、本来はまだ進めていない位置までショートカットできてしまうということが考えられる。このような状況の発生を抑制するために、初期状態ではサーバパネルは無効状態としている。なお、これは、他のプレイヤがいないステージ部屋についての話である。例えばリモートキャラがリアルタイムで配置したリモートパネルについては、オンラインプレイのメリットや協力プレイ的な要素をプレイヤに感じさせるために、上記のようなショートカットは許容する。そのため、上記リモートパネルについては、配置した時点から有効な状態である。
【0091】
またその他、サーバパネル自体を、チェックポイントのように通過するということ自体を一種の遊び方として提供するという観点で、初期状態を無効状態としている。
【0092】
次に、ゲーム装置3、および、ゲームサーバ1で用いられる各種データと、それぞれで行われる処理の詳細を説明する。
【0093】
[ゲームサーバ1で用いられるデータについて]
まず、ゲームサーバ1で用いられるデータに関して説明する。
図27は、ゲームサーバ1の記憶部12に記憶される各種データの一例を示すメモリマップである。ゲームサーバ1の記憶部12には、ゲームサーバプログラム301、プレイヤデータベース302、ステージ部屋管理データ304、リプレイ管理データ305、パネル管理データ306が少なくとも記憶されている。
【0094】
ゲームサーバプログラム301は、上述したようなゲーム処理を実現するためにゲームサーバ1を機能させるプログラムである。
【0095】
プレイヤデータベース302は、本実施形態に係るゲームをプレイする各プレイヤに関するデータベースである。データベースには、複数のプレイヤデータ303が含まれている。各プレイヤデータ303には、例えば、各プレイヤを識別するためのプレイヤID307、各プレイヤのプレイヤ名308等が含まれる。
【0096】
ステージ部屋管理データ304は、上記ステージ部屋を管理するためのデータベースである。
図28に、ステージ部屋管理データ304のデータ構成の一例を示す。
図28において、ステージ部屋管理データ304には、各ステージを特定するステージ番号311毎に、ステージ部屋情報312が含まれている。当該ステージ部屋情報312は、1つのステージに対して複数含まれ得る。当該ステージ部屋情報312のひとつひとつが上記ステージ部屋に対応する情報である。各ステージ部屋情報312には、部屋ID313、入室プレイヤ情報314等が含まれる。部屋ID313は、そのステージ部屋を一意に特定するためのIDである。入室プレイヤ情報314は、そのステージ部屋に現在入室しているプレイヤに関する情報である。例えば、入室プレイヤ情報314には、上記プレイヤID307が格納される。
【0097】
図27に戻り、リプレイ管理データ305は、上述したような、ゲーム装置3から送信されてくる上記リプレイデータを保存したものである。
図29に、リプレイ管理データのデータ構成の一例を示す。リプレイ管理データ305には、ステージ番号321毎に、1つ以上のリプレイデータ322が含まれている。各リプレイデータ322には、登録日時323、登録プレイヤ情報324、リプレイ内容325が少なくとも含まれる。登録日時323は、そのリプレイデータがゲームサーバ1に登録された日時を示す。登録プレイヤ情報324は、そのリプレイデータを生成したプレイヤに関する情報である。登録プレイヤ情報324には、例えば、上記プレイヤID307等が含まれている。リプレイ内容325は、リプレイの内容を示すためのデータである。例えば、リプレイ内容325は、リプレイに係るキャラクタの位置情報や状態を示す情報が時系列に並べられて格納されたデータである。また、リプレイ内容325は、例えばキーデータ等であってもよい。つまり、リプレイ内容325は、プレイヤの操作履歴が把握できるようなデータであれば、どのようなデータ内容であってもよい。
【0098】
図27に戻り、パネル管理データ306は、上記のようにゲーム装置3から送信されるパネル情報を保存したものである。
図30に、パネル管理データ306のデータ構成の一例を示す。パネル管理データ306には、ステージ番号331毎に、1つ以上のパネル情報332が含まれている。各パネル情報332には、登録日時333、配置プレイヤ情報334、配置位置335が少なくとも含まれる。登録日時333は、そのパネル情報332がゲームサーバ1に登録された日時を示す。配置プレイヤ情報334は、パネル情報332に係るパネルを配置したプレイヤに関する情報である。配置位置335は、パネル情報332に係るパネルの配置位置を示す情報である。
【0099】
また、図示は省略するが、プレイヤのマッチング処理等を行うために必要な各種データも、記憶部12に適宜記憶され得る。
【0100】
[ゲーム装置3で用いられるデータについて]
次に、ゲーム装置3で用いられるデータに関して説明する。
図31は、ゲーム装置3の記憶部32に記憶される各種データの一例を示すメモリマップである。ゲーム装置3の記憶部32には、ゲームプログラム351、ステージデータ352、オブジェクトデータ353、プレイヤキャラデータ354、リモートキャラデータ361、リプレイゴーストデータ362、プレイヤアクター管理データ363、パネルデータ364、操作データ365、選出済みフラグ366、配置完了フラグ367が少なくとも記憶されている。
【0101】
ゲームプログラム351は、ゲーム装置3において、本実施形態におけるゲーム処理を実行するためのプログラムである。
【0102】
ステージデータ352は、プレイするステージを構築するためのデータが含まれている。具体的には、ステージデータ352には、ステージ毎に、スタート地点、ゴール地点の位置情報、中間地点オブジェクト等のステージ内に配置される各種オブジェクトを示すデータが含まれる。
【0103】
オブジェクトデータ353は、ステージ内に配置される各種オブジェクトと、リモートキャラやリプレイゴーストとして表示されるキャラクタオブジェクトの外観を示すマスタデータである。具体的には、オブジェクトデータ353には、各オブジェクトのモデルデータやテクスチャデータ等が含まれている。
【0104】
プレイヤキャラデータ354は、プレイヤの操作対象となる上記プレイヤキャラ201に関するデータである。プレイヤキャラデータ354には、プレイヤ位置情報355、特殊状態フラグ356、特殊状態化回数357、中間通過フラグ358、リプレイ記録用データ359、ロスト発生フラグ360等のデータが含まれる。プレイヤ位置情報355は、プレイするステージにおけるプレイヤキャラ201の位置を示すデータである。特殊状態化回数357は、プレイヤキャラ201が上記特殊キャラに変化した回数を記録するためのカウンタである。特殊状態フラグ356は、オンの場合は特殊状態、オフの場合は通常状態であることを示すフラグである。特殊状態化回数357は、プレイヤキャラ201が特殊キャラに変化する度に1回分カウントアップされる。また、上記ロストが発生した際に、リセットされる。中間通過フラグ358は、プレイヤキャラ201が上記中間地点オブジェクトに接触したか否かを示すためのフラグである。中間地点オブジェクトに接触するとオンに設定される。リプレイ記録用データ359は、プレイヤキャラ201のリプレイ用のデータを記録するためのデータである。ロスト発生フラグ360は、上述したロストとなる状況が発生したことを示すためのフラグである。オンであれば、ロストとなる状況が発生したことを示す。
【0105】
次に、リモートキャラデータ361は、同じステージ部屋に入室しているリモートプレイヤに係るリモートキャラのデータである。
図32に、リモートキャラデータ361のデータ構成の一例を示す。本例では、ステージ部屋は最大4人まで入室可能という例であるため、リモートキャラデータ361には、最大で3体分のリモートキャラのデータが格納される。また、各データは、リモートプレイヤの入室に伴い生成され、退室に伴って適宜削除される。各データには、識別名371、リモートプレイヤ情報372、使用キャラクタ情報373、リモート位置情報374が少なくとも含まれる。識別名371は、各リモートキャラを一意に識別するための識別子である。リモートプレイヤ情報372は、各リモートキャラを操作しているリモートプレイヤを特定するための情報である。使用キャラクタ情報373は、リモートキャラとして画面に表示されるキャラクタを指定する情報である。つまり、各リモートプレイヤがプレイヤキャラとして用いているキャラクタを示す情報である。リモート位置情報374は、そのリモートキャラのステージ内での位置を示す情報である。
【0106】
図31に戻り、次に、リプレイゴーストデータ362は、上記リプレイゴーストについてのデータである。具体的には、リプレイゴーストデータ362には、リプレイゴーストとして用いられる上記リプレイデータ322が最大で3件分、格納される。
【0107】
プレイヤアクター管理データ363は、プレイヤアクターの枠と、リモートキャラ、リプレイゴーストの割り当て関係を管理するためのデータである。
図33に、プレイヤアクター管理データ363のデータ構成の一例を示す。アクター枠番号381は、プレイヤアクターの枠番号である。本例では、プレイヤアクターの枠は4つ用意されている場合を例に説明する。割り当て対象382は、その枠に割り当てたプレイヤアクターを特定するための情報である。まず、1枠分は、プレイヤキャラ201に割り当てられる。そのため、残り3枠分について、リモートキャラまたはリプレイゴーストのいずれかを特定するための情報が格納される。また、リモートキャラやリプレイゴーストが割り当てられていない状態のときは、Null値が設定される。
【0108】
図31に戻り、次に、パネルデータ364は、上述したパネルを管理するためのデータである。
図34に、パネルデータ364のデータ構成の一例を示す。パネルデータ364には、自パネルデータ391、リモートパネルデータ394、サーバパネルデータ400とが含まれている。また、本例では、リモートパネルデータ394およびサーバパネルデータ400はそれぞれ3件分用意されておる。自パネルデータ391は、プレイヤキャラ201が配置したパネル(以下、自パネル)に関する情報である。自パネルデータ391には、自パネル配置位置392、自パネル配置日時393が含まれる。自パネル配置位置392は、自パネルの配置位置を示し、自パネル配置日時393は、自パネルが配置された日時を示す。また、複数回のパネル配置が行われた場合は、最新の配置内容が自パネルデータ391に保存される。
【0109】
リモートパネルデータ394は、リモートキャラが配置したパネルに関する情報である。リモートパネルデータ394には、リモートパネル配置位置396、配置プレイヤ情報397、リモートパネル配置日時398が含まれる。リモートパネル配置位置396は、リモートパネルの配置位置を示し、リモートパネル配置日時398は、リモートパネルが配置された日時を示す。配置プレイヤ情報397は、そのリモートパネルを配置した他のプレイヤに関する情報である。
【0110】
サーバパネルデータ400は、上記サーバパネルに関するデータである。サーバパネルデータ400には、サーバパネル配置位置402、有効化フラグ403が含まれる。サーバパネル配置位置402は、そのサーバパネルが配置されている位置を示す。有効化フラグ403は、そのサーバパネルが有効化されているか否かを示すフラグである。有効化フラグ403の初期値はオフであり、有効化されるとオンに設定される。
【0111】
なお、
図34で示されるように、パネルデータ364には、自パネル、リモートパネル、サーバパネルを合計して7つ分のパネルデータが記憶可能ではある。但し、上記のように、パネルは最大で4つまでしかステージ内に配置できないため、実際に用いられるデータとしては、上記7つ分のパネルのデータのうち最大で4つまでのデータとなる。つまり、パネル配置の発生に伴って、パネル数が最大で4つとなるように、各データの中身の削除と生成が適宜行われる。
【0112】
図31に戻り、操作データ365は、プレイヤが操作するコントローラ4から得られるデータである。すなわち、プレイヤが行った操作内容を示すデータである。
【0113】
選出済みフラグ366および配置完了フラグ367は、リプレイゴーストを配置する処理において用いられるフラグである。選出済みフラグ366は、ダウンロードしたリプレイデータからのリプレイゴーストの選出が済んだか否かを示すためのフラグである。配置完了フラグ367は、選出したリプレイゴーストをステージ内に全ては位置したか否かを示すためのフラグである。
【0114】
その他、図示は省略するが他のゲーム装置に各種データを送信するための送信用データや、他のゲーム装置3から受信した受信データ、サーバからダウンロードしたリプレイデータ等、ゲーム処理に必要となる各種データも必要に応じて生成され、記憶部32に記憶され得る。
【0115】
次に、本実施形態におけるゲーム処理の詳細を説明する。まず、ゲーム装置3で行われる処理の詳細を説明し、その後、ゲームサーバ1における処理について説明する。
【0116】
[ゲーム装置3のプロセッサ31が実行する処理の詳細]
図35~
図36は、ゲーム装置3のプロセッサ31が実行するゲーム装置側処理の詳細を示すフローチャートである。本実施形態では、1以上のプロセッサが1以上のメモリに記憶された上記プログラムを読み込んで実行することにより、以下に示すフローチャートが実現される。なお、以下に示すフローチャートは、処理過程の単なる一例にすぎない。そのため、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよい。また、変数の値や、判定ステップで利用される閾値も、単なる一例であり、必要に応じて他の値を採用してもよい。
【0117】
ゲーム装置3において、プレイヤによって所定のステージをプレイすることが指示されると、まず、ステップS1で、プロセッサ31は、ステージ開始処理を実行する。
図37は、当該ステージ準備処理の詳細を示すフローチャートである。
図37において、まず、ステップS21で、プロセッサ31は、ステージ部屋への入室処理を行う。具体的には、まず、プロセッサ31は、ゲームサーバ1にマッチング処理をリクエストする。そして、プロセッサ31は、そのマッチング結果に基づき決定されたステージ部屋への入室処理を実行する。この際、既存の部屋に入室する場合は、入室済みのプレイヤに係るゲーム装置3に、自分がプレイヤキャラ201として用いるキャラクタの情報も送信する。
【0118】
次に、ステップS22で、プロセッサ31は、今回プレイするステージ(仮想空間)を、ステージデータ352に基づいて生成する。更に、既存のステージ部屋に入室した場合は、リモートキャラおよびリモートパネルの情報を他のゲーム装置3から受信する。そして、各種キャラクタをステージ内に配置する。
【0119】
次に、ステップS23で、プロセッサ31は、ステージ内のパネル数が0か否かを判定する。当該判定の結果、0ではない場合は(ステップS23でNO)、後述するステップS27に処理が進められる。一方、0の場合は(ステップS23でYES)、ステップS24で、プロセッサ31は、直近30件分のパネル情報をゲームサーバ1から取得する。次に、ステップS25で、プロセッサ31は、取得したパネル情報からランダムで4つのパネル情報を選出する。そして、プロセッサ31は、選出したパネル情報をサーバパネルデータ400として記憶する。この際、過去にプレイヤ自身が配置したパネルの情報が含まれていた場合は、これについては自パネルデータ391として記憶する。そして、プロセッサ31は、パネルデータ364に基づき、サーバパネルを配置する。
【0120】
次に、ステップS26で、プロセッサ31は、ステージ部屋に他のプレイヤがいる場合は、配置したサーバパネル(場合によっては自パネルデータも)の情報を他のゲーム装置に送信する。つまり、サーバパネルの情報を同じステージ部屋のリモートプレイヤと共有する。なお、例えばほぼ同じタイミングで2人のプレイヤが入室し、共にサーバパネルに関する処理を行った場合は、いずれか1人のサーバパネルの情報を優先する。
【0121】
次に、ステップS27で、プロセッサ31は、ゲーム画面を生成し、表示部5に表示する。これにより、ステージプレイが開始されることになる。
【0122】
図35に戻り、次に、ステップS2で、プロセッサ31は、入退室チェック処理を実行する。これは、プレイヤが入室した後に発生した他のプレイヤの入退室をチェックするための処理である。
図38~
図39は、入退室チェック処理の詳細を示すフローチャートである。まず、ステップS31で、プロセッサ31は、対応するリモートキャラが存在していない新たなプレイヤの入室が発生したか否かを判定する。当該判定の結果、新たな入室者がいない場合は(ステップS31でNO)、プロセッサ31は、後述のステップS39に処理を進める。一方、新たなプレイヤの入室が発生した場合は(ステップS31でYES)、ステップS32で、プロセッサ31は、当該入室してきたプレイヤのゲーム装置3に対して、その時点で設置済みのサーバパネルとリモートパネルに関する情報を、必要に応じて送信する。なお、当該情報の送信処理は、先に入室済みのプレイヤのいずれかのゲーム装置3で行われればよい。
【0123】
次に、ステップS33で、プロセッサ31は、部屋内のプレイヤ人数が4人になったか否かを判定する。当該判定の結果、4人になっていない場合は(ステップS33でNO)、後述のステップS36に処理が進められる。一方、4人になった場合は(ステップS33でYES)、ステップS34で、プロセッサ31は、プレイヤアクター管理データ363を参照し、プレイヤアクターの枠に空きがあるか否かを判定する。当該判定の結果、空きが無い場合は(ステップS34でNO)、リプレイゴーストが存在している状態と考えられる。そのため、ステップS35で、プロセッサ31は、プレイヤキャラ201から最も遠くの位置にいるリプレイゴーストを削除する。すなわち、当該リプレイゴーストに係るデータを、リプレイゴーストデータ362およびプレイヤアクター管理データ363から削除する。その後、ステップS36に処理が進められる。一方、上記判定の結果、プレイヤアクターの枠に空きがある場合は(ステップS34でYES)、上記ステップS35の処理はスキップされる。
【0124】
次に、ステップS36で、プロセッサ31は、入室してきたプレイヤのゲーム装置から受信した情報に基づき、入室してきたプレイヤに対応するリモートキャラのデータをリモートキャラデータ361に追加する。そして、リモートキャラデータ361に基づき、入室してきたプレイヤに対応するリモートキャラを配置する。
【0125】
次に、ステップS37で、プロセッサ31は、今回配置したリモートキャラと同じプレイヤのリプレイゴーストが存在するか否かを判定する。当該判定の結果、存在する場合は(ステップS37でYES)、ステップS38で、プロセッサ31は、同プレイヤのリプレイゴーストを削除する。すなわち、プロセッサ31は、リプレイゴーストデータ362から当該リプレイゴーストのデータを削除する。一方、同プレイヤのリプレイゴーストが存在していなければ(ステップS37でNO)、上記ステップS38の処理はスキップされる。
【0126】
次に、
図39のステップS39で、プロセッサ31は、いずれかのリモートプレイヤの退室が発生したか否かを判定する。また、これに併せて、プロセッサ31は、そのときに存在しているリプレイゴーストの再生が終了したか否かも判定する。当該判定の結果、リモートプレイヤの退室、または、リプレイゴーストの再生終了が発生した場合は(ステップS39でYES)、ステップS40で、プロセッサ31は、退室したプレイヤに係るリモートキャラを削除する。あるいは、再生が終了したリプレイゴーストおよび、対応するリプレイデータを削除する。
【0127】
一方、リモートプレイヤの退室、リプレイゴーストの再生終了のいずれも発生していない場合は(ステップS39でNO)、上記ステップS40の処理はスキップされる。その後、プロセッサ31は、入退室チェック処理を終了する。
【0128】
図35に戻り、次に、ステップS3で、プロセッサ31は、リモートパネルチェック処理を実行する。これは、リモートプレイヤがパネルを設置した場合に、これを自分のゲーム処理に反映させるための処理である。
図40は、リモートパネルチェック処理の詳細を示すフローチャートである。まず、ステップS51で、プロセッサ31は、他のゲーム装置3から、上記配置イベント情報を受信したか否かを判定する。当該判定の結果、受信した場合は(ステップS51でYES)、ステップS52で、プロセッサ31は、当該配置イベント情報に基づき、パネルデータ364の内容を更新する。例えば、同じプレイヤがパネルを再設置した場合は、既に設置済みのパネルを削除して新たなパネルのデータに置き換える処理が行われる。また、新たにパネルが設置された場合、そのパネルに係るデータが新たに作成される。そして、プロセッサ31は、パネルデータ364に基づいてリモートパネルを適宜設置する。一方、上記判定の結果、配置イベント情報を受信していなければ、上記ステップS52の処理はスキップされる。その後、リモートパネルチェック処理は終了する。
【0129】
図35に戻り、次に、ステップS4で、プロセッサ31は、特殊状態フラグ356を参照し、プレイヤキャラ201が特殊状態か否かを判定する。当該判定の結果、特殊状態ではない場合は(ステップS4でNO)、ステップS5で、プロセッサ31は、通常状態処理を実行する。一方、特殊状態の場合は(ステップS4でYES)、ステップS6で、プロセッサ31は、特殊状態処理を実行する。以下、各処理について説明する。
【0130】
[通常状態の時の処理]
図41~
図42は、通常状態処理の詳細を示すフローチャートである。
図41において、まず、ステップS61で、プロセッサ31は、操作データ365を取得する。次に、ステップS62で、プロセッサ31は、パネル配置操作が行われたか否かを判定する。当該判定の結果、パネル配置操作が行われた場合は(ステップS62でYES)、ステップS64で、プロセッサ31は、自パネル配置処理を実行する。
図43は、当該自パネル配置処理の詳細を示すフローチャートである。まず、ステップS81で、プロセッサ31は、パネルデータ364を参照し、既存の自パネルが存在するか否かを判定する。存在している場合は(ステップS81でYES)、ステップS82で、プロセッサ31は、既存の自パネルのデータをパネルデータ364から消去する。一方、存在していなければ(ステップS81でNO)、上記ステップS82の処理はスキップされる。
【0131】
次に、ステップS83で、プロセッサ31は、パネル配置操作が行われた位置に自パネルを配置する。すなわち、プロセッサ31は、当該自パネルにかかるデータをパネルデータ364に生成し、当該データに基づいて自パネルをステージ内に配置する。
【0132】
次に、ステップS84で、プロセッサ31は、自パネルに係る配置イベント情報を生成して、他のゲーム装置3に送信する。以上で、自パネル配置処理は終了する。
【0133】
図41に戻り、上記ステップS62の判定の結果、パネル配置操作が行われていない場合は(ステップS62でNO)、ステップS63で、プロセッサ31は、操作データ365で示される操作内容に基づいて、プレイヤキャラ201の動作を制御する。更に、プロセッサ31は、プレイヤキャラ201の位置情報、および、通常状態である特殊状態であるかを示す状態情報を他のゲーム装置3に送信する。
【0134】
次に、ステップS65で、プロセッサ31は、他のゲーム装置3からリモートキャラに関する情報を受信し、リモートキャラを移動させる。当該リモートキャラに関する情報は、リモートキャラの位置情報および状態を示す情報である。なお、位置情報の代わりに、例えば、リモートプレイヤが行った操作情報を受信するようにしてもよい。この場合は、当該受信した操作情報に基づいてリモートキャラが移動制御されればよい。また、リプレイゴーストが存在している場合は、プロセッサ31は、リプレイデータに基づく再生を継続する。これにより、当該リプレイゴーストが移動制御される。
【0135】
次に、ステップS66で、プロセッサ31は、敵キャラクタ等の動作を制御する。更に、プロセッサ31は、プレイヤキャラ201と敵キャラクタやリモートパネル等との衝突判定を行い、その結果に応じたゲーム処理を適宜実行する。例えば、リモートパネルに接触した場合は、そのリモートパネルを配置したリモートプレイヤ名を一時的に表示する処理が行われる。また、例えば、敵キャラクタに接触した場合、敵キャラクタにダメージを与える処理、あるいは、プレイヤキャラ201がダメージを受ける処理が行われる、また、このゲーム処理の結果、上述したミスイベントが発生し得る。
【0136】
次に、ステップS67で、プロセッサ31は、プレイヤキャラ201が中間地点オブジェクトに接触したか否かを判定する。当該判定の結果、接触した場合は(ステップS67でYES)、ステップS68で、プロセッサ31は、中間通過フラグ358をオンに設定する。これに伴い、これ以降のリスタート地点を中間地点オブジェクトの位置とする設定も行われる。次に、ステップS69で、プロセッサ31は、リプレイ記録用データ359を用いて、プレイヤキャラ201に係るリプレイデータの記録を開始する。この際、中間地点からリスタートした状況である場合は、上述のように一定確率でリプレイデータの記録を開始しないように制御してもよい。
【0137】
一方、上記ステップS67の判定の結果、中間地点オブジェクトに接触していない場合は(ステップS67でNO)、上記ステップS68およびS69の処理はスキップされる。
【0138】
次に、
図42のステップS70で、プロセッサ31は、プレイヤキャラ201が無効状態のサーバパネルに接触したか否かを判定する。当該判定の結果、接触した場合は(ステップS70でYES)、ステップS71で、プロセッサ31は、接触したサーバパネルの有効化フラグ403にオンを設定する。一方、接触していない場合は(ステップS70でNO)、上記ステップS71の処理はスキップされる。
【0139】
次に、ステップS72で、プロセッサ31は、上記ミスイベントが発生したか否かを判定する。当該判定の結果、発生した場合は(ステップS72でYES)、ステップS73で、プロセッサ31は、リプレイデータの記録を停止する。次に、ステップS74で、プロセッサ31は、プレイヤキャラ201が特殊状態になるための条件が満たされているか否かを判定する。すなわち、プロセッサ31は、プレイヤキャラ201から所定範囲内にいずれかの復活補助オブジェクトが存在するか否かを判定する。当該判定の結果、特殊状態になるための条件が満たされている場合は(ステップS74でYES)、ステップS75で、プロセッサ31は、プレイヤキャラ201を特殊状態とするための設定、および、これに伴う各種設定を行う。具体的には、プロセッサ31は、特殊状態フラグ356にオンを設定する。更に、プロセッサ31は、プレイヤキャラ201を特殊キャラに変更する。更に、プロセッサ31は、特殊状態化回数357に1を加算する。更に、プロセッサ31は、復活補助オブジェクトを除いてゲーム画面がモノクロで表示されるようにゲーム画面の表示設定を行う。その後、通常状態処理は終了する。
【0140】
一方、特殊状態になるための条件が満たされていない場合は(ステップS74でNO)、ステップS76で、プロセッサ31は、ロスト発生フラグ360にオンを設定する。その後、通常状態処理は終了する。
【0141】
一方、上記ステップS72の判定の結果、ミスイベントが発生していない場合は(ステップS70でNO)、通常状態処理は終了する。
【0142】
[特殊状態のときの処理]
次に、上記特殊状態処理について説明する。
図44は、当該特殊状態処理の詳細を示すフローチャートである。まず、ステップS91で、プロセッサ31は、操作データ365を取得する。次に、ステップS92で、プロセッサ31は、操作データに基づき、特殊キャラを移動させる。上記のように、特殊キャラの間は、地形や敵キャラクタとの衝突判定は行われない。
【0143】
次に、ステップS93で、プロセッサ31は、リモートキャラを制御する。プレイヤキャラ201が特殊状態の間は、上記のように、リモートキャラは半透明ではなく、不透明で表示されるよう制御される。また、リモートキャラと特殊キャラとの衝突判定が行われるよう制御される。また、リプレイゴーストが存在している場合は、リプレイゴーストについても上記リモートキャラと同様の制御を行う。
【0144】
次に、ステップS94で、プロセッサ31は、敵キャラクタ等の動作制御を行い、これに伴う各種のゲーム処理を行う。
【0145】
次に、ステップS95で、プロセッサ31は、上記特殊状態から復活可能な時間をカウントするための特殊カウンタのカウントを進める。この際、プロセッサ31は、特殊状態化回数357に基づいて、1カウントに係る時間間隔を適宜変化させた上で、カウントを進める。
【0146】
次に、ステップS96で、プロセッサ31は、特殊カウンタのカウントが終了したか否かを判定する。当該判定の結果、まだカウントが終了していない場合は(ステップS96でNO)、ステップS97で、プロセッサ31は、復活条件が満たされたか否かを判定する。すなわち、上記復活可能時間内に特殊キャラが復活対象オブジェクトとのいずれかと接触できたか否かを判定する。当該判定の結果、満たされた場合は(ステップS97でYES)、ステップS98で、プロセッサ31は、特殊状態フラグ356にオフを設定する。更に、プロセッサ31は、特殊キャラを通常状態のプレイヤキャラ201に変更する。更に、プロセッサ31は、ゲーム画面のモノクロ表示設定を解除し、通常の表示となるよう設定する。次に、ステップS99で、所定の復活位置にプレイヤキャラ201を配置する。復活位置の決め方については、例えば、接触した復活対象オブジェクトから特殊キャラに対し打てレイを飛ばし、地形に当たるか否かを判定する。地形に当たった場合は、復活補助オブジェクトの位置を復活位置とする。当たらなかった場合は、特殊キャラの位置を復活位置とする。これにより、上記
図13~
図18で示したような位置が復活位置として決定される。但し、上記
図19で示したように、双方とも地形内にいる場合は、上記検索用ポインタを螺旋状に拡げるようにして、復活位置が検索される。なお、上記決定または検索された復活位置に敵キャラクタ等が存在している状況の場合は、当該敵キャラクタと接触しないような位置に当該復活位置がずらされてもよい。つまり、通常状態に戻した直後にミスイベントが発生しないような位置が復活位置として決定されて、プレイヤキャラ201が配置されてもよい。
【0147】
また、復活位置の決定に際しては、通常状態に戻したプレイヤキャラのサイズも考慮して、復活位置が決定される。つまり、通常状態に戻したプレイヤキャラが障害物等にめり込まないようなスペースが十分に確保されている位置を復活位置として決定する。例えば、小さいサイズのプレイヤキャラであれば配置可能であるが、大きいサイズのプレイヤキャラの場合はスペースが足りていないような、障害物の隙間等の位置を想定する。この場合は、このような隙間位置が見つかったとしても、プレイヤキャラのサイズを考慮して、スペースが足りないと判断された場合は、他の位置の検索が継続される。一方、スペースが足りていると判断された場合は、この隙間位置が復活位置として決定されることになる。
【0148】
一方、上記ステップS96の判定の結果、特殊カウンタのカウントが終了した場合は(ステップS96でYES)、ステップS100で、プロセッサ31は、ロスト発生フラグ360にオンを設定する。その後、特殊状態処理は終了する。
【0149】
図35に戻り、次に、ステップS7で、プロセッサ31は、ロスト発生フラグ360がオンか否かを判定する。オンではない場合(ステップS7でNO)、ステップS8で、プロセッサ31は、中間通過フラグ358に基づき、プレイヤキャラ201が中間地点オブジェクトに接触済みか否かを判定する。当該判定の結果、まだ接触していない場合は(ステップS8でNO)、後述のステップS10に処理が進められる。一方、接触済みの場合は(ステップS8でYES)、ステップS9で、プロセッサ31は、リプレイゴースト処理を実行する。
【0150】
図45は、上記リプレイゴースト処理の詳細を示すフローチャートである。まず、ステップS111で、プロセッサ31は、配置完了フラグ367がオンか否かを判定する。オンの場合は(ステップS111でYES)、プロセッサ31は、リプレイゴースト処理を終了する。一方、オフの場合は(ステップS111でNO)、ステップS112で、プロセッサ31は、選出済みフラグ366がオンか否かを判定する。オンの場合は(ステップS112でYES)、後述するステップS117に処理が進められる。オフの場合は(ステップS112でNO)、ステップS113で、プロセッサ31は、リプレイデータのゲームサーバ1からのダウンロードが完了したか否かを判定する。当該判定の結果、まだ完了していない場合は(ステップS113でNO)、ステップS115で、プロセッサ31は、ゲームサーバ1からリプレイデータのダウンロードを開始する。または、既に開始済みの場合は、プロセッサ31は、ダウンロードを継続する。その後、リプレイゴースト処理は終了する。
【0151】
一方、リプレイデータのダウンロードが完了した場合は(ステップS113でYES)、次に、ステップS114で、プロセッサ31は、この時点でリモートプレイヤが存在するか否かを判定する。当該判定の結果、リモートプレイヤが存在する場合は(ステップS114でYES)、ステップS119で、プロセッサ31は、配置完了フラグ367にオンを設定する。この場合、例えば、ダウンロード中にリモートプレイヤが入室してきた場合に、リプレイデータのダウンロードが完了しても、実際にリプレイゴーストの配置は行われないことになる。その後、リプレイゴースト処理は終了する。
【0152】
一方、リモートプレイヤが存在しない場合は(ステップS114でNO)、ステップS116で、プロセッサ31は、ダウンロードしたリプレイデータの中から、リプレイゴーストとして用いるリプレイデータをランダムで最大3件まで選出する。この際、自分のリプレイデータについては選出対象から除外する。そして、プロセッサ31は、選出済みフラグ366にオンを設定する。
【0153】
次に、ステップS117で、プロセッサ31は、選出したリプレイゴーストを全てステージ内に配置したか否かを判定する。まだ全て配置していない場合は(ステップS117でNO)、ステップS118で、プロセッサ31は、リプレイゴーストを1体生成して、ステージ内に配置する。この際、上記のように、配置するタイミングを少しずらしながら、1体ずつリプレイゴーストを配置するよう制御される。
【0154】
一方、選出したリプレイゴーストを全てステージ内に配置したら(ステップS117でYES)、上記ステップS119に処理が進められ、配置完了フラグ367にオンが設定される。その後、リプレイゴースト処理は終了する。
【0155】
次に、
図36のステップS10で、プロセッサ31は、プレイヤキャラ201がゴールしたか否かを判定する。当該判定の結果、まだゴールしていない場合は(ステップS10でNO)、ステップS11で、プロセッサ31は、上記の処理が反映されたゲーム画面を生成して表示する。その後、上記ステップS2に戻り、処理が繰り返される。
【0156】
一方、ゴールした場合は(ステップS10でYES)、ステップS12で、プロセッサ31は、ステージクリア処理を実行する。
図46は、ステージクリア処理の詳細を示すフローチャートである。まず、ステップS141で、プロセッサ31は、リプレイ記録用データ359へのリプレイデータの記録を停止する。次に、ステップS142で、プロセッサ31は、ステージクリアの演出を表示を行う。次に、ステップS143で、プロセッサ31は、リプレイ記録用データ359をゲームサーバ1に送信する。その後、ステージクリア処理を終了する。
【0157】
図36に戻り、次に、ステップS13で、プロセッサ31は、自身が配置した自パネルがステージに残っている場合、自パネルデータ391をゲームサーバ1に送信する。
【0158】
次に、ステップS14で、プロセッサ31は、ステージ部屋から退室する処理を行う。その後、ステージ処理は終了する。
【0159】
次に、上記ステップS7の判定の結果、ロスト発生フラグ360がオンの場合の処理について説明する(ステップS7でYES)。この場合は、まず、ステップS15で、プロセッサ31は、プレイヤキャラ201の残数から1を減らす。次に、ステップS16で、プロセッサ31は、プレイヤキャラ201の残数が0か否かを判定する。当該判定の結果、0ではない場合は(ステップS16でNO)、ステップS17で、プロセッサ31は、リスタート処理を実行する。
【0160】
図47は、上記リスタート処理の詳細を示すフローチャートである。
図47において、まず、ステップS131で、プロセッサ31は、ロスト発生フラグ360にオフを設定する。また、この際、特殊状態化回数357も0に設定する。つまり、リスタートに伴い、特殊状態への変化回数のカウントをリセットする。この点、他の実施形態では、リセットせずにリスタート後も特殊状態化回数357引き継ぐようにしてもよい。
【0161】
次に、ステップS132で、プロセッサ31は、上記選出済みフラグ366および配置完了フラグ367を初期化する。これにより、中間地点からリスタートした場合、再度リプレイデータのダウンロードおよび新たなリプレイゴーストの再配置が行われ得る。
【0162】
次に、ステップS133で、プロセッサ31は、所定のリスタート地点にプレイヤキャラ201を配置する。また、これに併せて、仮想カメラもプレイヤキャラ201が撮像範囲に入るような位置に移動される。次に、ステップS134で、プロセッサ31は、ゲーム画面を生成して表示する。以上で、リスタート処理は終了する。
【0163】
図36に戻り、リスタート処理が終われば、上記ステップS2に戻り、処理が繰り返される。
【0164】
一方、上記ステップS16の判定の結果、プレイヤキャラ201の残数が0の場合は(ステップS16でYES)、ステップS18で、プロセッサ31は、ゲームオーバーの演出を表示する。その後、上記ステップS13に処理が進められる。この場合は、自パネルの情報をゲームサーバ1に送信してからステージ部屋から退室する流れとなる。
【0165】
以上で、ステージプレイ処理の詳細説明を終了する。
【0166】
[ゲームサーバ1の処理]
次に、ゲームサーバ1で実行される処理の詳細について説明する。
図48は、ゲームサーバ1に係る処理の詳細を示すフローチャートである。
図48において、まず、ステップS151で、ゲームサーバ1のプロセッサ11は、マッチング処理を実行する。この処理では、プレイヤからのステージプレイの開始要求に応じて、プレイヤ同士のマッチング、すなわち、各プレイヤが入室するステージ部屋を決定する処理が実行される。また、その結果をゲーム装置3に送信する処理も実行される。
【0167】
次に、ステップS152で、プロセッサ31は、ステージ部屋を管理する処理を行う。この処理では、新たな部屋を作成する処理、プレイヤの補填を行う処理、プレイヤがいなくなった部屋を削除する処理等、ステージ部屋管理データ304を適宜更新して各ステージ部屋を管理する処理が行われる。
【0168】
次に、ステップS153で、プロセッサ31は、パネル情報を管理する処理を実行する。この処理では、各ゲーム装置3から送信されてい自パネルデータ391を受信し、上記パネル管理データ306への登録や更新が行われる。また、必要に応じて、所定のゲーム装置3からの要求に応じて、上記サーバパネルの基となるパネル情報332を送信する処理も実行される。
【0169】
次に、ステップS154で、プロセッサ31は、リプレイデータを管理する処理を行う。この処理では、各ゲーム装置3から受信したリプレイデータに基づいてリプレイ管理データ305への登録や更新が行われる。
【0170】
その後、プロセッサ11は、上記ステップS151に戻り、処理を繰り返す。以上で、ゲームサーバ1に係る処理の詳細説明は終了する。
【0171】
このように、本実施形態では、プレイヤキャラ201にミスイベントが発生した場合、近くに復活補助オブジェクトであるリモートキャラがいる場合は、プレイヤキャラ201をロストさせずに、プレイヤキャラ201を一旦特殊状態に変化させる。そして、復活可能時間中にリモートキャラに接触することで、通常状態に復活することができる。これにより、シングルプレイの感覚でゲームを進行させつつ、オンラインでプレイすることのメリットをプレイヤに提供できる。そのため、オンラインマルチでゲームプレイすることを促進できる。
【0172】
また、リモートキャラだけでなく、各リモートキャラが配置したリモートパネルや上記サーバパネルも上記復活補助オブジェクトとして機能させている。そのため、あるプレイヤは、リモートパネルを配置しておけば、これが自分の代わりに他のプレイヤの手助けとして機能することを期待できる。これにより、例えば、あるプレイヤが他のプレイヤの復活を補助することを意識して自分のペースでゲームが進行できなくなることを抑制できる。
【0173】
また、本実施形態では、上記のように、ステージの中間地点を通過したことに応じて、リプレイゴーストを出現させている。当該リプレイゴーストは、一見しただけでは、上記リモートキャラとの見分けがつかないものとなっている。また、当該リプレイゴーストも、上記復活補助オブジェクトとして機能する。そのため、ステージの途中まで他のプレイヤとの出会いが無かった場合でも、ステージ後半については他のプレイヤとオンラインで繋がっており、同じステージ部屋で一緒に遊んでいるプレイ体験をプレイヤに提供できる。つまり、ステージプレイの開始から中間地点に到達するまでは、他のプレイヤと出会えることへの期待感を与える。例えばステージ前半であれば、後から入室してきたプレイヤのリモートキャラが追いついてくることは十分考えられる。そのため、ステージプレイ開始後にすぐにゴーストは出現させずに、しばらくの間は、他のプレイヤの入室およびリモートキャラの出現を待つようにしている。その一方で、ステージのプレイ開始から中間地点に到達しても他のプレイヤが入室してこないような場合は、リプレイゴーストを出現させることで、あたかもリモートキャラと一緒にステージを進んでいるようなプレイ体験を提供する。これにより、オンラインでプレイすることの意義を与え、プレイヤが積極的にオンラインでプレイすることを促進できる。また、リプレイゴースト出現後に他のプレイヤが入室してきた場合は、入室した人数に応じてリプレイゴーストを消去してリモートキャラを出現させている。そのため、コミュニケーションを取ることが可能なリモートキャラとのプレイを優先することもできる。
【0174】
[変形例]
なお、上記リプレイゴーストに関して、例えば、プレイヤがプレイヤキャラ201として使用しているキャラクタと同じキャラクタが上記リプレイゴーストとして選出されることもあり得る。この場合、リプレイゴーストに係るキャラクタの外観については他のキャラクタの外観に変更してもよい。プレイヤキャラ201と同じキャラクタであるリプレイゴーストがいると、場合によっては見分けがつきにくく、プレイヤに不要な混乱を与えることを抑制するためである。
【0175】
また、上記の例では、リプレイゴーストを出現させるタイミングについて、プレイヤキャラが上記中間地点に到達した場合を例に挙げた。この点、特定のステージでは、スタート地点からリプレイゴーストを出現させるようにしてもよい。この場合は、当該特定のステージにおいてはリプレイデータの記録もスタート地点から開始するようにすればよい。
【0176】
また、上記の例では、リプレイゴーストの見た目はリモートキャラと変わらない場合を例示した。この点、他の実施形態では、リモートキャラであるかリプレイゴーストであるのかをプレイヤが区別可能なように、その見た目を異ならせるようにしてもよい。
【0177】
また、上記の例では、リモートキャラが存在する場合はリプレイゴーストを出現させない(リプレイの再生をしない)という例を挙げた。他の実施形態では、リモートキャラが存在している場合でも、リプレイゴーストを出現させてもよい。例えばステージ部屋の定員の空きの分だけリプレイゴーストを出現させてもよい。更に、この場合は、いずれかのゲーム装置で出現させたリプレイゴーストの情報を他のゲーム装置との間で共有してもよい。例えば、ゲーム装置Aのゲーム処理においてリプレイゴーストを出現させる処理が行われた場合、位置情報を共有したり、リプレイデータそのものを共有する等して、同じステージ部屋の他のゲーム装置でも、同じリプレイゴーストが出現するようにしてもよい。
【0178】
また、上記実施形態では、所定条件下でミスイベントが発生したときにプレイヤキャラ201が特殊状態に変化する例を挙げた。この点、他の実施形態では、プレイヤが所定の操作を行うことで、自発的に上記特殊状態に変化できるようにしてもよい。但し、特殊状態から通常状態への復活は自発的な操作では行えず、上記のように復活補助オブジェクトに復活可能時間内に接触する必要があるようにしてもよい。これにより、プレイヤはステージを攻略する上で、戦略的にわざと特殊状態となって、ステージ上の難所を抜けてから復活する、というようなプレイが可能となる。そのため、オンラインプレイによるメリットを恒常しつつ、プレイの幅を広げることも可能となる。
【0179】
また、上記リモートパネルに関して、他の実施形態では、退室したプレイヤが配置したリモートパネルについては、退室後所定の時間が経過したら自動的に消去するように制御してもよい。
【0180】
また、上記パネル情報をゲームサーバ1に送信するタイミングについて、上記の例ではステージ部屋から退室する時に送信する例を挙げた。他の実施形態では、配置がおこなわれる都度、ゲームサーバ1へのパネル情報の送信が行われてもよい。また、同一プレイヤについての複数のパネル情報をゲームサーバ1に登録可能としてもよい。
【0181】
また、上記実施形態では、通常状態のプレイヤキャラ201とリモートキャラとの衝突判定は行われないという例で説明した。この点、他の実施形態では、衝突判定自体は行うが、リモートキャラがプレイヤのゲームプレイに直接影響は及ぼさないような処理を行ってもよい。例えば、通常状態のプレイヤキャラ201が(半透明の)リモートキャラと接触したとき、リモートキャラが少し押されるような反応を演出的に表示しつつ、リモートキャラに係るリモートプレイヤ名を一時的に表示するような処理を行ってもよい。
【0182】
また、上記実施形態では、各ゲーム装置でプレイするプレイヤ数が1人である場合を想定して説明していた。この点、1台のゲーム装置について例えば2人のプレイヤが同時にステージプレイに参加できるようにしてもよい。例えば、ゲーム装置Aにおいて、プレイヤAとプレイヤBが2人同時プレイ(ローカルマルチプレイ)の態様で、同じゲーム画面内で各自のプレイヤキャラであるプレイヤキャラAおよびプレイヤキャラBが表示されるようにしてもよい。また、この場合は、プレイヤキャラAおよびプレイヤキャラBについては、リモートキャラのような半透明表示は行わず、双方とも不透明の態様で表示すればよい。また、プレイヤキャラAおよびプレイヤキャラBはお互いに復活補助オブジェクトとして機能させればよい。また、上記パネル配置については、お互いに相手が配置したパネルを上記リモートパネルとして扱ってもよい。あるいは、いずれか一方のプレイヤキャラが配置したものだけを上記リモートパネルとして扱ってもよい。
【0183】
なお、上記のようなローカルマルチプレイの場合、サーバに送信するパネル情報については、いずれか1人のプレイヤが配置したパネル情報のみ送信するようにしても良よい。
上述したサーバパネルについては、最大で2つまで配置されるようにすればよい。
【0184】
また、上記リプレイゴーストについては、プレイヤアクター数が1部屋で最大4つまでとなるように調整されるため、最大で2体分までの配置とすればよい。
【0185】
また、ローカルマルチプレイに係るプレイヤキャラが全て通常状態ではなくなった場合は、特殊キャラがいなければ、その時点で、当該ローカルマルチプレイに係るプレイヤキャラについて上記ロストが発生する。一方、いずれかが特殊キャラになっていた場合は、この時点ではまだロストは発生しない。例えば上記リモートキャラやリモートパネルによって復活できる可能性があるためである。
【0186】
また、上記実施形態では、特殊キャラであるときに復活可能時間内に復活補助オブジェクトに接触できれば、プレイヤキャラの残数を減らさずに復活させる例を挙げた。この点、他の実施形態では、残数を減らしたうえで復活させるようにしてもよい。この場合でも、復活する位置は復活補助オブジェクトの近くの位置になるため、リスタート地点まで戻されて復活する場合よりは、プレイヤにとって有利になる。
【符号の説明】
【0187】
1 ゲームシステム
3 情報処理端末(ゲーム装置)
4 コントローラ
31 プロセッサ
32 記憶部
33 無線通信部
34 コントローラ通信部