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

Abstract

【課題】ゲームの興趣性を向上させる。【解決手段】ゲームプログラム（１３１）は、プロセッサ（１０）に、プレイ要素を、ユーザが選択可能に複数個提示するステップ（Ｓ１０１）と、ユーザに選択されたプレイ要素を、該ユーザの入力操作に応答して進行させるステップ（Ｓ１０２）と、隠しプレイ要素を解放する要件に係る要件パラメータを、選択されたプレイ要素が進行している間、該プレイ要素の進行状況に応じて、更新するステップ（Ｓ１０３）と、要件パラメータが更新されたことを通知するステップ（Ｓ１０４）と、を実行させる。提示するステップでは、要件パラメータが要件を満たしている場合に、隠しプレイ要素を、複数のプレイ要素とともに、ユーザが選択可能に提示し、ゲームプログラムに基づくゲームの実行中、要件パラメータが更新される条件は開示されない。【選択図】図４

Description

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

従来、ユーザに複数の選択肢を提示し、ユーザに選択された選択肢にしたがってゲームを進行させる形態のゲームを実現するためのゲームプログラムが数多く様々な事業者により提供されている。このような形態は、一例として、アドベンチャーゲーム、ロールプレイングゲーム（ＲＰＧ）、クイズゲームなどのジャンルに属するゲームにおいて数多く見られる。また、近年、ＲＰＧとクイズゲームとを合わせたクイズＲＰＧも提供されており、多くのユーザにプレイされている。

例えば、非特許文献１に開示されたクイズＲＰＧは、ユーザが集めたキャラクタを育成し、キャラクタでパーティーを編成し、該パーティーで敵キャラクタとのバトルに臨み、勝利を目指すというゲームである。そして、上述のバトルにクイズが採用されている。ユーザは、上述のバトルを含むクエストをいくつもプレイして、上述のクイズＲＰＧのストーリーを進めることにより、該ゲームに興じる。

"クイズRPG 魔法使いと黒猫のウィズ 公式ポータルサイト"、[online］、COLOPL, Inc.、[２０１８年１月１６日検索]、インターネット（ＵＲＬ：https://colopl.co.jp/magicianwiz/game/）

一般に、ユーザがゲームに飽きるという問題に如何に対処するかは重要である。ゲームには、常に、ユーザにプレイを動機付けるような魅力的なコンテンツを提供することが求められる。

本開示の一態様は、ゲームの興趣性を向上させることを目的とする。

本開示に係るゲームプログラムは、プロセッサおよびメモリを備えるコンピュータにより実行される。ゲームプログラムは、プロセッサに、ユーザにプレイさせるゲームの内容を区切る単位であるプレイ要素を、ユーザが選択可能に複数個提示するステップと、ユーザに選択されたプレイ要素を、該ユーザの入力操作に応答して進行させるステップと、プレイ要素をクリアするのみでは解放する要件が満たされない特殊なプレイ要素である隠しプレイ要素を解放する要件に係る要件パラメータを、選択されたプレイ要素が進行している間、該プレイ要素の進行状況に応じて、更新するステップと、要件パラメータが更新されたことを通知するステップと、を実行させる。提示するステップでは、要件パラメータが要件を満たしている場合に、隠しプレイ要素を、複数のプレイ要素とともに、ユーザが選択可能に提示し、ゲームプログラムに基づくゲームの実行中、要件パラメータが更新される条件（第１の更新条件、第２の更新条件）は開示されない。

本開示の一態様によれば、ゲームの興趣性を向上させる効果を奏する。

ゲームシステムのハードウェア構成を示す図である。 ユーザ端末およびサーバの機能的構成を示すブロック図である。 本実施形態に係るゲームの内容に基づく構成の一例を示す図である。 本実施形態に係るゲームシステムにおいて実行される処理の流れを示すフローチャートである。 要件情報のデータ構造の一例を示す図である。 進捗情報のデータ構造の一例を示す図である。 本実施形態に係るユーザ端末のクエスト進行部によって実行される、クエストを進行させる処理の流れを示すフローチャートである。 本実施形態に係るユーザ端末のパラメータ処理部によって実行される、要件パラメータに係る処理の流れを示すフローチャートである。 本実施形態に係るユーザ端末のパラメータ処理部によって実行される、要件パラメータに係る処理の流れを示すフローチャートである。 表示部に表示されるスキル発動画面の具体例を示す図である。 表示部に表示されるクリア通知画面の具体例を示す図である。 結果画面に重ねて表示される要件表示ウィンドウの具体例を示す図である。 結果画面に重ねて表示されるヒント表示ウィンドウの具体例を示す図である。 表示部に表示されるステージマップ画面の具体例を示す図である。 表示部に表示されるステージマップ画面の他の具体例を示す図である。 仮想空間のデータ構造の一例を示す図である。 表示部に表示されるステージマップ画面のさらに他の具体例を示す図である。 表示部に表示されるステージマップ画面のさらに他の具体例を示す図である。 表示部に表示されるステージマップ画面のさらに他の具体例を示す図である。

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

＜ゲームシステム１のハードウェア構成＞
図１は、ゲームシステム１のハードウェア構成を示す図である。ゲームシステム１は図示の通り、複数のユーザ端末１００と、サーバ２００とを含む。各ユーザ端末１００は、サーバ２００とネットワーク２を介して接続する。ネットワーク２は、インターネットおよび図示しない無線基地局によって構築される各種移動通信システム等で構成される。この移動通信システムとしては、例えば、所謂３Ｇ、４Ｇ移動通信システム、ＬＴＥ（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）ディスプレイ等によって構成される。

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

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

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

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

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

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

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

＜ゲーム概要＞
本実施形態に係るゲームシステム１において実現されるゲーム（以下、本ゲーム）は、一例として、複数のゲーム内プレイ要素（以下、プレイ要素）で構成される。プレイ要素とは、ユーザにプレイさせるゲームの内容を所定の規則に基づいて区切る単位である。ゲームの内容は、例えば、テーマ、ゲーム内での位置付け、または、分量などの所定の規則に基づいて、プレイ要素単位で区切られる。ユーザは、プレイ要素の１つ１つを選択することができ、該プレイ要素単位で、ゲームプレイに興じる。

本ゲームは、複数のプレイ要素が提示され、ユーザが、プレイ要素ごとにゲームに興じるような形態を有するものであれば、どのようなジャンルのゲームであってもよい。例えば、テニス、卓球、ドッジボール、野球、サッカーおよびホッケーなどのスポーツを題材としたゲーム、パズルゲーム、クイズゲーム、ＲＰＧ、クイズＲＰＧ、アドベンチャーゲーム、シューティングゲーム、シミュレーションゲーム、育成ゲーム、ならびに、アクションゲームなどであってもよい。

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

本ゲームは、例えば、クイズＲＰＧである。クイズＲＰＧは、一例として、１以上の味方キャラクタで編成されたデッキを用いて、デッキ内の味方キャラクタが敵キャラクタと戦うバトルを１回以上進行させるクエストをプレイ要素として含む。本クイズＲＰＧでは、一例として、バトルは、ターン制で進行する。１つのターンは、味方キャラクタのそれぞれが所定の回数、バトルにおける行動を実施する機会と、敵キャラクタのそれぞれが同じく所定の回数、バトルにおける行動を実施する機会とが含まれる。本クイズＲＰＧでは、一例として、１つのターンにおける味方キャラクタの行動を決定するためのコマンド入力を、コマンドの選択肢を単にユーザに選択させることに代えて、クイズを採用することにより実現する。本クイズＲＰＧでは、一例として、基本的に、１ターンにつき１問出題される。具体的には、本クイズＲＰＧでは、バトルにおける行動を実施する機会において、ユーザに出題するクイズのジャンルを選択させ、選択されたジャンルのクイズを出題し、その解答をユーザから受け付け、解答結果に応じて味方キャラクタの行動を決定するという一連の処理を実施する。

上述の味方キャラクタは、例えば、該味方キャラクタを表したカードを模すように構成されたデジタルデータとして提供されることがあり、特に、クイズＲＰＧの世界観またはそこで展開される物語の文脈に応じて、精霊、選手などと呼ばれることがある。デッキは、文脈に応じて、パーティー、チーム、オーダーなどと呼ばれることがある。

なお、上述のカードをユーザに提供する形態は、特に限定されない。デジタルデータとしてのカードが、通信ネットワークを介して、サーバ２００からユーザ端末１００に送信されてもよい。あるいは、サーバ２００において、カードが該ユーザのユーザ識別情報と関連付けてメモリ２１に記憶されており、ユーザ端末１００が、サーバ２００から任意に、ユーザが所有するカードを読み出すことができる構成であってもよい。あるいは、カードは、コード、パスワード、バーコード、ＱＲコード（登録商標）などが印字された物理媒体で、ユーザに販売または提供されてもよい。この場合、該物理媒体に印字された情報をユーザ端末１００に読み取らせて、カードに関連付けられた情報（例えば、味方キャラクタに関する情報）をユーザ端末１００が実行するゲーム上で利用できる状態にする。

本実施形態では、一例として、クエストに含まれる１回以上のバトルのそれぞれにおいて、クイズを実施し、該クイズに対するユーザのプレイ結果に応じて該バトルが進行する。具体的には、ゲームシステム１は、出題された問題に対するユーザの解答の正否に応じて味方キャラクタの動作を決定し、各味方キャラクタに所定の動作を実施させる。所定の動作としては、例えば、敵キャラクタへダメージを与えるための攻撃動作が想定される。

また、バトルは、ターン制に則って進行してもよい。例えば、１つのターンは、少なくとも、味方キャラクタの攻撃の機会（すなわち、ユーザへの出題、ユーザによる解答、それに伴う味方キャラクタの攻撃）と、敵キャラクタの攻撃の機会とを含む。

バトルは、終了条件が満たされるまで継続される。バトルは、例えば、（１）味方キャラクタの攻撃を受けた敵キャラクタが全滅することにより、ユーザが編成したデッキのパーティーが勝利すること、（２）敵キャラクタの攻撃を受けた味方キャラクタが全滅することにより該パーティーが敗北すること、または、（３）ユーザによってリタイヤ（途中棄権）の操作がなされること、などを終了条件として終了する。

本実施形態に係るゲームシステム１が提供するクイズＲＰＧは、上述のクエストをプレイするプレイパートの他に、例えば、ユーザが手持ちのカードに基づいてデッキを編成するためのデッキ編成パートを含んでいてもよい。ユーザは、デッキ編成パートにおいて、所定のユーザインターフェース（ＵＩ）画面を操作し、バトルに参加させる味方キャラクタを、手持ちのカードの中から選んでデッキに組み入れる。

（スキルについて）
なお、本クイズＲＰＧでは、ゲーム、とりわけ、クエストの中のバトルの興趣性を向上させるために、味方キャラクタのそれぞれに、該キャラクタ固有のスキルが設定されている。

スキルは、キャラクタのそれぞれが固有に備える特殊能力であり、バトルの進行中において所定の条件に基づいて発動される。スキルの定義は、図示しない、ユーザごとに作成されたキャラクタデータベースにおいて、キャラクタに関連付けて記憶されている。スキルは、バトルにおいて、味方キャラクタにとって有利な効果をもたらす。スキルの作用は、味方キャラクタに直接及んでもよいし、敵キャラクタに及ぶことによって間接的に味方キャラクタに利益をもたらしてもよい。

スキルは、例えば、スキルの内容と、該スキルによる効果の程度とによって定義される。効果の程度は、例えば、数値で表される。スキルを定義する要素として、さらに、該スキルが発動可能となる条件が含まれていてもよい。

スキルの具体例として、例えば、敵キャラクタに対して特攻によりダメージを与えるスキル、味方キャラクタの攻撃力が一時的にアップするスキル、味方キャラクタの体力が回復するスキル、敵キャラクタからの攻撃により受けるダメージを軽減するスキル、および、敵キャラクタの守備力を下げるスキルなどがあってもよい。これらのスキルが発動可能となる条件は、該スキルを有するすべてのキャラクタにおいて共通であってもよいし、キャラクタごとに異なっていてもよい。

スキルの効果の程度を表す数値として、例えば、「３００％（のダメージ）」とは、通常の攻撃、すなわち、クイズに正答したときに実施される攻撃の３倍のダメージを与えることを意味する。

スキルは、例えば、クイズが出題されてから所定時間内に、ユーザが早く正答できた場合に、クイズに正答したときに実施される攻撃と併せて自動的に発動してもよい。このように正答の速さに基づいて発動するスキルを速答スキルと称してもよい。あるいは、スキルは、例えば、複数ターンに亘って、ユーザが所定数以上正答数を積み上げた場合に、発動可能となるものであって、該スキルをユーザが任意のタイミングで発動させることができてもよい。このように累積の正答数に基づいて発動するスキルを累積スキルと称してもよい。あるいは、スキルは、複数ターンに亘って、誤答することなく所定回数以上連続で正答した場合に、発動可能となってもよい。このように連続正答数に基づいて発動するスキルを連答スキルと称してもよい。

一例として、累積スキルとしては、解答時に実施される通常の攻撃とは別に、該累積スキルを発動させたときに敵キャラクタに直接ダメージを与えることが可能な攻撃タイプの累積スキル、味方キャラクタの体力を回復させる回復タイプの累積スキル、および、他の味方キャラクタの性能を模倣して、バトル中に、該他の味方キャラクタのようにふるまうことを可能にするコピータイプの累積スキルなどがある。

＜ゲーム構成＞
図３は、本ゲームの内容に基づく構成の一例を示す図である。本実施形態では、一例として、本ゲームを構成する各プレイ要素は、階層構造を有する。まず、本ゲームは、第１階層として１以上のエリアを有する。各エリアは、第２階層として１以上のステージを有する。各ステージは、第３階層として１以上のクエストを有する。

各クエストは、１つ以上のバトルのフェーズと、結果出力のフェーズとを含む。クエストに含まれるすべてのバトルが終了すると、該クエストのプレイ結果が出力されて、該クエストが終了する。すべてのバトルに勝利した場合、該クエストがクリアされたと判定される。なお、結果出力のフェーズでは、クエストのクリア判定、プレイ成績、または、プレイ報酬としてユーザに付与されるゲーム内価値が、ユーザに対して提示される。

本実施形態では、本ゲームに含まれる各プレイ要素は、すべてが一度に解放されなくてもよい。「プレイ要素が解放される」とは、該プレイ要素が、ユーザに選択可能にかつプレイ可能に提示されることを意味する。一部のプレイ要素が解放され、残りのプレイ要素はロックされていてもよく、この場合、先に解放されているプレイ要素をクリアすることにより、解放要件が満たされて、残りのプレイ要素が解放されてもよい。

一例として、１つのステージ内の各クエストは、クエスト１がクリアされたらクエスト２が解放され、クエスト２がクリアされたらクエスト３が解放される、というように、直列的に順次解放されてもよい。本実施形態では、１つのステージに含まれるすべてのクエストがクリアされると、該ステージがクリアされたと判定される。

一例として、１つのエリア内の各ステージは、１〜３個程度のグループ単位で順次解放されてもよい。例えば、ステージ１〜３がクリアされたら、ステージ４が解放され、ステージ４がクリアされたら、ステージ５〜６が解放され、ステージ５〜６がクリアされたら、ステージ７〜９が解放される、というように、１〜３個ずつステージが解放されてもよい。本実施形態では、１つのエリアに含まれるすべてのステージがクリアされると、該エリアがクリアされたと判定される。

一例として、エリアは、クエストと同様に、直列で順次解放されてもよい。本実施形態では、１つのエリアに含まれるすべてのステージがクリアされて、該エリアがクリアされたと判定されると、次のエリアが解放される。

以上のとおり、各プレイ要素は、先に解放されているプレイ要素がクリアされることを解放要件としてロックされており、先のプレイ要素がクリアされることにより、該解放要件が満たされて解放される。すなわち、ユーザが選択してプレイできるようになる。

本実施形態では、さらに、本ゲームは、上述の通常のプレイ要素の他に、隠しプレイ要素を含む。隠しプレイ要素とは、先に解放されているプレイ要素をクリアするだけでは解放要件が満たされないプレイ要素のことであり、先のプレイ要素をクリアするということ以外に特殊な解放要件が設定されている特殊なプレイ要素のことである。

一例として、本ゲームは、特定のエリア、例えば、エリアＮにおいて隠しプレイ要素を含む。具体的には、エリアＮは、隠しプレイ要素として、シークレットステージを含む。シークレットステージには、通常のステージ１〜最終ステージをクリアすること以外にも、特殊な解放要件が設定されており、該シークレットステージは、先のステージのクリアによって順次解放される通常のステージ１〜最終ステージとは区別される。

本実施形態では、一例として、シークレットステージの解放要件として、通常のステージ１〜最終ステージをクリアすることに加えて、クエストの進行状況に応じて増減する要件パラメータを、目標値に到達させること、という特殊な解放要件が設定される。

具体的には、まず、ユーザは、エリアＮにおいて、通常のステージ１〜最終ステージをクリアする。さらに、ユーザは、通常のステージ１〜最終ステージ内の各クエストをプレイし、クエストを進めることによって、要件パラメータを増減させながら、最終的に要件パラメータを目標値に到達させる。本実施形態では、クエストの進行状況がどのような場合に要件パラメータが増加あるいは減少するのかがあらかじめ定められている。しかし、本実施形態では、要件パラメータが増加あるいは減少する条件は、ユーザに対して明示されない。ユーザは、クエストをどのように進めれば要件パラメータを増加させることができるのか確信がないまま、要件パラメータを目標値に到達させるためにクエストをプレイする。ユーザは、同じクエストを何回繰り返しプレイしてもよい。ユーザが、クエストのプレイを繰り返すうちに、要件パラメータを目標値に到達させることができた場合に、上述のシークレットステージが解放される。

シークレットステージも、通常のステージと同様に、１以上のシークレットクエストを含む。シークレットステージに含まれるクエストを、通常のステージに含まれるクエストと区別するためにシークレットクエストと称する。ただし、シークレットステージが解放された後は、各シークレットクエストは、通常のクエストと同様に、直列で順次解放されてもよい。例えば、シークレットクエスト１がクリアされると、シークレットクエスト２が解放され、シークレットクエスト２がクリアされると、シークレットクエスト３が解放される。

上述のゲーム構成によれば、ユーザは、エリア内のステージをクリアした後も、思いがけず新しいシークレットステージを発見して、該シークレットステージのプレイに興じることができる。

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

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

サーバ２００は、各ユーザ端末１００と通信して、ユーザ端末１００がゲームを進行させるのを支援する機能を有する。ゲームがマルチプレイゲームである場合には、サーバ２００は、ゲームに参加する各ユーザ端末１００と通信して、ユーザ端末１００同士のやりとりを仲介する機能を有していてもよい。サーバ２００は、プロセッサ２０、メモリ２１、ストレージ２２、通信ＩＦ２３、および入出力ＩＦ２４等の協働によって、制御部２１０および記憶部２２０として機能する。

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

（サーバ２００の機能的構成）
制御部２１０は、記憶部２２０に格納されたゲームプログラム２３１を実行することにより、サーバ２００を統括的に制御する。例えば、制御部２１０は、ユーザ端末１００に各種データおよびプログラム等を送信する。制御部２１０は、ゲーム情報もしくはユーザ情報の一部または全部をユーザ端末１００から受信する。ゲームがマルチプレイゲームである場合には、制御部２１０は、ユーザ端末１００からマルチプレイの同期の要求を受信して、同期のためのデータをユーザ端末１００に送信してもよい。

制御部２１０は、ゲームプログラム２３１の記述に応じて、進行支援部２１１として機能する。制御部２１０は、実行するゲームの性質に応じて、ユーザ端末１００におけるゲームの進行を支援するために、図示しないその他の機能ブロックとしても機能することができる。

進行支援部２１１は、ユーザ端末１００と通信し、ユーザ端末１００が、本ゲームに含まれる各種のプレイパートを進行させるための支援を行う。例えば、本ゲームは、クエスト選択パート、デッキ編成パート、クエスト進行パート、抽選パートなどを含んでいる。進行支援部２１１は、上述の各プレイパートのいずれが実行されているのかに応じて、そのときにユーザ端末１００が参照すべき情報を適宜提供する。また、進行支援部２１１は、ユーザ端末１００が各プレイパートを実行した結果をユーザ端末１００から受け付けて、記憶部２２０に保存し、上述の結果をゲーム情報１３２またはユーザ情報１３３に反映させる。

例えば、クエスト選択パートとは、複数のプレイ要素の中からプレイしたいプレイ要素をユーザが選択するためのゲームパートである。クエスト選択パートにおいて、ユーザ端末１００が各プレイ要素をユーザに選択可能に提示するために必要な情報を、進行支援部２１１が、ユーザ端末１００に対して提供する。

例えば、デッキ編成パートとは、クエストのバトルに参加させるキャラクタをユーザが選択するためのゲームパートである。本実施形態では、ユーザは、ゲーム内で１以上のデッキを保有しており、デッキを構成する各ポジションに、自身が保有する味方キャラクタを対応付けて、デッキを編成する。デッキを構成する各ポジションには、バトルで果たすべき一定の役割が予め対応付けられていてもよいし、バトル中で採用される陣形の位置関係が対応付けられていてもよいし、バトル中で行動を起こす順番が対応付けられていてもよい。あるいは、各ポジションは、デッキにおいて、単なる「枠」の意味しか持たず、デッキが、バトルに参加するキャラクタの組み合わせを単に示すものであってもよい。

デッキ編成パートにおいて、デッキ編成に関する一連の入力操作を行うためのＵＩをユーザ端末１００がユーザに提示するために必要な情報を、進行支援部２１１が、ユーザ端末１００に対して提供する。

例えば、クエスト進行パートとは、ユーザがクエストをプレイするためのゲームパートである。本実施形態では、ユーザ端末１００は、クエストに含まれる１以上のバトルのフェーズと、該１以上のバトルが終了した後の結果を出力する結果出力のフェーズとを進行させる。クエスト進行パートにおいて、ユーザがクエストを進めるためのＵＩをユーザ端末１００がユーザに提示するために必要な情報を、進行支援部２１１が、ユーザ端末１００に対して提供する。

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

制御部１１０は、ゲームプログラム１３１の記述に応じて、要素提示部１１１、要素制御部１１２、クエスト進行部１１３、および、パラメータ処理部１１４として機能する。

なお、制御部１１０は、実行するゲームの性質に応じて、ゲームを進行させるために、図示しないその他の機能ブロックとしても機能することができる。

さらに、制御部１１０は、図示しない操作受付部、および、表示制御部などとしても機能する。操作受付部は、入力部１５１に対するユーザの入力操作を検知し受け付ける。例えば、操作受付部は、上述の入力操作の、入力部１５１における入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部は、例えば、タッチ操作、スライド操作、スワイプ操作、およびタップ操作等を特定する。表示制御部は、タッチスクリーン１５の表示部１５２に対して、制御部１１０の各部によって実行された処理結果が反映されたゲーム画面を出力する。表示制御部は、制御部１１０の各部によって生成された映像を含むゲーム画面を表示部１５２に表示してもよい。また、表示制御部は、グラフィカルユーザインターフェース（以下、ＧＵＩ）を、該ゲーム画面に重畳して描画してもよい。

要素提示部１１１は、クエスト選択パートを実行して、ユーザが所望のプレイ要素を選択するためのＵＩを提示する。具体的には、要素提示部１１１は、ユーザがプレイしたいエリアを選択するためのＵＩであるエリアマップを表示したり、ユーザがプレイしたいステージを選択するためのＵＩであるステージマップを表示したり、ユーザがプレイしたいクエストを選択するためのクエストリストを表示したりする。

要素制御部１１２は、各プレイ要素の解放要件の達成進捗を監視して、各プレイ要素のロックおよび解放を制御する。具体的には、要素制御部１１２は、通常のプレイ要素については、先に解放されているプレイ要素のクリア状況に応じて、ロックされているプレイ要素を解放する。また、要素制御部１１２は、隠しプレイ要素については、先に解放されているプレイ要素のクリア状況と、要件パラメータに関する特殊な解放要件の達成進捗とに応じて、ロックされている隠しプレイ要素を解放する。

クエスト進行部１１３は、クエスト進行パートを実行して、ユーザの入力操作に応答して、クエストを進行させる。

パラメータ処理部１１４は、クエスト進行部１１３がクエストを進行させている間、隠しプレイ要素の特殊な解放要件に係る要件パラメータを処理する。例えば、パラメータ処理部１１４は、クエスト進行部１１３が実行するクエストの進行状況に応じて、上述の要件パラメータを更新する。一例として、パラメータ処理部１１４は、クエストの進行状況が、所定の状況に至れば、要件パラメータを増加させ、また、クエストの進行状況が、別の所定の状況に至れば、要件パラメータを減少させる。本実施形態では、パラメータ処理部１１４が要件パラメータを増減させた結果、クエストが終了した時点で、要件パラメータが目標値に到達していれば、要素制御部１１２は、隠しプレイ要素の特殊な解放要件が満たされたと判定する。

また、本実施形態では、パラメータ処理部１１４は、クエスト進行部１１３がクエストを進行させている間、隠しプレイ要素の特殊な解放要件に係る要件パラメータを更新した場合に、必要に応じて、更新したことをユーザにフィードバックする。具体的には、パラメータ処理部１１４は、要件パラメータを更新したことを通知するためのＵＩを提示する。

なお、本実施形態では、一例として、初期値が０である要件パラメータが増減を繰り返した結果、０より多い目標値、例えば、１０００に到達した場合に、要素制御部１１２が、特殊な解放要件が満たされたと判定してもよい。この場合、別の例では、パラメータ処理部１１４は、要件パラメータについて、進行状況に応じて増分のみ実施する構成であってもよい。

別の実施形態では、初期値が０より多い、例えば１０００である要件パラメータが増減を繰り返した結果、目標値である０に到達した場合に、要素制御部１１２が特殊な解放要件が満たされたと判定してもよい。この場合、別の例では、パラメータ処理部１１４は、要件パラメータについて、進行状況に応じて減算のみ実施する構成であってもよい。

本実施形態では、一例として、パラメータ処理部１１４は、隠しプレイ要素が含まれるエリアにおいて、クエスト進行部１１３がクエストを実行している間、並行して要件パラメータに係る処理を実行する。

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

＜処理概要＞
図４は、ゲームシステム１、例えば、ユーザ端末１００において実行される処理の流れを示すフローチャートである。

本実施形態では、ユーザ端末１００は、ゲームの興趣性を向上させるために、ゲームプログラム１３１に基づいて、以下のステップを実行するように構成されている。具体的には、ユーザ端末１００は、複数のプレイ要素をユーザが選択可能に提示するステップＳ１０１と、ユーザに選択されたプレイ要素を、該ユーザの入力操作に応答して進行させるステップＳ１０２と、複数のプレイ要素をクリアするのみでは解放する要件が満たされない特殊なプレイ要素である隠しプレイ要素を解放する要件に係る要件パラメータを、選択されたプレイ要素が開始してから終了するまでの所定のタイミングにおいて、例えば、ステップＳ１０２からステップＳ１０５までの所定のタイミングＳ１０３において、該プレイ要素の進行状況に応じて、更新するステップＳ１０３と、選択されたプレイ要素が開始してから終了するまでの所定のタイミングにおいて、例えば、ステップＳ１０２からステップＳ１０５までの所定のタイミングＳ１０４において、要件パラメータが更新される条件を開示することなく、要件パラメータが更新されたことを通知するステップＳ１０４と、を実行するように構成されている。さらに、ユーザ端末１００は、提示するステップにおいて、要件パラメータが要件を満たしている場合に、隠しプレイ要素を、複数のプレイ要素とともに、ユーザが選択可能に提示する。例えば、ユーザ端末１００は、ステップＳ１０６のＹＥＳからステップＳ１０７に進む。

一例として、上述の提示するステップでは、要件パラメータが要件を満たしていない間、隠しプレイ要素および該隠しプレイ要素の存在を示唆するオブジェクトを表示せず、上述の通知するステップでは、要件パラメータが、隠しプレイ要素を解放する解放要件に関連していることを明示しないことが好ましい。

一例として、通知するステップでは、更新するステップにおいて、プレイ要素が進行している間の所定のタイミングにて要件パラメータが更新されたときに、該要件パラメータが更新されたことをユーザに通知することが好ましい。

一例として、通知するステップでは、進行させるステップによって進行したプレイ要素が終了するときに、更新された後の要件パラメータを、要件パラメータが解放要件を満たしたと判定されるときの値である目標値とともに通知することが好ましい。

＜データ構造＞
（要件情報）
図５は、要件情報のデータ構造の一例を示す図である。要件情報は、隠しプレイ要素の解放要件を定義するための情報であり、一例として、テーブルの構造を有した要件テーブルとして生成される。本実施形態では、要件テーブルは、ゲームシステム１につき１つ生成され、ゲームシステム１内の各装置、すなわち、サーバ２００と、各ユーザ端末１００との間で共有される。

要件テーブルは、一例として、要件ＩＤ、要件名、ヒント、詳細ヒント、判定タイミング、更新条件、および、更新量の各項目を有する。

要件ＩＤの項目には、特殊な解放要件の１つ１つを識別するための識別情報が格納されている。隠しプレイ要素の特殊な解放要件が、すべてのエリアおよびすべてのユーザに共通で１つしかない場合には、要件ＩＤを設定する必要はないので、該項目は省略されてもよい。本実施形態では、一例として、あるエリアに含まれている１つのシークレットステージにつき、４つの特殊な解放要件が設定されている。図５には、その４つの解放要件を定義する要件テーブルが図示されており、要件ＩＤ００１〜００４によって、４つの解放要件がゲームシステム１において識別可能になっている。

別の例では、１つのシークレットステージにつき、１つの特殊な解放要件が設定されてもよい。また、シークレットステージは、１つまたは複数のエリアにおいて複数設定されてもよい。この場合、さらに、シークレットステージを識別するステージＩＤを格納する項目を設けて、ステージＩＤと要件ＩＤとを関連付けて上記要件テーブルに記憶させておく。これにより、ユーザ端末１００は、要件テーブルを参照して、どのシークレットステージにどの特殊な解放要件が設定されているのかを識別することができる。

要件名の項目には、１つの特殊な解放要件をユーザに識別させるために、該特殊な解放要件に付された名称が格納されている。特殊な解放要件の名称は、ゲームの世界観または該ゲームで展開される物語などの文脈に応じて、適切な名称が設定されることが好ましい。例えば、本実施形態では、特殊な解放要件に係る要件パラメータが、クエスト進行中に起こるどのような事象に関連して更新されるのか、すなわち、要件パラメータの更新条件を連想させる端的な言葉が、該解放要件の名称として選択される。すなわち、要件名は、要件パラメータの更新条件を暗示するものであってもよい。

ヒントの項目には、要件パラメータの更新条件を、要件名よりも具体的にユーザに想起させるためのヒントとなる一文が格納されている。ユーザに更新条件を想起させるためのヒントとなる一文は、ゲームの世界観または該ゲームで展開される物語などの文脈に応じて、かつ、容易に想起され過ぎない適度な難易度となるように暗示的に、適切に作文されることが好ましい。

詳細ヒントの項目には、要件パラメータの更新条件を、上述の一文のヒントよりも一層具体的にユーザに想起させるためのより詳細なヒントとなる文章群が格納されている。ユーザに更新条件を想起させるためのより詳細なヒントとなる文章群は、ゲームの世界観または該ゲームで展開される物語などの文脈に応じて、かつ、更新条件を直接的に明示しないように、適切に作文されることが好ましい。

判定タイミングの項目には、パラメータ処理部１１４が、クエストの進行中において、要件パラメータの更新条件が満たされたか否かを判定するタイミングを指定する情報が格納されている。例えば、要件ＩＤ「００１」の第１の解放要件に関して、要件パラメータの更新条件を判定するタイミングは、「クエストクリア時」と指定されている。パラメータ処理部１１４は、クエスト進行中のクエストクリア時のタイミングにおいて、クエストの進行状況、具体的には、該タイミングにおいて発生した事象が、要件ＩＤ「００１」の、後述する更新条件を満たすか否かを判定する。

更新条件の項目には、要件パラメータを更新するトリガとなるクエスト進行中の事象を定義する情報、すなわち、要件パラメータの更新条件が格納されている。本実施形態では、パラメータ処理部１１４が実行する要件パラメータの更新は、値を増分すること、および、値を減算することの両方を含む。したがって、更新条件の項目において、要件パラメータを増分するための第１の更新条件と、要件パラメータを減算するための第２の更新条件とが定義される。

例えば、要件ＩＤ「００１」の第１の解放要件「生存」に関して、パラメータ処理部１１４は、クエストクリア時における生存している味方キャラクタの数を参照し、その数が、第１の更新条件および第２の更新条件のいずれかを満たしているか否かを判定する。パラメータ処理部１１４は、味方キャラクタの数が、第１の更新条件を満たしている場合、第１の解放要件「生存」に係る要件パラメータを増分し、第２の更新条件を満たしている場合、該要件パラメータを減算する。味方キャラクタの数が、いずれの更新条件も満たさない場合には、パラメータ処理部１１４は、該要件パラメータの更新を行わない。

更新量の項目には、更新条件が満たされた場合に、要件パラメータを更新する量を規定する情報が格納されている。本実施形態では、一例として、すべての解放要件において更新量は共通であるとする。具体的には、パラメータ処理部１１４は、クエストの進行状況が第１の更新条件を満たす場合には、要件パラメータを、３０増分し、第２の更新条件を満たす場合には、要件パラメータを、２５減算する。別の実施形態では、解放要件ごとに、更新量を規定してもよい。例えば、１つのクエストで、何度も判定タイミングが訪れる第３の解放要件「００３」および第４の解放要件「００４」については、更新量の絶対値を小さく、例えば、増加量を「＋１０」、減少量を「＋８」と規定してもよい。一方、１つのクエストで、１度しか判定タイミングが訪れない第１の解放要件「００１」については、更新量の絶対値を大きく、例えば、増加量を「＋５０」、減少量を「−４０」と規定してもよい。

なお、解放要件ごとの更新条件について、ある解放要件では、要件パラメータがプラスになる事象が、同時に満たさなければならない別の解放要件においてはマイナスになるような、内容的に矛盾する更新条件の設定は行わないようにしてもよい。これにより、隠しプレイ要素を解放することの難易度が徒に上がることを避け、謎を解き明かして隠しプレイ要素を暴きたいというユーザのモチベーションを損なわないようにすることができる。

上述のような設定で容易に隠しプレイ要素を解放してしまったユーザが、謎解きの難易度に物足りなさを感じることも想定される。このようなユーザに対しては、高難度の隠しプレイ要素を用意し、当該高難度の隠しプレイ要素に係る複数の解放要件につき、内容的に矛盾する更新条件を設定してもよい。隠しプレイ要素解放までのハードルを高くすることで、謎解き要素の興趣性を格段に向上させることができる。また、難易度が高い分、隠しプレイ要素が解放されたときに、ユーザに、より大きな達成感、充実感などを与えることができる。

（進捗情報）
図６は、進捗情報のデータ構造の一例を示す図である。進捗情報は、ユーザが、クエストのプレイを通じて、隠しプレイ要素を解放するための１以上の解放要件を、それぞれ、どれだけ達成しているのか、すなわち、解放要件の達成進捗を管理するための情報である。一例として、進捗情報は、テーブルの構造を有した進捗テーブルとして生成される。本実施形態では、進捗テーブルは、ユーザごとに生成され、ゲームシステム１内の各装置、すなわち、サーバ２００と、各ユーザ端末１００との間で共有される。具体的には、ユーザ端末１００は、該ユーザ端末１００を使用するユーザの進捗テーブルをゲーム情報１３２として記憶部１２０に保持する。サーバ２００は、各ユーザの進捗テーブルを、ユーザのユーザＩＤに関連付けて、ゲーム情報１３２として記憶部２２０に保持する。ユーザ端末１００とサーバ２００との各装置にて保持されている進捗テーブルは、適時更新され、同期がとれている。

進捗テーブルは、一例として、要件ＩＤ、要件パラメータ、目標値、および、達成フラグの各項目を有する。

要件ＩＤの項目には、特殊な解放要件の１つ１つを識別するための、上述の識別情報が格納されている。

要件パラメータの項目には、要件パラメータの現在値が格納されている。本実施形態では、一例として、要件パラメータが後述の目標値以上に到達した場合に、解放要件が満たされたと判定される。

目標値の項目には、該特殊な解放要件が満たされたとされる要件パラメータの目標値が格納されている。本実施形態では、一例として、すべての解放要件につき、一律、目標値が「１０００」と定められている。それぞれの特殊な解放要件に係る要件パラメータが目標値である「１０００」に到達した場合に、該解放要件が満たされたと判定される。別の実施形態では、解放要件ごとに、それぞれの目標値が設定されてもよい。

達成フラグの項目には、特殊な解放要件が満たされたか否かを示すフラグが格納されている。本実施形態では、一例として、「１」は達成済、「０」は未達成を意味する。パラメータ処理部１１４は、クエストの進行状況に応じて要件パラメータを更新した結果、更新後の現在値が上述の目標値に到達した場合に、「０」から「１」へと、達成フラグを更新する。要素制御部１１２は、進捗テーブルに定義されているすべての特殊な解放要件について、達成フラグの項目に達成済を意味する「１」が格納されている場合に、隠しプレイ要素の特殊な解放要件がすべて満たされたと判定する。本実施形態では、要素制御部１１２は、特殊な解放要件と、その他の通常の解放要件とが併せてすべて満たされた場合に、隠しプレイ要素を解放する。

なお、要件パラメータの項目において、０未満の値、および、１０００を超える値を格納してもよい。ユーザに通知するのは、０〜１０００の値だとしても、要件パラメータを、内部的に、０未満の値〜１０００を超える値を持つように処理することができる。

本実施形態では、パラメータ処理部１１４は、一度、要件パラメータが目標値に到達したとしても、その後減算されたことによって、再び、要件パラメータが目標値を下回った場合には、達成フラグを「１」から「０」に更新する。

これにより、ユーザは、すべての特殊な解放要件を同時に満たすことを要求されることとなり、隠しプレイ要素を解放するためのプレイの難易度が上がる。隠しプレイ要素解放までのハードルを高くすることで、謎解き要素の興趣性を格段に向上させることができる。また、難易度が高い分、隠しプレイ要素が解放されたときに、ユーザに、より大きな達成感、充実感などを与えることができる。

別の実施形態では、一度でも目標値が達成された解放要件について、パラメータ処理部１１４は、達成フラグを「１」の状態で固定してもよい。この場合、パラメータ処理部１１４は、一度、要件パラメータが目標値に到達したら、その後は、クエストがいかなる状況に進行したとしても、該要件パラメータを更新する処理を行わないか、もしくは、更新したとしても、達成フラグを「１」の状態から「０」へ更新する処理を行わない。

これにより、一度目標値が達成された解放要件は、達成済の状態が維持されるので、ユーザは、残りの目標未達の解放要件のみを意識して、クエストをプレイすることができる。ユーザは、別の解放要件を満たすことを意識してプレイした結果、すでに達成済の解放要件を再び未達の状態に戻してしまうことがないので、このことによるストレスを感じずに済む。これにより、ユーザが、隠しプレイ要素を解放することをあきらめてしまって、クエストをプレイしなくなるという事態を回避することができる。

＜処理フロー＞
（クエストの進行フロー）
図７は、ユーザ端末１００のクエスト進行部１１３が実行する、クエストを進行させる処理の流れを示すフローチャートである。本実施形態では、クエスト進行中に、パラメータ処理部１１４が要件パラメータに係る処理を実行する。したがって、図７に示すフローチャートは、パラメータ処理部１１４が実行する要件パラメータに係る処理の流れも示す。

要素提示部１１１がユーザから受け付けた、クエストを選択する入力操作、および、クエストの開始を指示する入力操作に応答して、クエスト進行部１１３は、クエストを開始する。

ステップＳ２０１にて、パラメータ処理部１１４は、クエスト進行部１１３が開始したクエストについて、進行状況の監視を開始する。

ステップＳ２０２において、クエスト進行部１１３は、例えば、エンカウント処理を実行してもよい。一例として、エンカウント処理は、（１）クエスト内のバトルをすべてクリアしたときの進行率を１００％とした場合の現在の進行率をカウントし、表示すること、（２）主人公またはデッキに編成した味方キャラクタを含むパーティーが進軍中であることを演出するアニメーションを表示すること、（３）パーティーを、所定の進行率にて所定の敵キャラクタ群と遭遇させること、（４）パーティーを、ランダムでまたは所定の規則にしたがって、希少価値が高い敵キャラクタ群と遭遇させること、および、（５）敵キャラクタと遭遇したことを演出するアニメーションを表示すること、などを含む。

ステップＳ２０３において、クエスト進行部１１３は、バトルのフェーズを開始して、バトル画面を表示部１５２に表示させる。一例として、バトルがターン制で進行する場合、クエスト進行部１１３は、１つのターンを開始して、該ターンの初期状態であるバトル画面を表示する。この後、クエスト進行部１１３は、ゲームプログラムにしたがって、味方キャラクタの行動の前に、敵キャラクタに所定の先制行動を実施させてもよい。さらにその後、クエスト進行部１１３は、ターゲッティング処理を実施してもよい。ターゲッティング処理とは、ユーザの指示にしたがって、どの味方キャラクタにどの敵キャラクタを攻撃させるのかを決定する処理である。ユーザは、例えば、バトル画面において、味方キャラクタのカードが表示されている領域を始点として、攻撃相手の敵キャラクタのカードが表示されている領域までスライド操作する。このスライド操作により、ユーザは、攻撃主体と攻撃対象とを対応付けることができる。

ステップＳ２０４において、クエスト進行部１１３は、ユーザの指示にしたがって、スキルを発動する処理を実施してもよい。本実施形態では、味方キャラクタには、スキルと称される能力が設定されている。味方キャラクタがスキルを発動すると、バトルに有利に効果がもたらされる。ここでは、例えば、クエスト進行部１１３は、味方キャラクタに累積スキルを発動させてもよい。ステップＳ２０４において、累積スキルが発動されたとき、パラメータ処理部１１４は、更新条件を満たす事象が発生したか否かを判定してもよい。そして、パラメータ処理部１１４は、判定結果に応じて要件パラメータを更新してもよい。パラメータ処理部１１４は、要件パラメータを更新したとき、その旨を、状況に応じてユーザに対して通知してもよい。

ステップＳ２０５において、クエスト進行部１１３は、図示しない操作受付部を介して、クイズのジャンルを示す出題パネルの選択を受け付ける。例えば、ユーザは、バトル画面に配置される出題パネルのうちの１つをタップ操作して選択する。クエスト進行部１１３は、操作受付部が検知したタップ位置に基づいて、いずれの出題パネルが選択されたのかを判別する。ステップＳ２０５において、出題パネルが選択されたとき、パラメータ処理部１１４は、更新条件を満たす事象が発生したか否かを判定してもよい。そして、パラメータ処理部１１４は、判定結果に応じて要件パラメータを更新してもよい。例えば、第４の解放要件に関して、第１の更新条件に定義されたジャンルの出題パネルが選択された場合には、パラメータ処理部１１４は、第４の解放要件に係る要件パラメータを３０増分する。また、第２の更新条件に定義されたジャンルの出題パネルが選択された場合には、パラメータ処理部１１４は、該要件パラメータを２５減算する。パラメータ処理部１１４は、要件パラメータを更新したとき、その旨を、状況に応じてユーザに対して通知してもよい。

ステップＳ２０６において、クエスト進行部１１３は、クイズを実行する。具体的には、選択された出題パネルに紐付けられている問題を提示し、併せて解答ＧＵＩを提示して、ユーザの解答を受け付ける。解答ＧＵＩは、ユーザが出された問題に対する解答を入力するためのＵＩ部品で構成されている。ステップＳ２０６において、解答が入力されたとき、パラメータ処理部１１４は、更新条件を満たす事象が発生したか否かを判定してもよい。そして、パラメータ処理部１１４は、判定結果に応じて要件パラメータを更新してもよい。例えば、第３の解放要件に関して、出題からユーザが解答を入力するまでの経過時間が１秒以上であった場合には、パラメータ処理部１１４は、第３の解放要件に係る要件パラメータを３０増分する。また、上述の経過時間が１秒未満であった場合には、パラメータ処理部１１４は、該要件パラメータを２５減算する。パラメータ処理部１１４は、要件パラメータを更新したとき、その旨を、状況に応じてユーザに対して通知してもよい。

ステップＳ２０７において、クエスト進行部１１３は、クイズの進行状況に応じて、攻撃などの所定の行動を味方キャラクタに実施させる。一例として、クエスト進行部１１３は、ユーザがクイズに正答した場合に、味方キャラクタに、敵キャラクタを攻撃させる。味方キャラクタが敵キャラクタに攻撃することにより、味方キャラクタは、敵キャラクタにダメージを与えることができる。クエスト進行部１１３は、与えたダメージの大きさに相当するダメージ値を、敵キャラクタの体力から減算する。

ステップＳ２０８において、クエスト進行部１１３は、すべての敵キャラクタの体力が０になったか否かを判定する。クエスト進行部１１３は、体力が０を超える敵キャラクタが１体でも残っている場合には、ステップＳ２０８のＮＯからステップＳ２０９に進む。一方、クエスト進行部１１３は、すべての敵キャラクタの体力が０になった場合には、ステップＳ２０８のＹＥＳからステップＳ２１３に進む。

ステップＳ２０９において、クエスト進行部１１３は、生き残っている該敵キャラクタに、味方キャラクタを攻撃させる。クエスト進行部１１３は、与えたダメージの大きさに相当するダメージ値を、味方キャラクタの体力から減算する。

ステップＳ２１０において、クエスト進行部１１３は、すべての味方キャラクタの体力が０になったか否かを判定する。クエスト進行部１１３は、体力が０を超える味方キャラクタが１体でも残っている場合には、ステップＳ２１０のＮＯからステップＳ２０３に戻り、次のターンを開始する。クエスト進行部１１３は、すべての味方キャラクタの体力が０になった場合には、ステップＳ２１０のＹＥＳからステップＳ２１１に進む。

ステップＳ２１１において、クエスト進行部１１３は、味方キャラクタの敗北によりバトルが終了したと判定する。

ステップＳ２１２において、クエスト進行部１１３は、すべての味方キャラクタの体力が０になったこと、すなわち、バトル不能状態に陥ったことに基づいて、クエストのクリアに失敗したと判定し、すべてのバトルのフェーズを強制的に終了させる。

一方、ステップ２１３において、クエスト進行部１１３は、すべての敵キャラクタの体力が０になったこと、すなわち、バトルに登場するすべての敵キャラクタを倒したことに基づいて、味方キャラクタの勝利によりバトルが終了したと判定する。

ステップＳ２１４において、クエスト進行部１１３は、クエストに含まれているすべてのバトルが終了したか否かを判定する。まだ、実行されていないバトルが残っている場合、つまり、進行率が１００％に到達していない場合には、クエスト進行部１１３は、ステップＳ２１４のＮＯからステップＳ２０２に戻り、以降の処理を繰り返す。一方、すべてのバトルが終了している場合には、クエスト進行部１１３は、ステップＳ２１４のＹＥＳからステップＳ２１５に進む。

ステップＳ２１５において、クエスト進行部１１３は、クエストに含まれるすべてのバトルに勝利したことに基づいて、該クエストのクリアに成功したと判定し、すべてのバトルのフェーズを終了する。ステップＳ２１５の、すべてのバトルが終了した時点において、パラメータ処理部１１４は、更新条件を満たす事象が発生したか否かを判定してもよい。そして、パラメータ処理部１１４は、判定結果に応じて要件パラメータを更新してもよい。パラメータ処理部１１４は、要件パラメータを更新したとき、その旨を、状況に応じてユーザに対して通知してもよい。

ステップＳ２１６において、パラメータ処理部１１４は、クエスト進行部１１３が、クエストに含まれるすべてのバトルを終了させたことに基づいて、進行状況の監視を終了する。そして、一連の各バトルの進行状況に応じて増減させた更新パラメータの現在値を確定させる。

ステップＳ２１７において、クエスト進行部１１３は、結果出力のフェーズを進行させる。具体的には、クエスト進行部１１３は、クエストの結果画面を表示する。結果画面では、例えば、該クエストのクリアの成否判定、クエストのプレイ報酬としてユーザが獲得した仮想通貨、経験値、カード、または、アイテムなどが表示される。さらに、パラメータ処理部１１４は、確定した要件パラメータを示すＵＩを表示してもよい。

（第２の解放要件に係る要件パラメータの処理フロー）
図８は、ユーザ端末１００のパラメータ処理部１１４が実行する、要件パラメータに係る処理の流れを示すフローチャートである。具体的には、図８は、第２の解放要件（要件ＩＤ「００２」）に係る要件パラメータの処理の流れを示す。図８に示す一連の処理は、図７に示すステップＳ２０４がクエスト進行部１１３によって実行されている間に、パラメータ処理部１１４によって並行して実行される。

ステップＳ３０１では、パラメータ処理部１１４は、図５に示す要件テーブルにおいて第２の解放要件「００２」につき定義された第１の更新条件が満たされているか否かを判定する。具体的には、パラメータ処理部１１４は、ステップＳ２０４にて発動された累積スキルのタイプが、攻撃タイプであるか否かを判定する。発動された累積スキルが攻撃タイプであれば、パラメータ処理部１１４は、第１の更新条件が満たされたと判定し、ステップＳ３０１のＹＥＳからステップＳ３０２に進む。発動された累積スキルが攻撃タイプでなければ、パラメータ処理部１１４は、第１の更新条件は満たされなかったと判定し、ステップＳ３０１のＮＯからステップＳ３０３に進む。

ステップＳ３０２では、パラメータ処理部１１４は、第２の解放要件「００２」に係る要件パラメータを、３０増分する。

ステップＳ３０３では、パラメータ処理部１１４は、第２の解放要件「００２」につき定義された第２の更新条件が満たされているか否かを判定する。具体的には、パラメータ処理部１１４は、ステップＳ２０４にて発動された累積スキルのタイプが、コピータイプであるか否かを判定する。発動された累積スキルがコピータイプであれば、パラメータ処理部１１４は、第２の更新条件が満たされたと判定し、ステップＳ３０３のＹＥＳからステップＳ３０４に進む。発動された累積スキルがコピータイプでなければ、パラメータ処理部１１４は、第１の更新条件に加えて第２の更新条件も満たされなかったと判定し、ステップＳ３０３のＮＯからステップＳ３０７に進む。

ステップＳ３０４では、パラメータ処理部１１４は、第２の解放要件「００２」に係る要件パラメータを、２５減算する。

ステップＳ３０５では、パラメータ処理部１１４は、現在進行中のクエストが含まれるエリアについて、すべてのステージがすでにクリアされているか否かを判定する。すなわち、パラメータ処理部１１４は、シークレットステージの解放要件のうち、通常の解放要件「エリア内のステージが最終ステージまでクリアされていること」が満たされているか否かを判定する。なお、判定自体は、要素制御部１１２が実行しており、その判定結果をパラメータ処理部１１４が要素制御部１１２から取得してもよい。最終ステージまでクリアされている場合、パラメータ処理部１１４は、ステップＳ３０５のＹＥＳからステップＳ３０６に進む。まだ最終ステージまでクリアされていない場合、パラメータ処理部１１４は、ステップＳ３０５のＮＯからステップＳ３０７に進む。

ステップＳ３０６では、パラメータ処理部１１４は、要件ＩＤ「００２」の解放要件に係る要件パラメータを増加または減少させたことを通知する。具体的には、パラメータ処理部１１４は、クエスト進行部１１３がスキルを発動させるときに表示させるゲーム画面に、要件パラメータの増減を通知するアイコンを重畳させる。

ステップＳ３０７では、パラメータ処理部１１４は、要件ＩＤ「００２」の解放要件に係る要件パラメータを増加または減少させたことの通知を行わない。したがって、上述のアイコンは重畳されずに、スキルを発動させるときに表示させるゲーム画面だけがクエスト進行部１１３によって表示部１５２に表示される。

（第１の解放要件に係る要件パラメータの処理フロー）
図９は、ユーザ端末１００のパラメータ処理部１１４が実行する、要件パラメータに係る処理の流れを示すフローチャートである。具体的には、図９は、第１の解放要件（要件ＩＤ「００１」）に係る要件パラメータの処理の流れを示す。図９に示す一連の処理は、図７に示すステップＳ２１５がクエスト進行部１１３によって実行されている間に、パラメータ処理部１１４によって並行して実行される。

ステップＳ４０１では、パラメータ処理部１１４は、図５に示す要件テーブルにおいて第１の解放要件「００１」につき定義された第１の更新条件が満たされているか否かを判定する。具体的には、パラメータ処理部１１４は、ステップＳ２１５にて最終バトルが終了した時点における、デッキ内の生存キャラクタ数が、１体および５体のいずれかであるか、または、それ以外の数かを判定する。生存キャラクタ数が、１体または５体であれば、パラメータ処理部１１４は、第１の更新条件が満たされたと判定し、ステップＳ４０１のＹＥＳからステップＳ４０２に進む。生存キャラクタ数が、それ以外の数、例えば、２体〜４体であれば、第２の更新条件が満たされたと判定し、ステップＳ４０１のＮＯからステップＳ４０３に進む。

ステップＳ４０２では、パラメータ処理部１１４は、第１の解放要件「００１」に係る要件パラメータを、３０増分する。

ステップＳ４０３では、パラメータ処理部１１４は、第１の解放要件「００１」に係る要件パラメータを、２５減算する。

ステップＳ４０４では、パラメータ処理部１１４は、バトルが終了した直後のクエストが含まれるエリアについて、すべてのステージがすでにクリアされているか否かを判定する。すなわち、パラメータ処理部１１４は、シークレットステージの解放要件のうち、通常の解放要件「エリア内のステージが最終ステージまでクリアされていること」が満たされているか否かを判定する。なお、判定自体は、要素制御部１１２が実行しており、その判定結果をパラメータ処理部１１４が要素制御部１１２から取得してもよい。最終ステージまでクリアされている場合、パラメータ処理部１１４は、ステップＳ４０４のＹＥＳからステップＳ４０５に進む。まだ最終ステージまでクリアされていない場合、パラメータ処理部１１４は、ステップＳ４０４のＮＯからステップＳ４０６に進む。

ステップＳ４０５では、パラメータ処理部１１４は、要件ＩＤ「００１」の解放要件に係る要件パラメータを増加または減少させたことを通知する。具体的には、パラメータ処理部１１４は、クエスト進行部１１３が最終バトル終了時に表示させるゲーム画面に、要件パラメータの増減を通知するアイコンを重畳させる。

ステップＳ４０６では、パラメータ処理部１１４は、要件ＩＤ「００１」の解放要件に係る要件パラメータを増加または減少させたことの通知を行わない。したがって、上述のアイコンは重畳されずに、最終バトル終了時に表示させるゲーム画面だけがクエスト進行部１１３によって表示部１５２に表示される。

＜画面例＞
（スキルが発動したときのゲーム画面）
図１０は、クエスト進行部１１３がクエストの進行中に表示部１５２に表示させるゲーム画面の一例を示す図である。具体的には、図１０に示すゲーム画面は、味方キャラクタが累積スキルを発動するという演出をユーザに提示するために表示されるスキル発動画面である。クエスト進行部１１３は、ステップＳ２０４にて、スキル発動画面を表示させる。

スキル発動画面３００は、一例として、以下のＵＩ部品を含む。具体的には、スキル発動画面３００は、出題パネル３０１〜３０４と、スキルを発動した味方キャラクタ３０５と、味方キャラクタのデッキ３０６と、連続正答ポイント３０７と、味方キャラクタの属性を示すアイコン３０８とを含む。さらに、スキル発動画面３００は、状況に応じて、シークレットステージの存在をほのめかす第１の示唆アイコン３０９と、要件パラメータが更新されたことをほのめかす第２の示唆アイコン３１０とを含むことがある。パラメータ処理部１１４は、ステップＳ３０６にて、スキル発動画面３００に、第１の示唆アイコン３０９および第２の示唆アイコン３１０を重畳させる。

出題パネル３０１〜３０４は、ステップＳ２０３にて、バトル画面（不図示）が表示部１５２に表示されて以降継続して表示されているＵＩ部品であり、ユーザにクイズのジャンルおよび出題される問題を選択させるためのＵＩ部品である。出題パネル３０１〜３０４に対する入力操作は、ステップＳ２０５にて受け付けられる。そのため、スキル発動画面３００において、味方キャラクタ３０５によるスキル発動の演出が出力されている間は、ジャンルを選択するための入力操作が受け付けられないようにロックされてもよい。

味方キャラクタ３０５は、スキルを発動した味方キャラクタを示すＵＩ部品である。例えば、その他の味方キャラクタと同様にカードとして、デッキ３０６の領域の定位置に配置されていた味方キャラクタが、スキルを発動するとき、上記定位置から飛び出して、味方キャラクタ３０５として、デッキ３０６の上部に表示される演出が出力されてもよい。

デッキ３０６には、ユーザがデッキ編成パートにおいてデッキに編成した味方キャラクタに対応するカードが、該デッキにおいて指定されたポジションに対応付けて配置される。デッキ３０６に配置されている各味方キャラクタのうち、累積スキルを発動できる状態にある味方キャラクタについては、味方キャラクタの属性を示すアイコン３０８の表示態様が変化してもよい。これにより、ユーザは、累積スキルを発動できる味方キャラクタを識別することができる。属性については後述する。

連続正答ポイント３０７は、１問も間違えずに連続して正答している問題数に応じて獲得されたポイントであり、例えば、１問につき１ポイント増分される。

第１の示唆アイコン３０９は、シークレットステージの存在をユーザにほのめかすためのＵＩ部品であり、例えば、シークレットステージに登場する謎のキャラクタのアイコンで実現される。第１の示唆アイコン３０９は、一目見てそれがシークレットステージを意味していると分かるような明示的な表示態様である必要はない。ユーザにとって、それが何を意味しているのか明確でない状態で第１の示唆アイコン３０９が通知されることにより、謎が深まり、その謎を解きたいとするユーザの好奇心や探究心を掻き立てることができる。パラメータ処理部１１４は、図８のステップＳ３０２またはＳ３０４において、要件パラメータの更新を行った場合、かつ、進行中のクエストが含まれるエリアにおいてすべてのステージがすでにクリアされている場合に、第１の示唆アイコン３０９をスキル発動画面３００に重畳させて表示する。

第２の示唆アイコン３１０は、何らかの値が更新されたことをユーザにほのめかすためのＵＩ部品であり、例えば、矢印のアイコンで実現される。第２の示唆アイコン３１０は、一目見てそれがシークレットステージの解放要件に係る要件パラメータの更新を意味していると分かるような明示的な表示態様である必要はない。ただし、第２の示唆アイコン３１０は、第１の示唆アイコン３０９とともに表示され、例えば、「上向き矢印」、「下向き矢印」など、一方から一方への動きを表す表示態様であることが好ましい。

これにより、ユーザは、第１の示唆アイコン３０９で示唆されている何らかの存在に関連する何らかの値が更新されたことだけを認識する。結果として、第１の示唆アイコン３０９および第２の示唆アイコン３１０が何を意味するのかという謎が深まり、その謎を解きたいとするユーザの好奇心や探究心を掻き立てることができる。パラメータ処理部１１４は、例えば、要件パラメータを増加させたときに、上向き矢印の第２の示唆アイコン３１０を表示させ、要件パラメータを減少させたときに、下向き矢印の第２の示唆アイコン３１０を、第１の示唆アイコン３０９の下側に表示させる。これにより、ユーザは、第１の示唆アイコン３０９に係る何らかの値が、増減することを認識することができる。

また、パラメータ処理部１１４は、第１の示唆アイコン３０９および第２の示唆アイコン３１０を、スキル発動画面３００の表示中に重畳表示させる。したがって、ユーザに、スキルの発動に関連して値の増減が起こっているのではないかと推測するように促すことができる。

なお、属性は、キャラクタを性質で分類した場合にどの性質に該当するのかを示すパラメータである。本実施形態では、一例として、各キャラクタには、火、雷、および、水の３つの属性のいずれかが設定される。属性は、味方キャラクタにも敵キャラクタにも設定されていてもよい。また、各キャラクタには、「火＋水」など複数の属性が設定されていてもよい。以下では、このようなキャラクタを複属性キャラクタと称する。

デッキに組み入れられた味方キャラクタの属性は、バトルにおける各種の値を決定したり、味方キャラクタの行動を決定したりするために、バトルの進行中においても参照される。各属性には、互いに、有利な属性および不利な属性が設定されていてもよい。例えば、火は雷に、雷は水に、水は火に対して有利であるように設定されていてもよい。より具体的には、バトルにおいて、火属性のキャラクタは、雷属性の敵キャラクタに対して、通常よりも多くのダメージを与えられるなどが考えられる。また、バトルにおいて、同属性同士の味方キャラクタがバトルに有利な相互作用を与え合うことなどが考えられる。

本実施形態では、バトル中に提示される出題パネルにも、属性が設定されている。例えば、クエスト進行部１１３は、問題にユーザが正答すること、かつ、味方キャラクタが、該問題が紐付いている出題パネルに設定されている属性を少なくとも１つ有していることを条件に、バトルに係る所定の行動を該味方キャラクタに実施させる。つまり、出題パネルに設定されている属性と同じ属性を持つ味方キャラクタだけがそのターンの攻撃に参加できるように、クエスト進行部１１３が進行を制御する。

したがって、設定されている属性の数が多い出題パネルほど、それに正答した場合に、より多くの味方キャラクタを攻撃に参加させることができるため、バトルに勝利しやすくなる。

ここで、クエスト進行部１１３は、出題パネルに紐付いている問題の難易度が高いほど、多くの数の属性が該出題パネルに設定されるように、出題パネルを提示することが好ましい。これにより、バトルにおける戦略が多様化し、ゲームの興趣性を一層向上させることが可能となる。例えば、ユーザは、攻撃参加できる味方キャラクタが少なくなっても、誤答のリスクを回避して難易度の低い問題に挑戦することもできるし、できるだけ多くの味方キャラクタを攻撃参加させるために、あえて難易度の高い問題に挑戦することもできる。

本実施形態では、クエスト進行部１１３は、バトルに係る所定の行動（攻撃など）を実施する条件を満たす味方キャラクタに、該所定の行動を、該味方キャラクタが有するすべての属性について実施させることが好ましい。これにより、クエスト進行部１１３は、ユーザが問題に正答した場合に、該問題が紐付いている出題パネルに設定されている属性を少なくとも１つ有する味方キャラクタに、攻撃などの所定の行動を、該味方キャラクタが有する属性の数に相当する回数分実施させることができる。

例えば、クエスト進行部１１３は、火属性１色または火＋雷属性の２色の出題パネルの問題にユーザが正答した場合に、火＋水の属性を持つ味方キャラクタに、火属性の攻撃行動を１回、水属性の攻撃行動を１回、計２回の攻撃行動を実施させる。ここで、クエスト進行部１１３は、出題パネルの属性と一致していない水属性分の攻撃行動に関しては、該味方キャラクタの攻撃力を５０％に補正した上でダメージ値を算出することが好ましい。

また、例えば、クエスト進行部１１３は、火＋水属性の２色の出題パネルの問題にユーザが正答した場合に、火＋水の属性を持つ味方キャラクタに、同じく、計２回の攻撃行動を実施させる。ここで、クエスト進行部１１３は、火属性、水属性ともに、味方キャラクタが有する属性と、出題パネルに設定されている属性とが一致しているので、２回とも該味方キャラクタが本来持つ攻撃力に基づいてダメージ値を算出する。

このように、複属性キャラクタは、１つの属性しか有しない単属性キャラクタと比較して攻撃などバトルに係る行動を起こす機会を多く得られる。ユーザは、この点に魅力を感じながら、また、この点を活かせるクエストにて、所有する複属性キャラクタをバトルに参加させてゲームを楽しむことができる。

（最終バトルが終了したときのゲーム画面）
図１１は、クエスト進行部１１３がクエストに含まれる最終バトルの終了時に表示部１５２に表示させるゲーム画面の一例を示す図である。具体的には、図１１に示すゲーム画面は、クエストに含まれるすべてのバトルに味方キャラクタが勝利し、クエストがクリアされたことをユーザに通知するために表示されるクリア通知画面である。クエスト進行部１１３は、ステップＳ２１５にて、クリア通知画面を表示させる。

クリア通知画面４００は、一例として、以下のＵＩ部品を含む。具体的には、クリア通知画面４００は、クリア判定通知４０１を含む。さらに、クリア通知画面４００は、状況に応じて、シークレットステージの存在をほのめかす第１の示唆アイコン４０２と、要件パラメータが更新されたことをほのめかす第２の示唆アイコン４０３とを含むことがある。パラメータ処理部１１４は、ステップＳ４０５にて、クリア通知画面４００に、第１の示唆アイコン４０２および第２の示唆アイコン４０３を重畳させる。

クリア判定通知４０１は、クエストに含まれるすべてのバトルに味方キャラクタが勝利し、クエストがクリアされたことをユーザに通知するＵＩ部品であり、例えば、「ＣＬＥＡＲ」の文字列を含むアイコンで実現される。

第１の示唆アイコン４０２は、図１０と同様に、シークレットステージの存在をユーザにほのめかすためのＵＩ部品である。

第２の示唆アイコン４０３は、図１０と同様に、何らかの値が更新されたことをユーザにほのめかすためのＵＩ部品である。

例えば、パラメータ処理部１１４は、図９のステップＳ４０２において、要件パラメータを増分した場合、かつ、プレイされたクエストが含まれるエリアにおいてすべてのステージがすでにクリアされている場合に、第１の示唆アイコン４０２とともに、上向き矢印の第２の示唆アイコンをクリア通知画面４００に重畳させて表示する。パラメータ処理部１１４は、図９のステップＳ４０３において、要件パラメータを減算した場合、かつ、プレイされたクエストが含まれるエリアにおいてすべてのステージがすでにクリアされている場合には、上向き矢印に代えて、図１１に示すとおり、下向き矢印の第２の示唆アイコン４０３をクリア通知画面４００に重畳させて表示する。

これにより、ユーザは、第１の示唆アイコン４０２で示唆されている何らかの存在に関連する何らかの値が更新されたことを認識する。また、ユーザは、第２の示唆アイコン４０３により、第１の示唆アイコン４０２に係る何らかの値が、増加または減少することを認識することができる。

ここで、第１の示唆アイコン４０２がシークレットステージを意味していることは明示されないことが好ましく、また、値が増加または減少した理由も明示されないことが好ましい。これにより、第１の示唆アイコン４０２および第２の示唆アイコン４０３が何を意味するのかという謎が深まり、その謎を解きたいとするユーザの好奇心や探究心を掻き立てることができる。

（プレイ結果を出力するときのゲーム画面）
図１２は、クエスト進行部１１３が、クエスト内のバトルを終了させた後に表示部１５２に表示させるゲーム画面の一例を示す図である。具体的には、図１２に示すゲーム画面は、クエスト内のバトルにおいて味方キャラクタが全滅して敗北したか、または、すべてのバトルに勝利したかによってバトルフェーズが終了した後、該クエストのプレイ結果をユーザに通知するために表示される結果画面である。クエスト進行部１１３は、ステップＳ２１７にて、結果画面を表示させる。

結果画面５００は、結果表示ウィンドウ５０１を含む。結果表示ウィンドウ５０１は、クエストのプレイ結果をユーザに通知するためのＵＩ部品である。結果表示ウィンドウ５０１には、図示されていないが、例えば、プレイされたクエストのクリアの成否判定、該クエストのプレイ報酬としてユーザが獲得した仮想通貨、経験値、カード、または、アイテムなどが表示される。

本実施形態では、一例として、パラメータ処理部１１４は、結果画面５００に重ねて、要件表示ウィンドウ５０２を表示させる。要件表示ウィンドウ５０２は、シークレットステージを解放するための特殊な解放要件をユーザがどこまで達成しているか、すなわち、解放要件の達成進捗をユーザに提示するためのＵＩ部品である。

要件表示ウィンドウ５０２は、一例として、解放要件情報５０３を含む。さらに、要件表示ウィンドウ５０２には、バトル中に示唆された第１の示唆アイコン３０９および４０２と同じ第１の示唆アイコン５０７が配置されてもよい。これにより、要件表示ウィンドウ５０２の下部に示される各解放要件情報５０３が、バトル中に増減していた何らかの値に関連するものであるとユーザが推測することができる。要件表示ウィンドウ５０２は、ＯＫボタン５０８を含んでもよい。例えば、ＯＫボタン５０８がタップされると、パラメータ処理部１１４は、要件表示ウィンドウ５０２を閉じる。これにより、要件表示ウィンドウ５０２によって隠れていた結果表示ウィンドウ５０１の部分が見られるようになる。

解放要件情報５０３は、シークレットステージの特殊な解放要件に関する情報をユーザに提示するためのＵＩ部品であり、解放要件ごとに作成される。解放要件情報５０３は、一例として、達成進捗５０４と、ヒント５０５と、詳細ボタン５０６とを含む。

達成進捗５０４は、要件パラメータの目標値に対する現在値の割合を示すＵＩ部品であり、割合は、例えば、ゲージ、分数、パーセンテージなどによって表現される。パラメータ処理部１１４は、進捗テーブルにおいて特殊な解放要件ごとに関連付けられている目標値と要件パラメータの現在値とに基づいて、達成進捗５０４を作成する。

ヒント５０５は、要件パラメータの更新条件がクエスト中に発生するどのような事象と関連しているのかをユーザに推測させるためのヒントとなる一文をユーザに提示するＵＩ部品である。パラメータ処理部１１４は、要件テーブルにおいて特殊な解放要件ごとに関連付けられているヒントの一文に基づいて、ヒント５０５を作成する。

詳細ボタン５０６は、要件パラメータの更新に関連する事象についてヒント５０５よりも具体的に言及した詳細ヒントをユーザが呼び出すために操作するＵＩ部品である。例えば、詳細ボタン５０６がタップされると、パラメータ処理部１１４は、要件表示ウィンドウ５０２に重ねて、詳細ヒントを提示するためのＵＩ部品であるヒント表示ウィンドウを表示させる。

図１３は、ヒント表示ウィンドウの一例を示す図である。パラメータ処理部１１４は、詳細ボタン５０６がタップされると、詳細ボタン５０６に対応付けられている特殊な解放要件についてのヒント表示ウィンドウ５１１を表示させる。具体的には、パラメータ処理部１１４は、詳細ボタン５０６に対応付けられている特殊な解放要件についての要件名と詳細ヒントとを要件テーブルから読み出し、これらの読み出した情報に基づいてヒント表示ウィンドウ５１１を生成する。パラメータ処理部１１４は、ヒント表示ウィンドウ５１１を、上述したとおり、要件表示ウィンドウ５０２に重ねて表示させてもよいし、別のゲーム画面に切り替えて表示させてもよい。

ヒント表示ウィンドウ５１１は、一例として、要件名５１２、詳細ヒント５１３、および、ＯＫボタン５１４を含む。要件名５１２には、要件テーブルにおいて、詳細ボタン５０６に対応付けられている特殊な解放要件、例えば、第１の解放要件「００１」に関連付けられている要件名が配置される。詳細ヒント５１３には、要件テーブルにおいて、第１の解放要件「００１」に関連付けられている詳細ヒントが配置される。ＯＫボタン５１４は、ヒント表示ウィンドウ５１１を閉じる指示をユーザが入力するためのＵＩ部品である。例えば、ＯＫボタン５１４がタップされると、パラメータ処理部１１４は、ヒント表示ウィンドウ５１１を閉じる。これにより、要件表示ウィンドウ５０２が再び見られるようになる。

（シークレットステージがロックされているときのゲーム画面）
図１４は、要素提示部１１１が、ユーザにプレイ要素を選択させるために表示部１５２に表示させるゲーム画面の一例を示す図である。具体的には、図１４に示すゲーム画面は、ユーザが、複数のエリアの中から所望のエリアを選択した後、該エリア内の各ステージをユーザに選択可能に提示するステージマップ画面である。要素提示部１１１は、エリアマップを介してユーザからエリアの選択を受け付けた後、図４に示すステップＳ１０１に先行して、ステージマップ画面を表示させる。なお、図１４に示すステージマップ画面は、特殊な解放要件が満たされていないときに表示される画面である。

ステージマップ画面６００は、例えば、選択されたエリア全土をイメージした背景画像６０１上に、ステージアイコン７１、７２、および、７６などを配置して構成される。また、背景画像６０１は、表示部１５２の１画面に収まらない領域を有していてもよい。この場合、要素提示部１１１は、背景画像６０１の非表示領域を、スクロールすることによって表示できることを示すスクロールアイコン６０２を配置してもよい。例えば、スクロールアイコン６０２は、背景画像６０１にはさらに右に続きがあり、背景画像６０１を左にスクロールさせることにより、該右の非表示領域を表示可能であることを示す。

本実施形態では、要素提示部１１１は、入力部１５１の全領域、すなわち、ステージマップ画面６００が表示されている領域の任意の位置においてユーザのスワイプ操作を受け付ける。そして、要素提示部１１１は、ユーザのスワイプ操作の始点から終点までのＸ座標上の移動量に応じて、背景画像６０１を右または左にスクロールさせる。別の実施形態では、スクロールアイコン６０２は、単なる表示のＵＩ部品ではなく、ユーザのタップ操作に応答して背景画像６０１を一定量左にスクロールさせる機能が対応付けられたＵＩ部品として構成されてもよい。

ステージアイコン７１〜７６は、ユーザにステージを選択させるためのＵＩ部品である。ステージアイコンのそれぞれには、図３に示すとおり、１つのプレイ要素としての１つのステージが対応付けられている。ステージアイコンには、対応付けられているステージのステージ番号が付されていてもよい。また、クリアされたステージのステージアイコンには、クリア済みであることが分かる表記が付加されていてもよい。例えば、ユーザが、ステージアイコンをタップすると、要素提示部１１１は、タップされたステージアイコンに対応するステージに含まれている１以上のクエストからなるクエストリストをステージマップ画面６００から切り替えて表示する。

本実施形態では、要素提示部１１１は、エリア内にシークレットステージが含まれている場合であっても、シークレットステージの解放要件が満たされていない場合は、シークレットステージのステージアイコンを表示しない。一例として、要素提示部１１１は、シークレットステージの存在を示唆するようなオブジェクトも一切非表示とする。これにより、シークレットステージが解放されたときには、ユーザに、シークレットステージを思いがけずに発見した喜びを与えることができる。別の実施形態では、シークレットステージの存在を示唆するようなオブジェクトを、シークレットステージのステージアイコンが表示される予定の位置に配置してもよい。これにより、何らかの秘密が隠されていることさえユーザが気付かず、謎解きに挑戦しようとすら思わない（思う機会が失われる）というリスクを回避することができる。

（シークレットステージが解放されているときのゲーム画面）
図１５は、ステージマップ画面の他の例を示す図である。具体的には、図１５に示すステージマップ画面６５０は、特殊な解放要件が満たされているときに表示される画面である。図４に示すステップＳ１０５においてクエストが終了した結果、ステップＳ１０６において要素制御部１１２がシークレットステージのすべての解放要件が満たされたと判定した場合に、要素提示部１１１は、ステップＳ１０７において、ステージマップ画面６５０を表示させる。

ステージマップ画面６５０は、図１４に示すステージマップ画面６００と比較して、シークレットステージのステージアイコン７７を含む点で異なる。ステージアイコン７７は、ユーザが選択可能に、可視状態にて、背景画像６０１上に配置される。ユーザが、ステージアイコン７７をタップすると、要素提示部１１１は、シークレットステージに含まれている１以上のシークレットクエストからなるクエストリストをステージマップ画面６５０から切り替えて表示する。

以上のように、ユーザが見慣れたいつものステージマップ画面に、通常のステージのステージアイコンと同列に、シークレットステージのステージアイコン７７が選択可能に配置される。したがって、シークレットステージのステージアイコン７７は、予告などが行われず、解放要件が満たされたことに応答して、ユーザにとっては不意に表示されることになる。これにより、シークレットステージが解放されたときには、ユーザに、シークレットステージを思いがけずに発見した喜びを与えることができる。

以上の各ゲーム画面に配置されている各種のＵＩ部品によって、ユーザは、クエスト内のバトルの進行中に、要件パラメータが更新されたそのタイミングで、要件パラメータが増えたり減ったりしていることのフィードバックを受け取ることができる。加えて、ユーザは、クエストが終了する直前に、最終的に各要件パラメータがどれだけ増減し、結果、各解放要件がどれだけ達成されているのかのフィードバックを受け取ることができる。また、ユーザは、達成進捗のフィードバックを受けたタイミングで、目標を達成するための糸口となるヒントを簡単な操作で呼び出し、確認することができる。最後に、目標が達成されると、すでにクリア済みのステージが配置されていて、ユーザがこれまで見慣れていたマップに、シークレットステージのアイコンが選択可能に表示される。

これにより、シークレットステージを解放するまでの道筋は明示されずにその存在だけが、ユーザに認知され、さらに、シークレットステージを解放するまでの道筋を推測させるようなヒントがクエストの進行中の適切なタイミングで提示される。結果として、謎を解きたいとするユーザの好奇心や探究心を掻き立て、ゲームの興趣性を格段に向上させることができる。

さらに、特殊な解放要件が満たされると、いつもの見慣れたマップに全く新しいシークレットステージのアイコンが追加される。これにより、ユーザに、これまで隠されていたものを思いがけず発見する楽しみを与えることができる。

また、特殊な解放要件は、すでにクリアされているクエストをユーザが繰り返しプレイすることにより満たされるように規定されている。これにより、ユーザは、すでにクリア済みのクエストに対しても、新たに提示された謎を解くために、必要性を感じて、新鮮な気持ちで取り組むことができる。

また、すでに製作済みのプレイ要素を活用して少しの隠しプレイ要素を付加するだけで、長くユーザを飽きさせないゲームを実現することができる。ゲームを提供する運営側にとっては、全く新規のコンテンツを次々に製作することと比較して少ない労力で、長くユーザを飽きさせないゲームを実現することができ、大きなメリットがある。

〔実施形態２〕
従来、ステージやクエストなどのプレイ要素をユーザに選択させるゲームにおいては、平面上にプレイ要素に対応するオブジェクトをユーザが選択可能に並べて配置することが一般的に行われてきた。さらには、図１４に示すように、背景などが描かれた２Ｄ画像上にオブジェクトを重ねて配置することも行われている。２Ｄ画像に描かれている内容物の位置を考慮してオブジェクトを配置することにより、ユーザがゲームの世界観に浸れるような演出することが可能となっている。

一方、ＶＲ（Virtual Reality）技術などのように、３次元の仮想ゲーム空間と仮想カメラと各種のオブジェクトを定義して、ゲームの世界を立体的に表現し、ユーザがあたかもゲームの世界における国や街などを探索しているかのような没入感を演出することが可能となっている。当然のことながら、ゲームの世界を表現する表現力は、２Ｄ画像を用いた場合と比較にならないほど、格段に向上する。しかしながら、こうした技術においては、ゲームの世界への没入感を高める代償として、一般的に負荷が高い処理が必要となり、また、ユーザに対しても非常に煩雑な入力操作を要求することになる。

単にユーザにプレイ要素を選択させるということを主な機能とするＵＩに対して、上記の代償を払ってまでＶＲ技術を用いた表現を採用することのメリットは低い。とりわけ、ゲームを実行するコンピュータとして、大きさやメモリ容量などハードウェア的な制約が極端に大きいスマートフォンなどの携帯端末が想定されている場合には、ＶＲ技術を採用することは困難である。

プレイ要素を選択させるということを主な機能とするＵＩについて、コンピュータの処理負荷を上げることなく、また、ユーザに煩雑な入力操作を強いることなく、一層表現力が豊かなＵＩを実現し、ゲームの世界への没入感を高めたい。実施形態２では、このような表現力豊かなＵＩを実現するためのゲームシステム１の構成について説明する。

図１６は、プレイ要素としての１つのエリアを空間として定義する仮想空間のデータ構造の一例を示す図である。仮想空間７００は、エリアごとにあらかじめ作成されており、サーバ２００およびユーザ端末１００によって共有されている。具体的には、仮想空間は、サーバ２００の記憶部２２０およびユーザ端末１００の記憶部１２０に記録されている。

仮想空間７００には、例えば、互いに異なる向きを持つ３つの軸に基づいて３次元座標系が規定されている。一例として、３次元座標系における、第１の方向、具体的には水平方向、第２の方向、具体的には前後方向、および、第３の方向、具体的には鉛直方向は、それぞれ、Ｘ軸、Ｙ軸、および、Ｚ軸と規定される。

本実施形態では、Ｘ軸方向は、ユーザの入力操作を受け付けるユーザ端末１００（具体的には、タッチスクリーン１５の入力部１５１）の操作面における水平方向に対応している。

仮想空間７００には、一例として、以下のオブジェクトが配置される。例えば、レール５０、仮想カメラ５１、遠景６０、近景６１〜６３、ステージアイコン７１、７２、７６および７７などが配置される。また、別の実施形態では、図示しない複雑な地形の地面や天井などのオブジェクトが配置されていてもよい。

オブジェクトのうち、レール５０および仮想カメラ５１は、不可視オブジェクトである。要素提示部１１１は、これらの不可視オブジェクトが、仮想カメラ５１の画角に収まったとしても、これらの不可視オブジェクトをステージマップ画面に表示させない。なお、不可視オブジェクト以外の残りのオブジェクトを可視オブジェクトと総称する。

レール５０は、仮想カメラ５１の移動経路を規定するオブジェクトである。本実施形態では、レール５０は、Ｘ座標の最小値（例えば、０）をとる任意の位置（図示の例では、仮想空間７００における最左端）から、Ｘ座標の最大値（例えば、８）をとる任意の位置（図示の例では、仮想空間７００における最右端）に至るように敷かれる。より具体的には、レール５０の位置は、レール５０上のすべての点について、Ｘ座標を入力として、Ｙ座標およびＺ座標が一意に決まるように規定される。レール５０を構成する各点には、Ｙ座標およびＺ座標に加えて、仮想カメラ５１の向き５９が対応付けて記憶されている。レール５０上の各点を定義する粒度、すなわち、分解能は、想定されるコンピュータの情報処理能力、または、出力されるステージマップ映像のフレームレートなどに応じて適宜定めればよい。以上のデータ構造により、Ｘ座標を入力として、仮想カメラ５１のＹ座標およびＺ座標が一意に定まるとともに、仮想カメラ５１の向きも一意に定まるものとする。なお、本実施形態では、仮想カメラ５１の画角は、仮想カメラ５１の位置によらず一律であるものとする。

本実施形態では、Ｘ座標の入力は、仮想空間７００に基づくステージマップ映像が表示部１５２に表示されているときに、ユーザがタッチスクリーン１５の入力部１５１（操作面）の任意の位置をスワイプ操作することによってなされる。具体的には、要素提示部１１１は、タッチスクリーン１５上のスワイプ操作によるタッチ位置の始点から終点までのＸ軸上の移動量を、仮想空間７００におけるＸ軸上の移動量に変換する。そして、スワイプ操作入力直前の仮想カメラ５１の位置を始点として、レール５０に沿って仮想カメラ５１を移動させ、スワイプ操作入力直後の仮想カメラ５１の位置まで移動させる。

要素提示部１１１は、仮想カメラ５１の移動に伴って、仮想カメラ５１が移動するレール５０上の各点から得られる仮想カメラ５１の位置（ＸＹＺ座標）と向き５９とに基づいて仮想カメラ５１が捉えたとされる画像を逐次レンダリングし、それによって得られた映像を表示部１５２に出力する。

上述の構成によれば、ユーザは、図１４などの２Ｄ画像で表現されたステージマップ画面６００を操作するときと同じ簡易な操作によって、仮想空間７００に基づくステージマップ画面のスクロールを行うことができる。

図１７は、本実施形態に係る、ユーザにステージを選択させるためのステージマップ画面の一例を示す図である。ステージマップ画面６８０は、仮想カメラ５１の移動に伴って、仮想空間７００内に表現されたエリアの一部を映すステージマップ映像６８１を含む。また、ステージマップ画面６８０は、仮想空間７００内の１画面に収まらない非表示空間を、スクロールすることによって表示できることを示すスクロールアイコン６８２を含んでいてもよい。図１７に示すステージマップ画面６８０は、仮想カメラのＸ座標がＸ１であるときに得られる映像、すなわち、仮想カメラ５１の視野領域に基づいてレンダリングされた画像をステージマップ映像６８１のうちの一フレームとして表示している。

要素提示部１１１は、仮想カメラ５１のＸＹＺ座標および向きに応じて、仮想空間７００上の可視オブジェクトを、図示しない投影面（例えば、遠景６０と同じ位置にあってもよい）に投影することにより、仮想カメラ５１の視野領域に基づく画像をレンダリングし、レンダリングによって得られた画像を、ステージマップ画面６８０に配置するステージマップ映像６８１の各フレームとして逐次出力する。

このとき、要素提示部１１１は、例えば、投影対象となった可視オブジェクトと仮想カメラ５１との距離に応じて、可視オブジェクトを一時的に非表示にしたり、可視オブジェクトの表示サイズを変更したり、ぼかしをかけたり、遠いほど青みがかった色にするなど色味を調整したりする画像処理を行ってよい。具体的には、本実施形態では、要素提示部１１１は、近景６１〜だけでなく、ステージアイコン７１〜についても、仮想カメラ５１との距離が遠いほど表示サイズが小さくなるように投影し、さらに、一定の距離以上離れたステージアイコン７１〜を非表示にする。これらの画像処理によって、遠近感をより正確に再現することが可能となる。また、要素提示部１１１は、遠景６０に対しては他の可視オブジェクトに施すような画像処理を省略してもよい。これにより、例えば、空、雲、太陽など、非常に遠くのものがまとめて描画された遠景６０のオブジェクトと仮想カメラ５１との距離をユーザに意識させないようにして、全体として違和感のない映像を出力することが可能となる。

図１７に基づいて具体的に説明すれば、ステージマップ映像６８１として、近景６１〜６３が描画される。要素提示部１１１は、仮想カメラ５１に近い近景６１および６２については、それぞれ、対応するステージアイコン７１および７２を描画する。一方、近景６３に対応するステージアイコン７６および７７は、仮想カメラ５１の画角に入っているものの、仮想空間７００において、仮想カメラ５１とのＹ軸上の距離が一定以上離れている。要素提示部１１１は、このことに基づいて、ステージアイコン７６および７７を描画しない。

本実施形態において、図１６に示す仮想空間７００の左に行くほど、仮想空間７００におけるＸ座標の値は小さい。図１７に示すステージマップ映像６８１は、仮想空間７００におけるＸ座標の最小値、すなわち、最左端を投影しており、ステージマップ映像６８１をこれ以上右にスクロールさせることは許容されていない。そこで、要素提示部１１１は、右方向へのスクロールが可能であることを示すスクロールアイコンを表示しないとともに、これ以上右にスクロールさせるためのスワイプ操作を受け付けない。

一方、仮想空間７００は、右にさらに広がっており、ステージマップ映像６８１を左にスクロールさせることが可能である。そこで、要素提示部１１１は、ステージマップ映像６８１を左にスクロールさせるためのスワイプ操作を受け付け、また、左方向へのスクロールが可能であること、すなわち、右側に非表示の仮想空間７００が存在することを示すスクロールアイコン６８２をステージマップ画面６８０に配置する。例えば、要素提示部１１１は、タッチスクリーン１５上の、ある時点のユーザの指のタッチ位置と、一定時間後の該指のタッチ位置とがなすベクトルのＸ軸への正射影ベクトルから、仮想空間７００における仮想カメラ５１のＸ軸方向の移動量を算出し、移動後のＸ座標に基づいて特定されたレール５０上の位置および向きに仮想カメラ５１を移動させる。そして、要素提示部１１１は、移動後の仮想カメラ５１の位置および向きに基づいて、ステージマップ画面６８０に配置するステージマップ映像６８１を描画する。

本実施形態において、要素提示部１１１は、ステージマップ映像６８１上に、ステージアイコンが表示されている限りにおいては、該ステージアイコンに対するユーザからのタップ操作を受け付ける。そして、要素提示部１１１は、該タップ操作に応じて、例えば、タップされたステージアイコンに対するステージ内のクエストを一覧表示するクエストリストを表示させる。

図１８は、本実施形態に係る、ユーザにステージを選択させるためのステージマップ画面の他の例を示す図である。図１８に示すステージマップ画面６８０は、仮想カメラのＸ座標がＸ１とＸ２との間であるときに得られる映像、すなわち、仮想カメラ５２から得られるステージマップ映像６８１の一場面を表示している。

ユーザが図１７に示すステージマップ映像６８１が表示されているタッチスクリーン１５に対して、右から左へスワイプ操作を行ったとする。要素提示部１１１は、スワイプ操作に応答して、仮想カメラを５１の位置から５２の位置へと移動させる。

仮想カメラ５１から仮想カメラ５２へと位置が変更になったことに伴い、仮想カメラ５２と、近景６３、ステージアイコン７６および７７との距離が縮まる。そして、ステージアイコン７６および７７と仮想カメラ５２とのＹ軸上の距離は一定距離以内になったとする。この場合、要素提示部１１１は、近景６３を、図１７と比較して手前により大きく描画するとともに、ステージアイコン７６および７７の表示態様を、非表示から小さく表示する態様へと変更する。本実施形態では、要素提示部１１１は、ステージアイコンと仮想カメラ５２との距離が一定以上離れていることに基づき、アイコンの内容表記を行わず、アイコンの輪郭だけを小さく表示させてもよい。図１７に示すステージマップ映像６８１から図１８に示すステージマップ映像６８１へと至るまでの映像が漸次的に表示部１５２に出力されるので、ユーザは、徐々に近景６３へとまるで自分が近づいていくかのように感じながら、ステージマップ画面６８０を操作することができる。

図１９は、本実施形態に係る、ユーザにステージを選択させるためのステージマップ画面のさらに他の例を示す図である。図１８に示すステージマップ画面６８０は、仮想カメラのＸ座標がＸ２であるときに得られる映像、すなわち、仮想カメラ５３から得られるステージマップ映像６８１の一場面を表示している。

ユーザが図１８に示すステージマップ映像６８１が表示されているタッチスクリーン１５に対して、さらに右から左へスワイプ操作を行ったとする。要素提示部１１１は、スワイプ操作に応答して、仮想カメラを５２の位置から５３の位置へと移動させる。

仮想カメラ５２から仮想カメラ５３へと位置が変更になったことに伴い、仮想カメラ５３と、近景６３、ステージアイコン７６および７７との距離がさらに縮まる。そして、ステージアイコン７６および７７と仮想カメラ５３とのＹ軸上の距離は一定距離以内になったとする。この場合、要素提示部１１１は、近景６３を、図１８と比較してさらに手前により一層大きく描画するとともに、ステージアイコン７６および７７の表示態様を、小さく輪郭だけ表示する態様から、通常通り内容表記も含めて表示する態様へと変更する。図１８に示すステージマップ映像６８１から図１９に示すステージマップ映像６８１へと至るまでの映像が漸次的に表示部１５２に出力されるので、ユーザは、徐々に近景６３へとまるで自分が近づいていくかのように感じながら、ステージマップ画面６８０を操作することができる。

上述の構成によれば、要素提示部１１１は、ユーザから、Ｘ軸方向（左右方向）の移動量を指定する入力操作、例えば、スワイプ操作などの簡単な入力操作を受け付けるだけで、仮想空間７００に基づいて、プレイ要素および背景の遠近感を再現したより表現力豊かなステージマップ画面６８０を出力することができる。

これにより、ユーザに複雑な操作を要求することなく、プレイ要素を選択する画面の表現力を向上させることが可能となり、例えば、ユーザがプレイ要素を求めてゲーム内の世界へあたかも分け入って探索するような没入感を演出することができる。さらに、仮想空間７００において、３Ｄオブジェクトではなく、２Ｄオブジェクトによって可視オブジェクトを構成すること、および、仮想カメラの位置および向きを、Ｘ座標の入力のみに応じて一意に定めることができるレール５０を予め定義することによって、立体的なステージマップ映像６８１を描画するための処理に係る負荷を大幅に低減させることができる。結果として、コンピュータの処理負荷を増大させることなく、プレイ要素を選択させるＵＩにおいて表現力を一層豊かにすることができる。

〔変形例〕
第１の解放要件「００１」につき規定されている第２の更新条件は、「生存している味方キャラクタ数が０体の場合」を含んでいてもよい。この場合、クエスト進行部１１３が、ステップＳ２１１およびＳ２１２において、敗北したバトルを終了させるときに敗北通知画面（不図示）を表示させる。パラメータ処理部１１４は、敗北によりバトルが終了して生存している味方キャラクタ数が０体になったことに基づいて、要件パラメータを減少させ、その旨の通知を敗北通知画面に重ねて出力する。

〔ソフトウェアによる実現例〕
制御部２１０の制御ブロック（特に、進行支援部２１１）、ならびに、制御部１１０の制御ブロック（特に、要素提示部１１１、要素制御部１１２、クエスト進行部１１３およびパラメータ処理部１１４）は、集積回路（ＩＣチップ）等に形成された論理回路（ハードウェア）によって実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェアによって実現してもよい。

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

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

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

（項目１） ゲームプログラム（１３１）について説明した。本開示のある局面によると、ゲームプログラムは、プロセッサ（１０）およびメモリ（１１）を備えるコンピュータ（ユーザ端末１００）により実行される。ゲームプログラムは、プロセッサに、ユーザにプレイさせるゲームの内容を区切る単位であるプレイ要素（エリア、ステージ、クエスト）を、ユーザが選択可能に複数個提示するステップ（Ｓ１０１）と、ユーザに選択されたプレイ要素を、該ユーザの入力操作に応答して進行させるステップ（Ｓ１０２）と、プレイ要素をクリアするのみでは解放する要件が満たされない特殊なプレイ要素である隠しプレイ要素（シークレットステージ）を解放する要件に係る要件パラメータを、選択されたプレイ要素が進行している間、該プレイ要素の進行状況に応じて、更新するステップ（Ｓ１０３）と、要件パラメータが更新されたことを通知するステップ（Ｓ１０４）と、を実行させる。提示するステップでは、要件パラメータが要件を満たしている場合に、隠しプレイ要素を、複数のプレイ要素とともに、ユーザが選択可能に提示し、ゲームプログラムに基づくゲームの実行中、要件パラメータが更新される条件（第１の更新条件、第２の更新条件）は開示されない。

上述の構成によれば、ユーザには、クエストなどのプレイ要素が進行している間、要件パラメータが更新されていることが通知されるが、具体的に、プレイ要素をどのようにプレイしたら要件パラメータが更新されるのか、すなわち、要件パラメータの更新条件は、ユーザに通知されない。ユーザは、プレイ要素をプレイすることで要件パラメータが更新されるということを認知する一方、具体的に、どのようにプレイを進めれば要件パラメータが更新されるのかについて確信を得られない。したがって、ユーザは、その謎を解明したくなり、必要性からとにかくプレイ要素を繰り返しプレイするように動機付けられる。

結果として、ユーザには、プレイ要素をクリアするという目標だけでなく、それとは別軸で、謎を解明するという目標が与えられるので、ゲームの興趣性が一層向上する。

さらに、要件パラメータの更新条件はゲーム全体を通じて開示されないため、ユーザは、謎を解くために試行錯誤が必要となり、例えば、一度クリアしたプレイ要素であっても、何度もプレイするように促される。これにより、既存のコンテンツを活用しながら、本筋とは別軸の謎解き要素をユーザに提供することができる。結果として、新規のコンテンツを次々に数多く用意する場合と比較して少ない労力で、ユーザを飽きさせないゲームを提供することができる。

（項目２） （項目１）において、提示するステップでは、要件パラメータが要件を満たしていない間、隠しプレイ要素および該隠しプレイ要素の存在を示唆するオブジェクトを表示せず、通知するステップでは、要件パラメータが、隠しプレイ要素を解放する解放要件に関連していることを明示しないことが好ましい。

上述の構成によれば、ユーザは、プレイ要素を選択するとき、隠しプレイ要素の存在を認識しないし、また、プレイ要素が進行している間も、更新されている要件パラメータが隠しプレイ要素を解放するために設定されているものだと確信しない。解放要件が満たされた後、実際に新しく隠しプレイ要素が提示されたときにはじめてその存在を認識することになる。したがって、ユーザに、隠しプレイ要素の思いがけない発見の楽しみを与えることができる。

（項目３） （項目１）または（項目２）において、通知するステップでは、更新するステップにおいて、所定のタイミングにて要件パラメータが更新されたときに、該要件パラメータが更新されたことをユーザに通知してもよい。

上述の構成によれば、プレイ要素の進行状況に応じて要件パラメータが更新されたまさにそのときに、更新されたことがユーザに認識される。ユーザは、自身のプレイ内容と、要件パラメータの更新との因果関係を推測するように促される。

（項目４） （項目１）から（項目３）までのいずれか１項目において、通知するステップでは、進行させるステップによって進行したプレイ要素が終了するときに、更新された後の要件パラメータを、要件パラメータが要件を満たしたと判定されるときの値である目標値とともに通知してもよい。

（項目５） （項目４）において、ゲームプログラムは、プロセッサに、さらに、複数のプレイ要素のそれぞれがクリアされているか否かを判定するステップ（Ｓ３０５、Ｓ４０４）を実行させ、通知するステップでは、複数のプレイ要素のうち、所定のプレイ要素がクリアされていないと判定された場合には、要件パラメータが更新されても、更新されたことを通知しないことが好ましい。

上述の構成によれば、ユーザに謎解きの要素を認識させずに、まずは、本筋のプレイ要素のクリアに集中させることができ、ユーザがプレイ要素をクリアした後、それを条件として、本筋とは別軸の謎解きの要素を改めて提示することが可能となる。

（項目６） （項目１）から（項目５）までのいずれか１項目において、メモリにおいて、１つの隠しプレイ要素につき複数の要件が規定されており、要件ごとに要件パラメータが関連付けて記憶されており、更新するステップでは、要件パラメータごとに、プレイ要素の進行状況に応じた更新を行い、提示するステップでは、すべての要件パラメータがそれぞれの要件を満たしている場合に、隠しプレイ要素をユーザが選択可能に提示してもよい。

（項目７） （項目１）から（項目６）までのいずれか１項目において、更新するステップでは、プレイ要素の進行状況が第１の条件を満たす場合に、要件パラメータを増加させ、該進行状況が第２の条件を満たす場合に、要件パラメータを減少させることが好ましい。

（項目８） （項目１）から（項目７）までのいずれか１項目において、進行させるステップでは、ユーザが操作可能な味方キャラクタが敵キャラクタと戦うバトルを１回以上進行させるクエストを、プレイ要素として進行させ、進行させるステップでは、バトルを、複数の出題パネルを、ユーザが選択可能に提示し、ユーザに選択された出題パネルに紐付けられた問題を提示し、ユーザより問題に対する解答を受け付け、解答の正否に応じた１以上の処理を実行することにより、進行させることが好ましい。

（項目９） （項目８）において、メモリにおいて、味方キャラクタは、バトルに有利な効果をもたらす１以上のスキルが設定されて記憶されており、進行させるステップでは、バトルの進行中に、スキルの発動を指示するユーザの入力操作に応答して、スキルを発動させ、更新するステップでは、発動されたスキルの種類に応じて、要件パラメータを増加または減少させてもよい。

（項目１０） （項目８）または（項目９）において、更新するステップでは、クエストが終了する時点において生存しているキャラクタの数に応じて、要件パラメータを増加または減少させてもよい。

（項目１１） （項目８）から（項目１０）までのいずれか１項目において、進行させるステップでは、問題のジャンルが関連付けられた出題パネルを提示し、更新するステップでは、ユーザに選択された出題パネルに関連付けられているジャンルに応じて、要件パラメータを増加または減少させてもよい。

（項目１２） （項目８）から（項目１１）までのいずれか１項目において、進行させるステップでは、問題を提示してから解答を受け付けるまでの解答所要時間を計測し、更新するステップでは、解答所要時間に応じて、要件パラメータを増加または減少させてもよい。

（項目１３） （項目１）から（項目１２）までのいずれか１項目において、提示するステップでは、仮想空間に、複数のプレイ要素および隠しプレイ要素のそれぞれに対応する選択オブジェクトを配置し、仮想空間において、移動経路および該移動経路上の位置に応じた向きが予め規定された仮想カメラを配置し、仮想空間における座標間距離を指定するための入力操作をユーザから受け付け、入力操作に応答して、指定された座標間距離に相当する移動量だけ、移動経路に沿って仮想カメラの位置および向きを変更し、変更に伴って仮想カメラの視野領域の画像を逐次レンダリングし、レンダリングによって得られる画像を、コンピュータが備える表示部に逐次出力してもよい。

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

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

１ ゲームシステム、２ ネットワーク、１０，２０ プロセッサ、１１，２１ メモリ、１２，２２ ストレージ、１３，２３ 通信ＩＦ（操作部）、１４，２４ 入出力ＩＦ（操作部）、１５ タッチスクリーン（表示部、操作部）、１７ カメラ（操作部）、１８ 測距センサ（操作部）、１００ ユーザ端末（情報処理装置）、１１０，２１０ 制御部、１１１ 要素提示部、１１２ 要素制御部、１１３ クエスト進行部、１１４ パラメータ処理部、１２０，２２０ 記憶部、１３１，２３１ ゲームプログラム、１３２ ゲーム情報、１３３ ユーザ情報、１５１ 入力部（操作部）、１５２ 表示部、２００ サーバ、２１１ 進行支援部、１０１０ 物体、１０２０ コントローラ（操作部）、１０３０ 記憶媒体

Claims (15)

1. ゲームプログラムであって、
   前記ゲームプログラムは、プロセッサおよびメモリを備えるコンピュータにより実行されるものであり、
   前記ゲームプログラムは、前記プロセッサに、
   ユーザにプレイさせるゲームの内容を区切る単位であるプレイ要素を、ユーザが選択可能に複数個提示するステップと、
   前記ユーザに選択されたプレイ要素を、該ユーザの入力操作に応答して進行させるステップと、
   前記プレイ要素をクリアするのみでは解放する要件が満たされない特殊なプレイ要素である隠しプレイ要素を解放する要件に係る要件パラメータを、選択された前記プレイ要素が進行している間、該プレイ要素の進行状況に応じて、更新するステップと、
   前記要件パラメータが更新されたことを通知するステップと、を実行させ、
   前記提示するステップでは、前記要件パラメータが前記要件を満たしている場合に、前記隠しプレイ要素を、複数の前記プレイ要素とともに、前記ユーザが選択可能に提示し、
   前記ゲームプログラムに基づく前記ゲームの実行中、前記要件パラメータが更新される条件は開示されない、ゲームプログラム。
2. 前記提示するステップでは、前記要件パラメータが前記要件を満たしていない間、前記隠しプレイ要素および該隠しプレイ要素の存在を示唆するオブジェクトを表示せず、
   前記通知するステップでは、前記要件パラメータが、前記隠しプレイ要素を解放する解放要件に関連していることを明示しない、請求項１に記載のゲームプログラム。
3. 前記通知するステップでは、前記更新するステップにおいて、前記プレイ要素が進行している間の所定のタイミングにて前記要件パラメータが更新されたときに、該要件パラメータが更新されたことを前記ユーザに通知する、請求項１または２に記載のゲームプログラム。
4. 前記通知するステップでは、前記進行させるステップによって進行した前記プレイ要素が終了するときに、更新された後の前記要件パラメータを、前記要件パラメータが前記要件を満たしたと判定されるときの値である目標値とともに通知する、請求項１から３のいずれか１項に記載のゲームプログラム。
5. 前記ゲームプログラムは、前記プロセッサに、さらに、
   複数の前記プレイ要素のそれぞれがクリアされているか否かを判定するステップを実行させ、
   前記通知するステップでは、複数の前記プレイ要素のうち、所定のプレイ要素がクリアされていないと判定された場合には、前記要件パラメータが更新されても、更新されたことを通知しない、請求項１から４のいずれか１項に記載のゲームプログラム。
6. 前記メモリにおいて、１つの前記隠しプレイ要素につき複数の要件が規定されており、前記要件ごとに前記要件パラメータが関連付けて記憶されており、
   前記更新するステップでは、前記要件パラメータごとに、前記プレイ要素の進行状況に応じた更新を行い、
   前記提示するステップでは、すべての前記要件パラメータがそれぞれの前記要件を満たしている場合に、前記隠しプレイ要素を前記ユーザが選択可能に提示する、請求項１から５のいずれか１項に記載のゲームプログラム。
7. 前記更新するステップでは、前記プレイ要素の進行状況が第１の条件を満たす場合に、前記要件パラメータを増加させ、該進行状況が第２の条件を満たす場合に、前記要件パラメータを減少させる、請求項１から６のいずれか１項に記載のゲームプログラム。
8. 前記進行させるステップでは、前記ユーザが操作可能な味方キャラクタが敵キャラクタと戦うバトルを１回以上進行させるクエストを、前記プレイ要素として進行させ、
   前記進行させるステップでは、前記バトルを、
   複数の出題パネルを、ユーザが選択可能に提示し、
   前記ユーザに選択された前記出題パネルに紐付けられた問題を提示し、
   前記ユーザより前記問題に対する解答を受け付け、
   前記解答の正否に応じた１以上の処理を実行することにより、進行させる、請求項１から７のいずれか１項に記載のゲームプログラム。
9. 前記メモリにおいて、前記味方キャラクタは、前記バトルに有利な効果をもたらす１以上のスキルが設定されて記憶されており、
   前記進行させるステップでは、前記バトルの進行中に、前記スキルの発動を指示する前記ユーザの入力操作に応答して、前記スキルを発動させ、
   前記更新するステップでは、発動された前記スキルの種類に応じて、前記要件パラメータを増加または減少させる、請求項８に記載のゲームプログラム。
10. 前記更新するステップでは、前記クエストが終了する時点において生存しているキャラクタの数に応じて、前記要件パラメータを増加または減少させる、請求項８または９に記載のゲームプログラム。
11. 前記進行させるステップでは、前記問題のジャンルが関連付けられた前記出題パネルを提示し、
    前記更新するステップでは、前記ユーザに選択された出題パネルに関連付けられているジャンルに応じて、前記要件パラメータを増加または減少させる、請求項８から１０のいずれか１項に記載のゲームプログラム。
12. 前記進行させるステップでは、前記問題を提示してから前記解答を受け付けるまでの解答所要時間を計測し、
    前記更新するステップでは、前記解答所要時間に応じて、前記要件パラメータを増加または減少させる、請求項８から１１のいずれか１項に記載のゲームプログラム。
13. 前記提示するステップでは、
    仮想空間に、複数の前記プレイ要素および前記隠しプレイ要素のそれぞれに対応する選択オブジェクトを配置し、
    前記仮想空間において、移動経路および該移動経路上の位置に応じた向きが予め規定された仮想カメラを配置し、
    前記仮想空間における座標間距離を指定するための入力操作を前記ユーザから受け付け、
    前記入力操作に応答して、指定された前記座標間距離に相当する移動量だけ、前記移動経路に沿って前記仮想カメラの位置および向きを変更し、
    前記変更に伴って前記仮想カメラの視野領域の画像を逐次レンダリングし、
    前記レンダリングによって得られる前記画像を、前記コンピュータが備える表示部に逐次出力する、請求項１から１１のいずれか１項に記載のゲームプログラム。
14. コンピュータがゲームプログラムを実行する方法であって、
    前記コンピュータは、プロセッサおよびメモリを備え、
    前記プロセッサが請求項１に記載の各ステップを実行する方法。
15. 情報処理装置であって、
    前記情報処理装置は、
    請求項１に記載のゲームプログラムを記憶するメモリと、
    該ゲームプログラムを実行することにより、情報処理装置の動作を制御するプロセッサとを備えている、情報処理装置。

Images