JP2020174977A - ゲームプログラム、方法、および情報処理装置 - Google Patents

Abstract

【課題】ゲームを進行させるために使用されるパラメータの新たな回復手法をゲームに導入する。【解決手段】ゲームプログラム（１３１）は、プロセッサ（１０）に、キャラクタに関連付けられる第１パラメータが減少し得る第１ゲームパートの実行中に、第１操作に応答して、キャラクタの第１パラメータを、キャラクタの第２パラメータを消費することによって回復させる第１ステップ（Ｓ２）と、第２ゲームパートの実行中における第２操作に応答して、キャラクタの第１パラメータを、キャラクタの第２パラメータを消費することによって回復させる第２ステップ（Ｓ７）と、第２ゲームパートの実行中における第３操作に応答して、時間経過に従って自動的に回復する第３パラメータを消費することによって、キャラクタの第１パラメータと第２パラメータとを回復させる第３ステップ（Ｓ９）とを実行させる。【選択図】図３

Description

本開示は、ゲームプログラム、プログラムを実行する方法、および情報処理装置に関する。

非特許文献１に、クエストのプレイに必要な魔力（スタミナ）を回復できる従来のゲームが開示される。

黒猫のウィズ攻略ぶろぐ＠あっきー、"黒猫のウィズの魔力の回復方法一覧"、［online］、平成26年4月6日、［平成31年3月15日検索］、インターネット〈http://www.i-zm.info/archives/81>

非特許文献１の技術には、ゲームを進行させるために使用されるパラメータの回復手法に関し、改善の余地がある。

本開示の一態様は、ゲームを進行させるために使用されるパラメータの新たな回復手法をゲームに導入することを目的とする。

本開示に係るゲームプログラムは、プロセッサおよびメモリを備えるコンピュータにより実行される。ゲームプログラムは、プロセッサに、ユーザに関連付けられるキャラクタを用いるゲームプレイに従って、前記キャラクタに関連付けられる第１パラメータが減少し得る第１ゲームパートの実行中に、前記ユーザの第１操作に応答して、前記キャラクタの少なくとも何れかに関連付けられる第１パラメータを、前記キャラクタの少なくとも何れかに関連付けられる所定のスキルを発動させて当該キャラクタに関連付けられる第２パラメータを消費することによって回復させる第１ステップと、前記第１ゲームパートとは異なる第２ゲームパートの実行中におけるユーザの第２操作であって、前記第１ゲームパートにおいては実行できない第２操作に応答して、前記キャラクタの少なくとも何れかに関連付けられる前記第１パラメータを、前記キャラクタの少なくとも何れかに関連付けられる第２パラメータを消費することによって回復させる第２ステップと、前記第２ゲームパートの実行中における前記ユーザの第３操作に応答して、時間経過に従って自動的に回復する第３パラメータを消費することによって、前記キャラクタの少なくとも何れかに関連付けられる前記第１パラメータと前記第２パラメータとを回復させる第３ステップとを実行させる。

本開示の一態様によれば、ゲームを進行させるために使用されるパラメータの新たな回復手法をゲームに導入することができる。

ゲームシステムのハードウェア構成を示す図である。 ゲームシステムに含まれるサーバ及びユーザ端末の機能的構成を示すブロック図である。 ある実施の形態に係るコンピュータが、ゲームプログラムに基づいて実行する処理の流れを示すフローチャートである。 ある実施の形態に係るゲーム画面を示す図である。 ある実施の形態に係るゲーム画面を示す図である。 ある実施の形態に係るゲーム画面を示す図である。 ある実施の形態に係るゲーム画面を示す図である。 ある実施の形態に係るゲーム画面を示す図である。 ある実施の形態に係るゲーム画面を示す図である。 ある実施の形態に係るゲーム画面を示す図である。 ある実施の形態に係るゲーム画面を示す図である。 ある実施の形態に係るスタミナ表示欄およびキャラクタ表示欄を示す図である。 ある実施の形態に係るゲーム画面を示す図である。 ある実施の形態に係るメッセージを示す図である。 ある実施の形態に係るゲーム画面を示す図である。 ある実施の形態に係るゲーム画面を示す図である。

本開示に係るゲームシステムは、ユーザにゲームを提供するためのシステムである。以下、ゲームシステムについて図面を参照しつつ説明する。なお、本発明はこれらの例示に限定されるものではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が本発明に含まれることが意図される。以下の説明では、図面の説明において同一の要素には同一の符号を付し、重複する説明を繰り返さない。

（ゲームシステム１のハードウェア構成）
図１は、ゲームシステム１のハードウェア構成を示す図である。ゲームシステム１は図示の通り、複数のユーザ端末１００と、サーバ２００とを含む。各ユーザ端末１００は、サーバ２００とネットワーク２を介して接続する。ネットワーク２は、インターネット及び図示しない無線基地局によって構築される各種移動通信システム等で構成される。この移動通信システムとしては、例えば、所謂３Ｇ、４Ｇ移動通信システム、ＬＴＥ（Long Term Evolution）、及び所定のアクセスポイントによってインターネットに接続可能な無線ネットワーク（例えばWi-Fi（登録商標））等が挙げられる。

サーバ２００（コンピュータ、情報処理装置）は、ワークステーション又はパーソナルコンピュータ等の汎用コンピュータであってよい。サーバ２００は、プロセッサ２０と、メモリ２１と、ストレージ２２と、通信ＩＦ２３と、入出力ＩＦ２４とを備える。サーバ２００が備えるこれらの構成は、通信バスによって互いに電気的に接続される。

ユーザ端末１００（コンピュータ、情報処理装置）は、スマートフォン、フィーチャーフォン、ＰＤＡ（Personal Digital Assistant）、又はタブレット型コンピュータ等の携帯端末であってよい。ユーザ端末１００は、ゲームプレイに適したゲーム装置であってもよい。ユーザ端末１００は図示の通り、プロセッサ１０と、メモリ１１と、ストレージ１２と、通信インターフェース（ＩＦ）１３と、入出力ＩＦ１４と、タッチスクリーン１５（表示部１５２）と、カメラ１７と、測距センサ１８とを備える。ユーザ端末１００が備えるこれらの構成は、通信バスによって互いに電気的に接続される。なお、ユーザ端末１００は、タッチスクリーン１５に代えて、又は、加えて、ユーザ端末１００本体とは別に構成されたディスプレイ（表示部１５２）を接続可能な入出力ＩＦ１４を備えていてもよい。

また、図１に示すように、ユーザ端末１００は、１つ以上のコントローラ１０２０と通信可能に構成されることとしてもよい。コントローラ１０２０は、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の通信規格に従って、ユーザ端末１００と通信を確立する。コントローラ１０２０は、１つ以上のボタン等を有していてもよく、該ボタン等に対するユーザの入力操作に基づく出力値をユーザ端末１００へ送信する。また、コントローラ１０２０は、加速度センサ、及び、角速度センサ等の各種センサを有していてもよく、該各種センサの出力値をユーザ端末１００へ送信する。

なお、ユーザ端末１００がカメラ１７及び測距センサ１８を備えることに代えて、又は、加えて、コントローラ１０２０がカメラ１７及び測距センサ１８を有していてもよい。

ユーザ端末１００は、例えばゲーム開始時に、コントローラ１０２０を使用するユーザに、該ユーザの名前又はログインＩＤ等のユーザ識別情報を、該コントローラ１０２０を介して入力させることが望ましい。これにより、ユーザ端末１００は、コントローラ１０２０とユーザとを紐付けることが可能となり、受信した出力値の送信元（コントローラ１０２０）に基づいて、該出力値がどのユーザのものであるかを特定することができる。

ユーザ端末１００が複数のコントローラ１０２０と通信する場合、各コントローラ１０２０を各ユーザが把持することで、ネットワーク２を介してサーバ２００などの他の装置と通信せずに、該１台のユーザ端末１００でマルチプレイを実現することができる。また、各ユーザ端末１００が無線ＬＡＮ（Local Area Network）規格等の無線規格により互いに通信接続する（サーバ２００を介さずに通信接続する）ことで、複数台のユーザ端末１００によりローカルでマルチプレイを実現することもできる。１台のユーザ端末１００によりローカルで上述のマルチプレイを実現する場合、ユーザ端末１００は、さらに、サーバ２００が備える後述する種々の機能の少なくとも一部を備えていてもよい。また、複数のユーザ端末１００によりローカルで上述のマルチプレイを実現する場合、複数のユーザ端末１００は、サーバ２００が備える後述する種々の機能を分散して備えていてもよい。

なお、ローカルで上述のマルチプレイを実現する場合であっても、ユーザ端末１００はサーバ２００と通信を行ってもよい。例えば、あるゲームにおける成績又は勝敗等のプレイ結果を示す情報と、ユーザ識別情報とを対応付けてサーバ２００に送信してもよい。

また、コントローラ１０２０は、ユーザ端末１００に着脱可能な構成であるとしてもよい。この場合、ユーザ端末１００の筐体における少なくともいずれかの面に、コントローラ１０２０との結合部が設けられていてもよい。該結合部を介して有線によりユーザ端末１００とコントローラ１０２０とが結合している場合は、ユーザ端末１００とコントローラ１０２０とは、有線を介して信号を送受信する。

図１に示すように、ユーザ端末１００は、外部のメモリカード等の記憶媒体１０３０の装着を、入出力ＩＦ１４を介して受け付けてもよい。これにより、ユーザ端末１００は、記憶媒体１０３０に記録されるプログラム及びデータを読み込むことができる。記憶媒体１０３０に記録されるプログラムは、例えばゲームプログラムである。

ユーザ端末１００は、サーバ２００等の外部の装置と通信することにより取得したゲームプログラムをユーザ端末１００のメモリ１１に記憶してもよいし、記憶媒体１０３０から読み込むことにより取得したゲームプログラムをメモリ１１に記憶してもよい。

以上で説明した通り、ユーザ端末１００は、該ユーザ端末１００に対して情報を入力する機構の一例として、通信ＩＦ１３、入出力ＩＦ１４、タッチスクリーン１５、カメラ１７、及び、測距センサ１８を備える。入力する機構としての上述の各部は、ユーザの入力操作を受け付けるように構成された操作部と捉えることができる。

例えば、操作部が、カメラ１７及び測距センサ１８の少なくともいずれか一方で構成される場合、該操作部が、ユーザ端末１００の近傍の物体１０１０を検出し、当該物体の検出結果から入力操作を特定する。一例として、物体１０１０としてのユーザの手、予め定められた形状のマーカーなどが検出され、検出結果として得られた物体１０１０の色、形状、動き、又は、種類などに基づいて入力操作が特定される。より具体的には、ユーザ端末１００は、カメラ１７の撮影画像からユーザの手が検出された場合、該撮影画像に基づき検出されるジェスチャ（ユーザの手の一連の動き）を、ユーザの入力操作として特定し、受け付ける。なお、撮影画像は静止画であっても動画であってもよい。

あるいは、操作部がタッチスクリーン１５で構成される場合、ユーザ端末１００は、タッチスクリーン１５の入力部１５１に対して実施されたユーザの操作をユーザの入力操作として特定し、受け付ける。あるいは、操作部が通信ＩＦ１３で構成される場合、ユーザ端末１００は、コントローラ１０２０から送信される信号（例えば、出力値）をユーザの入力操作として特定し、受け付ける。あるいは、操作部が入出力ＩＦ１４で構成される場合、該入出力ＩＦ１４と接続されるコントローラ１０２０とは異なる入力装置（図示せず）から出力される信号をユーザの入力操作として特定し、受け付ける。

（各装置のハードウェア構成要素）
プロセッサ１０は、ユーザ端末１００全体の動作を制御する。プロセッサ２０は、サーバ２００全体の動作を制御する。プロセッサ１０及び２０は、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、及びＧＰＵ（Graphics Processing Unit）を含む。

プロセッサ１０は後述するストレージ１２からプログラムを読み出し、後述するメモリ１１に展開する。プロセッサ２０は後述するストレージ２２からプログラムを読み出し、後述するメモリ２１に展開する。プロセッサ１０及びプロセッサ２０は展開したプログラムを実行する。

メモリ１１及び２１は主記憶装置である。メモリ１１及び２１は、ＲＯＭ（Read Only Memory）及びＲＡＭ（Random Access Memory）等の記憶装置で構成される。メモリ１１は、プロセッサ１０が後述するストレージ１２から読み出したプログラム及び各種データを一時的に記憶することにより、プロセッサ１０に作業領域を提供する。メモリ１１は、プロセッサ１０がプログラムに従って動作している間に生成した各種データも一時的に記憶する。メモリ２１は、プロセッサ２０が後述するストレージ２２から読み出した各種プログラム及びデータを一時的に記憶することにより、プロセッサ２０に作業領域を提供する。メモリ２１は、プロセッサ２０がプログラムに従って動作している間に生成した各種データも一時的に記憶する。

本実施形態においてプログラムとは、ゲームをユーザ端末１００により実現するためのゲームプログラムであってもよい。あるいは、該プログラムは、該ゲームをユーザ端末１００とサーバ２００との協働により実現するためのゲームプログラムであってもよい。あるいは、該プログラムは、該ゲームを複数のユーザ端末１００の協働により実現するためのゲームプログラムであってもよい。また、各種データとは、ユーザ情報及びゲーム情報などのゲームに関するデータ、ならびに、ユーザ端末１００とサーバ２００との間又は複数のユーザ端末１００間で送受信する指示又は通知を含んでいる。

ストレージ１２及び２２は補助記憶装置である。ストレージ１２及び２２は、フラッシュメモリ又はＨＤＤ（Hard Disk Drive）等の記憶装置で構成される。ストレージ１２及びストレージ２２には、ゲームに関する各種データが格納される。

通信ＩＦ１３は、ユーザ端末１００における各種データの送受信を制御する。通信ＩＦ２３は、サーバ２００における各種データの送受信を制御する。通信ＩＦ１３及び２３は例えば、無線ＬＡＮ（Local Area Network）を介する通信、有線ＬＡＮ、無線ＬＡＮ、又は携帯電話回線網を介したインターネット通信、ならびに近距離無線通信等を用いた通信を制御する。

入出力ＩＦ１４は、ユーザ端末１００がデータの入力を受け付けるためのインターフェースであり、またユーザ端末１００がデータを出力するためのインターフェースである。入出力ＩＦ１４は、ＵＳＢ（Universal Serial Bus）等を介してデータの入出力を行ってもよい。入出力ＩＦ１４は、例えば、ユーザ端末１００の物理ボタン、カメラ、マイク、又は、スピーカ等を含み得る。サーバ２００の入出力ＩＦ２４は、サーバ２００がデータの入力を受け付けるためのインターフェースであり、またサーバ２００がデータを出力するためのインターフェースである。入出力ＩＦ２４は、例えば、マウス又はキーボード等の情報入力機器である入力部と、画像を表示出力する機器である表示部１５２とを含み得る。

ユーザ端末１００のタッチスクリーン１５は、入力部１５１と表示部１５２とを組み合わせた電子部品である。入力部１５１は、例えばタッチセンシティブなデバイスであり、例えばタッチパッドによって構成される。表示部１５２は、例えば液晶ディスプレイ、又は有機ＥＬ（Electro-Luminescence）ディスプレイ等によって構成される。

入力部１５１は、入力面に対しユーザの操作（主にタッチ操作、スライド操作、スワイプ操作、及びタップ操作等の物理的接触操作）が入力された位置を検知して、位置を示す情報を入力信号として送信する機能を備える。入力部１５１は、図示しないタッチセンシング部を備えていればよい。タッチセンシング部は、静電容量方式又は抵抗膜方式等のどのような方式を採用したものであってもよい。

図示していないが、ユーザ端末１００は、該ユーザ端末１００の保持姿勢を特定するための１以上のセンサを備えていてもよい。このセンサは、例えば、加速度センサ、又は、角速度センサ等であってもよい。ユーザ端末１００がセンサを備えている場合、プロセッサ１０は、センサの出力からユーザ端末１００の保持姿勢を特定して、保持姿勢に応じた処理を行うことも可能になる。例えば、プロセッサ１０は、ユーザ端末１００が縦向きに保持されているときには、縦長の画像を表示部１５２に表示させる縦画面表示としてもよい。一方、ユーザ端末１００が横向きに保持されているときには、横長の画像を表示部１５２に表示させる横画面表示としてもよい。このように、プロセッサ１０は、ユーザ端末１００の保持姿勢に応じて縦画面表示と横画面表示とを切り替え可能であってもよい。

カメラ１７は、イメージセンサ等を含み、レンズから入射する入射光を電気信号に変換することで撮影画像を生成する。

測距センサ１８は、測定対象物までの距離を測定するセンサである。測距センサ１８は、例えば、パルス変換した光を発する光源と、光を受ける受光素子とを含む。測距センサ１８は、光源からの発光タイミングと、該光源から発せられた光が測定対象物にあたって反射されて生じる反射光の受光タイミングとにより、測定対象物までの距離を測定する。測距センサ１８は、指向性を有する光を発する光源を有することとしてもよい。

ここで、ユーザ端末１００が、カメラ１７と測距センサ１８とを用いて、ユーザ端末１００の近傍の物体１０１０を検出した検出結果を、ユーザの入力操作として受け付ける例をさらに説明する。カメラ１７及び測距センサ１８は、例えば、ユーザ端末１００の筐体の側面に設けられてもよい。カメラ１７の近傍に測距センサ１８が設けられてもよい。カメラ１７としては、例えば赤外線カメラを用いることができる。この場合、赤外線を照射する照明装置及び可視光を遮断するフィルタ等が、カメラ１７に設けられてもよい。これにより、屋外か屋内かにかかわらず、カメラ１７の撮影画像に基づく物体の検出精度をいっそう向上させることができる。

プロセッサ１０は、カメラ１７の撮影画像に対して、例えば以下の（１）〜（５）に示す処理のうち１つ以上の処理を行ってもよい。（１）プロセッサ１０は、カメラ１７の撮影画像に対し画像認識処理を行うことで、該撮影画像にユーザの手が含まれているか否かを特定する。プロセッサ１０は、上述の画像認識処理において採用する解析技術として、例えばパターンマッチング等の技術を用いてよい。（２）また、プロセッサ１０は、ユーザの手の形状から、ユーザのジェスチャを検出する。プロセッサ１０は、例えば、撮影画像から検出されるユーザの手の形状から、ユーザの指の本数（伸びている指の本数）を特定する。プロセッサ１０はさらに、特定した指の本数から、ユーザが行ったジェスチャを特定する。例えば、プロセッサ１０は、指の本数が５本である場合、ユーザが「パー」のジェスチャを行ったと判定する。また、プロセッサ１０は、指の本数が０本である（指が検出されなかった）場合、ユーザが「グー」のジェスチャを行ったと判定する。また、プロセッサ１０は、指の本数が２本である場合、ユーザが「チョキ」のジェスチャを行ったと判定する。（３）プロセッサ１０は、カメラ１７の撮影画像に対し、画像認識処理を行うことにより、ユーザの指が人差し指のみ立てた状態であるか、ユーザの指がはじくような動きをしたかを検出する。（４）プロセッサ１０は、カメラ１７の撮影画像の画像認識結果、及び、測距センサ１８の出力値等の少なくともいずれか１つに基づいて、ユーザ端末１００の近傍の物体１０１０（ユーザの手など）とユーザ端末１００との距離を検出する。例えば、プロセッサ１０は、カメラ１７の撮影画像から特定されるユーザの手の形状の大小により、ユーザの手がユーザ端末１００の近傍（例えば所定値未満の距離）にあるのか、遠く（例えば所定値以上の距離）にあるのかを検出する。なお、撮影画像が動画の場合、プロセッサ１０は、ユーザの手がユーザ端末１００に接近しているのか遠ざかっているのかを検出してもよい。（５）カメラ１７の撮影画像の画像認識結果等に基づいて、ユーザの手が検出されている状態で、ユーザ端末１００とユーザの手との距離が変化していることが判明した場合、プロセッサ１０は、ユーザが手をカメラ１７の撮影方向において振っていると認識する。カメラ１７の撮影範囲よりも指向性が強い測距センサ１８において、物体が検出されたりされなかったりする場合に、プロセッサ１０は、ユーザが手をカメラの撮影方向に直交する方向に振っていると認識する。

このように、プロセッサ１０は、カメラ１７の撮影画像に対する画像認識により、ユーザが手を握りこんでいるか否か（「グー」のジェスチャであるか、それ以外のジェスチャ（例えば「パー」）であるか）を検出する。また、プロセッサ１０は、ユーザの手の形状とともに、ユーザがこの手をどのように移動させているかを検出する。また、プロセッサ１０は、ユーザがこの手をユーザ端末１００に対して接近させているのか遠ざけているのかを検出する。このような操作は、例えば、マウス又はタッチスクリーンなどのポインティングデバイスを用いた操作に対応させることができる。ユーザ端末１００は、例えば、ユーザの手の移動に応じて、タッチスクリーン１５においてポインタを移動させ、ユーザのジェスチャ「グー」を検出する。この場合、ユーザ端末１００は、ユーザが選択操作を継続中であると認識する。選択操作の継続とは、例えば、マウスがクリックされて押し込まれた状態が維持されること、又は、タッチスクリーンに対してタッチダウン操作がなされた後タッチされた状態が維持されることに対応する。また、ユーザ端末１００は、ユーザのジェスチャ「グー」が検出されている状態で、さらにユーザが手を移動させると、このような一連のジェスチャを、スワイプ操作（またはドラッグ操作）に対応する操作として認識することもできる。また、ユーザ端末１００は、カメラ１７の撮影画像によるユーザの手の検出結果に基づいて、ユーザが指をはじくようなジェスチャを検出した場合に、当該ジェスチャを、マウスのクリック又はタッチスクリーンへのタップ操作に対応する操作として認識してもよい。

（ユーザ端末１００の機能的構成）
図２は、ゲームシステム１に含まれるユーザ端末１００の機能的構成を示すブロック図である。ユーザ端末１００は、図示しない、一般的なコンピュータとして機能する場合に必要な機能的構成、および、ゲームにおける公知の機能を実現するために必要な機能的構成を含み得る。

ユーザ端末１００は、ユーザの入力操作を受け付ける入力装置としての機能と、ゲームの画像や音声を出力する出力装置としての機能を有する。ユーザ端末１００は、プロセッサ１０、メモリ１１、ストレージ１２、通信ＩＦ１３、および入出力ＩＦ１４等の協働によって、制御部１１０および記憶部１２０として機能する。

記憶部２２０は、ゲームプログラム１３１、ゲーム情報１３２、およびユーザ情報１３３を格納する。ゲームプログラム１３１は、ユーザ端末１００で実行するゲームプログラムである。ゲーム情報１３２は、制御部１１０がゲームプログラム１３１を実行する際に参照するデータである。ユーザ情報１３３は、ユーザのアカウントに関するデータである。

制御部１１０は、記憶部１２０に格納されたゲームプログラム１３１を実行することにより、ユーザ端末１００を統括的に制御する。例えば、制御部１１０は、ゲームプログラム１３１およびユーザの操作にしたがって、ゲームを進行させる。また、制御部１１０は、ゲームを進行させている間、必要に応じて、サーバ２００と通信して、情報の送受信を行う。

制御部１１０は、ゲームプログラム１３１の記述に応じて、操作受付部１１１、ゲーム実行部１１２、キャラクタ制御部１１３、パラメータ管理部１１４、スタミナ回復部１１５、および表示制御部１１７として機能する。制御部１１０は、実行するゲームの性質に応じて、ゲームを進行させるために、図示しないその他の機能ブロックとしても機能することができる。

操作受付部１１１は、タッチスクリーン１５（入力部１５１）の出力に基づいて、ユーザの入力操作を受け付ける。具体的には、操作受付部１１１は、ユーザの指などがタッチスクリーン１５に接近したことを、タッチスクリーン１５を構成する面の横軸及び縦軸からなる座標系の座標として検出する。例えば、操作受付部１１１は、入力部１５１に対する入力操作を受け付け、該入力操作の入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部１１１は、入力操作の種類として、例えばタッチ操作、スライド操作、スワイプ操作、およびタップ操作等を特定する。また、操作受付部１１１は、連続して検知されていた入力が途切れると、タッチスクリーン１５から接触入力が解除されたことを検知する。

操作受付部１１１は、タッチスクリーン１５に対するユーザの操作を判別する。操作受付部１１１は、例えば、（１）「接近操作」、（２）「リリース操作」、（３）「タップ操作」、（４）「ダブルタップ操作」、（５）「長押し操作（ロングタッチ操作）」、（６）「ドラッグ操作（スワイプ操作）」、（７）「ムーブ操作」、（８）「フリック操作」、その他のユーザの操作を判別する。操作受付部１１１が判別するユーザの操作は、上記に限られない。例えば、タッチスクリーン１５が、ユーザがタッチスクリーン１５に対して押下する圧力の大きさを検出可能な機構を有する場合、操作受付部１１１は、ユーザにより押下された圧力の大きさを判別する。

（１）「接近操作」とは、ユーザが指などをタッチスクリーン１５に接近させる操作である。タッチスクリーン１５は、ユーザの指などが接近したこと（ユーザの指などがタッチスクリーン１５に接触したことを含む）をタッチスクリーン１５により検出し、検出したタッチスクリーン１５の座標に応じた信号を制御部１１０へ出力する。制御部１１０は、タッチスクリーン１５へのユーザの指などの接近を検出しない状態から、接近を検出したときに、状態が「タッチオン状態」になったと判別する。

（２）「リリース操作」とは、ユーザがタッチスクリーン１５を接近操作している状態を止める操作である。操作受付部１１１は、例えば、ユーザが指などをタッチスクリーン１５に接触させている状態から、指を離す操作をしたときに、ユーザの操作を「リリース操作」と判別する。制御部１１０は、タッチスクリーン１５へのユーザの指などの接近を検出している状態から、接近を検出しない状態になったときに、状態が「タッチオン状態」から「タッチオフ状態」になったと判別する。

（３）「タップ操作」とは、ユーザがタッチスクリーン１５に対して指などを接近させる接近操作をした後に、接近操作をした位置でリリース操作を行うことである。操作受付部１１１は、接近操作が検出されない状態（ユーザの指などがタッチスクリーン１５から離れており、タッチスクリーン１５がユーザの指などの接近を検出していない状態）から、タッチスクリーン１５の出力に基づいて、ユーザの指などが接近したことを検出した場合に、その検出した座標を「初期タッチ位置」として保持する。操作受付部１１１は、初期タッチ位置の座標と、リリース操作をした座標とがほぼ同一である場合（接近操作が検出された座標から一定範囲内の座標においてリリース操作の座標が検出された場合）に、ユーザの操作を「タップ操作」と判別する。

（４）「ダブルタップ操作」とは、ユーザがタップ操作を一定時間内に２回行う操作である。操作受付部１１１は、例えば、ユーザの操作をタップ操作と判別してから一定時間内に、タップ操作にかかる座標で再びタップ操作を判別した場合に、ユーザの操作を「ダブルタップ操作」と判別する。

（５）「長押し操作」とは、ユーザがタッチスクリーン１５を押し続ける操作である。タッチスクリーン１５は、ユーザの操作を検出して接近操作を判別してから、接近操作が検出された座標において接近操作が継続している時間が一定時間を超えた場合に、ユーザの操作を「長押し操作」（「長押し操作」を、「ロングタッチ操作」と称することもある）と判別する。

（６）「ドラッグ操作」とは、ユーザがタッチスクリーン１５に指などを接近させた接近状態を維持したまま、指をスライドさせる操作である。

（７）「ムーブ操作」とは、ユーザがタッチスクリーン１５において、接近操作を維持しつつ、タッチスクリーン１５に指などを接近させている位置を移動させてリリース操作を行う一連の操作をいう。

（８）「フリック操作」は、ユーザがムーブ操作を予め定められた時間よりも短い時間で行う操作をいう。フリック操作は、ユーザがタッチスクリーン１５で指を弾くような操作である。

ゲーム実行部１１２は、ゲームを進行させるための各種の処理を実行する。キャラクタ制御部１１３は、ゲーム中のキャラクタの挙動を制御する。パラメータ管理部１１４は、ゲームに用いられる各種のパラメータを管理する。スタミナ回復部１１５は、ゲームに用いられるスタミナを回復する。

表示制御部１１７は、タッチスクリーン１５の表示部１５２に対して、上述の各要素によって実行された処理結果が反映されたゲーム画面を出力する。表示制御部１１７は、各種オブジェクトのモーションを示すアニメーションを含むゲーム画面を、表示部１５２に表示してもよい。また、表示制御部１１７は、ＵＩ（User Interface）オブジェクトを、ゲーム画面に重畳して描画してもよい。

図２に示すユーザ端末１００の機能は、一例にすぎない。サーバ２００は、ユーザ端末１００が備える機能の少なくとも一部を備えていてもよい。また、ユーザ端末１００は、サーバ２００が備える機能の少なくとも一部を備えていてもよい。さらに、ユーザ端末１００およびサーバ２００以外の他の装置をゲームシステム１の構成要素とし、該他の装置にゲームシステム１における処理の一部を実行させてもよい。すなわち、本実施形態においてゲームプログラムを実行するコンピュータは、ユーザ端末１００、サーバ２００、および他の装置のいずれであってもよいし、これらの複数の装置の組み合わせにより実現されてもよい。

（ゲーム概要）
ゲームシステム１に基づくゲームは、例えば、ユーザによって操作されるキャラクタ（味方キャラクタ）が登場する任意のゲームである。このゲームは、例えば、ユーザによって操作されるキャラクタと、ゲームシステム１によって制御される他のキャラクタ（敵キャラクタ）とが戦闘するゲームである。ユーザは、複数の異なるキャラクタを保有することができる。ユーザは、有償または無償の手段によって、ゲームにおいて利用可能な味方キャラクタ（ゲーム媒体）を取得することができる。

ゲームシステム１に基づくゲームは、戦闘ゲームに限らず、スポーツゲームなどの任意のジャンルのゲームであってよい。ゲームシステム１は、特定のプレイ形態に限らず、あらゆるプレイ形態のゲームを実行するためのシステムであってもよい。例えば、単一のユーザによるシングルプレイゲーム、及び、複数のユーザによるマルチプレイゲーム、また、マルチプレイゲームの中でも、複数のユーザが対戦する対戦ゲーム、及び、複数のユーザが協力する協力プレイゲームなどであってもよい。

（処理フロー）
以下では、本ゲームがオープンワールド方式のロールプレイングゲーム（ＲＰＧ）である例を説明する。本ゲームでは、ユーザが操作するキャラクタはヒットポイント（ＨＰ、第１パラメータ）およびスキルポイント（ＳＰ、第２パラメータ）を有する。以下、ユーザが操作する１又は複数のキャラクタのことを味方キャラクタと呼称することもある。

ＨＰはキャラクタが有する体力である。キャラクタはＳＰを使用して所定のスキルを発動できる。全ての味方キャラクタのＨＰがゼロ以下にならない限り、ユーザは自由にキャラクタをゲームフィールド内で操作して、戦闘イベントで敵キャラタクと戦闘するなどのゲームプレイを楽しむことができる。

また、本ゲームにおいては、少なくとも第１ゲームパートと第２ゲームパートとが別々のタイミングで実行される。以下に説明する例において、第１ゲームパートは、味方キャラクタと敵キャラクタとの戦闘を行う戦闘イベントである。第１ゲームパートにおいては敵キャラクタの攻撃等によって味方キャラクタのＨＰが減少し得る。また、第２ゲームパートは、ゲームフィールド内で味方キャラクタを移動させる探索パートである。

本ゲームでは、ゲームプレイ中に用いることが可能なスタミナ（第３パラメータ）が、ユーザに提供される。スタミナは、ＨＰおよびＳＰを回復させるために必要なパラメータである。ＨＰおよびＳＰはゲーム中のユーザのゲームプレイに従って減少し得るパラメータであり、ユーザはスタミナを用いることによってＨＰおよびＳＰを回復することができる。スタミナの使用時には、ＨＰおよびＳＰの回復に伴って一定量のスタミナが消費される。本実施形態ではユーザは基本的に最大で３つのスタミナを所持することができ、各スタミナを個別に使用することでＨＰおよびＳＰを回復させる。詳しくは後述するように、スタミナを使用できる機会は無制限に与えられるのではなく、ゲームを構成するゲーム空間内に設けられる回復ポイントでしかスタミナを用いることができない。本ゲームにはスタミナ自体を回復させる仕様が導入されており、詳細には、消費されたスタミナはスタミナの最大値を超えない範囲で時間経過に従って自動的に回復する。以上のように、本実施形態では、スタミナはゲームにおけるキャラクタの行動（例えばクエストへの参加）に伴って消費されるものではなく、ゲームにおけるキャラクタの行動（例えば戦闘行動）に使用されるパラメータ（ＨＰ，ＳＰ）を回復させるために用いられるものである。

図３は、ある実施の形態に係るユーザ端末１００が、ゲームプログラム１３１に基づいて実行する処理の流れを示すフローチャートである。図４は、ある実施の形態に係るゲーム画面を示す図である。図４に示す一連の処理の一部または全部が、サーバ２００によって実行されてもよい。

ステップＳ１において、ゲーム実行部１１２は、ゲームのプレイ中にゲームの探索パート（第２ゲームパート）を実行する。表示制御部１１７は、ゲームのプレイ中に、例えば図４に示すゲーム画面を表示部１５２に表示する。図４に示すゲーム画面では、探索パートに用いられるゲームフィールド（ゲーム空間）の背景、回復ポイント３１、キャラクタ３２、およびキャラクタ３３が表示される。回復ポイント３１は、キャラクタ３２，３３のＨＰおよびＳＰを回復可能なゲームフィールド内の所定位置である。キャラクタ３２，３３は、ユーザに関連付けられるキャラクタである。

表示制御部１１７は、スタミナ表示欄４０、キャラクタ表示欄５０、キャラクタ表示欄６０、および回復ボタン７０をゲーム画面にさらに表示する。スタミナ表示欄４０は、ユーザが所持するスタミナ４１が表示される欄である。図４では、３つのスタミナ４１がスタミナ表示欄４０に表示される。また、回復ボタン７０等の画面に表示されるボタンは、ＵＩオブジェクトの一例である。

キャラクタ表示欄５０は、キャラクタ３２に関する情報を表示する欄であり、図４では、キャラクタ画像５１、ＨＰバー５２、およびＳＰバー５３がキャラクタ表示欄５０に表示される。キャラクタ画像５１は、キャラクタ３２の一部を示す画像である。ＨＰバー５２は、キャラクタ３２のＨＰの現在値および最大値を視覚的にユーザに提示する表示情報である。図４において、ＨＰバー５２の左端はキャラクタ３２が倒された状態におけるＨＰの値に対応し、ＨＰバー５２の右端はキャラクタ３２のＨＰの最大値に対応する。表示制御部１１７は、ＨＰバー５２の全体のうち、ＨＰの現在値に相当する部分を、第１色に着色する。表示制御部１１７は、ＨＰバー５２のうち残りの部分を、第１色と異なる第２色に着色する。ユーザは、ＨＰバー５２を視認することによってキャラクタ３２のＨＰの現在値を直感的に把握することができる。ＳＰバー５３は、キャラクタ３２のＳＰの現在値および最大値を視覚的にユーザに提示する表示情報である。図４において、ＳＰバー５３の左端はキャラクタ３２のＳＰが枯渇した状態におけるＳＰの値に対応し、ＳＰバー５３の右端はキャラクタ３２のＳＰの最大値に対応する。また、各キャラクタのＨＰバー５２及び６２、並びにＳＰバー５３及び６３の左端に対応する値とは例えば０である。ＨＰバー５２の着色ルールは、対象をキャラクタ３２のＳＰに変更した上で、ＳＰバー５３に等しく適用される。

キャラクタ表示欄６０は、キャラクタ３３に関する情報を表示する欄であり、図４では、キャラクタ画像６１、ＨＰバー６２、およびＳＰバー６３がキャラクタ表示欄６０に表示される。キャラクタ画像６１は、キャラクタ３３の一部を示す画像である。ＨＰバー６２は、キャラクタ３３のＨＰの現在値および最大値を視覚的にユーザに提示する表示情報である。図４において、ＨＰバー６２の左端はキャラクタ３３が倒された状態におけるＨＰの値に対応し、ＨＰバー６２の右端はキャラクタ３３のＨＰの最大値に対応する。ＨＰバー５２の着色ルールが、対象をキャラクタ３３のＨＰに変更した上で、ＨＰバー６２に等しく適用される。ＳＰバー６３は、キャラクタ３３のＳＰの現在値および最大値を視覚的にユーザに提示する表示情報である。ＳＰバー５３の着色ルールが、対象をキャラクタ３３のＳＰに変更した上で、ＳＰバー６３に等しく適用される。

図４では、キャラクタ３２のＨＰおよびＳＰの現在値、ならびにキャラクタ３３のＨＰおよびＳＰ現在値は、いずれもそれぞれの最大値に等しい。これに応じて、ＨＰバー５２、ＳＰバー５３、ＨＰバー６２、およびＳＰバー６３のそれぞれの全体が、第１色に着色されている。なお、回復ボタン７０の詳細については後述する。

ユーザは、探索パートのプレイ中に、タッチスクリーン１５に対する操作に基づいて、キャラクタ３２，３３をゲームフィールド内で移動させることができる。キャラクタ３２，３３の移動時に、戦闘イベントを発生させるための所定条件が成立する場合がある。所定条件は、例えば、キャラクタ３２，３３がゲームフィールド内の移動中に敵キャラクタ３４と遭遇すること（いわゆるランダムエンカウント）である。ステップＳ２において、ゲーム実行部１１２は、ランダムエンカウントが発生した場合、探索パートの実行を中断すると共に、当該エンカウントに対応したゲームの戦闘イベント（第１ゲームパート）を実行する。表示制御部１１７は、戦闘イベントのゲーム画面を例えば図５に示すように表示制御部１１７に表示する。

図５〜図７は、ある実施の形態に係るゲーム画面を示す図である。図５のゲーム画面において、キャラクタ３２，３３がゲーム画面内の右側に表示され、敵キャラクタ３４がゲーム画面内の左側に表示される。表示制御部１１７は、ゲーム画面にキャラクタ表示欄５０およびキャラクタ表示欄６０を表示する。ユーザは、戦闘イベントのゲーム画面を視認しながら、戦闘イベントをプレイする。ユーザは、キャラクタ３２または３３に敵キャラクタ３４を攻撃させるための操作をタッチスクリーン１５に入力する。キャラクタ制御部１１３は、この操作に応答して、キャラクタ３２または３３に敵キャラクタ３４を攻撃させる。敵キャラクタ３４は、所定のアルゴリズムに基づいて、キャラクタ３２または３３を自動的に攻撃する。敵キャラクタ３４の攻撃が成功した場合、キャラクタ３２または３３のＨＰが減少する。

ユーザは、キャラクタ３２または３３にスキルを発動させるための操作をタッチスクリーン１５に入力することもできる。キャラクタ制御部１１３は、この操作に応答して、キャラクタ３２または３３のＳＰを消費することによって、キャラクタ３２または３３に所定の動作を実行させることでスキルを発動させる。スキルは、例えば少なくとも何れかの味方キャラクタのＨＰを回復させる行動、又は通常攻撃よりも大きなダメージを敵キャラクタに対して与える行動等である。以上のように、キャラクタ３２，３３のＨＰおよびＳＰは、戦闘イベントでのユーザのゲームプレイに基づいて減少し得る。

ゲーム実行部１１２は、戦闘イベントに規定されるクリア条件を満たした場合、キャラクタ３２，３３が敵キャラクタ３４との戦闘に勝利したとして、戦闘イベントを終了する。クリア条件は、例えば、敵キャラクタ３４のＨＰを、戦闘イベントにおいて行動するために必要な最低値未満に減少させることである。つまり、戦闘イベントにおいて敵キャラクタのＨＰを当該値未満に減少させることは、当該敵キャラクタを倒したことを意味する。味方キャラクタについても同様であって、味方キャラクタのＨＰが戦闘イベントにおいて行動するために必要な最低値未満に減少することは、当該味方キャラクタが倒されたことを意味する。また、味方キャラクタが戦闘イベントにおいて行動するために必要なＨＰの最低値とは、換言すると、ユーザが当該味方キャラクタを用いて戦闘イベントを実行するために必要なＨＰの最低値である。以下、当該最低値を、単に「戦闘に必要な最低値」と呼称することもある。また、戦闘に必要な最低値とは例えば１である。

一例によれば、味方又は敵キャラクタのＨＰの値が０である場合には当該キャラクタは倒されており、１以上である場合には当該キャラクタは倒されておらず、戦闘イベントにおいて行動できる。

また、ゲーム実行部１１２は、戦闘イベントの実行中に、ユーザの第１操作がなされたことに応答して、味方キャラクタの少なくとも何れかのＨＰを、味方キャラクタの少なくとも何れかのＳＰを消費することによって回復させる。ここで、第１操作とは、例えば味方キャラクタが発動可能な所定の回復スキルの使用を指示する入力操作である。上記所定の回復スキルは、戦闘イベントの実行中に使用できるが、探索パートにおいては使用できないものとする。

図６は、図５に示す状態からキャラクタ３３が所定の回復スキルを使用してキャラクタ３２のＨＰを回復させた状態を示している。キャラクタ３３が上記回復スキルを使用した結果、ＨＰバー５２に示すようにキャラクタ３２のＨＰが回復し、ＳＰバー６３に示すようにキャラクタ３３のＳＰが減少している。

また、図７は、図６に示す状態から戦闘が更に進行した状態を示している。図７においては、戦闘に必要な最低値未満にＨＰが減少してキャラクタ３２が既に行動不能となっている。また、キャラクタ３３の攻撃によって、敵キャラクタ３４が倒されている。戦闘の対象となった全ての敵キャラクタが倒され戦闘イベントに規定されるクリア条件が満たされたことによって、当該戦闘イベントが終了し、続いてステップＳ３の処理が実行される。

なお、戦闘イベントに規定されるクリア条件が満たされる前に味方キャラクタ全てのＨＰが戦闘に必要な最低値未満となった場合には、味方キャラクタが全滅したものとして、例えば最後にセーブしたポイントからのゲームの再開がユーザに課されてもよい。

図８は、ある実施の形態に係るゲーム画面を示す図である。ステップＳ３において、ゲーム実行部１１２は、戦闘イベントの終了後、探索パートを再開する。これにより、表示制御部１１７は、再開後の探索パートに対応するゲーム画面を、例えば図８に示すように表示部１５２に表示する。なお、当該探索パートは、新たなランダムエンカウントが発生するまで継続される。また、戦闘イベントを実行した結果、キャラクタ３２，３３のＨＰおよびＳＰがいずれも減少している。図８では、ＳＰバー５３等の表示状態が、減少後のＨＰ等の現在値を反映した状態に更新されている。このように、戦闘イベントにおいて減少したＨＰおよびＳＰの現在値が、探索パートの再開後に引き継がれている。ただし、ＨＰバー５２が示す値に関しては例外である。直前の戦闘イベントが終了した際、キャラクタ３２のＨＰの値は戦闘に必要な最低値未満であったが、図８に示す画面においては、キャラクタ３２のＨＰの値は、戦闘に必要な最低値以上の値となっている。以下、この仕様について説明する。

ゲーム実行部１１２は、ステップＳ３において探索パートを再開したことに続いてステップＳ４の処理を実行する。ステップＳ４においてゲーム実行部１１２は、パラメータ管理部１１４が管理する、味方キャラクタのＨＰの値を参照して、判定の対象となる味方キャラクタのＨＰの値が戦闘に必要な最低値未満であるか否かを判定する。ゲーム実行部１１２は、当該キャラクタのＨＰの値が戦闘に必要な最低値未満であると判定した場合、続いてステップＳ５の処理を実行する。

ステップＳ５においてゲーム実行部１１２は、パラメータ管理部１１４に、ステップＳ４においてＨＰの値が戦闘に必要な最低値未満であると判定したキャラクタのＨＰの値を、当該最低値以上の値に更新させる。これにより、戦闘イベントの実行中に何れかの味方キャラクタを用いることができなくなっても、次回の戦闘イベントにおいて当該キャラクタを用いることができる。また、特に更新後のＨＰの残りの値が少なく、戦闘に必要な最低値に近い場合、ユーザに対して第２操作を促すことができる。ゲーム実行部１１２は、ステップＳ４及びＳ５の処理を、全ての味方キャラクタを対象として実行したのち、続いてステップＳ６の処理を実行する。

ステップＳ６において、ゲーム実行部１１２は、操作受付部１１１が回復ボタン７０に対するユーザの入力操作を受け付けたか否かを判定する。ゲーム実行部１１２は、操作受付部１１１が当該入力操作を受け付けたと判定した場合、続いてステップＳ７の処理を実行し、受け付けていないと判定した場合、続いてステップＳ８の処理を実行する。なお、回復ボタン７０に対する入力操作は、本実施形態における第２操作の一例であって、戦闘イベント中には行えない操作である。

ステップＳ７において、ゲーム実行部１１２は、回復ボタン７０に対するユーザの入力操作に応答して、味方キャラクタの少なくとも何れかのＨＰの値を、味方キャラクタの少なくとも何れかのＳＰを消費することによって回復させる。

本実施形態では、前述したように、戦闘イベント中に使用可能な所定の回復スキルは、探索パートにおいて使用することができない。これは、以下の理由によるものである。

詳細は後述するが、本実施形態では、ＨＰおよびＳＰの回復ではなく回復ポイントの使用にスタミナ制を採用する仕様を本ゲームに導入することによって、ゲームプレイに対する実質的なスタミナ制を本ゲームにおいても実現する。これにより、ユーザが所持できるスタミナの数に制限があり、なおかつスタミナの自動回復には一定の時間経過を要するので、ユーザが無制限にゲームを進めてゲームコンテンツを早期に消費し尽くし、やがてゲームに飽きてしまうことを防止できる。一方で、スタミナが切れても一定時間待機すればスタミナが自動回復し、ゲームプレイが再開できるので、スタミナの所持数に限りがあることでゲームプレイの一定制限があるとしても、そのことにユーザは十分に納得できる。したがって、スタミナをうまく活用しながらゲームをプレイするように、ユーザを動機付けられる。

このように本実施形態では、ＨＰおよびＳＰの回復機会を制限することで、ユーザが本ゲームを短期間で制覇することを防ぐとともに、ユーザに本ゲームを息長く継続的にプレイして貰えるようにしている。なお、探索パートにおいても所定の回復スキルでＨＰを回復できるようにしてしまうと、上述の意図の下でのゲームバランスの設計が困難になってしまうので、本実施形態では上述のように、探索パートにおける所定の回復スキルでのＨＰの回復を制限している。

しかしながら探索パートにおける所定の回復スキルでのＨＰの回復を制限してしまうと、例えば、ステップＳ５においてキャラクタのＨＰの値が最低値となっているような、キャラクタのＨＰの値が少ない場合であっても、キャラクタのＨＰを回復できない。この結果、戦闘イベントにおいて、敵の攻撃よりすぐに倒されてしまうことを防止するために、敵の攻撃が先か、所定の回復スキルが先かという無用な勝負が頻繁に生じてしまい、ゲーム性を損なってしまう。

このため本実施形態では、探索パートにおける緊急避難的なＨＰの回復手法として、回復ボタン７０によるＨＰの回復手法を用意している。但し、回復ボタン７０によるＨＰの回復手法は、回復スキルに比べ、ＨＰの回復効率、即ち、ＳＰの単位消費量あたりのＨＰの回復量を少なくしている。これにより、探索パートにおいて制限なくＨＰの回復が行われてしまうという事態を防止しつつ、緊急避難的なＨＰの回復手法をユーザに提供するようにしている。

図９は、図８に示す状態から、本ステップＳ７における処理が実行された状態の一例を示す図である。図９は、回復ボタン７０に対する入力操作に応答して、複数の味方キャラクタのＳＰを消費することによって、当該キャラクタ自身それぞれのＨＰが回復した例を示している。また、上記の例の構成によれば、複数の味方キャラクタのＨＰを回復させる場合におけるユーザの手間を軽減できる。

上述したように、図９は、ＳＰを消費したキャラクタ自身それぞれのＨＰを回復させる構成の一例を示している。ＳＰを消費していないキャラクタのＨＰは回復されない。ＳＰが必要な値に満たないキャラクタは、ＨＰの回復ができないので、ユーザに求められる戦略性が向上する。

なお、第２操作に起因する上述した回復処理に関して、表示制御部１１７は、各キャラクタのＨＰが回復されたことを通知するためのダイアログ画面等の画面を新たに表示させない。これにより、ダイアログ画面等を閉じる煩わしさが無いので操作性が向上し、例えばユーザが連続して当該入力操作を行いやすくなる効果を奏する。

ステップＳ８において、ゲーム実行部１１２は、操作受付部１１１がユーザの第３操作を受け付けたか否かを判定する。ここで、第３操作とは、例えば時間経過に従って自動的に回復するスタミナを消費することによって、味方キャラクタの少なくとも何れかのＨＰとＳＰとを回復させることを指示する入力操作である。

また、図１０及び図１１は、ある実施の形態に係るゲーム画面を示す図である。なお上述した第３操作は、ゲーム空間内に含まれる１又は複数の所定位置に味方キャラクタの少なくとも何れかが配置されている場合に、ユーザに許可される構成でもよい。本実施形態において、前記所定の位置とは回復ポイント３１である。つまり、味方キャラクタの少なくとも何れかが図１０に示すように回復ポイント３１に位置する場合に第３操作の実行がユーザに許可され、何れのキャラクタも回復ポイント３１に位置しない場合には第３操作の実行がユーザに許可されない。これにより、スタミナの消費による味方キャラクタのＨＰ、ＳＰが回復可能な位置が制限されるのでユーザに求められる戦略性が向上する。図１０では、キャラクタ３２が回復ポイント３１に配置され、キャラクタ３３はキャラクタ３２の側に配置される。この配置に基づいて、スタミナを用いたＨＰおよびＳＰの回復が許可される。また、図１０の例において第３操作とは、例えば、スタミナ表示欄４０に表示されるいずれかのスタミナ４１をタップする操作である。ゲーム実行部１１２は、操作受付部１１１がユーザの第３操作を受け付けたと判定した場合、続いてステップＳ９の処理を実行し、受付けていないと判定した場合、探索パートの実行を継続する。

ステップＳ９において、ゲーム実行部１１２は、パラメータ管理部１１４に各パラメータの値を更新させる。具体的には、パラメータ管理部１１４は、スタミナ４１を１つ消費することによって、キャラクタ３２，３３のＨＰおよびＳＰを最大値まで回復する。表示制御部１１７は、スタミナ４１の消費に応答して、図１１に示すようにゲーム画面を更新する。

図１１は、ある実施の形態に係るゲーム画面を示す図である。表示制御部１１７は、スタミナ表示欄４０に表示される３つのスタミナ４１のうち１つの表示を消去する。表示制御部１１７は、さらに、キャラクタ３２のＨＰバー５２およびＳＰバー５３の表示状態を、ＨＰおよびＳＰの各現在値が最大値であることを示す状態に更新する。加えて、キャラクタ３３のＨＰバー６２およびＳＰバー６３の表示状態も、ＨＰおよびＳＰの各現在値が最大値であることを示す状態に更新する。これにより、ユーザは、キャラクタ３２，３３を用いたゲームを続けることができるようになる。

ゲーム実行部１１２は、本ステップＳ９における上述した処理を実行したのち、探索パートの実行を継続する。ステップＳ８又はＳ９における処理の終了後における探索パートの実行中にランダムエンカウントが発生した場合、ゲーム実行部１１２は、続いてステップＳ２の処理を実行する。なお、図３のフローチャートに基づく処理は、所定の条件が満たされた場合に終了する。ここで、所定の条件とは、例えばゲームの中断又はクリア等であってもよい。

（スタミナの自動回復）
図１２は、ある実施の形態に係るスタミナ表示欄４０およびキャラクタ表示欄５０を示す図である。図１２（Ａ）では、スタミナ４１が１つ消費されており、残りのスタミナは２つである。キャラクタ３２のＨＰおよびＳＰのいくらか使用済みであり、それぞれの現在値は最大値よりも低くなっている。また、スタミナ回復部１１５は、時間経過に従って、スタミナを自動的に回復する。これには、所定の時刻の到来によってスタミナを自動的に回復する態様が含まれる。

例えば、図１２（Ａ）の状態から一定時時間が経過した場合、スタミナ回復部１１５は、消費された１つのスタミナ４１の一部を回復する。表示制御部１１７は、図１２（ｂ）に示すように、スタミナ表示欄４０内の左端部に、部分的に回復された状態のスタミナ４１を表示する。スタミナ回復部１１５は、スタミナ４１を完全に回復させるために必要な所定時間が経過した場合、消費された１つのスタミナ４１を完全に回復する。表示制御部１１７は、図１２（Ｃ）に示すように、スタミナ表示欄４０内の左端部に、完全に回復された状態のスタミナ４１を表示する。これにより、ユーザが使用可能なスタミナ４１が１つ増加する。したがって、ユーザは、仮にスタミナ４１が全て無くなったとしても、ゲームを中断してしばらくまつことによって、新たなスタミナ４１を取得することができるので、その後、ゲームを再びプレイすることができるようになる。

スタミナ４１の自動回復は、残りのスタミナ４１がゼロになった場合にのみ有効化してもよい。

本開示のある局面において、ＨＰおよびＳＰは、時間経過に従って自動的に回復しないパラメータである。図１２に示すように、時間経過に従ってスタミナ４１が回復する際も、ＨＰおよびＳＰはそれぞれの現在値を維持し続ける。

（主要な作用効果）
本ゲームの運営者は、ゲームのユーザが本ゲームの本編シナリオを短期間で制覇（消費）することを防ぎ、できればユーザが本ゲームを毎日欠かさずプレイすること、言い換えれば一種のライフサイクルとして本ゲームをプレイすることを、望んでいる。これを実現するためには、例えば本ゲームをスタミナ制のゲームとして設計し、すなわちスタミナを消費しなければ本ゲームを先に進めることができない仕組みを導入すれば良い。しかし、本ゲームにはいわゆるクエストのようなゲーム内の明確なプレイ単位（区切り）がないため、このようなスタミナ制の導入には適さない。また、本ゲームはオープンワールドの世界観を有するＲＰＧであり得る。しかし、このようなＲＰＧでは、ゲームプレイ自体を途中で制限するようなスタミナ制の導入に対してユーザが納得感を持ち辛い。そこで、上述したようなＨＰおよびＳＰの回復する機会を制限する仕様、すなわち、ＨＰおよびＳＰの回復ではなく回復ポイント３１の使用にスタミナ制を採用する仕様を本ゲームに導入することによって、ゲームプレイに対する実質的なスタミナ制を本ゲームにおいても実現することができる。結果、ユーザが本ゲームを短期間で制覇することを防ぐことができるので、ユーザに本ゲームを息長く継続的にプレイして貰えるようになる。

以上のように、本開示の一態様によれば、ゲームを進行させるために使用されるパラメータ（ＨＰ，ＳＰ）の新たな回復手法をゲームに導入できる利点が生ずる。さらには、回復ポイント３１までキャラクタ３２又はキャラクタ３３を移動させた場合に初めて、スタミナ４１を用いたＨＰおよびＳＰの回復が可能になるため、回復ポイント３１から離れてゲームフィールド内でキャラクタを移動させることに一定の緊張感が生じ、これによりゲームの興趣性を高められる。一方、限られた回復ポイント３１でのみＨＰおよびＳＰを回復できるので、ゲームの運営者にとっては、回復ポイント３１の数及び配置を工夫することによってゲームの難易度を思うように設計しやすくなるという利点がある。

ユーザが所持できるスタミナ４１の数に制限があり、なおかつスタミナ４１の自動回復には一定の時間経過を要するので、ユーザが無制限にゲームを進めてゲームコンテンツを早期に消費し尽くし、やがてゲームに飽きてしまうことを防止できる。一方で、スタミナ４１が切れても一定時間待機すればスタミナ４１が自動回復し、ゲームプレイが再開できるので、スタミナ４１の所持数に限りがあることでゲームプレイの一定制限があるとしても、そのことにユーザは十分に納得できる。したがって、スタミナ４１をうまく活用しながらゲームをプレイするように、ユーザを動機付けられる。

（レベルアップによるＨＰおよびＳＰの回復）
本開示のある局面において、ユーザ端末１００は、戦闘イベントにおけるユーザのゲームプレイの結果としてキャラクタがレベルアップしたことに応答して、キャラクタに設定されるＨＰおよびＳＰを回復するステップとを実行する。

例えば、キャラクタ３２およびキャラクタ３３は、図５に示す戦闘イベントで勝利した場合、戦闘イベントに設定される経験値を獲得する。キャラクタ制御部１１３は、キャラクタ３２の累積の獲得経験値が閾値を超えた場合、キャラクタ３２をレベルアップさせる。パラメータ管理部１１４は、このレベルアップに応答して、キャラクタ３２のＨＰおよびＳＰをそれぞれ最大値まで回復させる。キャラクタ３３の場合も事情は同様である。レベルアップによってＨＰおよびＳＰが全回復するので、ユーザはゲームプレイを継続することができる。したがって、キャラクタ３２，３３をレベルアップさせることをユーザに動機付けることができる。

キャラクタ３２，３３のレベルが低い場合はレベルアップ間隔を短くしてもよく、このように設定のされる態様ではキャラクタ３２のＨＰが無くなる前にキャラクタ３２が次々とレベルアップすることになる。これにより、ユーザはゲームの序盤ではスタミナ４１を使用することなく、ゲームを次々と先に進めることができる。

（ＨＰ、ＳＰの課金回復）
本開示のある局面において、ユーザ端末１００は、ユーザによる対価の支払いまたは対価に支払いにより得られるゲームアイテムの消費に基づいて、複数のキャラクタのそれぞれに設定される第１パラメータおよび第２パラメータを回復するステップを実行する。

図１３は、ある実施の形態に係るゲーム画面を示す図である。この図の例では、キャラクタ３２，３３のＨＰがいずれもゼロに近いため、ＨＰを回復させない限りゲームを継続することが難しい。しかしユーザはスタミナ４１を１つも所持していないため、スタミナ４１を使用してＨＰおよびＳＰを回復することができない。このような場合でも、本ゲームではユーザは課金によりＨＰおよびＳＰを回復できる。例えばユーザは、課金によりＨＰおよびＳＰを回復するための操作をタッチスクリーン１５に入力する。この操作に応答して、表示制御部１１７は、例えば図１４に示すメッセージ７１を表示部１５２に表示する。

図１４は、ある実施の形態に係るメッセージ７１を示す図である。メッセージ７１は、課金によりＨＰおよびＳＰを回復することをユーザに問い合わせるテキストである。表示制御部１１７は、ボタン７２および７３を併せて表示部１５２に表示する。制御部１１０は、ユーザがボタン７２を押下した場合、ユーザによる対価の支払いに関する処理を実行する。この処理は、ＨＰおよびＳＰを全回復するために必要な金銭の決済に関する処理を含む。パラメータ管理部１１４は、決済に関する処理が完了したことに応答して、図１５に示すようにキャラクタ３２，３３のＨＰおよびＳＰを全回復する。この際、スタミナ４１は回復しない。すなわち、スタミナ４１の残りはゼロのままであり、かつ、回復途中のスタミナ４１が使用可能な状態になるまで必要な残り時間（チャージ時間）が減少することもない。

図１５は、ある実施の形態に係るゲーム画面を示す図である。キャラクタ３２，３３のＨＰおよびＳＰが全回復されたため、ＨＰバー５２等の表示状態を、ＨＰ等の現在値が最大値に一致する状態に更新している。ＨＰが全回復されたため、ユーザは、スタミナ４１の自動回復を待たずに、直ちにゲームを継続してプレイする。このようにして、課金によるＨＰ・ＳＰの回復を可能とすれば、スタミナ４１が切れた後もゲームを続けたいユーザに対して課金を動機付けることができる。なお、別の態様として、課金によって回復するパラメータはスタミナ４１であってもよい。

パラメータ管理部１１４は、ユーザによる対価の支払いによってユーザに付与されるゲームアイテムの使用に基づいて、ＨＰおよびＳＰを回復することもできる。例えば、ユーザが、事前の課金によって、有償のゲームアイテムであるダイヤを入手済みであるとする。パラメータ管理部１１４は、ダイヤを使用するためのユーザの操作に応答して、ダイヤを消費することによってキャラクタ３２，３３のＨＰおよびＳＰを全回復する。この例では、ゲームの継続プレイに積極的なユーザに対して、ダイヤという有償アイテムを購入する動機付けを与えることができる。

〔変形例〕
第２操作に起因する回復処理を何れのキャラクタについても実行できない場合、表示制御部１１７は、回復ボタン７０を画面に表示しない構成でもよい。なお、上述した場合とは、例えば全ての味方キャラクタのＨＰが最大値である場合、又はＨＰが最大値でない全ての味方キャラクタのＳＰが必要な値に満たない場合等である。

また、第２操作に起因する回復処理において、ＳＰを消費したキャラクタとＨＰが回復するキャラクタとが互いに異なるキャラクタであることが許容される構成でもよい。

また、戦闘イベントで倒された味方キャラクタのＨＰが戦闘に必要な最低値以上の値に更新されるステップＳ５の処理は必須ではなく、また、対象となる味方キャラクタの人数も限定されない。また当該処理が実行されるタイミングは限定されず、味方キャラクタが倒された戦闘イベントから次回の戦闘イベント開始までの間の任意のタイミングであってもよい。

回復ボタンの表示手法については、上述の例に限定されるものではない。例えば、表示制御部１１７は、回復ボタン７０を探索パートの実行中に表示させるための操作を受け付けるＵＩオブジェクトを画面に表示させ、このＵＩオブジェクトが操作された場合に、回復ボタン７０を表示させるようにしてもよい。これにより、探索パートの実行中に、ユーザの誤操作により回復ボタン７０が選択され、ユーザの意図せぬＨＰの回復が行われてしまうことを抑制できる。

図１６は、図４等とは異なる態様による探索パートのプレイ画面の一例を示す図である。図１６に示す画面において、ボタン９１は、所定のゲーム単位である所謂クエストを実行するためのボタンである。ボタン９２は、使用する味方キャラクタを選択するためのボタンである。ボタン９３は、ゲームに関するその他の情報を閲覧または設定するためのボタンである。また、アイコン９４は、ユーザに対する通知が存在することを示している。ボタン９５は、後述するボタン８５を表示させるためのボタンである。即ちボタン９５は、第２操作を受け付けるボタンを探索パートの実行中に表示させておくための操作を受け付けるＵＩオブジェクトの一例である。

テキスト８１（ａ〜ｄ）は、味方キャラクタのキャラクタ名を示している。オブジェクト８２は、キャラクタの顔の外観図を示している。オブジェクト８３は、キャラクタの属性を示している。ここで、キャラクタの属性とは、例えばキャラクタが何れの武器種を使用可能であるかを示す情報であってもよい。テキスト８４は、キャラクタのレベルを示している。

ボタン８５は、各キャラクタのＨＰを回復させるためのボタンであり、ボタン９５が選択されたことにより表示される。ボタン８５が表示されている状態でボタン９５が選択されたことに伴い、ボタン８５が消去されてもよい。また、ボタン８５を表示させるためにボタン９５が選択されたことに伴い、ボタン９５が消去されてもよい。この場合、画面上の任意の位置（但し、ボタン等の表示されている位置を除く）がユーザにより選択（タップ）されたことにより、ボタン８５が消去されて、ボタン９５が再表示されてもよい。ＨＰバー８６は、キャラクタのＨＰを示している。また、ＳＰバー８７は、キャラクタのＳＰを示している。また、オブジェクト９０はキャラクタの全身の外観図を示している。

図１６の例においては、ボタン９５が選択されたことに伴い、キャラクタＡのＨＰを回復させるためのボタン８５ａ、及びキャラクタＢのＨＰを回復させるためのボタン８５ｂが表示されている状態を示している。なお、キャラクタＣ及びキャラクタＤに対応するボタンは表示されていないが、これは、キャラクタＡ及びキャラクタＢのＨＰは第２操作によって回復可能であるが、キャラクタＣ及びキャラクタＤのＨＰは既に最大値であるため回復できない、又は回復に必要なＳＰが残っていないためである。なお、キャラクタＣ及びキャラクタＤのＨＰは第２操作によって回復可能であれば、キャラクタＣ及びキャラクタＤのＨＰを回復させるためのボタンも表示される。

このように、表示制御部１１７は、第２操作を受け付ける複数のボタンであって、複数の味方キャラクタの各々に対応する複数のボタンを画面に表示させる構成でもよい。ゲーム実行部１１２は、ボタン８５ａとボタン８５ｂとの何れかへの第２操作がなされたことに応答して、パラメータ管理部１１４に、第２操作の対象となったボタンに対応する味方キャラクタのＳＰを消費させ、且つ当該キャラクタのＨＰを回復させる。これにより、ユーザは、所望するキャラクタのＨＰを容易に回復させることができる。

なお、回復ボタン７０によるＨＰの回復手法では、前述のとおり、回復スキルに比べ、ＨＰの回復効率、即ち、ＳＰの単位消費量あたりのＨＰの回復量を少なくしている。例えば、ボタン８５を１回タップすることで、ＨＰをＨＰの最大値の２０％分の分量で回復することができる。この際のＳＰの消費量は、例えば、ＳＰの最大値の１０％分の分量とすることができる。一方、回復スキルによる回復については、例えば、ＳＰの最大値の１０％以下の分量を消費すれば、ＨＰを全回復できるなどとすることができる。

また、図１６は、ボタン８５ｂが選択されてキャラクタＢのＨＰが回復された例を示している。結果、ＳＰバー８７ｂの近傍に表示された値が示すようにキャラクタＢのＳＰの値は減少し、ＨＰバー８６ｂの近傍に表示された値が示すようにキャラクタＢのＨＰの値は増加している。また、これらの値は所定の時間が経過したのちにユーザ操作に依らずに画面から消去される。なお、キャラクタＢのＨＰが回復されたことを示すダイアログ画面等、消去するためにユーザ操作が必要となるような情報は新たに表示されない。これにより、ダイアログ画面等を閉じる煩わしさが無く操作性が向上する上に、ＨＰおよびＳＰの増減値をユーザが容易に把握することができる。

〔ソフトウェアによる実現例〕
制御部１１０の制御ブロック（特に、操作受付部１１１、ゲーム実行部１１２、キャラクタ制御部１１３、パラメータ管理部１１４、スタミナ回復部１１５および表示制御部１１７）は、集積回路（ＩＣチップ）等に形成された論理回路（ハードウェア）によって実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェアによって実現してもよい。

後者の場合、制御部１１０を備えた情報処理装置は、各機能を実現するソフトウェアであるプログラムの命令を実行するＣＰＵ、上記プログラム及び各種データがコンピュータ（またはＣＰＵ）で読み取り可能に記録されたＲＯＭ（Read Only Memory）又は記憶装置（これらを「記録媒体」と称する）、上記プログラムを展開するＲＡＭ（Random Access Memory）などを備えている。そして、コンピュータ（またはＣＰＵ）が上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記記録媒体としては、「一時的でない有形の媒体」、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムは、該プログラムを伝送可能な任意の伝送媒体（通信ネットワークや放送波等）を介して上記コンピュータに供給されてもよい。なお、本発明の一態様は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。

本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。

〔付記事項〕
本発明の一側面に係る内容を列記すると以下の通りである。

（項目１） プロセッサ（１０）と、メモリ（１１）と、タッチスクリーン（１５）とを備えるコンピュータ（ユーザ端末１００）により実行されるゲームプログラム（１３１）について説明した。本開示のある局面によると、ゲームプログラムは、プロセッサに、ユーザに関連付けられるキャラクタを用いるゲームプレイに従って、キャラクタに関連付けられる第１パラメータが減少し得る第１ゲームパートの実行中に、ユーザの第１操作に応答して、キャラクタの少なくとも何れかに関連付けられる第１パラメータを、キャラクタの少なくとも何れかに関連付けられる第２パラメータを消費することによって回復させる第１ステップ（Ｓ２）と、第１ゲームパートとは異なる第２ゲームパートの実行中におけるユーザの第２操作であって、第１ゲームパートにおいては実行できない第２操作に応答して、キャラクタの少なくとも何れかに関連付けられる第１パラメータを、キャラクタの少なくとも何れかに関連付けられる第２パラメータを消費することによって回復させる第２ステップ（Ｓ７）と、第２ゲームパートの実行中におけるユーザの第３操作に応答して、時間経過に従って自動的に回復する第３パラメータを消費することによって、キャラクタの少なくとも何れかに関連付けられる第１パラメータと第２パラメータとを回復させる第３ステップ（Ｓ９）とを実行させる。

上記の構成によれば、ゲームを進行させるために使用されるパラメータの新たな回復手法をゲームに導入できる効果を奏する。また、第１、２パラメータを回復する場合におけるユーザに求められる戦略性が向上する。また、例えばキャラクタに関連付けられる第１パラメータの減少によって当該キャラクタを用いて第１ゲームパートを進行させるための条件が満たされなくなりそうな場合には、事前に第２ゲームパートにて第１パラメータを回復することが可能なので、第１ゲームパートにて第１パラメータの減少よりも先に回復ができるか否かというだけで正否が決定される作業を回避することができる。これにより、第１ゲームパートにおけるゲーム性の低下を抑制できる。また、ユーザの使用するキャラクタが所謂回復役のキャラクタに偏ることを抑制できる。また、一定期間内に第３操作を実行可能な回数には制限があるため、例えばゲームの進行において第１、２パラメータの回復が必須となる場合に、ユーザがゲームを一度に過剰に進行させることを抑制できる。

（項目２） （項目１）においては、１ステップにおける、第２パラメータの単位消費量あたりの第１パラメータの回復値が、第２ステップにおける、第２パラメータの単位消費量あたりの第１パラメータの回復値の値よりも大きくてもよい。これにより、第２パートにおいて制限なく第１パラメータの回復が行われてしまうという事態を防止しつつ、緊急避難的な第１パラメータの回復手法をユーザに提供することができる。

（項目３） （項目１）又は（項目２）において、第３ステップは、ゲーム空間内に含まれる１又は複数の所定位置に、キャラクタの少なくとも何れかが配置されている場合に、ユーザに対して第３操作の実行を許可してもよい。

（項目４） （項目１）から（項目３）の何れかにおいて、第２ステップは、消費された第２パラメータに関連付けられるキャラクタ自身に関連付けられる第１パラメータを回復させてもよい。

（項目５） （項目４）において、第２操作を受け付ける複数のＵＩオブジェクト（７２、７３）であって、複数のキャラクタの各々に対応する複数のＵＩオブジェクトを画面に表示させる第４ステップを更に実行させ、第２ステップは、複数のＵＩオブジェクトの何れかへの第２操作に応答して、第２操作の対象となったＵＩオブジェクトに対応するキャラクタに関連付けられる第２パラメータを消費することによって、当該キャラクタに関連付けられる第１パラメータを回復させてもよい。

（項目６） （項目１）から（項目４）の何れかにおいて、第２操作を受け付けるUIオブジェクトを画面に表示させる第５ステップを更に実行させ、第２ステップは、UIオブジェクトへの第２操作に応答して、複数のキャラクタに関連付けられる第２パラメータを消費することによって、当該複数のキャラクタに関連付けられる第１パラメータを回復させてもよい。

（項目７） （項目５）又は（項目６）において、第2ステップでは、第１パラメータが回復されたことを通知するための通知情報を画面に表示させ、通知情報は、画面に表示された後に、ユーザによる操作を必要とせずに画面から消去される情報である。これにより、操作性の向上に寄与し、例えばユーザが連続して第２操作を行いやすくなる効果を奏する。

（項目８） （項目５）から（項目７）の何れかにおいて、第２操作を受け付けるＵＩオブジェクトを第２ゲームパートの実行中に表示させるための操作を受け付けるＵＩオブジェクト（８０）を画面に表示させる第６ステップを更に実行させてもよい。これにより、回復の必要がない場合に、第２操作を受け付けるＵＩオブジェクトが表示されないので、ユーザの意図せぬＨＰの回復が行われてしまうことを抑制できる。

（項目９） （項目１）から（項目８）までの何れかにおいて、第１ゲームパートが終了した場合にキャラクタに関連付けられる第１パラメータの値が当該キャラクタを用いて第１ゲームパートを実行するために必要な最低値未満に減少しているとき、当該第１ゲームパート終了後から次回の第１ゲームパート開始までの間に、当該第１パラメータの値を最低値以上の値に設定する第５ステップを更に実行させてもよい。

ゲームプログラムを実行する方法を説明した。本開示のある局面によると、ゲームプログラムは、プロセッサおよびメモリを備えるコンピュータにより実行される。該方法は、プロセッサが（項目１）に記載の各ステップを実行する方法である。（項目１１）に係る方法は、（項目１）に係るゲームプログラムと同様の作用効果を奏する。

（項目１１）情報処理装置を説明した。本開示のある局面によると、該情報処理装置は、（項目１）に係るゲームプログラムを記憶するメモリ（メモリ１１、記憶部１２０）と、該ゲームプログラムを実行することにより、情報処理装置（ユーザ端末１００）の動作を制御するプロセッサ（プロセッサ１０、制御部１１０）とを備える。（項目１１）に係る情報処理装置は、（項目１）に係るゲームプログラムと同様の作用効果を奏する。

１ ゲームシステム、２ ネットワーク、１０，２０ プロセッサ、１１，２１ メモリ、１２，２２ ストレージ、１３，２３ 通信ＩＦ（操作部）、１４，２４ 入出力ＩＦ（操作部）、１５ タッチスクリーン（表示部、操作部）、１７ カメラ（操作部）、１８ 測距センサ（操作部）、１００ ユーザ端末（情報処理装置）、１１０ 制御部、１２０ 記憶部、１３１ ゲームプログラム、１３２ ゲーム情報、１３３ ユーザ情報、１５１ 入力部（操作部）、１５２ 表示部、２００ サーバ、１０１０ 物体、１０２０ コントローラ（操作部）、１０３０ 記憶媒体、 ３１ 回復ポイント、３２，３３ キャラクタ、３４ 敵キャラクタ、４０ スタミナ表示欄、４１ スタミナ、５０，６０ キャラクタ表示欄、５１，６１ キャラクタ画像、５２，６２ ＨＰバー、５３，６３ ＳＰバー、７１ メッセージ、７２ ボタン、１１１ 操作受付部、１１２ ゲーム実行部、１１３ キャラクタ制御部、１１４ パラメータ管理部、１１５ スタミナ回復部、１１７ 表示制御部

Claims (11)

1. プロセッサおよびメモリを備えるコンピュータにより実行されるゲームプログラムであって、
   前記ゲームプログラムは、前記プロセッサに、
   ユーザに関連付けられるキャラクタを用いるゲームプレイに従って、前記キャラクタに関連付けられる第１パラメータが減少し得る第１ゲームパートの実行中に、前記ユーザの第１操作に応答して、前記キャラクタの少なくとも何れかに関連付けられる第１パラメータを、前記キャラクタの少なくとも何れかに関連付けられる第２パラメータを消費することによって回復させる第１ステップと、
   前記第１ゲームパートとは異なる第２ゲームパートの実行中におけるユーザの第２操作であって、前記第１ゲームパートにおいては実行できない第２操作に応答して、前記キャラクタの少なくとも何れかに関連付けられる前記第１パラメータを、前記キャラクタの少なくとも何れかに関連付けられる第２パラメータを消費することによって回復させる第２ステップと、
   前記第２ゲームパートの実行中における前記ユーザの第３操作に応答して、時間経過に従って自動的に回復する第３パラメータを消費することによって、前記キャラクタの少なくとも何れかに関連付けられる前記第１パラメータと前記第２パラメータとを回復させる第３ステップと
   を実行させるゲームプログラム。
2. 前記第１ステップにおける、前記第２パラメータの単位消費量あたりの前記第１パラメータの回復値が、前記第２ステップにおける、前記第２パラメータの単位消費量あたりの前記第１パラメータの回復値の値よりも大きい請求項１に記載のゲームプログラム。
3. 前記第３ステップは、ゲーム空間内に含まれる１又は複数の所定位置に、前記キャラクタの少なくとも何れかが配置されている場合に、前記ユーザに対して前記第３操作の実行を許可する請求項１又は２に記載のゲームプログラム。
4. 前記第２ステップは、消費された前記第２パラメータに関連付けられる前記キャラクタ自身に関連付けられる前記第１パラメータを回復させる請求項１から３までの何れか１項に記載のゲームプログラム。
5. 前記第２操作を受け付ける複数のＵＩオブジェクトであって、複数の前記キャラクタの各々に対応する複数のＵＩオブジェクトを画面に表示させる第４ステップを更に実行させ、
   前記第２ステップは、前記複数のＵＩオブジェクトの何れかへの前記第２操作に応答して、前記第２操作の対象となった前記ＵＩオブジェクトに対応する前記キャラクタに関連付けられる前記第２パラメータを消費することによって、当該キャラクタに関連付けられる前記第１パラメータを回復させる請求項４に記載のゲームプログラム。
6. 前記第２操作を受け付けるUIオブジェクトを画面に表示させる第５ステップを更に実行させ、
   前記第２ステップは、前記UIオブジェクトへの前記第２操作に応答して、複数の前記キャラクタに関連付けられる前記第２パラメータを消費することによって、当該複数の前記キャラクタに関連付けられる前記第１パラメータを回復させる請求項１から４までの何れか１項に記載のゲームプログラム。
7. 前記第2ステップでは、前記第１パラメータが回復されたことを通知するための通知情報を前記画面に表示させ、
   前記通知情報は、前記画面に表示された後に、前記ユーザによる操作を必要とせずに前記画面から消去される情報である、請求項５又は６に記載のゲームプログラム。
8. 前記ＵＩオブジェクトを前記第２ゲームパートの実行中に表示させるための操作を受け付けるＵＩオブジェクトを画面に表示させる第６ステップを更に実行させる請求項５から７までの何れか１項に記載のゲームプログラム。
9. 前記ゲームプログラムは、前記プロセッサに、
   前記第１ゲームパートが終了した場合に前記キャラクタに関連付けられる第１パラメータの値が当該キャラクタを用いて前記第１ゲームパートを実行するために必要な最低値未満に減少しているとき、当該第１ゲームパート終了後から次回の前記第１ゲームパート開始までの間に、当該第１パラメータの値を前記最低値以上の値に設定する第５ステップを
   更に実行させる請求項１から８までの何れか１項に記載のゲームプログラム。
10. コンピュータがゲームプログラムを実行する方法であって、
    前記コンピュータは、プロセッサおよびメモリを備え、
    前記プロセッサが請求項１に記載の各ステップを実行する方法。
11. 情報処理装置であって、
    前記情報処理装置は、
    請求項１に記載のゲームプログラムを記憶するメモリと、
    該ゲームプログラムを実行することにより、情報処理装置の動作を制御するプロセッサとを備えている、情報処理装置。

Images