(57)【要約】【課題】ゲームの場面に応じた支払い（アイテムや課金）を案内することにより、プレイを効率的に援助する。【解決手段】ゲーム空間およびゲーム空間内のオブジェクトの状態を演算してゲームを進行させ、所定時間毎に現在のゲームの状況を記述したゲーム状況データを生成する。ゲーム状況データに基づいてゲーム画面を描画して表示する。ゲーム状況データが所定の課金条件に該当しているか否かを判定する。ゲーム状況データが課金条件に該当していると判定された場合に、ゲーム進行処理手段によるゲーム状況データの生成およびゲーム画面表示手段によるゲーム画面の描画を継続しつつ、課金条件に対応する支払いを促す課金案内を報知する。【選択図】図３
2013208219.tif 000002
【特許請求の範囲】
【請求項１】
表示部が接続されるコンピュータを、
ユーザの操作によって生成された操作情報を入力する操作情報入力手段、
仮想の三次元のゲーム空間を生成するゲーム空間制御手段、
前記ゲーム空間内にプレイヤオブジェクトを生成し、前記操作情報に基づいて前記プレイヤオブジェクトを前記ゲーム空間内で活動させるプレイヤオブジェクト制御手段、
前記ゲーム空間および該ゲーム空間内のオブジェクトの状態を演算してゲームを進行させ、所定時間毎に現在のゲーム進行の状況を示すゲーム状況データを生成するゲーム進行処理手段、
前記ゲーム状況データに基づいてゲーム画面を描画して前記表示部に表示するゲーム画面表示手段、
前記ゲーム状況データが所定の課金条件に該当しているか否かを判定する状況判定手段、
前記ゲーム状況データが前記課金条件に該当していると判定された場合に、前記ゲーム進行処理手段によるゲームの進行を継続しつつ、前記課金条件に対応する支払いを促す課金案内を報知する課金案内手段、
として動作させるゲームプログラム。
【請求項２】
前記課金案内手段は、前記課金案内を前記表示部に表示する手段である請求項１に記載のゲームプログラム。
【請求項３】
前記状況判定手段は、ゲーム空間内で活動する特定オブジェクトの特定パラメータが所定値以下であるとき、前記課金条件に該当していると判定し、
前記課金条件に対応する支払いは、前記プレイヤキャラクタの前記特定パラメータを上昇させるとともに、前記プレイヤキャラクタ以外のキャラクタの前記特定パラメータ以外のパラメータを更新するアイテムの購入である請求項１または請求項２に記載のゲームプログラム。
【請求項４】
前記ゲーム進行処理手段は、前記課金案内手段が前記課金案内を報知している期間のうち少なくとも一部の期間、前記特定オブジェクトの前記特定パラメータを含むパラメータを更新しない請求項３に記載のゲームプログラム。
【請求項５】
前記コンピュータを、前記操作情報入力手段から、前記課金案内に対応した支払いを行う旨の課金操作情報が入力されたとき、その旨をサーバ装置に通知する課金通知手段、としてさらに機能させる請求項１乃至請求項４のいずれかに記載のゲームプログラム。
【請求項６】
前記課金案内手段は、前記ゲーム状況データが前記課金条件に該当していると判定された場合に、その旨をサーバ装置に通知して、該サーバ装置から前記課金案内を受信する課金案内取得手段を含む請求項１乃至請求項５のいずれかに記載のゲームプログラム。
【請求項７】
前記コンピュータを、
前記操作情報入力手段から入力された操作情報を他のゲーム装置に送信するとともに、前記他のゲーム装置から操作情報を受信する通信手段、
前記ゲーム空間内に前記他のゲーム装置に対応する第２プレイヤオブジェクトを生成し、前記他のゲーム装置から受信した操作情報に基づいて、前記第２プレイヤオブジェクトをゲーム空間内で活動させる第２プレイヤオブジェクト制御手段、
としてさらに機能させる
請求項１乃至請求項６のいずれかに記載のゲームプログラム。
【請求項８】
端末装置とサーバ装置を有するゲームシステムであって、
前記端末装置は、
ユーザの操作によって生成された操作情報を入力する操作情報入力部と、
仮想の三次元のゲーム空間を生成するゲーム空間制御部と、
前記ゲーム空間内にプレイヤオブジェクトを生成し、前記操作情報に基づいて前記プレイヤオブジェクトを前記ゲーム空間内で活動させるプレイヤオブジェクト制御部と、
前記ゲーム空間および該ゲーム空間内のオブジェクトの状態を演算してゲームを進行させ、所定時間毎に現在のゲーム進行の状況を示すゲーム状況データを生成するゲーム進行処理部と、
前記ゲーム状況データに基づいてゲーム画面を描画して前記表示部に表示するゲーム画面表示部と、
前記ゲーム状況データが所定の課金条件に該当しているか否かを判定する状況判定部と、
前記ゲーム状況データが前記課金条件に該当していると判定された場合に、前記ゲーム進行処理部によるゲームの進行を継続しつつ、前記課金条件に対応する支払いを促す課金案内を報知する課金案内部と、
前記操作情報入力部から、前記課金案内に対応した支払いを行う旨の課金操作情報が入力されたとき、その旨を前記サーバ装置に通知する課金通知部と、
を備え、
前記サーバ装置は、前記端末装置から前記課金操作情報が入力された旨の通知を受信したとき、当該課金操作情報に基づく決済処理を行う課金処理部を備えた
ゲームシステム。
【請求項９】
前記端末装置の前記課金案内部は、前記ゲーム状況データが前記課金条件に該当していると判定された場合に、その旨を前記サーバ装置に通知して、前記サーバ装置から前記課金案内を受信する課金案内取得部を含み、
前記サーバ装置は、前記端末装置から前記ゲーム状況データが前記課金条件に該当した旨の通知を受信したとき、そのときのゲーム状況データに応じた課金を案内する課金案内を、前記端末装置に対して送信する
請求項８に記載のゲームシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ゲーム中におけるアイテム販売および課金に関する。
【背景技術】
【０００２】
現在発表されているビデオゲームでは、キャラクタにアイテムを取得させることによって、ゲームの展開をより複雑に、且つ、ユーザにとって面白いものにしている。また、アイテムを有料にすることによって、無駄なアイテムの使用を無くし、ゲームにリアリティを持たせる提案もなされている（特許文献１）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−３４０６５６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
また、特許文献１には、ゲーム実行中にアイテムメューを表示させてアイテムの購入を可能にすることも記載されているが、ゲーム進行において発生する所定条件に基づいたアイテム購入若しくは課金をプレイヤに案内することは記載されていなかった。
【０００５】
本発明は、ゲームの場面に応じたアイテム、課金を案内することにより、プレイを効率的に援助するゲームプログラムおよびゲームシステムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明の第１の側面によって提供されるゲームプログラムは、表示部が接続されるコンピュータを、ユーザの操作によって生成された操作情報を入力する操作情報入力手段、仮想の三次元のゲーム空間を生成するゲーム空間制御手段、前記ゲーム空間内にプレイヤオブジェクトを生成し、前記操作情報に基づいて前記プレイヤオブジェクトを前記ゲーム空間内で活動させるプレイヤオブジェクト制御手段、前記ゲーム空間および該ゲーム空間内のオブジェクトの状態を演算してゲームを進行させ、所定時間毎に現在のゲーム進行の状況を示すゲーム状況データを生成するゲーム進行処理手段、前記ゲーム状況データに基づいてゲーム画面を描画して前記表示部に表示するゲーム画面表示手段、前記ゲーム状況データが所定の課金条件に該当しているか否かを判定する状況判定手段、前記ゲーム状況データが前記課金条件に該当していると判定された場合に、前記ゲーム進行処理手段によるゲームの進行を継続しつつ、前記課金条件に対応する支払いを促す課金案内を報知する課金案内手段、として動作させることを特徴とする。
【０００７】
上記発明において、前記課金案内手段を、前記課金案内を前記表示部に表示する手段としてもよい。
【０００８】
上記発明において、前記状況判定手段は、ゲーム空間内で活動する特定オブジェクトの特定パラメータが所定値以下であるとき、前記課金条件に該当していると判定し、前記課金条件に対応する支払いは、前記プレイヤキャラクタの前記特定パラメータを上昇させるとともに、前記プレイヤキャラクタ以外のキャラクタの前記特定パラメータ以外のパラメータを更新するアイテムの購入であってもよい。
【０００９】
上記発明において、前記ゲーム進行処理手段が、前記課金案内手段が前記課金案内を報知している期間のうち少なくとも一部の期間、前記特定オブジェクトの前記特定パラメータを含むパラメータを更新しないようにしてもよい。
【００１０】
上記発明において、前記コンピュータを、前記操作情報入力手段から、前記課金案内に対応した支払いを行う旨の課金操作情報が入力されたとき、その旨をサーバ装置に通知する課金通知手段、としてさらに機能させてもよい。
【００１１】
上記発明において、前記課金案内手段に、前記ゲーム状況データが前記課金条件に該当していると判定された場合に、その旨をサーバ装置に通知して、該サーバ装置から前記課金案内を受信する課金案内取得手段を含めてもよい。
【００１２】
上記発明において、前記コンピュータを、前記操作情報入力手段から入力された操作情報を他のゲーム装置に送信するとともに、前記他のゲーム装置から操作情報を受信する通信手段、前記ゲーム空間内に前記他のゲーム装置に対応する第２プレイヤオブジェクトを生成し、前記他のゲーム装置から受信した操作情報に基づいて、前記第２プレイヤオブジェクトをゲーム空間内で活動させる第２プレイヤオブジェクト制御手段、としてさらに機能させてもよい。
【００１３】
本発明の第２の側面によって提供されるゲームシステムは、端末装置とサーバ装置を有するゲームシステムであって、前記端末装置は、ユーザの操作によって生成された操作情報を入力する操作情報入力部と、仮想の三次元のゲーム空間を生成するゲーム空間制御部と、前記ゲーム空間内にプレイヤオブジェクトを生成し、前記操作情報に基づいて前記プレイヤオブジェクトを前記ゲーム空間内で活動させるプレイヤオブジェクト制御部と、前記ゲーム空間および該ゲーム空間内のオブジェクトの状態を演算してゲームを進行させ、所定時間毎に現在のゲーム進行の状況を示すゲーム状況データを生成するゲーム進行処理部と、前記ゲーム状況データに基づいてゲーム画面を描画して前記表示部に表示するゲーム画面表示部と、前記ゲーム状況データが所定の課金条件に該当しているか否かを判定する状況判定部と、前記ゲーム状況データが前記課金条件に該当していると判定された場合に、前記ゲーム進行処理部によるゲームの進行を継続しつつ、前記課金条件に対応する支払いを促す課金案内を報知する課金案内部と、前記操作情報入力部から、前記課金案内に対応した支払いを行う旨の課金操作情報が入力されたとき、その旨を前記サーバ装置に通知する課金通知部と、を備え、前記サーバ装置は、前記端末装置から前記課金操作情報が入力された旨の通知を受信したとき、当該課金操作情報に基づく決済処理を行う課金処理部を備えたことを特徴とする。
【００１４】
上記発明において、前記端末装置の前記課金案内部が、前記ゲーム状況データが前記課金条件に該当していると判定された場合に、その旨を前記サーバ装置に通知して、前記サーバ装置から前記課金案内を受信する課金案内取得部を含み、前記サーバ装置は、前記端末装置から前記ゲーム状況データが前記課金条件に該当した旨の通知を受信したとき、そのときのゲーム状況データに応じた課金を案内する課金案内を、前記端末装置に対して送信するものであってもよい。
【発明の効果】
【００１５】
この発明によれば、ゲーム中でゲームの進行が課金条件に該当したとき、その課金条件を解消するための支払い（アイテムなど）を案内するため、ユーザによるプレイを効率的に援助することが可能になる。
【図面の簡単な説明】
【００１６】
【図１】携帯端末装置およびサーバ装置を有するゲームシステムの構成図である。
【図２】携帯端末装置のブロック図である。
【図３】携帯端末装置とゲームプログラムの協働で構成されるゲーム装置（通常モード）の機能ブロック図である。
【図４】ゲーム画面の一例を示す図である。
【図５】サーバ装置に設けられるユーザデータベースの一例を示す図である。
【図６】サーバ装置に設けられるゲームデータベースの一例を示す図である。
【図７】携帯端末装置とゲームプログラムの協働で構成されるゲーム装置（アイテム販売モード）の機能ブロック図である。
【図８】アイテム案内画面の一例を示す図である。
【図９】ゲーム装置およびサーバ装置の動作を示すフローチャートである。
【図１０】ゲーム装置およびサーバ装置の動作を示すフローチャートである。
【図１１】ゲーム装置の動作を示すフローチャートである。
【図１２】ゲーム装置の動作を示すフローチャートである。
【図１３】ゲーム装置およびサーバ装置の動作を示すフローチャートである。
【図１４】ゲームシステムの他の構成図である。
【発明を実施するための形態】
【００１７】
図１は、携帯端末装置１およびゲームサーバ３を有するシステムの構成を示す図である。また、図２は、携帯端末装置１のブロック図である。携帯端末装置１は、たとえば携帯電話機やスマートフォンであり、他の携帯端末装置１とピア・ツー・ピア（Ｐｅｅｒ  ｔｏ  Ｐｅｅｒ）またはブルートゥース（Ｂｌｕｅｔｏｏｔｈ（登録商標））で接続されるとともに、ネットワーク２を介してゲームサーバ３と接続される。ネットワーク２は、たとえば携帯電話通信網である。
【００１８】
携帯端末装置１は、内蔵のＲＯＭ２２またはメモリカード５に保存されているゲームプログラム５０との協働によって、図３、図７に示すようなゲーム装置１００を構成し、他の携帯端末装置１と通信することによってゲームを実行する。ここで実行されるゲームは、複数のキャラクタが対戦するサバイバルゲームである。このゲームでは、それぞれ１台の携帯端末装置１（プレイヤ）によって操作される１人〜３人のキャラクタ（１人〜３人のプレイヤ）でチームが構成され、２チームが対戦する。すなわち、最大６台の携帯端末装置１（プレイヤ）がゲームに参加することができる。この最大６台が参加するゲームの単位はセッションと呼ばれ、ゲームサーバ３が、セッションのマッチングを行う。ゲームサーバ３は、この実施形態のゲームを含む複数のオンラインゲームを提供するゲーム運営会社によって設置されたものである。
【００１９】
ゲームサーバ３には、自分でセッションを作成することを要求する携帯端末装置１（ホスト１Ａ）からセッション作成要求が送られてくる。また、他の携帯端末装置１（ホスト１Ａ）が作成したセッションに参加を希望する携帯端末装置（ゲスト１Ｂ）からセッション参加要求が送られてくる。ゲームサーバ３は、１台のホスト１Ａと１〜５台のゲスト１Ｂとを組み合わせるマッチング処理を行い、セッション６を編成する。セッション６が編成された旨は、そのセッション６に参加するホスト１Ａおよび各ゲスト１Ｂに通知され、それぞれの携帯端末装置１（１Ａ，１Ｂ）は、ピア・ツー・ピアまたはブルートゥースで相互に通信し合いながらゲームを進めてゆく。
【００２０】
図２において、携帯端末装置１は、バス２６上に、制御部２０、操作部３０、メディアインタフェース３１および無線通信回路部３２を有している。制御部２０は、ＣＰＵ２１、ＲＯＭ（フラッシュメモリ）２２、ＲＡＭ２３、画像プロセッサ２４および音声プロセッサ２５を含んでいる。画像プロセッサ２４には、ビデオＲＡＭ（ＶＲＡＭ）４０が接続され、ＶＲＡＭ４０には表示部４１が接続されている。表示部４１は、液晶のディスプレイを含み、電話番号やゲーム画面などを表示する。音声プロセッサ２５には、Ｄ／Ａコンバータを含むアンプ４２が接続され、アンプ４２にはスピーカおよびイヤホン端子が接続されている。
【００２１】
無線通信回路部３２は、携帯電話通信網２を介して、音声通話およびデータ通信を行う。データ通信によってネットワークゲームのオンライン処理がなされる。
【００２２】
操作部３０は、表示部４１上に形成されたタッチパネルであってもよく、テンキー、十字キーなどのボタンスイッチ群から構成されていてもよい。操作部３０は、ユーザ（プレイヤ）の操作を受け付けて、その操作内容に応じた操作信号を発生する。発生した操作信号はＣＰＵ２１に入力される。
【００２３】
メディアインタフェース３１にはメモリカード５が接続される。メモリカード５は、たとえばマイクロＳＤカードである。ゲームプログラム５０は、無線通信回路部３２によってゲームサーバ３２からダウンロードされたのち、メモリカード５またはＲＯＭ２２に保存される。ゲームプログラム５０は、プログラム本体のほか、ゲームの進行に必要なアイテム画像などのゲームデータを含んでいる。
【００２４】
ＲＡＭ２３には、ＣＰＵ２０がゲームプログラム５０を実行する際に使用されるワークエリアが設定される。ワークエリアには、この携帯端末装置１でコントロールされるプレイヤキャラクタＰＣに関する各種パラメータなどが保存される。ＲＯＭ２２には、この携帯端末装置１の通話やゲームプログラム５０を含むアプリケーションプログラムを実行するための基本プログラムが記憶されている。また、ＲＯＭ２２はフラッシュメモリであり、基本プログラムのほか、ダウンロードされたアプリケーションプログラムなどを記憶することも可能である。
【００２５】
画像プロセッサ２４は、待ち受け画面や電話番号等を描画して表示部４１に表示するが、ゲーム映像を生成可能なＧＰＵ（Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ，グラフィックス・プロセッシング・ユニット）を備えている。画像プロセッサ２４は、ＣＰＵ２１の指示に従ってゲーム空間を生成し、このゲーム空間を仮想のカメラで撮影した画像をゲーム画像としてＶＲＡＭ４０上に描画する。
【００２６】
音声プロセッサ２５は、通話音声をエンコード／デコードするＤＳＰ（Ｄｉｇｉｔａｌ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｏｒ：デジタル・シグナル・プロセッサ）を有している。また、ＤＳＰはゲーム音声を生成する。音声プロセッサ２５は、デコード／生成した音声をアンプ４２に出力する。アンプ４２は、この音声信号を増幅してスピーカ１６およびイヤホン端子１７に出力する。
【００２７】
図３および図７の機能ブロック図を参照して、携帯端末装置１（ハードウェア）にゲームメディア５のゲームプログラム５０が読み込まれることによって実現されるゲーム装置１００について説明する。図３は通常モード１００Ａの機能ブロック図であり、図７はゲーム装置１００のアイテム販売モード１００Ａの機能ブロック図である。上述したように、本発明のゲームシステムは、ゲーム装置１００およびゲームサーバ３によって構成される。
【００２８】
ゲームプログラム５０が携帯端末装置１に読み込まれることによって実現されるゲーム装置１００は、通常モード１００Ａにおいては、操作データ入力部１２０、ゲーム進行処理部１１０、通信部１３０、状況判定部１４０、および、ゲーム画面描画部１５０を有している。操作データ入力部１２０は、制御部２０、操作部３０およびゲームプログラム５０の協働によって実現される。ゲーム画面描画部１５０は、制御部２０、ＶＲＡＭ４０、表示部４１およびゲームプログラム５０の協働によって実現される。
【００２９】
なお、ホスト１Ａとなる携帯端末装置１は、このゲーム装置１００用のプログラムに加えてホスト用のプログラムを起動させ、セッションに参加している携帯端末装置１（ゲーム装置１００）の間のゲーム進行の同期をとる処理動作を実行する。
【００３０】
操作データ入力部１２０は、ユーザによる操作部３０の操作によって発生した操作信号を取り込み、操作データ２００としてゲーム進行処理部１１０に入力する。通信部１３０はホスト１Ａと通信し、ホスト１Ａからゲーム同期データ２１０を受信してゲーム進行処理部１１０に入力するとともに、ゲーム進行処理部１１０が出力したローカルデータ２３０をホスト１Ａに送信する。
【００３１】
ゲーム進行処理部１１０は、操作データ２００、ゲーム同期データ２１０および直前のゲーム状況データ２２０などに基づいてゲームの進行やゲーム画像の描画に関する内容を演算し、演算結果であるデータ群を現在のゲーム状況データ２２０として出力する。ここで、ゲーム状況データ２２０とは、ゲームの場面や、プレイヤキャラクタＰＣのスタミナ値ＳＴ、活動値ＨＰなど各種パラメータの値、現在位置、残弾数、宝箱オブジェクトなどとの距離などを含む「ゲーム状況」を表すデータである。また、ゲーム状況に含まれるゲームの場面とは、ゲームステージの属性、難易度、敵味方の数、および、ゲームの戦況などを含む情報である。
【００３２】
ゲーム進行処理部１１０が行う演算は、たとえば、入力された操作データ２００に応じたプレイヤキャラクタの動作の演算、ゲーム同期データ２１０や時間経過に応じた他のキャラクタの動作の演算、時間経過に伴う環境の変化などである。
【００３３】
ゲーム進行処理部１１０が出力するローカルデータ２３０は、ゲーム状況データ２２０から直前のゲーム状況データ２２０およびゲーム同期データ２１０の内容を消去した差分データである。すなわち、ゲーム状況データ２２０は、現在のゲームの状況を再現するための全ての情報を含む大きいデータであるため、ゲームの進行において、この携帯端末装置１（ゲーム装置１００）内で発生した変化分を抽出したローカルデータ２３０のみをホスト１Ａに送信するようにしている。また、ホスト１Ａから送られてくるゲーム同期データ２１０は、このセッション６に参加している全ての携帯端末装置１（ゲーム装置１００）から受信したローカルデータ２３０を集約してゲームシステム全体におけるゲームの進行をまとめて表したデータである。ホスト１Ａは、ゲーム同期データ２１０を、セッション６に参加している全ての携帯端末装置１（ゲーム装置１００）に配信することにより、全携帯端末装置１（ゲーム装置１００）で同期してゲームが進行するようにコントロールする。
【００３４】
ゲーム進行処理部１１０は、ゲーム画面の１フレーム毎に、直前のフレームのゲーム状況データ２２０を基礎にして操作データ２００および時間経過を変数として演算を行い、現在のゲーム状況データ２２０を生成して出力する。このゲーム状況データ２２０は、ゲーム画面描画部１５０に入力される。ゲーム画面描画部１５０は、ゲーム状況データ２２０に基づいてゲーム画面を描画し表示部４１に表示する。ゲーム装置１００の以上の処理により、ユーザによる操作部３０の操作および時間経過に応じてゲームが進行し、そのゲームの進行に伴って変化するゲーム画面が表示部４１に表示される。
【００３５】
上述したように本実施形態のゲームシステムで実行されるゲームは、複数のキャラクタが対戦するサバイバルゲームであり、ゲーム画面は、たとえば図４に示すようなものである。このゲーム画面５００は、ゲーム空間内に岩山や建物などの障害物があり、その間に、キャラクタ５０１、５０２、５０３が存在する画面である。このうち中央に大きく背中向きに表示されているキャラクタ５０１がこの携帯端末装置１（ゲーム装置１００）でコントロールされるキャラクタ、すなわちプレイヤキャラクタＰＣである。また、キャラクタ５０２はキャラクタ５０１（プレイヤキャラクタＰＣ）と同じチームに属する仲間キャラクタＭＣであり、キャラクタ５０３は相手チームに属する敵キャラクタＥＣである。キャラクタ５０１、５０２、５０３は、それぞれ対応する携帯端末装置（ゲーム装置１００）によってコントロールされ、ゲーム空間内を移動したり、敵のキャラクタと闘ったりする。ここで、携帯端末装置１（ゲーム装置１００）によってコントロールされるとは、その携帯端末装置１（ゲーム装置１００）を操作するユーザが入力した操作データによってコントロールされゲーム空間内で活動すること、および、携帯端末装置１（ゲーム装置１００）のＡＩによってコントロールされゲーム空間内で活動することの両方を含んでいる。
【００３６】
プレイヤの操作などによりゲームが開始されると、まず、メインメニューが表示部４１に表示される。メインメニューには複数の個別メニューが表示されている。プレイヤが、メインメニューから所望の個別メニューを選択することにより、自身のステータスを確認したり、自身がゲーム中のバトルで操作するキャラクタを選択したり、その選択したキャラクタにアイテム、武器などを装備させたりすることができる。また、武器などを強化したり、回復スプレーなどのアイテムを購入しゲーム中のバトルに備えることができる。プレイヤは、メインメニューから「バトル（３ＶＳ３）」を選択することにより、バトルを開始することができる。また、バトルにおいて、スタミナ値が０になったときは、バトルのリザルト画面を表示してメインメニューに戻る。なお、メインメニューが表示された時点からセッション６からの離脱またはセッション６の解消までゲームが継続するが、このゲーム中で敵キャラクタと戦闘する場面、いわゆるゲーム画面が表示される場面を、特に「バトル」と呼ぶ。
【００３７】
このようなゲームにおいて、図６に示すように、キャラクタには体力値ＨＰ、スタミナ値ＳＴを含む各種のパラメータが設定されている。体力値ＨＰは相手の攻撃に耐えられる程度を示すパラメータであり、スタミナ値ＳＴはキャラクタの活動余力を示すパラメータである。キャラクタが活動するとスタミナ値ＳＴは徐々に減少してゆき、スタミナ値ＳＴが０になると回復するまで動けなくなる。また、スタミナ値が０になったキャラクタを疲労状態として、疲労して身動きがとれないようなモーションを行わせる。このとき、回復スプレーなどのアイテムがあるとスタミナ値ＳＴを例えば最大値まで回復させることができ、キャラクタを即座にゲームに復帰させることができる。回復スプレーなどのアイテムは、プレイヤが、自己のプレイヤキャラクタＰＣに事前に入手させておき、プレイヤキャラクタＰＣのスタミナ値ＳＴが最大値より小さい値（例えば０）まで減少したとき、このアイテムを使用してスタミナ値ＳＴを回復させるが、プレイヤキャラクタＰＣのスタミナ値が０になってしまったときにスタミナ値を回復させるアイテムを保持していないと、これ以上ゲーム空間上での活動ができなくなり、バトルを続けられなくなる。スタミナ値は時間（例えば実時間）の経過などに基づいて増加（補填）してもよいが、ゲーム中にスタミナ値が０になったときは、回復スプレーを使用しなければゲームを続けられなくなる。
【００３８】
そこで、この実施形態では、このような場合に、ゲーム空間を表示するゲーム画面５００とは別にアイテム案内画面５１０（図８参照）を表示して、アイテムの購入を可能にする。これにより、アイテムが無いときにプレイヤキャラクタＰＣが動けなくなっても、ゲームへの復帰を可能にしている。
【００３９】
状況判定部１４０は、ゲーム状況データ２２０を分析して、プレイヤにアイテムを提示する状況か否かを判定する。この実施形態では、プレイヤキャラクタＰＣのスタミナ値ＳＴが０になったか否かを判定する。この条件が満たされた場合には、通信部１３０を介してゲームサーバ３にアイテム選択要求購入情報２４０を送信するとともに、図７に示すアイテム販売モード１００Ｂを起動する。
【００４０】
また、アイテム販売モード１００Ｂを起動する条件として、プレイヤキャラクタＰＣのスタミナ値ＳＴが０になった場合に、プレイヤキャラクタＰＣがアイテムを所持しているか否かをさらに判断し、所持していない場合に起動するようにしてもよい。また、この実施形態では、スタミナ値ＳＴの値に基づいてアイテム販売モード１００Ｂを起動しているが、体力値ＨＰ、やプレイ時間などに基づいてアイテム販売モード１００Ｂを起動してもよい。
【００４１】
図５、図６は、ゲームサーバ３に設けられるユーザデータベース６００およびゲームデータベース６１０を示す図である。なお、ゲームデータベース６１０は、個別のセッション６を管理するホスト１Ａにも設けられる。
【００４２】
ユーザデータベース６００は、このゲームサーバ３に登録しているユーザのレコード６０１が登録されるデータベースである。ユーザのレコード６０１には、ユーザＩＤ、ユーザ名のほか、このユーザがゲーム運営会社に予納している金額（コイン数）が記憶される。
【００４３】
ゲーム運営会社が提供するゲームをしようとするユーザは、このゲーム運営会社のサイトにアクセスして自己の情報を登録、且つ、所定の金額を予納してユーザＩＤを取得する。登録された（ユーザＩＤを取得した）ユーザは、しようとするゲームのゲームプログラムをダウンロードして携帯端末装置１をゲーム装置１００に構成し、ゲームサーバ３にアクセスしてゲームにエントリーすることによって、プレイヤとしてゲームを行うことができる。なお、サーバ上でゲームを行うブラウザゲームの場合や、ブルーレイディスクなどの記憶媒体からゲームプログラムを読み込む場合には、ゲームプログラムをダウンロードしなくてもよい。
【００４４】
ゲームデータベース６１０は、各セッションを管理するデータを記憶するデータベースである。ゲームデータベース６１０には、ゲームプレイヤテーブル６１１およびアイテムテーブル６１３が設けられている。
【００４５】
上述したように、この実施形態のゲームは、最大３対３のキャラクタが対戦するサバイバルゲームである。このため、ゲームプレイヤテーブル６１１には、６プレイヤ分のレコード６１２が設定される。各レコード６１２には、プレイヤとしてエントリーしたユーザのユーザＩＤ、操作するゲーム内のキャラクタ（キャラクタ名）、そのキャラクタが属するチーム（Ａ／Ｂ）、現在の活動値ＨＰ、現在のスタミナ値ＳＴ、および、このキャラクタが現在所持しているアイテム（アイテム番号）などが記憶される。
【００４６】
アイテムテーブル６１３には、このゲームで提供される複数のアイテムの情報を記憶するレコード６１４が記憶される。各レコード６１４には、アイテム番号、アイテム名、価格、画像データ（ファイル名）、および、このアイテムの機能などが記憶される。携帯端末装置１（ゲーム装置１００）からアイテム選択要求通知を受信したときは、このアイテムテーブル６１３に登録されているアイテムのなかから、その通知の状況に最適なものが選択される。
【００４７】
携帯端末装置１（ゲーム装置１００）は、上記ユーザデータベース６００およびゲームプレイテーブル６１１のうち、少なくとも自装置のユーザに関するレコードは、ローカルに記憶している。
【００４８】
図７は、ゲーム装置１００のアイテム販売モード１００Ｂの構成を示す図である。アイテム販売モード１００Ｂは、図３に示した通常モード１００Ａによって起動され、通常モード１００Ａと並行して動作する。アイテム販売モード１００Ｂは、通常モード１００Ａによるゲームの進行中に、ゲーム状況が、ある条件に該当したとき、そのゲーム状況に応じたアイテムをプレイヤに提示し、プレイヤキャラクタＰＣにそのアイテムを取得させてゲームを上手く有利に進行させることができるよう支援する機能である。またさらに、有料のアイテムを提示して購入を促すことにより、ゲーム運営会社にとってはアイテムの販売促進にもつながる利点がある。
【００４９】
アイテム販売モード１００Ｂは、操作データ入力部１２０、通信部１３０、アイテム案内処理部４１０、および、アイテム案内画面描画部４２０を有している。操作データ入力部１２０は、制御部２０、操作部３０およびゲームプログラム５０の協働によって実現される。アイテム案内画面描画部４２０は、制御部２０、ＶＲＡＭ４０、表示部４１およびゲームプログラム５０の協働によって実現される。
【００５０】
図３の通常モードのゲーム装置１００Ａにおいて、ゲームサーバ３は、状況判定部１４０からアイテム選択要求通知２４０を受信する。アイテム選択要求通知２４０を受信したゲームサーバ３は、アイテムテーブル６１３から最適のアイテムを選択し、選択したアイテムのアイテム情報２７０をゲーム装置（アイテム販売モード）１００Ｂに送信する。なお、アイテムの選択はゲーム装置１００がローカルで行ってもよい。
【００５１】
アイテム販売モード１００Ｂでは、通信部１３０でアイテム情報２７０を受信してアイテム案内処理部４１０に入力する。アイテム案内処理部４１０は、このアイテム情報２７０に基づき、アイテム案内画面５１０を構築するためのＸＭＬファイルを作成し、このＸＭＬファイルをアイテム案内画面描画部４２０に入力する。アイテム案内画面描画部４２０は、入力されたＸＭＬファイルに基づいてアイテム案内画面５１０（図８参照）を描画し、表示部４１に表示する。
【００５２】
図８にアイテム案内画面の一例を示す。このアイテム案内画面５１０には、現在のスタミナ値ＳＴ（＝０）５１１、ゲームサーバ３によって選択されたアイテムである回復スプレーの画像５１２、このアイテムの効果（スタミナ値ＳＴが０から３００に回復する旨）５１３、このアイテムの価格（１００コイン）５１４、プレイヤの現在の所持コイン数（１０００コイン）５１５、回復スプレーの購入操作を受け付ける回復アイテム購入アイコン５１６、および、画面表示を直前の画面にもどす戻るアイコン５１７が表示される。
【００５３】
プレイヤが図８の回復アイテム購入アイコン５１６を選択すると、図７の操作データ入力部１２０からアイテム購入操作の操作データ２００がアイテム案内処理部４１０に入力される。アイテム案内処理部４１０は、アイテム購入操作の操作データ２００が入力されると、通信部１３０を介してゲームサーバ３に対して購入情報２８０を送信する。ゲームサーバ３では、この購入情報２８０に応じて、ユーザデータベース６００に記憶されている予納金額からアイテム価格分を減算する課金処理が行われる。さらに、アイテム案内処理部４１０は、回復スプレーが購入された旨の操作結果情報２９０を、通常モード１００Ａのゲーム進行処理部１１０に対して送信する。一方、プレイヤが、回復アイテム購入アイコン５１６を操作しなかった場合、または、ゲームを終了する旨の操作をした場合、アイテム案内処理部４１０は、アイテムが購入されなかった旨の操作結果情報２９０をゲーム進行処理部１１に対して送信する。ゲーム進行処理部１１０は、入力された操作結果情報２９０に応じたゲーム進行処理を行う。
【００５４】
なお、この実施形態では、ゲームサーバ３に記憶されている予納金額を減算することで課金処理を行ったが、課金をゲームサーバ３で行わず、ゲーム装置１００に課金処理部４１０Ａを設けてローカルで課金処理を行うようにしてもよい。たとえば、携帯端末装置１に内蔵された電子マネー機能を用いてリアルタイムに決済するようにしてもよい。また、クレジット決済やプリペイドＩＣカードなどで決済処理をしてもよい。
【００５５】
図９〜図１３は、ゲーム装置１００、ホスト１Ａおよびゲームサーバ３の動作を示すフローチャートである。
【００５６】
図９（Ａ）は、ゲーム装置１００（通常モード１００Ａ）のゲーム進行処理動作を示すフローチャートである。この処理動作は所定時間毎に繰り返し実行される。入力された操作データ１２０、ゲーム同期データ２１０、直前のゲーム状況データ２２０および時間経過などのデータに基づいてゲームの進行状況を決定する演算を行う（Ｓ１）。この演算によって生成されたゲーム状況データ２２０をゲーム画面描画部１５０に出力するとともに（Ｓ２）、ゲーム状況データ２２０から直前のゲーム状況データ２２０およびゲーム同期データ２１０の内容を消去した差分データであるローカルデータ２３０を生成する（Ｓ３）。このローカルデータ２３０をホスト１Ａに送信する（Ｓ４）。
【００５７】
図９（Ｂ）はホスト１Ａのゲーム進行管理動作を示すフローチャートである。この処理動作は所定時間毎に繰り返し実行される。セッション６に参加しているプレイヤの携帯端末装置１（ゲーム装置１００）からローカルデータ２３０を受信する（Ｓ１０）。そして複数のローカルデータ２３０を集約してゲーム全体の進行を同期させ、ゲーム同期データ２１０を生成する（Ｓ１１）。そして、このゲーム同期データ２１０を各携帯端末装置１（ゲーム装置１００）に送信する（Ｓ１２）。これによりゲームシステム全体で同期してゲームが進行する。
【００５８】
図１０（Ａ）は、ゲーム装置１００（通常モード１００Ａ）の状況判定動作を示すフローチャートである。この処理動作は所定時間毎に繰り返し実行される。ゲーム状況データ２２０に基づいて現在の状況が、例えばプレイヤキャラクタＰＣのスタミナ値ＳＴが０になったなどのアイテムを案内する条件を満たしているかを分析する（Ｓ２０）。アイテムを案内すべき状況であると判定した場合には（Ｓ２１でＹＥＳ）、ゲームサーバ３にアイテム選択要求通知２４０を送信するとともに（Ｓ２２）、アイテム販売モード１００Ｂを起動する（Ｓ２３）。
【００５９】
上記Ｓ２０、Ｓ２１におけるアイテム案内条件の判定は、プレイヤキャラクタＰＣのスタミナ値ＳＴが０になったか否かのみでもよいが、さらに、この場合に、プレイヤキャラクタＰＣが回復アイテムを所持しているか否かの判定を加えてもよい。この場合、プレイヤキャラクタＰＣのスタミナ値ＳＴが０で所持する回復アイテム数が０であると判定した場合、Ｓ２１の判定が肯定的（ＹＥＳ）となり、Ｓ２２に進む。
【００６０】
また、アイテム案内条件は、ゲームを通じて同じである必要はなく、ゲーム状況によって変化させてもよい。たとえば、自分のチームが有利な場合と相手チームが有利な場合とで条件を変えてもよい。すなわち、スタミナ値ＳＴなどのパラメータの条件が同じであっても、他のゲームの状況に応じてアイテムが案内される場合とされない場合を生じさせてもよい。
【００６１】
図１０（Ｂ）は、ゲームサーバ３のアイテム選択動作を示すフローチャートである。この処理動作は携帯端末装置１（ゲーム装置１００）からアイテム選択要求通知２４０が送られてきたとき実行される。携帯端末装置１（ゲーム装置１００）からアイテム選択要求通知を受信すると（Ｓ２５）、その状況（たとえばプレイヤキャラクタＰＣのスタミナ値ＳＴが０）に基づき、その状況に適したアイテムを選択する（Ｓ２６）。そして、選択したアイテムの情報をアイテム情報２７０として携帯端末装置１（ゲーム装置１００）に返信する（Ｓ２７）。アイテム情報２７０は、選択したアイテムのアイテム番号のみでもよいが、アイテム案内画面５１０を構築するためのＸＭＬファイルを作成して送信してもよい。いずれの場合でもアイテム画像は、ゲームデータとして携帯端末装置１に予めダウンロードされているため改めて送信することは不要である。
【００６２】
図１１は、ゲーム装置１００のアイテム販売モード１００Ｂの動作を示すフローチャートである。ゲームサーバ３からアイテム情報２７０を受信すると（Ｓ３１）、このアイテム情報２７０に基づいてアイテム案内画面５１０を編集し（Ｓ３２）、このアイテム案内画面５１０を表示部１に表示する（Ｓ３３）。こののち、何らかの操作があるか（Ｓ３４）、一定時間が経過するまで（Ｓ３６）待機する。操作があった場合には（Ｓ３４でＹＥＳ）、その操作が購入操作（回復アイテム購入アイコン５１６の操作）か否かを判断する（Ｓ３５）。
【００６３】
購入操作がされた場合には（Ｓ３５でＹＥＳ）、ゲームサーバ３に購入情報２８０を送信する（Ｓ４０）。ゲームサーバ３では、図１３（Ａ）に示す販売処理を行い、販売処理が終了すると（課金が正常に完了すると）携帯端末装置１（ゲーム装置１００）にその旨を返信する。この返信を受信すると、通常モード１００Ａのゲーム進行処理部１１０にアイテムが購入された旨を通知し（Ｓ４１）、他の携帯端末装置１にアイテムを購入した旨を通知し（Ｓ４２）、アイテム案内画面５１０を消去して、表示部４１の表示をゲーム画面５００にもどす（Ｓ４３）。
【００６４】
一方、操作が購入操作以外の操作、たとえばゲーム終了操作などであった場合（Ｓ３５でＮＯ）、または何も操作が行われないまま一定時間が経過した場合（Ｓ３６でＹＥＳ）には、アイテムが購入されなかった旨をゲーム進行処理部１１０に通知し（Ｓ４４）、アイテム案内画面５１０を消去する（Ｓ４５）。この場合、図１２で説明するように、通常モード１００Ａでは、表示部４１にゲーム結果（リザルト）を表示したのちゲームを終了させる。
【００６５】
ここで、図１３（Ａ）のゲームサーバ３の販売処理について説明する。この処理動作は、携帯端末装置１（ゲーム装置１００）から購入情報２８０を受信したとき実行される。購入情報２８０を受信すると、まず課金処理を行う（Ｓ７０）。課金処理とは、ユーザデータベース６００の予納金額からこのアイテムの価格分を減算するなどの処理である。そして、課金が正常に完了すると、携帯端末装置１（ゲーム装置１００）に対して課金が完了した旨を返信する（Ｓ７１）。
【００６６】
図１２は、ゲーム進行処理部１１０が実行するゲーム進行処理のうち、プレイヤキャラクタＰＣのスタミナ値ＳＴが０になった場合の動作を取り出して説明したフローチャートである。プレイヤキャラクタＰＣのスタミナ値ＳＴが０になると、スタミナ値ＳＴが回復するまで活動できないため、プレイヤキャラクタＰＣの姿勢を疲労の状態に制御する（Ｓ５０）。疲労の状態とは、うつ伏せに倒れて動けない状態などである。こののち、プレイヤキャラクタＰＣを敵からの攻撃を受けないように（または、攻撃を受けても活動値ＨＰが減少しないように）制御して（Ｓ５１）、案内されたアイテムの購入を検討できるようにする。ただし、このときも通常モード１００Ａおよびゲームサーバ３の処理により、ゲームは通常どおり進行している。なお、Ｓ５１の処理を省き、プレイヤキャラクタＰＣが攻撃を受ける状態（攻撃を受けると活動値ＨＰが減少する状態）のまま疲労状態を継続してもよい。
【００６７】
アイテム販売モード１００Ｂによってアイテム案内画面５１０が表示されるため、アイテム販売モード１００Ｂからアイテムが購入された旨の通知を受信するか（Ｓ５２）、または、終了操作がされた旨若しくは操作がされないまま一定時間が経過した旨の通知があるまで（Ｓ５３）待機する。
【００６８】
アイテムを購入した旨の通知があると（Ｓ５２でＹＥＳ）、プレイヤの操作によりまたは自動的に購入したアイテムを使用する（Ｓ６０）。このアイテム使用の結果として、このプレイヤキャラクタＰＣのスタミナ値ＳＴを３００に回復させるとともに（Ｓ６１）、回復アイテムを使用した旨を他の携帯端末装置１（ゲーム装置１００）に送信する（Ｓ６２）。これにより、各携帯端末装置１は自身がコントロールするキャラクタが、回復アイテムを使用したキャラクタと同じチームの仲間キャラクタＭＰであった場合、その活動値ＨＰを所定値（たとえば５０程度）回復させる。こののち、プレイヤキャラクタＰＣのプロテクトを解除し（Ｓ６３）、プレイヤキャラクタＰＣのスタミナ値ＳＴが回復した旨を他の携帯端末装置１に送信する（Ｓ６４）。また、これと並行して、仲間キャラクタＭＰをコントロールする携帯端末装置１からは、その仲間キャラクタＭＰの体力値ＨＰが回復した旨の通知が送られてくる。なお、プレイヤキャラクタＰＣのスタミナ値ＳＴが０のときに回復スプレーが購入された場合には、所持アイテム欄に追加された瞬間に使用されるため、実質的に所持アイテム欄に追加登録されることはない。
【００６９】
一方、終了操作がされた旨または操作がされないまま一定時間が経過した旨の通知を受信した場合には（Ｓ５３でＹＥＳ）、プレイヤキャラクタＰＣの画像を消去して、ゲーム空間からプレイヤキャラクタＰＣを退去させる（Ｓ６５）。そしてゲームから退去する旨をローカルデータ２３０に乗せてホスト１Ａに通知し（Ｓ６６）、最終スコアなどのリザルト画面を表示して（Ｓ６７）、ゲームを終了する。ホスト１Ａは、１台の携帯端末装置１がセッション６から離脱した旨をゲームホスト３に通知して、他の携帯端末装置１の途中参加を可能にする。
【００７０】
以上のフローチャートでは、Ｓ６２、Ｓ６４およびＳ６６の通知をホスト１Ａに対し、ホストを介してセッション６に参加している他の携帯端末装置１に通知が行われるようにしているが、ゲーム装置１００がセッション６に参加している他の全ての携帯端末装置１に直接通知するようにしてよい。
【００７１】
図１３（Ｂ）は、Ｓ６３で送信されたローカルデータ２３０を受信した場合のゲームサーバ３の動作を示すフローチャートである。まず使用されたアイテムを所持アイテムから削除する（Ｓ７２）。そして、プレイヤキャラクタＰＣのスタミナ値ＳＴを回復させるとともに（Ｓ７３）、仲間キャラクタＭＰの活動値ＨＰを所定値上昇させる（Ｓ７４）。
【００７２】
このように、ゲーム中で回復アイテム（回復スプレー）を使用することにより、自分（プレイヤキャラクタＰＣ）だけでなく、他のプレイヤが操作する仲間キャラクタＭＰにもメリットを与えることができる。
【００７３】
携帯端末装置１（ゲーム装置１００）から、ゲームから退去する旨（Ｓ６５）のローカルデータ２３０を受信した場合、ホスト１Ａは、図１３（Ｃ）に示すように、ゲームデータベース６１０のゲームプレイヤテーブル６１１から、このプレイヤ（ユーザ）レコードを消去する（Ｓ７５）。これにより、ゲーム中のキャラクタが１人減るが、この状態でゲームを継続しつつ、ゲームサーバ３に対して新たなユーザのセッション６参加を受け付けるよう要求する。
【００７４】
以上のように、プレイヤキャラクタＰＣのスタミナ値ＳＴが０になった場合、一定時間内に回復アイテム購入の操作をしなければ課金が行えずバトルから退去することになる。課金を行わずにバトルから退去しても他のプレイヤはゲームを継続することができるが、プレイヤが一人減ることにより、ゲームの戦況に影響がでる。すなわち、同じチームのプレイヤは仲間キャラクタＭＰが減ることになるため不利になる。このようにゲームをチームで進行させることにより、プレイヤの課金意欲を高めることができる。また、課金案内画面の表示時間（購入可能な期限）をカウントダウン表示などすることで、プレイヤに緊張感を与えることができ、さらに強く課金を促すことができる。なお、回復アイテム購入の操作がされないまま一定時間経過してプレイヤキャラクタＰＣがゲームから退去したことにより、新たなプレイヤ（ゲーム装置）の当該バトルへの途中参加が可能になる。
【００７５】
以上説明した実施形態では、アイテム販売モードでプレイヤに案内するアイテムの選択をゲームサーバ３が行っているが、ゲーム装置１００がローカルでアイテムを選択し、ゲームサーバ３には各アイテムの価格のみを問い合わせるようにしてもよい。すなわち、ゲーム装置１００は、図１０（Ａ）のＳ２２でゲームサーバ３に対して各アイテムの価格リストを要求し、図１１のＳ３１でアイテムの選択を行う。ゲームサーバ３は、図１０（Ｂ）の動作で各アイテムの価格リストを返信する。また、各アイテムの価格を変更しない場合には、ゲーム装置１００が記憶している価格でアイテム販売モードを実行すればよいため、図１０（Ａ）のＳ２２の動作、図１０（Ｂ）の全動作、および、図１１のＳ３１の動作は不要になる。また、バトル開始前にゲームサーバ３から価格リストを受信するようにしてもよく、この場合にも、図１０（Ａ）のＳ２２の動作、図１０（Ｂ）の全動作、および、図１１のＳ３１の動作は不要になる。
【００７６】
上記実施形態では、プレイヤキャラクタＰＣのスタミナ値ＳＴが０になったとき、アイテム案内画面５１０を表示するようにしているが、アイテム案内画面５１０の表示タイミングは、これに限定しない。ゲーム中でプレイヤが援助を必要とするであろう場面でアイテム案内画面５１０を表示するようにすればよい。たとえば、プレイヤキャラクタＰＣが宝箱に近づいた場合に、アイテムとして鍵を案内する画面を表示するようにしてもよい。ここで、「宝箱に近づく」とは、宝箱オブジェクトとプレイヤキャラクタＰＣとの距離が所定値以下になった場合や、プレイヤキャラクタＰＣの宝箱を開ける動作を検出した場合などである。この場合、プレイヤキャラクタＰＣ（プレイヤ）が鍵を購入しなくても、このプレイヤキャラクタＰＣがゲームから退場する訳ではない。
【００７７】
また、回復スプレーや鍵以外に、その場に応じた武器や防具を案内するようにしてもよい。たとえば、プレイヤキャラクタＰＣの行動履歴や対戦しようとしている相手キャラクタの特徴に基づき、相手キャラクタを効率的に攻撃できる武器や、プレイヤキャラクタＰＣの弱点や相手キャラクタの得意技を防ぐ防具を適宜案内するようにしてもよい。
【００７８】
ゲーム中にキャラクタがマーケットに赴いて、アイテムを購入することができるゲームもあるが、本発明はこれとは異なり、戦闘や競争の場面で適宜アイテムの購入が案内されるものである。アイテム案内画面５１０で案内されるアイテムは、マーケットで購入可能なものであってもよく、アイテム案内画面５１０のみで購入可能なものであってもよい。すなわち、通常のゲーム進行では手に入れることができないアイテムを、プレイヤの意思で表示させることができないアイテム案内画面５１０で案内することにより購入（課金）意欲を高めてもよい。
【００７９】
また、案内するのはアイテムに限定されない。たとえば、近道などをするために川などの難所を飛び越える能力そのものを、画面で案内し、購入させるようにしてもよい。
【００８０】
また、図８に示したアイテム案内画面５１０は、図４のゲーム画面５００に代えて表示部４１に（フルスクリーンで）表示されるものであったが、アイテム案内画面を図４のゲーム画面５００の一部にウィンドウ表示するようにしてもよい。また、ゲーム進行画像などに合成表示してもよく、アイテム案内の仕方は限定されない。
【００８１】
この実施形態では、複数のキャラクタが戦うゲームを例にあげて説明したが、本発明のオブジェクトはキャラクタに限定されず、ゲームの種類はサバイバルゲームに限定されない。たとえば、オブジェクトが自動車や宇宙船などの乗り物であり、ゲームの種類がレーシングゲームであってもよい。
【００８２】
図１に示したゲームシステムでは、セッション６のメンバーである複数の携帯端末装置１が、直接通信してゲームを進めてゆく形態であったが、図１４に示すように、セッション６のメンバーの全部または一部がネットワーク２を介して直接、または、ネットワーク２およびゲームサーバ３を介して通信する形態であってもよい。この場合、ゲーム進行の同期処理は、ホスト１Ａが担当してもよく、ホスト１Ａを定めずにゲームサーバ３が担当してもよい。
【００８３】
上の説明では、携帯端末装置１の例として、スマートフォンや携帯電話機を提示したが、本発明の携帯端末装置１は、ゲーム専用機でない装置たとえばタブレット端末などでもよく、また、ゲーム専用機であってもよい。
【符号の説明】
【００８４】
１  携帯端末装置
５  メモリカード
２０  制御部
４１  表示部
５０  ゲームプログラム
１００  ゲーム装置
１００Ａ  通常モード
１００Ｂ  アイテム販売モード
【図１】
2013208219.tif 000003
【図２】
2013208219.tif 000004
【図３】
2013208219.tif 000005
【図５】
2013208219.tif 000006
【図６】
2013208219.tif 000007
【図７】
2013208219.tif 000008
【図８】
2013208219.tif 000009
【図９】
2013208219.tif 000010
【図１０】
2013208219.tif 000011
【図１１】
2013208219.tif 000012
【図１２】
2013208219.tif 000013
【図１３】
2013208219.tif 000014
【図１４】
2013208219.tif 000015
【図４】
2013208219.tif 000016