JP2012125286A - ゲームプログラム - Google Patents

Abstract

【課題】非同期ゲームでありながらプレイヤが他のゲーム装置で行われているゲームのプレイヤとの間で互いに係り合うことができ、救助においてプレイヤに緊迫感を感じさせるゲームプログラムを提供する。
【解決手段】ゲーム装置１ａで救助要請が行われると（Ｓ３：ＹＥＳ)、救助要請情報が送信される（Ｓ５）。救助要請情報を受信した（Ｓ２１）ゲーム装置１ｂで救助が完了した場合（Ｓ２５：ＹＥＳ）、救助完了情報が送信される（Ｓ２６）。一方、ゲーム装置１ｂで救助制限時間以内に救助が完了できなかった場合（Ｓ２４：ＹＥＳ）、敵キャラクタが出現する（Ｓ３０）。したがって、ゲーム装置１ｂのプレイヤは、救助制限時間以内に救助が完了できるように、緊迫感を持ってゲームを進行することになる。また、ゲーム装置１ｂのプレイヤは、ゲーム装置１ａのプレイヤと係り合うことができる。
【選択図】図６

Description

本発明は、ゲームプログラムに関する。

従来、プレイヤが所定のキャラクタを操作し、仮想ゲーム空間上で敵であるキャラクタと戦うアクションゲームが開発されている。以下では、プレイヤが操作するキャラクタを「プレイヤキャラクタ」とし、敵であるキャラクタを「敵キャラクタ」とする。

このようなアクションゲームでは、一般的に、プレイヤキャラクタが敵キャラクタから攻撃を受けると、プレイヤキャラクタはダメージを受け、当該プレイヤキャラクタに予め設定されている体力値が減少する。受けたダメージが蓄積してプレイヤキャラクタの体力値がゼロになると、プレイヤキャラクタが倒されたとしてゲームオーバーとなる。ゲームオーバーとなった後にゲームを再開する場合、一般的には、ゲームが最初（あるいはステージの最初）から開始することになり、獲得していたポイントやアイテムが消滅し、上がっていたプレイヤキャラクタのレベルが元のレベルに戻る。

一方、プレイヤキャラクタが倒された場合に条件を設け、当該条件をクリアした場合に、ゲームオーバーになったときの状態からゲームを再開できるようにしたゲームも開発されている。例えば、第１ゲームでプレイヤキャラクタが倒された場合に第２ゲームに救助要請を出し、当該第２ゲームで救助を行うことができれば、第１ゲームを再開するときに倒された地点から再開することができるゲームがある。当該ゲームでは、第１ゲームにおいてプレイヤキャラクタが倒された位置に、第２ゲームにおけるプレイヤキャラクタが到達することで救助を行うことができるようになっている。

特開２００７−１３５７９１号公報

上述したゲームでは、第２ゲームで救助を行うことについて特に制限がなく、プレイヤが通常通り第２ゲームを進行すれば救助できるようになっている。したがって、第２ゲームを進行するにあたり、通常通り第２ゲームを進行する以上の緊迫感を感じることがない。

また、上述したゲームでは第１ゲームを行うプレイヤと第２ゲームを行うプレイヤとが同一の者であり、自分で救助要請をして自分で救助することになるので、ゲームを通して他のプレイヤと係り合うことがない。

他のゲーム装置との間でリアルタイムに通信を行って、他のゲーム装置で進行されているゲームと係り合いながら進行されるゲームが「同期ゲーム」と呼ばれるのに対して、リアルタイムの通信が行われずに各ゲーム装置で単独で進行されるゲームは「非同期ゲーム」と呼ばれる。非同期ゲームではリアルタイムで他のゲーム装置やサーバと通信を行う必要がないので、サーバやゲーム装置における通信処理の負担が軽減される。しかし、各ゲーム装置でそれぞれゲームが進行されるので、他のゲーム装置で行われているゲームのプレイヤとの間で互いに係り合うことができない。

本発明は上記した事情のもとで考え出されたものであって、非同期ゲームでありながらプレイヤが他のゲーム装置で行われているゲームのプレイヤとの間で互いに係り合うことができ、救助においてプレイヤに緊迫感を感じさせるゲームプログラムを提供することをその目的としている。

上記課題を解決するため、本発明では、次の技術的手段を講じている。

本発明の第１の側面によって提供されるゲームプログラムは、コンピュータを、仮想ゲーム空間上でプレイヤが操作するプレイヤキャラクタを活動させるゲーム装置として機能させるためのゲームプログラムであって、前記コンピュータを、ゲームの進行を制御するゲーム進行制御手段と、他のコンピュータから送信された当該他のコンピュータのプレイヤキャラクタに関するプレイヤキャラクタ情報を少なくとも含む要請情報を受信部に受信させる要請情報受信制御手段と、前記受信部が前記要請情報を受信したときに、当該要請情報に基づいたキャラクタを前記仮想ゲーム空間上に生成させるキャラクタ生成手段と、前記要請情報が所定条件を満たすか否かを判断する判断手段として機能させ、前記キャラクタ生成手段は、前記所定条件を満たす場合、生成させるキャラクタの属性を敵キャラクタとすることを特徴とする。

本発明によれば、あるゲーム装置として機能しているコンピュータ（以下では、「ゲーム装置Ａ」とする。）から送信された要請情報を、他のゲーム装置として機能しているコンピュータ（以下では、「ゲーム装置Ｂ」とする。）が受信した場合、要請情報に基づくキャラクタがゲーム装置Ｂの仮想ゲーム空間上に生成される。このとき、要請情報が所定条件を満たしていると、生成されるキャラクタが敵キャラクタとして生成される。

したがって、要請情報を受信した場合、仮想ゲーム空間上に新たに敵キャラクタが生成される可能性があるので、ゲーム装置Ｂのプレイヤは緊迫感を感じながらゲームを進行することができる。また、ゲーム装置Ｂのプレイヤは、ゲームを通してゲーム装置Ａのプレイヤと係り合うことができる。

本発明のその他の特徴および利点は、添付図面を参照して以下に行う詳細な説明によって、より明らかとなろう。

本実施形態に係るゲーム装置を示す構成図である。 本ゲームの１場面のゲーム画像を示す図である。 救助要請情報を説明するための図である。 救助完了情報を説明するための図である。 報酬情報を説明するための図である。 ゲーム進行処理のうち、救助要請に関する部分を説明するためのフローチャートである。

以下、本発明の好ましい実施の形態として、添付図面を参照して具体的に説明する。以下の説明では、本発明に係るゲームプログラムをインストールした携帯電話端末（以下、「ゲーム装置」とする。）において、アクションゲームを進行している場合を例として説明する。

本実施形態に係るアクションゲーム（以下では、「本ゲーム」とする。）は、仮想ゲーム空間上でプレイヤキャラクタをゾンビである敵キャラクタと戦わせ、プレイヤキャラクタが敵キャラクタを倒すことにより進行する。プレイヤキャラクタが敵キャラクタからの攻撃を受けると、プレイヤキャラクタに予め設定されている体力値が減少する。体力値がゼロになると、プレイヤキャラクタは動けなくなってゲームを中断した状態となるが、プレイヤは他のプレイヤに救助要請を出すことができる。以下では、救助要請を出したプレイヤと当該救助要請を受けたプレイヤとを区別して説明する必要がある場合、救助要請を出したプレイヤを「プレイヤＡ」とし、当該救助要請を受けたプレイヤを「プレイヤＢ」とする。プレイヤＢが当該救助要請を受けると、当該プレイヤＢが行っているゲームにプレイヤＡのプレイヤキャラクタ（以下では、「プレイヤキャラクタＡ」とする。）に基づくキャラクタが出現する。

プレイヤＡが救助要請を出してから救助のための制限時間（以下、「救助制限時間」とする。）内にプレイヤＢが救助要請を受けた場合、プレイヤＢが行っているゲームに瀕死状態のプレイヤキャラクタＡが出現する。プレイヤＢのプレイヤキャラクタ（以下では、「プレイヤキャラクタＢ」とする。）が当該瀕死状態のプレイヤキャラクタＡにタッチすることができると、プレイヤキャラクタＡは救助されたことになり、プレイヤＡが行っているゲームの中でもプレイヤキャラクタＡの体力値が回復し、ゲームが再開される。この場合、プレイヤキャラクタＡのレベルは維持されたまま、獲得したアイテムもそのままで、ゲームを再開することができる。なお、本実施形態では救助制限時間を、例えば２時間としている。

一方、プレイヤＡが救助要請を出してから救助制限時間が経過した後にプレイヤＢが救助要請を受けた場合、プレイヤＢが行っているゲームにゾンビとなったプレイヤキャラクタＡが出現する。ゾンビとなったプレイヤキャラクタＡは、プレイヤキャラクタＢの敵キャラクタとして、プレイヤキャラクタＢを攻撃してくる。また、救助制限時間内にプレイヤＢが救助要請を受けた場合でも、当該救助制限時間内にプレイヤキャラクタＢが瀕死状態のプレイヤキャラクタＡにタッチすることができなかった場合は、当該瀕死状態のプレイヤキャラクタＡがゾンビ化して、プレイヤキャラクタＢの敵キャラクタとなる。

プレイヤＡが救助要請を出してから救助制限時間内にプレイヤキャラクタＡが救助されなかった場合、すなわち、プレイヤＡが救助要請を出してから救助制限時間内にいずれのプレイヤも救助要請を受けなかった場合、および、救助要請を受けたプレイヤがプレイヤキャラクタＡを救助できなかった場合は、プレイヤＡのゲームでは、プレイヤキャラクタＡが救助を受けられずに死亡したことになり、ゲームオーバーとなる。この場合にゲームを再開すると、ゲームが最初から開始することになり、プレイヤキャラクタＡのレベルは元のレベルに戻り、プレイヤキャラクタＡが獲得していたアイテムは消滅してしまう。なお、救助要請の詳細については後述する。

まず、本実施形態のハード構成について説明する。

図１は、本実施形態に係るゲーム装置を示す構成図である。ゲーム装置１は、制御部１１、描画処理部１２、音声処理部１３、通信処理部１４、メモリ部１５、Ｉ／Ｏインターフェース部１６、通信部１７、表示部１８、音声出力部１９、操作部２０、および、タッチ操作部２１を備えている。制御部１１には、描画処理部１２、音声処理部１３、通信処理部１４、メモリ部１５、および、Ｉ／Ｏインターフェース部１６が接続されている。また、Ｉ／Ｏインターフェース部１６には、通信部１７、表示部１８、音声出力部１９、操作部２０、および、タッチ操作部２１が接続されている。

なお、図１においては、ゲーム装置１のゲーム処理機能を果たすための構成のみを記載しており、携帯電話端末としての機能を果たすための構成（例えば、通話機能のためのマイクなど）は記載および説明を省略している。また、図１に記載の各部は機能的な構成に分けたものであって、実際のハードウェアに対応するものとは限らない。例えば、描画処理部１２、音声処理部１３および通信処理部１４は、制御部１１内のＣＰＵ１１ａ（後述）に含まれる場合もある。

ゲーム装置１は、インターネット回線などのネットワーク回線２を介して、サーバ３との間で通信を行うことができる。ゲーム装置１は、本ゲームのソフトウェアをサーバ３からダウンロードして、メモリ部１５にインストールしている。なお、本ゲームのソフトウェアのインストールは、これに限られない。例えば、ＤＶＤ−ＲＯＭなどの記録媒体からパソコンなどを経由して、ゲーム装置１のメモリ部１５にインストールするようにしてもよい。

ゲーム装置１は、メモリ部１５からゲームプログラムおよびゲームデータを制御部１１内のＲＡＭ１１ｃ（後述）に読み込んで、本ゲームを実行する。プレイヤは、操作部２０またはタッチ操作部２１を操作することによりプレイヤキャラクタを操作し、ゲームを進行させることができる。

制御部１１は、ゲーム装置１の全体動作を制御するマイクロコンピュータを有している。マイクロコンピュータは、ＣＰＵ１１ａ、ＲＯＭ１１ｂ、およびＲＡＭ１１ｃなどからなり、各部は、それぞれバスラインで接続されている。

ＣＰＵ１１ａは、メモリ部１５からＲＡＭ１１ｃに読み込まれるゲームプログラムを実行することより、ゲーム進行を統括的に制御する。より具体的には、操作部２０またはタッチ操作部２１からプレイヤが操作することによる操作信号が入力されると、ＣＰＵ１１ａは、ゲームプログラムにしたがってその操作信号に対する所定のゲーム進行処理を行う。ＣＰＵ１１ａはその処理結果を、例えば三次元空間を表現する二次元画像（以下、「ゲーム画像」という）として表示部１８に表示させるとともに、効果音などとして音声出力部１９に出力させる。

ＲＯＭ１１ｂには、ローディング機能などのゲーム装置１の基本的な機能やメモリ部１５に記録されたゲームプログラムおよびゲームデータを読み出す手順などを示す基本プログラムが記録されている。ＣＰＵ１１ａは、プレイヤによって本ゲームの開始が選択されると、ＲＯＭ１１ｂの基本プログラムにしたがってメモリ部１５からゲームプログラムおよびゲームデータをＲＡＭ１１ｃに読み込み、ゲーム開始状態に設定する。

ＲＡＭ１１ｃは、メモリ部１５から読み込まれたゲームプログラムやゲームデータが格納されるエリアと、ＣＰＵ１１ａがゲームプログラムを実行するためのワークエリアとを提供するものである。

上記ゲームプログラムは、複数のプログラムが組み合わされて構成されている。例えば、表示部１８に表示されているプレイヤキャラクタの動作を操作部２０またはタッチ操作部２１からのプレイヤの操作信号に基づいて制御するゲーム進行プログラムや表示部１８に表示すべきゲーム画像を制御するグラフィック制御プログラムなどが含まれている。

上記ゲームデータにはプレイヤキャラクタや敵キャラクタなどのキャラクタデータ（画像データ含む）、武器などのアイテムデータ（画像データ含む）、モーションデータ、背景などの画像データ、効果音やＢＧＭなどの音声データ、および、ゲーム進行や描画の際に参照される各種テーブルなどが含まれる。

ＣＰＵ１１ａは、操作部２０またはタッチ操作部２１からのプレイヤの操作信号に基づき、必要に応じてメモリ部１５からゲームプログラムや画像データなどをＲＡＭ１１ｃに読み込み、これらのデータを処理したりゲームプログラムを実行したりすることにより、表示部１８に表示すべきゲーム画像の内容を決定する。

描画処理部１２は、描画処理に必要な各種の演算処理を行うものである。ＣＰＵ１１ａは、例えば、１／６０秒毎に、描画処理部１２に描画指令を出力する。このとき、ＣＰＵ１１ａは、表示部１８に表示すべき画像を決定し、その画像の描画に必要なキャラクタデータ、アイテムデータ、背景などの画像データ、モーションデータおよび光源データなどをＲＡＭ１１ｃから読み出して描画処理部１２に供給する。また、ＣＰＵ１１ａは、各キャラクタの位置データや、操作部２０またはタッチ操作部２１から入力される操作信号を描画処理部１２に供給する。

描画処理部１２は、ＣＰＵ１１ａからの描画命令に基づいて画像データなどを用いて、描画に必要なデータ（各オブジェクトおよび背景の位置関係、表示部１８の画面上における各オブジェクトを構成するポリゴンの座標、各ポリゴンに対応するテクスチャ、並びに各ポリゴンの反射特性などのデータ）の演算などを行い、その演算結果に基づいて描画処理部１２内のＶＲＡＭ（図示せず）に１コマ（１フレーム）のゲーム画像のデータを作成する。作成されたゲーム画像のデータは、例えば１／６０秒毎に映像信号として表示部１８に出力されて、映像として表示される。

音声処理部１３は、効果音などの音声を発生させる処理に必要な各種の演算処理を行うものである。ＣＰＵ１１ａは、音声出力部１９から出力すべき効果音若しくはＢＧＭの音響内容を決定すると、音声処理部１３に音声指令を出力する。音声処理部１３は、ＣＰＵ１１ａからの音声指令に基づき、ＲＡＭ１１ｃから効果音もしくはＢＧＭの音声データを読み出し、所定の加工処理とＤ／Ａ変換処理とを施した後、音声出力部１９に出力する。

通信処理部１４は、ネットワーク回線２を介して他のゲーム装置１やサーバ３との間で通信を行う場合に、情報の送信および受信を行うための制御を行うものである。

メモリ部１５は、インストールされたゲームプログラムおよびゲームデータを記録するものであり、書き換え可能な不揮発性の記録媒体を備えている。また、メモリ部１５は、ゲーム進行中やゲーム終了時などに、ゲーム進行に関する情報（例えば、獲得したポイントやアイテムなどの各種の特典などの情報）を記録する。メモリ部１５に記録されたゲーム進行に関する情報は、ゲーム開始時などにＲＡＭ１１ｃに読み出される。

Ｉ／Ｏインターフェース部１６は、操作部２０およびタッチ操作部２１から入力される操作信号を制御部１１に伝送したり、制御部１１、描画処理部１２や音声処理部１３からの映像信号や音声信号などを表示部１８や音声出力部１９に伝送したりするものである。また、Ｉ／Ｏインターフェース部１６は、通信部１７から入出力される情報を制御部１１やメモリ部１５との間で伝送する。

通信部１７は、ネットワーク回線２を介して他のゲーム装置１やサーバ３との間で情報の送信および受信を行うものであり、送信データをキャリア周波数で変調した電磁波を生成する変調部、受信した電磁波から受信データを復調する復調部、変調部で生成した電磁波を送信したり電磁波を受信して復調部に送るためのアンテナを備えている。アンテナは図示しない基地局との間で電磁波を送受信し、ゲーム装置１は当該基地局およびネットワーク回線２を介して他のゲーム装置１やサーバ３との間で通信を行う。

表示部１８は、描画処理部１２から送られてきた映像信号に応じてゲーム進行状態を示すゲーム画像などを映し出すものであり、入力される映像信号をゲーム画像に変換して出力する液晶ディスプレイなどを備えている。

音声出力部１９は、音声処理部１３から送られてきた音声信号に応じて効果音などの音声を出力するための装置であり、入力される音声信号を所定の増幅度で増幅するアンプと増幅された音声信号を音声に変換して出力するスピーカ等を備えている。

操作部２０は、プレイヤキャラクタを動作させたり、ゲームに関する各種の設定を行ったりするために、プレイヤによって操作されるものであり、複数の操作ボタンなどを備えている。プレイヤによって操作ボタンなどが操作されると、その操作信号が制御部１１に入力され、表示部１８に表示されたプレイヤキャラクタが所定の動作を行う。所定の動作としては、例えば、走る、しゃがむ、ジャンプするなどの移動動作や武器を使用して相手を攻撃する攻撃動作などがある。プレイヤキャラクタの移動や向きの方向、動作の種別などが、各操作ボタンに割り当てられる。

タッチ操作部２１は、操作部２０と同様にプレイヤによって操作されるものであり、本実施形態では透明のタッチパネルを含んでいる。タッチパネルは表示部１８の表示画面を被うように設けられており、プレイヤがパネル面を直接指などで触れる（以下、「タッチする」という。）ことで、プレイヤの指示を制御部１１に入力する。タッチパネルのパネル面には多数の微小コンデンサまたは微小抵抗が格子状に配置されており、微小コンデンサの静電容量または微小抵抗の抵抗値の変化によって接触位置が検出され、接触位置の情報信号がＣＰＵ１１ａに入力される。ＣＰＵ１１ａは、入力される接触位置の情報信号に基づいて、プレイヤによる操作を判断する。

サーバ３は、ネットワーク回線２を介して各ゲーム装置１との間で通信を行うものである。サーバ３は、本ゲームのソフトウェアを記録しており、ゲーム装置１からのダウンロード指令に応じて、当該ゲーム装置１にソフトウェアを送信する。また、サーバ３は、各ゲーム装置１から送信される情報を蓄積記録し、各ゲーム装置１から受信した送信要求に応じて情報を送信する。つまり、サーバ３は各ゲーム装置１で実行されるゲームの進行を制御するものではなく、各ゲーム装置１で実行されるゲームの進行は、それぞれ各ゲーム装置１で制御される。なお、ゲームのソフトウェアを供給するサーバと情報の蓄積記録を行うサーバとは、別々のサーバであってもよい。また、情報の蓄積記録を行うサーバは、ゲームの提供会社が管理するサーバに限定されない。例えば、ＳＮＳ（ソーシャルネットワークサービス）が管理するサーバや掲示板のサーバなどであって、ＡＰＩ（Application Programming Interface)が公開されているものであれば、用いることができる。また、サーバ３を設けずに、ネットワーク回線２を介して各ゲーム装置１間で情報の送受信を行うようにしてもよい。

次に、救助要請の詳細について、図２〜図６を参照して説明する。

図２は、本ゲームの１場面のゲーム画像を示す図である。図２（ａ）は、ゲーム進行中の１場面であり、プレイヤキャラクタＰＣが複数の敵キャラクタＥＣに囲まれている場面を表している。

図２（ａ）に示すゲーム画像の画面左上には、ライフゲージＬＩＦＥおよびレベルゲージＬＶが表示されている。ライフゲージＬＩＦＥは、プレイヤキャラクタＰＣの体力値の残存を示すものであり、体力値の残存を斜線部分の領域で表している。レベルゲージＬＶは、プレイヤキャラクタＰＣのレベルを示すものであり、その長さがレベルを表している。また、レベルゲージＬＶの右側にはレベルが数値で表示されている。レベルは、プレイヤの本ゲームでの経験などに応じて増加する。レベルが高くなると、プレイヤキャラクタＰＣの戦闘力が高くなり、また、攻撃を受けた場合に減少する体力値が少なくなるので、敵キャラクタＥＣと戦う際に有利になる。

画面右上には、ポーズボタンＰＡＵＳＥが表示されている。ポーズボタンＰＡＵＳＥは、ゲームの進行を一時停止し、メニュー画面に進むためのボタンである。画面上のポーズボタンＰＡＵＳＥをタッチするか、対応付けられている操作部２０の操作ボタンを操作することで、ゲームの進行が一時停止され、メニュー画面が表示される。

メニュー画面では、現在の状態をセーブしてゲームを終了するための「終了メニュー」、仮想ゲーム空間上におけるプレイヤキャラクタＰＣの位置を確認するための「マップメニュー」などを選択することができる。なお、「マップメニュー」の詳細については後述する。

図２（ａ）に示すゲーム画像の画面左下には、移動ボタンＭＯＶＥが表示されている。移動ボタンＭＯＶＥは、プレイヤキャラクタＰＣを移動させるためのボタンである。画面右下には、攻撃ボタンＡＴＴＡＣＫとアイテムＩＴＥＭが表示されている。攻撃ボタンＡＴＴＡＣＫは、プレイヤキャラクタＰＣに攻撃を行わせるためのボタンである。アイテムＩＴＥＭは獲得した武器などのアイテムを表示しており、選択して使用することができる。移動ボタンＭＯＶＥ、攻撃ボタンＡＴＴＡＣＫ、およびアイテムＩＴＥＭは、画面上の各ボタンをタッチすることで選択して機能させることができる。また、各ボタンは操作部２０の各操作ボタンにそれぞれ対応付けられており、対応する操作ボタンを操作することでも機能させることができる。

プレイヤは、移動ボタンＭＯＶＥでプレイヤキャラクタＰＣを移動させ、攻撃ボタンＡＴＴＡＣＫで敵キャラクタＥＣを攻撃して倒すことができる。また、攻撃や防御に使用するアイテムをアイテムＩＴＥＭで選択して使用することができる。プレイヤキャラクタＰＣが敵キャラクタＥＣからの攻撃を受けると、プレイヤキャラクタＰＣの体力値が減少し、ライフゲージＬＩＦＥに示す斜線部分の領域が小さくなる。体力値の残存がなくなると（斜線部分の領域がなくなると）、プレイヤキャラクタＰＣは動けなくなって、救助要請選択状態となる。また、プレイヤキャラクタＰＣが食料を調達しないまま移動を続けることによっても体力値は減少し、この場合も体力値の残存がなくなるとプレイヤキャラクタＰＣは動けなくなって、救助要請選択状態となる。

救助要請選択状態になると、画面上に例えば「救助要請を行いますか？」という表示がされ、「ＹＥＳ」か「ＮＯ」を選択する状態になる。以下では、救助要請選択状態で表示される画面を「救助要請選択画面」とする。なお、レベルや保有アイテムを引き継いでゲームを再開する選択肢を選べるようにしてもよい。プレイヤによって「ＮＯ」が選択されると、救助要請が行われずに、ゲームオーバーとなる。一方、プレイヤによって「ＹＥＳ」が選択されると、現在のゲーム情報（プレイヤキャラクタＰＣのレベル、保有アイテム、ゲーム進行情報など）が記録されて、救助要請情報がサーバ３にアップロードされる。サーバ３は各ゲーム装置１からアップロードされた救助要請情報を蓄積記録する。ゲーム装置１では、救助要請を行ってから（救助要請情報がサーバ３にアップロードされてから）の経過時間が計時され、救助制限時間が経過するまでの残存時間がカウントダウンされる画像が表示される。ゲーム装置１のプレイヤは、救助されるまでゲームを進行することができない。

図３は、救助要請情報を説明するための図である。

救助要請情報は、プレイヤ情報、レベル情報、ノックアウト情報、メッセージ情報、ゲーム内暗号、タグ情報などを含んでいる。プレイヤ情報は、プレイヤを識別するための情報であり、プレイヤのニックネームやアイコン、ＩＤナンバーなどを含んでいる。レベル情報は、プレイヤキャラクタＰＣのレベル値を示す数値である。ノックアウト情報は、プレイヤキャラクタＰＣが倒れた場所および理由に関する情報であり、例えば、「おもちゃ売り場」、「ゾンビＡに殺された。」などの文字列である。メッセージ情報は、プレイヤによって入力されたメッセージ（任意）の文字列であり、救助要請選択画面で「ＹＥＳ」が選択された場合に入力のための画面が表示され、任意に入力することができる。ゲーム内暗号は、プレイヤキャラクタＰＣのキャラクタデータ（画像データなど）、倒れた位置座標データ、倒れた時刻データなどを含んでいる。タグ情報は、サーバ３に蓄積された各情報の種類を識別するための情報であり、救助要請情報を示す文字列（例えば「＃ＨＥＬＰ」などの文字列）である。

サーバ３にアップロードされた救助要請情報のうち、プレイヤ情報、レベル情報、ノックアウト情報、およびメッセージ情報は、マップメニューで確認することができる。

図２（ｂ）は、メニュー画面で「マップメニュー」を選択した場合に表示されるゲーム画像を示している。当該ゲーム画像は、プレイヤキャラクタＰＣの現在位置座標データおよび向きデータと、サーバ３にアップロードされた救助要請情報に基づいて作成される。

同図（ｂ）に示すゲーム画像には仮想ゲーム空間を上空からみた簡略図が表示されており、プレイヤキャラクタＰＣが矢印で表示されている。矢印の位置がプレイヤキャラクタＰＣの現在位置であり、矢印の向きがプレイヤキャラクタＰＣの向きを示している。プレイヤは、当該画像を見ることで、仮想ゲーム空間上におけるプレイヤキャラクタＰＣの位置および向きを知ることができる。

また、同図（ｂ）に示すゲーム画像には、サーバ３にアップロードされた救助要請情報に基づいて、倒れたプレイヤキャラクタを示すオブジェクトが表示される。同図（ｂ）においては、オブジェクトＰＣａ，ＰＣｂ，ＰＣｃが表示されている。オブジェクトＰＣａ，ＰＣｂ，ＰＣｃは、救助要請情報のゲーム内暗号の倒れた位置座標データが示す位置に、時刻データに応じた色で表示されている。倒れたプレイヤキャラクタを示すオブジェクトは、プレイヤキャラクタが倒れた時刻からあまり時間が経過していない場合は白色に近い灰色で表示され（オブジェクトＰＣａ参照）、時間が経過するほど黒色に近づいてゆき（オブジェクトＰＣｂ参照）、救助制限時間を経過すると黒色で表示される（オブジェクトＰＣｃ参照）。したがって、プレイヤは、当該画像を見ることで、救助要請を行ったゲーム装置１のプレイヤキャラクタの倒れているおおよその位置と救助要請を行ってからのおおよその経過時間を知ることができる。また、プレイヤは、画面上のオブジェクトＰＣａ，ＰＣｂ，ＰＣｃにタッチして選択することで、対応する倒れたプレイヤキャラクタの情報を見ることができる。なお、同図（ｂ）に示すゲーム画像に倒れたプレイヤキャラクタの情報を初めから表示しておくようにしてもよい。また、倒れたプレイヤキャラクタの情報の表示方法は、上述した「マップメニュー」で表示する方法に限定されない。例えば、倒れたプレイヤキャラクタの情報を時系列などで羅列して表示するようにしてもよい。

同図（ｃ）は、同図（ｂ）に示すゲーム画像において、プレイヤがオブジェクトＰＣｂを選択したときのゲーム画像を示している。当該ゲーム画像においては、オブジェクトＰＣｂに対応する倒れたプレイヤキャラクタの情報が、サーバ３にアップロードされている救助要請情報（図３参照）に基づいて表示されている。すなわち、プレイヤ情報に含まれるプレイヤのアイコンとニックネーム、レベル情報、ノックアウト情報に含まれる倒れた場所と理由、およびメッセージ情報が表示されている。

また、図２（ｃ）に示すゲーム画像には、救助するか否かの選択肢「ＹＥＳ」「ＮＯ」が表示されている。プレイヤによって「ＮＯ」が選択されると、プレイヤが救助要請を受けなかったとして、同図（ｂ）に示す画像に戻る。一方、プレイヤによって「ＹＥＳ」が選択されると、プレイヤが救助要請を受けたとして、サーバ３から救助要請情報のうちゲーム内暗号およびレベル情報がダウンロードされる。これらのダウンロードされた情報に基づいて、仮想ゲーム空間上にキャラクタが出現する。なお、救助するか否かの選択肢を表示することなく、同図（ｂ）に示すゲーム画像でオブジェクトを選択したことで救助要請を受けたとしてもよい。

図２（ｃ）で「ＹＥＳ」を選択した場合は、オブジェクトＰＣｂに対応するプレイヤキャラクタＰＣｂに基づくキャラクタが、仮想ゲーム空間上の位置座標（ｘ，ｙ，ｚ）に出現する。このとき、救助要請を行ってから救助制限時間が経過していなかった場合は、瀕死のプレイヤキャラクタＰＣｂを表すために、横たわる影としてのキャラクタが出現する（図２（ａ）のキャラクタＰＣｂ’参照）。一方、救助要請を行ってから救助制限時間が経過していた場合は、敵キャラクタとなったプレイヤキャラクタＰＣｂを表すために、ゾンビとしてのキャラクタが出現する。当該ゾンビとしてのキャラクタは、プレイヤキャラクタＰＣｂのキャラクタデータを加工して表示する。また、当該ゾンビとしてのキャラクタのレベル値には、救助要請情報のレベル情報が用いられる。したがって、プレイヤキャラクタＰＣｂの特徴を引き継いだ敵キャラクタが出現することになる。このような敵キャラクタと戦いたいプレイヤは、あえて救助制限時間が経過した救助要請を受けるという方法をとることができる。また、このような敵キャラクタを倒した場合にメリットがあるようにしてもよい。なお、同図（ｂ）において、倒れたプレイヤキャラクタを示すオブジェクト（同図（ｂ）のオブジェクトＰＣａ，ＰＣｂ，ＰＣｃ参照）の色を変化させないようにして、プレイヤが救助要請を行ってからの経過時間を知ることができないようにしてもよい。この場合、横たわる影としてのキャラクタが出現するか、ゾンビとしてのキャラクタが出現するか、事前に判らないので、プレイヤはギャンブル性を楽しむことができる。

プレイヤがプレイヤキャラクタＰＣを操作して、影としてのキャラクタにタッチすることができると、プレイヤキャラクタＰＣｂが救助されたことになる。この場合、当該ゲーム装置１からサーバ３に救助完了情報が送信される。サーバ３は、救助完了情報を蓄積記録するとともに、プレイヤキャラクタＰＣｂの救助要請情報をアップロードしたゲーム装置１に当該救助完了情報を送信する。なお、サーバ３を経由せずに、直接送信するようにしてもよい。なお、プレイヤキャラクタＰＣｂが救助された場合、および、プレイヤキャラクタＰＣｂの救助要請がキャンセルされた場合、サーバ３に記録された救助要請情報にその旨の情報が追加されて（または、救助要請情報が削除されて）、救助要請を受けることができないようになっている。

図４は、救助完了情報を説明するための図である。

救助完了情報は、救助プレイヤ情報、被救助プレイヤ情報、メッセージ情報、ゲーム内暗号、タグ情報などを含んでいる。救助プレイヤ情報は救助を行ったプレイヤのプレイヤ情報であり、被救助プレイヤ情報は救助されたプレイヤのプレイヤ情報である。それぞれ、プレイヤのニックネームやアイコン、ＩＤナンバーなどを含んでいる。メッセージ情報は、救助を行ったプレイヤによって入力されたメッセージの文字列であり、救助を完了したとき（影としてのキャラクタにタッチしたとき）に入力のための画面が表示され、任意に入力することができる。ゲーム内暗号は、救助暗号データなどを含んでいる。タグ情報は、救助完了情報を示す文字列（例えば「＃ＲＥＶＩＶＥＤ」などの文字列）である。

救助完了情報を受信したゲーム装置１では、救助要請を行ってからの経過時間の計時が停止され、メッセージ情報に基づいてメッセージが表示されて、プレイヤキャラクタＰＣの復活処理が行われる。復活処理とはプレイヤキャラクタＰＣを復活させてゲームを再開させるための処理であり、救助要請を行ったときに記録されたゲーム情報が読み出され、レベルおよびアイテムを維持したままで体力値が回復して、ゲームが再開される。このとき、当該ゲーム装置１からサーバ３に報酬情報が送信される。サーバ３は、報酬情報を蓄積記録するとともに、最初に救助を行った（最初に救助完了情報を送信した）ゲーム装置１に当該報酬情報を送信する。なお、サーバ３を経由せずに、直接送信するようにしてもよい。最初に受信した救助完了情報以外の救助完了情報については、メッセージを表示するだけにしている。なお、最初に救助完了情報を送信したゲーム装置１からの救助完了情報だけが受信されるようにしてもよい。また、救助を行った全てのゲーム装置１に報酬情報を送信するようにしてもよい。

図５は、報酬情報を説明するための図である。

報酬情報は、被救助プレイヤ情報、救助プレイヤ情報、メッセージ情報、ゲーム内暗号、タグ情報などを含んでいる。被救助プレイヤ情報は救助されたプレイヤ、すなわち報酬を送る方のプレイヤのプレイヤ情報である。救助プレイヤ情報は救助を行ったプレイヤ、すなわち報酬を送られる方のプレイヤのプレイヤ情報である。それぞれ、プレイヤのニックネームやアイコン、ＩＤナンバーなどを含んでいる。メッセージ情報は、救助されたプレイヤによって入力されたメッセージの文字列であり、救助完了情報を受信したときに入力のための画面が表示され、任意に入力することができる。ゲーム内暗号は、救助プレイヤに報酬を与えるための報酬暗号データなどを含んでいる。タグ情報は、報酬情報を示す文字列（例えば「＃ＲＥＷＡＲＤ」などの文字列）である。

報酬情報を受信したゲーム装置１では、メッセージ情報に基づいてメッセージが表示され、報酬暗号データに基づいた報酬が付与される。

図２（ｃ）で「ＹＥＳ」を選択したことで出現した影としてのキャラクタＰＣｂ’（図２（ａ）参照）をプレイヤキャラクタＰＣが救助する（タッチする）前に、救助要請を行ってからの経過時間が救助制限時間となった場合、影としてのキャラクタＰＣｂ’はゾンビとしてのキャラクタに変化して、プレイヤキャラクタＰＣを攻撃する。この場合のゾンビとしてのキャラクタにも、救助要請情報のキャラクタデータとレベル情報とが用いられる。

救助要請を行ったにも係らず、救助される前に救助制限時間が経過した場合、救助要請情報をアップロードする前に記録したゲーム情報（プレイヤキャラクタＰＣのレベル、保有アイテム、ゲーム進行情報など）が消去されて、ゲームオーバーとなる。この場合、ゲームを再開すると、プレイヤキャラクタＰＣのレベルは初期設定のレベルに戻り、プレイヤキャラクタＰＣが獲得していたアイテムは消滅した状態で、ゲームが最初から開始することになる。なお、プレイヤキャラクタＰＣのレベルを初期設定のレベルに戻すのではなく、所定のレベル（例えば、記録されたゲーム情報のレベルと初期設定のレベルとの中間のレベルなど）に下げるようにしてもよいし、アイテムを全て消滅させるのではなく、所定のアイテム（例えば、半分の数のアイテム）のみを消滅させるようにしてもよい。

なお、サーバ３には救助要請情報、救助完了情報、および報酬情報が蓄積記録されており、各ゲーム装置１からこれらの情報を参照ことができる。これにより、プレイヤは、非同期ゲームでありながら、他のプレイヤの参加状況やレベルなどを知ることができる。また、サーバ３には、上記情報以外にも任意のメッセージをアップロードすることができ、プレイヤ間でコミュニケーションをとることができる。また、サーバ３の情報はゲーム購入者以外の者にも公開されているので、プレイヤ同士のやり取りを見た者にゲームへの参加のモチベーションを与える効果もある。

図６は、ゲーム装置１の例えば制御部１１で行われるゲーム進行処理のうち、救助要請に関する部分を説明するためのフローチャートである。同図では、救助要請を行うゲーム装置１ａのゲーム進行処理のフローチャートと、救助要請を受けるゲーム装置１ｂの救助要請受信時のゲーム進行処理のフローチャートとして記載している。

まず、ゲーム装置１ａのゲーム進行処理のフローチャートについて説明する。

まず、プレイヤキャラクタの体力値がゼロになったか否かが判別され（Ｓ１）、ゼロになっていない場合（Ｓ１：ＮＯ）はステップＳ１に戻る。すなわち、プレイヤキャラクタの体力値がゼロになるまで、当該判別が繰り返される。プレイヤキャラクタの体力値がゼロになった場合（Ｓ１：ＹＥＳ）、救助要請選択画面が表示され（Ｓ２）、救助要請が選択されたか否かが判別される（Ｓ３）。具体的には、救助要請についての選択肢「ＹＥＳ」と「ＮＯ」のいずれが選択されたかが判別される。救助要請が選択されなかった場合（Ｓ３：ＮＯ）、ゲーム情報が消去されて（Ｓ１３）、ゲーム進行処理が終了される。一方、救助要請が選択された場合（Ｓ３：ＹＥＳ）、現在のゲーム情報が記録される（Ｓ４）。また、救助要請情報が生成されて送信され（Ｓ５）、経過時間の計時が開始される（Ｓ６）。

次に、計時された経過時間が救助制限時間を超えたか否かが判別される（Ｓ７）。救助制限時間が経過した場合（Ｓ７：ＹＥＳ）、ステップＳ４で記録されたゲーム情報が消去されて（Ｓ１３）、ゲーム進行処理が終了される。一方、救助制限時間が経過していない場合（Ｓ７：ＮＯ）、救助要請がキャンセルされたか否かが判別される（Ｓ８）。救助要請がキャンセルされた場合（Ｓ８：ＹＥＳ）、ステップＳ４で記録されたゲーム情報が消去されて（Ｓ１３）、ゲーム進行処理が終了される。一方、救助要請がキャンセルされていない場合（Ｓ８：ＮＯ）、救助完了情報を受信したか否かが判別される（Ｓ９）。救助完了情報を受信していない場合（Ｓ９：ＮＯ）、ステップＳ７に戻る。すなわち、救助制限時間が経過するか（Ｓ７：ＹＥＳ）、救助要請がキャンセルされるか（Ｓ８：ＹＥＳ）、救助完了情報を受信する（Ｓ９：ＹＥＳ）まで、ステップＳ７〜Ｓ９が繰り返される。

救助完了情報を受信した場合（Ｓ９：ＹＥＳ）、経過時間の計時が停止され（Ｓ１０）、ステップＳ４で記録されたゲーム情報が読み出される（Ｓ１１）。また、報酬情報が生成されて送信され（Ｓ１２）、ステップＳ１に戻って、ゲームが再開される。

次に、ゲーム装置１ｂの救助要請受信時のゲーム進行処理のフローチャートについて説明する。当該フローチャートの処理は、救助要請を受けた場合に開始される。

まず、救助要請情報が受信される（Ｓ２１）。次に、受信した救助要請情報の時刻情報からの経過時間が救助制限時間以内であるか否かが判別される（Ｓ２２）。救助制限時間を超えていた場合（Ｓ２２：ＮＯ）、救助要請情報に基づいてゾンビとしてのキャラクタ（敵キャラクタ）が生成されて（Ｓ２９）、救助要請受信時のゲーム進行処理が終了される。一方、救助制限時間以内であった場合（Ｓ２２：ＹＥＳ）、救助要請情報に基づいて影としてのキャラクタが生成される（Ｓ２３）。

次に、受信した救助要請情報の時刻情報からの経過時間が救助制限時間を超えたか否かが判別される（Ｓ２４）。救助制限時間を超えた場合（Ｓ２４：ＹＥＳ）、影としてのキャラクタが消去され、救助要請情報に基づいてゾンビとしてのキャラクタ（敵キャラクタ）が生成されて（Ｓ３０）、救助要請受信時のゲーム進行処理が終了される。一方、救助制限時間を超えていない場合（Ｓ２４：ＮＯ）、救助が完了されたか否かが判別される（Ｓ２５）。具体的には、ゲーム装置１ｂのプレイヤキャラクタが影としてのキャラクタにタッチしたか否かが判別される。救助が完了されていない場合（Ｓ２５：ＮＯ）、ステップＳ２４に戻る。すなわち、救助制限時間を超えるか（Ｓ２４：ＹＥＳ）、救助が完了されるまで（Ｓ２５：ＹＥＳ）、ステップＳ２４およびＳ２５が繰り返される。救助が完了された場合（Ｓ２５：ＹＥＳ）、救助完了情報が生成され送信されて（Ｓ２６）、報酬情報が受信されたか否かが判別される（Ｓ２７）。報酬情報が受信されるまでステップＳ２７が繰り返され（Ｓ２７：ＮＯ）、報酬情報が受信されると（Ｓ２７：ＹＥＳ）、報酬が付与されて（Ｓ２８）、救助要請受信時のゲーム進行処理が終了される。

本実施形態によると、救助要請を受けたプレイヤは、救助要請が行われてからの経過時間が救助制限時間となる前に救助を行えなかった場合や、救助要請を受けたときすでに経過時間が救助制限時間を超えていた場合に、敵キャラクタが出現するので、緊迫感を感じながらゲームを進行することができる。また、他のゲーム装置のプレイヤキャラクタを救助したり、救助してもらったりすることができるので、非同期ゲームであるにもかかわらず、プレイヤはゲームを通して他のゲーム装置のプレイヤと係り合うことができる。また、他のゲーム装置のプレイヤキャラクタの特徴を引き継いだ敵キャラクタがゲームに出現するので、他のゲーム装置のプレイヤとの係り合いをより強く意識することができる。

なお、上記実施形態では、救助制限時間が経過したときに敵キャラクタとして出現（変化）する場合について説明したが、これに限られない。敵キャラクタとなる代わりに、アイテムを奪うキャラクタや、プレイヤキャラクタの進路を塞ぐ障害物となってもよい。すなわち、ゲームの進行を阻害するオブジェクトであればよい。

上記実施形態では、救助要請情報に含まれる「倒れた時刻データ」に基づいて敵キャラクタを出現させる場合について説明したが、これに限られない。救助要請情報には図３に示す各情報以外の情報が含まれていてもよく、他のゲーム装置に出現させるキャラクタの属性を指定する情報が含まれても良い。例えば、プレイヤが自身のプレイヤキャラクタの情報に基づいた敵キャラクタを他のゲーム装置に出現させたい場合は、出現させるキャラクタの属性を敵キャラクタに指定して救助要請情報を送信するようにし、当該救助要請情報を受信したゲーム装置ではその情報に基づいて仮想ゲーム空間上に敵キャラクタを生成するようにしてもよい。

上記実施形態では、体力値の残存がなくなると救助要請を行うか否かをプレイヤが選択する場合について説明したが、プレイヤに選択させることなく救助要請を行うようにしてもよい。また、上記実施形態では、受ける救助要請をプレイヤが選択する場合について説明したが、プレイヤに選択させることなくランダムに救助要請を受けるようにしてもよい。また、仮想ゲーム空間上におけるプレイヤキャラクタから所定の距離以内で倒れた場合の救助要請をすべて受けるようにしてもよいし、現実のプレイヤの位置（ＧＰＳ機能で特定する。）から所定の距離以内にあるゲーム装置からの救助要請をすべて受けるようにしてもよい。

上記実施形態では、１人のプレイヤによって救助されたら（すなわち、救助完了情報を１件受信したら）、倒れたプレイヤキャラクタが復活する場合を説明したが、これに限られない。２人以上のプレイヤに救助されることを復活の条件としてもよい。

上記実施形態では、体力値の残存がなくなって救助要請を行った後は救助されるまでゲームを進行することができない場合について説明したが、これに限られない。救助要請を行った後も、ゲームの進行の一部のみが制限されるようにしてもよい。例えば、プレイヤキャラクタの動きが遅くなったり、レベルが大幅に低下されたり、アイテムを使えなくなるなどの制限がかけられるようにしてもよい。この場合、プレイヤはゲームを継続しながら救助を待つことができる。また、本ゲームが進行できない状態でも、他のミニゲームなどを行うことができるようにしてもよい。これらの場合、ゲームの成果に応じて、救助制限時間を延長したり短縮したりするようにしてもよい。

上記実施形態では、救助要請情報をサーバ３にアップロードする場合について説明したが、これに限られない。例えば、他のゲーム装置１にメールで送信するようにしてもよいし、すれ違い通信などで、所定の範囲内にあるゲーム装置１に送信するようにしてもよい。

上記実施形態では、アクションゲームを例に説明したが、これに限られない。例えば、アドベンチャーゲームやＲＰＧ（ロールプレイングゲーム）などのジャンルのゲームにおいても、本発明を適用することができる。また、本発明は、複数のプレイヤの操作するキャラクタ若しくはＣＰＵの制御するキャラクタがチームを組んで協同して敵キャラクタと対戦するようなゲームや、敵キャラクタとしての他のプレイヤの操作するキャラクタと対戦するようなゲームにも適用することができる。

上記実施形態では、携帯電話端末でゲームを実施する場合について説明したが、これに限られない。本発明は、例えば、携帯情報端末、パーソナルコンピュータ、携帯型ゲーム装置、家庭用ゲーム装置、および、アーケードゲーム装置などでゲームを実施する場合にも適用することができる。

本発明に係るゲームプログラムは、上述した実施形態に限定されるものではない。本発明に係るゲームプログラムの具体的な構成は、種々に設計変更自在である。

１ ゲーム装置
１１ 制御部
１１ａ ＣＰＵ（ゲーム進行制御手段、救助要請情報送信制御手段、計時手段、ゲーム終了制御手段、救助要請情報受信制御手段、キャラクタ出現制御手段、判別手段、救助完了情報送信制御手段、計時停止手段、キャラクタ変更手段）
１１ｂ ＲＯＭ
１１ｃ ＲＡＭ
１２ 描画処理部（キャラクタ出現制御手段、キャラクタ変更手段）
１３ 音声処理部
１４ 通信処理部（救助要請情報送信制御手段、救助要請情報受信制御手段、救助完了情報送信制御手段）
１５ メモリ部（プログラム記録部）
１６ Ｉ／Ｏインターフェース部
１７ 通信部（送信部、受信部）
１８ 表示部
１９ 音声出力部
２０ 操作部
２１ タッチ操作部
２ ネットワーク回線
３ サーバ

Claims (1)

1. コンピュータを、仮想ゲーム空間上でプレイヤが操作するプレイヤキャラクタを活動させるゲーム装置として機能させるためのゲームプログラムであって、
   前記コンピュータを、
   ゲームの進行を制御するゲーム進行制御手段と、
   他のコンピュータから送信された当該他のコンピュータのプレイヤキャラクタに関するプレイヤキャラクタ情報を少なくとも含む要請情報を受信部に受信させる要請情報受信制御手段と、
   前記受信部が前記要請情報を受信したときに、当該要請情報に基づいたキャラクタを前記仮想ゲーム空間上に生成させるキャラクタ生成手段と、
   前記要請情報が所定条件を満たすか否かを判断する判断手段と、
   して機能させ、
   前記キャラクタ生成手段は、前記所定条件を満たす場合、生成させるキャラクタの属性を敵キャラクタとするゲームプログラム。