〔実施形態1〕
本開示に係るゲームシステムは、複数のユーザにゲームを提供するためのシステムである。以下、ゲームシステムについて図面を参照しつつ説明する。なお、本発明はこれらの例示に限定されるものではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が本発明に含まれることが意図される。以下の説明では、図面の説明において同一の要素には同一の符号を付し、重複する説明を繰り返さない。
<ゲームシステム1のハードウェア構成>
図1は、ゲームシステム1のハードウェア構成を示す図である。ゲームシステム1は図示の通り、複数のユーザ端末100と、サーバ200とを含む。各ユーザ端末100は、サーバ200とネットワーク2を介して接続する。ネットワーク2は、インターネットおよび図示しない無線基地局によって構築される各種移動通信システム等で構成される。この移動通信システムとしては、例えば、所謂3G、4G移動通信システム、LTE(Long
Term Evolution)、および所定のアクセスポイントによってインターネットに接続可能な無線ネットワーク(例えばWi-Fi(登録商標))等が挙げられる。
サーバ200(コンピュータ、情報処理装置)は、ワークステーションまたはパーソナルコンピュータ等の汎用コンピュータであってよい。サーバ200は、プロセッサ20と、メモリ21と、ストレージ22と、通信IF23と、入出力IF24とを備える。サーバ200が備えるこれらの構成は、通信バスによって互いに電気的に接続される。
ユーザ端末100(コンピュータ、情報処理装置)は、スマートフォン、フィーチャーフォン、PDA(Personal Digital Assistant)、またはタブレット型コンピュータ等の携帯端末であってよい。ユーザ端末100は、ゲームプレイに適したゲーム装置であってもよい。ユーザ端末100は図示の通り、プロセッサ10と、メモリ11と、ストレージ12と、通信インターフェース(IF)13と、入出力IF14と、タッチスクリーン15(表示部)と、カメラ17と、測距センサ18とを備える。ユーザ端末100が備えるこれらの構成は、通信バスによって互いに電気的に接続される。なお、ユーザ端末100は、タッチスクリーン15に代えて、または、加えて、ユーザ端末100本体とは別に構成されたディスプレイ(表示部)を接続可能な入出力IF14を備えていてもよい。
また、図1に示すように、ユーザ端末100は、1つ以上のコントローラ1020と通信可能に構成されることとしてもよい。コントローラ1020は、例えば、Bluetooth(登録商標)等の通信規格に従って、ユーザ端末100と通信を確立する。コントローラ1020は、1つ以上のボタン等を有していてもよく、該ボタン等に対するユーザの入力操作に基づく出力値をユーザ端末100へ送信する。また、コントローラ1020は、加速度センサ、および、角速度センサ等の各種センサを有していてもよく、該各種センサの出力値をユーザ端末100へ送信する。
なお、ユーザ端末100がカメラ17および測距センサ18を備えることに代えて、または、加えて、コントローラ1020がカメラ17および測距センサ18を有していてもよい。
ユーザ端末100は、例えばゲーム開始時に、コントローラ1020を使用するユーザに、該ユーザの名前またはログインID等のユーザ識別情報を、該コントローラ1020を介して入力させることが望ましい。これにより、ユーザ端末100は、コントローラ1020とユーザとを紐付けることが可能となり、受信した出力値の送信元(コントローラ1020)に基づいて、該出力値がどのユーザのものであるかを特定することができる。
ユーザ端末100が複数のコントローラ1020と通信する場合、各コントローラ1020を各ユーザが把持することで、ネットワーク2を介してサーバ200などの他の装置と通信せずに、該1台のユーザ端末100でマルチプレイを実現することができる。また、各ユーザ端末100が無線LAN(Local Area Network)規格等の無線規格により互いに通信接続する(サーバ200を介さずに通信接続する)ことで、複数台のユーザ端末100によりローカルでマルチプレイを実現することもできる。1台のユーザ端末100によりローカルで上述のマルチプレイを実現する場合、ユーザ端末100は、さらに、サーバ200が備える後述する種々の機能の少なくとも一部を備えていてもよい。また、複数のユーザ端末100によりローカルで上述のマルチプレイを実現する場合、複数のユーザ端末100は、サーバ200が備える後述する種々の機能を分散して備えていてもよい。
なお、ローカルで上述のマルチプレイを実現する場合であっても、ユーザ端末100はサーバ200と通信を行ってもよい。例えば、あるゲームにおける成績または勝敗等のプレイ結果を示す情報と、ユーザ識別情報とを対応付けてサーバ200に送信してもよい。
また、コントローラ1020は、ユーザ端末100に着脱可能な構成であるとしてもよい。この場合、ユーザ端末100の筐体における少なくともいずれかの面に、コントローラ1020との結合部が設けられていてもよい。該結合部を介して有線によりユーザ端末100とコントローラ1020とが結合している場合は、ユーザ端末100とコントローラ1020とは、有線を介して信号を送受信する。
図1に示すように、ユーザ端末100は、外部のメモリカード等の記憶媒体1030の装着を、入出力IF14を介して受け付けてもよい。これにより、ユーザ端末100は、記憶媒体1030に記録されるプログラム及びデータを読み込むことができる。記憶媒体1030に記録されるプログラムは、例えばゲームプログラムである。
ユーザ端末100は、サーバ200等の外部の装置と通信することにより取得したゲームプログラムをユーザ端末100のメモリ11に記憶してもよいし、記憶媒体1030から読み込むことにより取得したゲームプログラムをメモリ11に記憶してもよい。
以上で説明したとおり、ユーザ端末100は、該ユーザ端末100に対して情報を入力する機構の一例として、通信IF13、入出力IF14、タッチスクリーン15、カメラ17、および、測距センサ18を備える。入力する機構としての上述の各部は、ユーザの入力操作を受け付けるように構成された操作部と捉えることができる。
例えば、操作部が、カメラ17および測距センサ18の少なくともいずれか一方で構成される場合、該操作部が、ユーザ端末100の近傍の物体1010を検出し、当該物体の検出結果から入力操作を特定する。一例として、物体1010としてのユーザの手、予め定められた形状のマーカーなどが検出され、検出結果として得られた物体1010の色、形状、動き、または、種類などに基づいて入力操作が特定される。より具体的には、ユーザ端末100は、カメラ17の撮影画像からユーザの手が検出された場合、該撮影画像に基づき検出されるジェスチャ(ユーザの手の一連の動き)を、ユーザの入力操作として特定し、受け付ける。なお、撮影画像は静止画であっても動画であってもよい。
あるいは、操作部がタッチスクリーン15で構成される場合、ユーザ端末100は、タッチスクリーン15の入力部151に対して実施されたユーザの操作をユーザの入力操作として特定し、受け付ける。あるいは、操作部が通信IF13で構成される場合、ユーザ端末100は、コントローラ1020から送信される信号(例えば、出力値)をユーザの入力操作として特定し、受け付ける。あるいは、操作部が入出力IF14で構成される場合、該入出力IF14と接続されるコントローラ1020とは異なる入力装置(図示せず)から出力される信号をユーザの入力操作として特定し、受け付ける。
<ゲーム概要>
ゲームシステム1は、ゲームの進行に応じてユーザに報酬が付与されるゲームを実行するシステムである。報酬は、ゲームにおいて利用可能なオブジェクトを取得可能な権利アイテムである。権利アイテムは、消費されることにより、当該権利アイテムに応じたオブジェクトがユーザに付与される。本実施形態では、報酬である権利アイテムは、カプセルとして表現される。また、権利アイテムの消費に応じてユーザに付与されるオブジェクトは、カプセルに封入された封入物として表現される。また、権利アイテムの消費は、カプセルの開封として表現される。
なお、ゲームシステム1によって実行されるゲームは、ゲームの進行に応じて上述した報酬がユーザに付与されるゲームであれば、特定のジャンルに限らず、各種のジャンルのゲームを実行するためのシステムであってもよい。例えば、テニス、卓球、ドッジボール、野球、サッカーおよびホッケーなどのスポーツを題材としたゲーム、パズルゲーム、クイズゲーム、RPG、アドベンチャーゲーム、シューティングゲーム、シミュレーションゲーム、育成ゲーム、ならびに、アクションゲームなどであってもよい。
また、本ゲームシステム1は、シングルプレイ型ゲームを実行するためのシステムであってもよい。シングルプレイ型ゲームは、単一のユーザ端末100において実行されるゲームである。この場合、シングルプレイ型ゲームをユーザ端末100において実行するために必要な情報のやりとりが、ユーザ端末100とサーバ200との間で行われる。
また、ゲームシステム1は、マルチプレイ型ゲームを実行するためのシステムであってもよい。マルチプレイ型ゲームは、複数のユーザ端末100の各ユーザが、1のゲームに参加して対戦又は協力してプレイすることが可能なゲームである。この場合、ユーザが操作するユーザ端末100と、1以上の他のユーザが操作する1以上の他のユーザ端末100との間で、該ゲームに係るデータの少なくとも一部が、サーバ200を介して共有される。
なお、シングルプレイ型又はマルチプレイ型に限らず、ゲームシステム1は、各種のプレイ形態のゲームを実行するためのシステムであってもよい。
<各装置のハードウェア構成要素>
プロセッサ10は、ユーザ端末100全体の動作を制御する。プロセッサ20は、サーバ200全体の動作を制御する。プロセッサ10および20は、CPU(Central Processing Unit)、MPU(Micro Processing Unit)、およびGPU(Graphics Processing Unit)を含む。
プロセッサ10は後述するストレージ12からプログラムを読み出し、後述するメモリ11に展開する。プロセッサ20は後述するストレージ22からプログラムを読み出し、後述するメモリ21に展開する。プロセッサ10およびプロセッサ20は展開したプログラムを実行する。
メモリ11および21は主記憶装置である。メモリ11および21は、ROM(Read Only Memory)およびRAM(Random Access Memory)等の記憶装置で構成される。メモリ11は、プロセッサ10が後述するストレージ12から読み出したプログラムおよび各種データを一時的に記憶することにより、プロセッサ10に作業領域を提供する。メモリ11は、プロセッサ10がプログラムに従って動作している間に生成した各種データも一時的に記憶する。メモリ21は、プロセッサ20が後述するストレージ22から読み出した各種プログラムおよびデータを一時的に記憶することにより、プロセッサ20に作業領域を提供する。メモリ21は、プロセッサ20がプログラムに従って動作している間に生成した各種データも一時的に記憶する。
本実施形態においてプログラムとは、ゲームをユーザ端末100により実現するためのゲームプログラムであってもよい。あるいは、該プログラムは、該ゲームをユーザ端末100とサーバ200との協働により実現するためのゲームプログラムであってもよい。あるいは、該プログラムは、該ゲームを複数のユーザ端末100の協働により実現するためのゲームプログラムであってもよい。また、各種データとは、ユーザ情報およびゲーム情報などのゲームに関するデータ、ならびに、ユーザ端末100とサーバ200との間または複数のユーザ端末100間で送受信する指示または通知を含んでいる。
ストレージ12および22は補助記憶装置である。ストレージ12および22は、フラッシュメモリまたはHDD(Hard Disk Drive)等の記憶装置で構成される。ストレージ12およびストレージ22には、ゲームに関する各種データが格納される。
通信IF13は、ユーザ端末100における各種データの送受信を制御する。通信IF23は、サーバ200における各種データの送受信を制御する。通信IF13および23は例えば、無線LAN(Local Area Network)を介する通信、有線LAN、無線LAN、または携帯電話回線網を介したインターネット通信、ならびに近距離無線通信等を用いた通信を制御する。
入出力IF14は、ユーザ端末100がデータの入力を受け付けるためのインターフェースであり、またユーザ端末100がデータを出力するためのインターフェースである。入出力IF14は、USB(Universal Serial Bus)等を介してデータの入出力を行ってもよい。入出力IF14は、例えば、ユーザ端末100の物理ボタン、カメラ、マイク、または、スピーカ等を含み得る。サーバ200の入出力IF24は、サーバ200がデータの入力を受け付けるためのインターフェースであり、またサーバ200がデータを出力するためのインターフェースである。入出力IF24は、例えば、マウスまたはキーボード等の情報入力機器である入力部と、画像を表示出力する機器である表示部とを含み得る。
ユーザ端末100のタッチスクリーン15は、入力部151と表示部152とを組み合わせた電子部品である。入力部151は、例えばタッチセンシティブなデバイスであり、例えばタッチパッドによって構成される。表示部152は、例えば液晶ディスプレイ、または有機EL(Electro-Luminescence)ディスプレイ等によって構成される。
入力部151は、入力面に対しユーザの操作(主にタッチ操作、スライド操作、スワイプ操作、およびタップ操作等の物理的接触操作)が入力された位置を検知して、位置を示す情報を入力信号として送信する機能を備える。入力部151は、図示しないタッチセンシング部を備えていればよい。タッチセンシング部は、静電容量方式または抵抗膜方式等のどのような方式を採用したものであってもよい。
図示していないが、ユーザ端末100は、該ユーザ端末100の保持姿勢を特定するための1以上のセンサを備えていてもよい。このセンサは、例えば、加速度センサ、または、角速度センサ等であってもよい。ユーザ端末100がセンサを備えている場合、プロセッサ10は、センサの出力からユーザ端末100の保持姿勢を特定して、保持姿勢に応じた処理を行うことも可能になる。例えば、プロセッサ10は、ユーザ端末100が縦向きに保持されているときには、縦長の画像を表示部152に表示させる縦画面表示としてもよい。一方、ユーザ端末100が横向きに保持されているときには、横長の画像を表示部に表示させる横画面表示としてもよい。このように、プロセッサ10は、ユーザ端末100の保持姿勢に応じて縦画面表示と横画面表示とを切り替え可能であってもよい。
カメラ17は、イメージセンサ等を含み、レンズから入射する入射光を電気信号に変換することで撮影画像を生成する。
測距センサ18は、測定対象物までの距離を測定するセンサである。測距センサ18は、例えば、パルス変換した光を発する光源と、光を受ける受光素子とを含む。測距センサ18は、光源からの発光タイミングと、該光源から発せられた光が測定対象物にあたって反射されて生じる反射光の受光タイミングとにより、測定対象物までの距離を測定する。測距センサ18は、指向性を有する光を発する光源を有することとしてもよい。
ここで、ユーザ端末100が、カメラ17と測距センサ18とを用いて、ユーザ端末100の近傍の物体1010を検出した検出結果を、ユーザの入力操作として受け付ける例をさらに説明する。カメラ17および測距センサ18は、例えば、ユーザ端末100の筐体の側面に設けられてもよい。カメラ17の近傍に測距センサ18が設けられてもよい。カメラ17としては、例えば赤外線カメラを用いることができる。この場合、赤外線を照射する照明装置および可視光を遮断するフィルタ等が、カメラ17に設けられてもよい。これにより、屋外か屋内かにかかわらず、カメラ17の撮影画像に基づく物体の検出精度をいっそう向上させることができる。
プロセッサ10は、カメラ17の撮影画像に対して、例えば以下の(1)〜(5)に示す処理のうち1つ以上の処理を行ってもよい。(1)プロセッサ10は、カメラ17の撮影画像に対し画像認識処理を行うことで、該撮影画像にユーザの手が含まれているか否かを特定する。プロセッサ10は、上述の画像認識処理において採用する解析技術として、例えばパターンマッチング等の技術を用いてよい。(2)また、プロセッサ10は、ユーザの手の形状から、ユーザのジェスチャを検出する。プロセッサ10は、例えば、撮影画像から検出されるユーザの手の形状から、ユーザの指の本数(伸びている指の本数)を特定する。プロセッサ10はさらに、特定した指の本数から、ユーザが行ったジェスチャを特定する。例えば、プロセッサ10は、指の本数が5本である場合、ユーザが「パー」のジェスチャを行ったと判定する。また、プロセッサ10は、指の本数が0本である(指が検出されなかった)場合、ユーザが「グー」のジェスチャを行ったと判定する。また、プロセッサ10は、指の本数が2本である場合、ユーザが「チョキ」のジェスチャを行ったと判定する。(3)プロセッサ10は、カメラ17の撮影画像に対し、画像認識処理を行うことにより、ユーザの指が人差し指のみ立てた状態であるか、ユーザの指がはじくような動きをしたかを検出する。(4)プロセッサ10は、カメラ17の撮影画像の画像認識結果、および、測距センサ18の出力値等の少なくともいずれか1つに基づいて、ユーザ端末100の近傍の物体1010(ユーザの手など)とユーザ端末100との距離を検出する。例えば、プロセッサ10は、カメラ17の撮影画像から特定されるユーザの手の形状の大小により、ユーザの手がユーザ端末100の近傍(例えば所定値未満の距離)にあるのか、遠く(例えば所定値以上の距離)にあるのかを検出する。なお、撮影画像が動画の場合、プロセッサ10は、ユーザの手がユーザ端末100に接近しているのか遠ざかっているのかを検出してもよい。(5)カメラ17の撮影画像の画像認識結果等に基づいて、ユーザの手が検出されている状態で、ユーザ端末100とユーザの手との距離が変化していることが判明した場合、プロセッサ10は、ユーザが手をカメラ17の撮影方向において振っていると認識する。カメラ17の撮影範囲よりも指向性が強い測距センサ18において、物体が検出されたりされなかったりする場合に、プロセッサ10は、ユーザが手をカメラの撮影方向に直交する方向に振っていると認識する。
このように、プロセッサ10は、カメラ17の撮影画像に対する画像認識により、ユーザが手を握りこんでいるか否か(「グー」のジェスチャであるか、それ以外のジェスチャ(例えば「パー」)であるか)を検出する。また、プロセッサ10は、ユーザの手の形状とともに、ユーザがこの手をどのように移動させているかを検出する。また、プロセッサ10は、ユーザがこの手をユーザ端末100に対して接近させているのか遠ざけているのかを検出する。このような操作は、例えば、マウスまたはタッチパネルなどのポインティングデバイスを用いた操作に対応させることができる。ユーザ端末100は、例えば、ユーザの手の移動に応じて、タッチスクリーン15においてポインタを移動させ、ユーザのジェスチャ「グー」を検出する。この場合、ユーザ端末100は、ユーザが選択操作を継続中であると認識する。選択操作の継続とは、例えば、マウスがクリックされて押し込まれた状態が維持されること、または、タッチパネルに対してタッチダウン操作がなされた後タッチされた状態が維持されることに対応する。また、ユーザ端末100は、ユーザのジェスチャ「グー」が検出されている状態で、さらにユーザが手を移動させると、このような一連のジェスチャを、スワイプ操作(またはドラッグ操作)に対応する操作として認識することもできる。また、ユーザ端末100は、カメラ17の撮影画像によるユーザの手の検出結果に基づいて、ユーザが指をはじくようなジェスチャを検出した場合に、当該ジェスチャを、マウスのクリックまたはタッチパネルへのタップ操作に対応する操作として認識してもよい。
<ゲームシステム1の機能的構成>
図2は、ゲームシステム1に含まれるサーバ200およびユーザ端末100の機能的構成を示すブロック図である。サーバ200およびユーザ端末100のそれぞれは、図示しない、一般的なコンピュータとして機能する場合に必要な機能的構成、および、ゲームにおける公知の機能を実現するために必要な機能的構成を含み得る。
ユーザ端末100は、ユーザの入力操作を受け付ける入力装置としての機能と、ゲームの画像や音声を出力する出力装置としての機能を有する。ユーザ端末100は、プロセッサ10、メモリ11、ストレージ12、通信IF13、および入出力IF14等の協働によって、制御部110および記憶部130として機能する。
サーバ200は、各ユーザ端末100と通信して、ユーザ端末100がゲームを進行させるのを支援する機能を有する。ゲームがマルチプレイ型ゲームである場合には、サーバ200は、ゲームに参加する各ユーザ端末100と通信して、ユーザ端末100同士のやりとりを仲介する機能を有していてもよい。サーバ200は、プロセッサ20、メモリ21、ストレージ22、通信IF23、および入出力IF24等の協働によって、制御部210および記憶部230として機能する。
記憶部130および記憶部230は、ゲームプログラム131、ゲーム情報132およびユーザ情報133を格納する。ゲームプログラム131は、ユーザ端末100およびサーバ200で実行するゲームプログラムである。ゲーム情報132は、制御部110および制御部210がゲームプログラム131を実行する際に参照するデータである。ユーザ情報133は、ユーザのアカウントに関するデータである。記憶部230において、ゲーム情報132およびユーザ情報133は、ユーザ端末100ごとに格納されている。
(サーバ200の機能的構成)
制御部210は、記憶部230に格納されたゲームプログラム131を実行することにより、サーバ200を統括的に制御する。例えば、制御部210は、ユーザ端末100に各種データおよびプログラム等を送信する。制御部210は、ゲーム情報もしくはユーザ情報の一部または全部をユーザ端末100から受信する。ゲームがマルチプレイゲームである場合には、制御部210は、ユーザ端末100からマルチプレイの同期の要求を受信して、同期のためのデータをユーザ端末100に送信してもよい。
制御部210は、ゲームプログラム131の記述に応じて機能する。制御部210は、実行するゲームの性質に応じて、ユーザ端末100におけるゲームの進行を支援するために、図示しないその他の機能ブロックとしても機能することができる。
(ユーザ端末100の機能的構成)
制御部110は、記憶部130に格納されたゲームプログラム131を実行することにより、ユーザ端末100を統括的に制御する。例えば、制御部110は、ゲームプログラム131およびユーザの操作にしたがって、ゲームを進行させる。また、制御部110は、ゲームを進行させている間、必要に応じて、サーバ200と通信して、情報の送受信を行う。
制御部110は、ゲームプログラム131の記述に応じて、操作受付部111、表示制御部112、ユーザインターフェース(以下、UI)制御部113、アニメーション生成部114、ゲーム進行部115、報酬決定部116、実行可能状態管理部117、オブジェクト付与部118として機能する。制御部110は、実行するゲームの性質に応じて、ゲームを進行させるために、図示しないその他の機能ブロックとしても機能することができる。
操作受付部111は、入力部151に対するユーザの入力操作を検知し受け付ける。操作受付部111は、タッチスクリーン15およびその他の入出力IF14を介したコンソールに対してユーザが及ぼした作用から、いかなる入力操作がなされたかを判別し、その結果を制御部110の各要素に出力する。
例えば、操作受付部111は、入力部151に対する入力操作を受け付け、該入力操作の入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部111は、入力操作の種類として、例えばタッチ操作、スライド操作、スワイプ操作、およびタップ操作等を特定する。また、操作受付部111は、連続して検知されていた入力が途切れると、タッチスクリーン15から接触入力が解除されたことを検知する。
UI制御部113は、UIを構築するために表示部152に表示させるUIオブジェクトを制御する。UIオブジェクトは、ユーザが、ゲームの進行上必要な入力をユーザ端末100に対して行うためのツール、または、ゲームの進行中に出力される情報をユーザ端末100から得るためのツールである。UIオブジェクトは、これには限定されないが、例えば、アイコン、ボタン、リスト、メニュー画面などである。
アニメーション生成部114は、各種オブジェクトの制御態様に基づいて、各種オブジェクトのモーションを示すアニメーションを生成する。例えば、抽選が実行されている様子を表現したアニメーション等を生成してもよい。
表示制御部112は、タッチスクリーン15の表示部152に対して、上述の各要素によって実行された処理結果が反映されたゲーム画面を出力する。表示制御部112は、アニメーション生成部114によって生成されたアニメーションを含むゲーム画面を表示部152に表示してもよい。また、表示制御部112は、上述のUIオブジェクトを、該ゲーム画面に重畳して描画してもよい。
なお、以降、操作受付部111によって入力部151に対する入力操作が検知され受け付けられることを、単に、入力操作が受け付けられる、とも記載する。また、他の機能ブロックが、各種のゲーム画面を表示制御部112によって表示部152に出力することを、単に、表示する、とも記載する。
ゲーム進行部115は、ゲームの進行に係る各種処理を行う。例えば、ゲーム進行部115は、操作受付部111が受け付けた入力操作の入力位置の座標と操作の種類とから示されるユーザの指示内容を解釈し、当該解釈に基づいて、ゲームを進行させる処理を行う。また、例えば、ゲーム進行部115は、ゲームの進行に応じて、ゲーム情報132またはユーザ情報133の追加、更新、または削除を行う。また例えば、ゲーム進行部115は、ゲームの進行に係る各種判定処理を行う。
例えば、ゲームにおいて、ユーザが操作する操作キャラクタと敵キャラクタとが戦闘するクエストが提供されている場合、ゲーム進行部115は、ユーザの操作に基づいて操作キャラクタの動作を決定する事により、戦闘を進行させる。また、この場合、ゲーム進行部115は、戦闘の進行状況に基づいて、操作キャラクタ及び敵キャラクタの何れが勝利したかを判定する。
報酬決定部116は、ユーザにカプセルを付与する。例えば、報酬決定部116は、付与条件が満たされたときに、ユーザにカプセルを付与してもよい。付与条件とは、ゲームにおいて所定の課題が達成されることであってもよい。例えば、ゲームにおいて、上述したクエストが提供されている場合、所定の課題とは、クエストにおいて敵キャラクタに勝利することであってもよい。ただし、付与条件は、これに限られず、ゲームにおいて設定されるその他の課題が達成されることであってもよい。
また、報酬決定部116は、ユーザにカプセルを付与する際に、付与するカプセルの個数を決定する。また、報酬決定部116は、ゲーム進行部115から通知されるゲームの進行状況に基づいて、付与するカプセルの個数を決定してもよい。例えば、ゲームにおいて上述したクエストが提供されている場合、報酬決定部116は、クエストにおいて設定された課題の達成状況に基づいて、カプセルの個数を決定してもよい。
また、報酬決定部116は、ユーザに付与するカプセルについて、その希少度を決定する。例えば、報酬決定部116は、付与するカプセルの種類を設定し、設定した種類に応じた希少度を決定してもよい。この場合、カプセルの種類によって、当該カプセルに封入される可能性がある1つ以上のオブジェクトが定められ、希少度は、当該可能性がある1つ以上のオブジェクトの価値に基づいて定められる。オブジェクトの価値は、ゲームを有利に進める上での価値を表す。報酬決定部116は、付与する各カプセルに対して、予め設定された設定確率に基づいて、その種類を設定してもよい。この場合、希少度が高い種類ほど、設定確率が低くなるよう定められている。
また、ユーザが所有し得るカプセルの個数には上限が設定される。保有カプセル群を構成するカプセルの個数が上限に達している場合、報酬決定部116は、付与条件が満たされた場合でも、カプセルの付与を行わないようにしてもよい。あるいは、カプセルの個数が上限に達している場合、報酬決定部116は、上述のようにして付与するカプセルを決定した上で、付与予定のカプセルとして保存してもよい。なお、付与予定のカプセルは、保有カプセル群を構成するカプセルの個数が変化して上限より少なくなれば、任意の時点で保有カプセル群に加えられてもよい。
実行可能状態管理部117は、ユーザによって保有されるカプセルのうち任意のカプセルの開封が可能な状態であるか、不能な状態から可能な状態までの待機状態であるかを表す管理情報を、記憶部130に記憶させて管理する。記憶部130に記憶される管理情報は、1つであってもよいし、複数であってもよい。なお、本実施形態では、複数の管理情報が記憶される例について、以下の説明を行う。
開封が可能な状態を表す管理情報に基づいて、後述するオブジェクト付与部118により、カプセルが開封される。管理情報に基づきカプセルが開封されることを表すよう、本実施形態では、管理情報のことを、「開封マシン」と表現する。また、開封が可能な状態を表す管理情報を「使用可能な開封マシン」とも記載し、待機状態を表す管理情報を「使用不能な開封マシン」とも記載する。また、開封が可能な状態を表す管理情報を、待機状態を表すよう更新することを、「開封マシンを使用不能にする」とも記載する。また、待機状態を表す管理情報を、開封が可能な状態を表すよう更新することを、「開封マシンを使用可能にする」とも記載する。また、開封が可能な状態を表す管理情報に基づいてカプセルを開封することを、「開封マシンによってカプセルを開封する」とも記載する。また、開封する対象となるカプセルを選択することを、「開封マシンにカプセルをセットする」とも記載する。
また、実行可能状態管理部117は、各開封マシンに関連付けて、個別使用可能条件を、記憶部130に記憶させて管理する。個別使用可能条件は、後述する第1の条件及び第2の条件を含む。また、実行可能状態管理部117は、使用不能な複数の開封マシンに関連付けて、一括使用可能条件を、記憶部130に記憶させて管理する。
具体的には、実行可能状態管理部117は、開封マシンによってカプセルが開封されて封入物であるオブジェクトがユーザに付与されると、当該開封マシンを使用不能にするとともに、当該開封マシンについて第1の条件を設定する。第1の条件は、当該開封マシンに関連付けて記憶部130に記憶される。第1の条件は、ユーザの操作によらずとも達成可能な条件である。また、実行可能状態管理部117は、第1の条件が満たされると、当該第1の条件に関連付けられた開封マシンを、使用可能にする。
第1の条件は、例えば、当該開封マシンによって直近で開封されたカプセルに基づいて設定されてもよい。本実施形態では、第1の条件は、直近で開封されたカプセルの希少度に基づく内容である。ただし、第1の条件は、直近で開封されたカプセルの希少度以外の属性に基づく内容であってもよい。
また、第1の条件は、例えば、必要時間が経過することであってもよい。この場合、必要時間は、直近で開封されたカプセルの希少度が高いほど、長くなるよう設定されてもよい。
これにより、ユーザは、操作によらずに、設定された必要時間の経過を待つだけで、開封マシンを使用可能にすることができる。また、経過を待たなければいけない必要時間が、直近に開封されたカプセルの希少度、すなわち、直近に取得できたオブジェクトの価値に基づくものであれば、ユーザは、必要時間の長さに対して納得感を得ることができる。
ここで、複数の開封マシンによってカプセルが一括して開封される場合がある。一括して開封された場合、当該一括での開封に関わった各開封マシンについて設定される第1の条件は、当該開封マシンによって個別にカプセルが開封された場合に設定される第1の条件と比べて、達成が容易なものとなる。例えば、第1の条件が、必要時間が経過することである場合、設定される必要時間は、個別に開封された場合に設定される必要時間より短くてもよい。これにより、ユーザは、カプセルを一括して開封することによるメリットを享受することができる。
また、実行可能状態管理部117は、第1の条件を設定するとともに、第2の条件を設定してもよい。換言すると、実行可能状態管理部117は、開封マシンに、第1の条件及び第2の条件を関連付けて記憶部130に記憶する。この場合、実行可能状態管理部117は、第2の条件が満たされた場合にも、当該第2の条件に関連付けられた開封マシンを使用可能にする。
第2の条件は、例えば、消費アイテムの必要量を消費することであってもよい。消費アイテムとは、ゲームにおける各種の事物との引き換えに定められた量が消費されるアイテムであり、ユーザに関連付けて記憶部130に記憶される。消費アイテムは、例えば、ゲーム内の仮想通貨であってもよいが、これに限られない。
この場合、第2の条件における消費アイテムの必要量は、当該開封マシンについて設定された第1の条件における必要時間が長いほど、多くなるよう設定されてもよい。ただし、消費アイテムの必要量は、第1の条件における必要時間が閾値を超えると、変化しなくてもよい。なお、第2の条件における消費アイテムの必要量は、第1の条件で設定された必要時間の経過に伴い、必要時間の残りに応じた量となるよう、随時更新される(例えば、減少する)ものとする。
これにより、ユーザは、必要時間の経過を待つ代わりに、消費アイテムの必要量を消費することで、開封マシンをすぐに使用可能にすることができる。その結果、オブジェクトを開封する手段が多様化され、ゲームの興趣性がさらに向上する。また、開封マシンをすぐに使用可能にするための消費アイテムの必要量が、経過を待たなければいけない必要時間の長さに応じた量であれば、ユーザは、消費アイテムの必要量に対して納得感を得ることができる。また、開封マシンをすぐに使用可能にするための消費アイテムの必要量が、経過を待たなければいけない必要時間がどんなに長くなっても所定値より多くならなければ、ユーザは、開封マシンをすぐに使用可能にするために消費アイテムを消費することによるメリットを享受することができる。
このように、第1の条件及び第2の条件は、それぞれ、開封マシンを個別に使用可能とするための個別使用可能条件に含まれる。
また、実行可能状態管理部117は、各開封マシンに個別使用可能条件を設定するとともに、さらに、一括使用可能条件を設定してもよい。一括使用可能条件は、本発明における第3の条件の一実施例に相当する。一括使用可能条件は、使用不能な複数の開封マシンを一括して使用可能にするための条件である。一括して使用可能にする対象となる複数の開封マシンは、使用不能となっている全ての開封マシンであってもよいし、その一部であってもよい。一括使用可能条件は、開封処理が終了した開封マシンに関連付けられるのではなく、対象となる使用不能な複数の開封マシンに関連付けられて、記憶部130に記憶される。この場合、実行可能状態管理部117は、一括使用可能条件が満たされた場合、当該一括使用可能条件に関連付けられている複数の開封マシンを、一括して使用可能にする。
一括使用可能条件は、例えば、消費アイテムの必要量を消費することであってもよい。この場合、消費アイテムの必要量は、対象となる使用不能な複数の開封マシンの各々を個別に使用可能とするための第2の条件における必要量の合計より、少なくなるよう設定されてもよい。また、一括使用可能条件における消費アイテムの必要量は、第1の条件における必要時間の経過に応じて、第2の条件における消費アイテムの必要量が更新されることに伴い、随時更新される(例えば、減少する)ものとする。具体的には、一括使用可能条件における消費アイテムの必要量は、対象となる複数の開封マシンの各々について設定された個別使用可能条件において、その時点における消費アイテムの必要量の合計より、少なくなるよう随時更新される。
これにより、オブジェクトを開封する手段がさらに多様化され、ゲームの興趣性がさらに向上する。また、ユーザは、複数の開封マシンを一括して使用可能にするために消費アイテムを消費することによるメリットを享受することができる。
また、実行可能状態管理部117は、開封マシンを表す表示オブジェクトを、表示部152に表示する。開封マシンを示す表示オブジェクトは、当該開封マシンが使用可能であるか否かを認識可能な態様で表示される。開封マシンを示す表示オブジェクトを、以降、単に、開封マシンとも記載する。
オブジェクト付与部118は、使用可能な開封マシンがある場合に、ユーザによって保有されるカプセルのうちユーザの操作に基づくカプセルを、開封マシンにセットする。ユーザの操作に基づくカプセルとは、例えば、保有カプセル群の中からユーザの操作により選択されたカプセルであってもよい。例えば、ユーザは、使用可能な態様の開封マシンが表示されている場合に、保有されるカプセルの何れかを選択する操作を行うことにより、当該開封マシンにカプセルをセットすることができる。
また、オブジェクト付与部118は、使用可能な開封マシンにセットされたカプセルを開封し、出現した封入物であるオブジェクトを、ユーザに付与する。例えば、オブジェクト付与部118は、当該カプセルの種類に基づいて、カプセルの封入物としてのオブジェクトを決定し、決定したオブジェクトをユーザに付与してもよい。このとき、オブジェクト付与部118は、使用可能な開封マシンにセットされたカプセルについて、開封を指示する入力操作が受け付けられたことに応じて、封入物としてのオブジェクトをユーザに付与してもよい。この場合、開封を指示する入力操作は、使用可能な開封マシンにカプセルがセットされると、受け付け可能となる。
また、オブジェクト付与部118は、複数の開封マシンのうち、1つの使用可能な開封マシンにセットされたカプセルを開封してもよい。また、オブジェクト付与部118は、使用可能な複数の開封マシン各々にセットされたカプセルを、一括して開封してもよい。
ここで、カプセルの種類に基づくオブジェクトの決定方法について説明する。記憶部130に記憶されるゲーム情報132は、カプセルの種類に対して、1つ以上のオブジェクトを関連付けた情報を含んでいる。具体的には、ゲーム情報132は、カプセルに設定され得る種類に対して、1つ以上のオブジェクトを関連付けた情報を含む。ある種類に対して関連付けられた1つ以上のオブジェクトのそれぞれには、当該オブジェクトの出現確率が設定されている。ある種類に対して関連付けられた各オブジェクトの出現確率の合計は、100%となるよう設定される。また、このようなゲーム情報132は、更新され得る。例えば、ゲーム情報132は、特定の期間において、ある種類に対して当該期間中に取得可能となるオブジェクトを関連付けた情報を含むよう更新されてもよい。
換言すると、カプセルには、その種類に関連付けられた1つ以上のオブジェクトの何れかが封入されている可能性がある。本実施形態では、封入物は、カプセルの開封処理時にオブジェクト付与部118により決定される。ただし、封入物の決定処理は、カプセルの開封処理時に限らず、その他の時点で実行されてもよい。例えば、封入物の決定処理は、カプセルがユーザに付与された時点で実行されてもよい。ただし、この場合も、決定された封入物がユーザに付与される処理は、カプセルの開封時に実行されるものとする。
ここで、カプセルに封入されている可能性があるオブジェクトについて説明する。カプセルに設定される種類には、その種類の希少度に応じた価値を有するオブジェクトと、消費アイテムとを含む1つ以上のオブジェクトが関連付けられている。当該1つ以上のオブジェクトの中から、カプセルの封入物が決定される。換言すると、カプセルには、その種類の希少度に応じ価値を有するオブジェクトが封入されている可能性がある。また、カプセルには、消費アイテムが封入されている可能性がある。
カプセルに封入されている可能性がある、希少度に応じた価値を有するオブジェクトの一例としては、クエストで利用可能なアイテムがある。アイテムは、そのクエストを有利に進めることができる程度に応じて、その価値の高さが定まる。より高い希少度の種類には、より価値の高いアイテムが関連付けられる。
カプセルに封入されている可能性がある消費アイテムは、上述した第2の条件及び一括使用可能条件における消費アイテムと同種類の消費アイテムであってもよいし、異なる種類の消費アイテムであってもよい。
オブジェクト付与部118は、ゲーム情報132を参照することにより、開封するカプセルの種類に関連付けられた1つ以上のオブジェクトの中から、各オブジェクトの出現確率に基づいて何れかを決定する。
なお、オブジェクト付与部118によって決定されるオブジェクトの個数は、1つであってもよいし、複数であってもよい。オブジェクト付与部118は、オブジェクトの封入個数を決定するための封入確率に基づいて、決定するオブジェクトの個数を決定する。例えば、より多い封入個数となる封入確率は、希少度が高いほど高く設定されていてもよい。
また、例えば、オブジェクト付与部118は、出現確率に基づいて決定したオブジェクトが、希少度に応じた価値を有するオブジェクトの場合、封入個数として所定数(例えば1個)を決定してもよい。また、例えば、オブジェクト付与部118は、出現確率に基づいて決定したオブジェクトが、消費アイテムである場合、封入個数として、希少度に応じた個数(例えば、希少度が高いほど多くなる個数)を決定してもよい。
なお、図2に示すサーバ200およびユーザ端末100の機能は一例にすぎない。サーバ200は、ユーザ端末100が備える機能の少なくとも一部を備えていてもよい。また、ユーザ端末100は、サーバ200が備える機能の少なくとも一部を備えていてもよい。さらに、ユーザ端末100およびサーバ200以外の他の装置をゲームシステム1の構成要素とし、該他の装置にゲームシステム1における処理の一部を実行させてもよい。すなわち、本実施形態においてゲームプログラムを実行するコンピュータは、ユーザ端末100、サーバ200、および他の装置の何れであってもよいし、これらの複数の装置の組み合わせにより実現されてもよい。
<処理フロー及び画面例>
ユーザ端末100が、ゲームプログラム131に基づいて実行する処理の流れについて、図3〜図13のフローチャート及び画面例を用いて説明する。なお、以下の説明において、フローチャートを用いて説明する一連の処理ステップの流れは、ユーザ端末100によって実行されるものとして記載しているが、これらの処理ステップの少なくとも一部が、サーバ200によって実行されてもよい。
(カプセルを付与する処理の流れ)
図3は、ユーザ端末100が、ユーザにカプセルを付与する処理の流れを説明するフローチャートである。
ステップS101において、ゲーム進行部115は、ゲームの進行状況に基づいて、付与条件が満たされたか否かを判断する。付与条件は、例えば、クエストにおいて敵キャラクタに勝利したことである。付与条件が満たされないと判断した場合、ステップS101の処理が繰り返される。付与条件が満たされたと判断した場合、ステップS102が実行される。
ステップS102において、報酬決定部116は、ゲーム進行部115から通知されるゲームの進行状況に基づいて、付与するカプセルの個数を決定する。カプセルの個数は、例えば、勝利したクエストにおいて達成された課題に応じて決定される。
ステップS103において、報酬決定部116は、付与する各カプセルの希少度を決定する。例えば、報酬決定部116は、希少度が高い種類ほど低くなるよう設定された設定確率に基づいて、各カプセルの種類を設定し、設定した種類に応じて希少度を決定すればよい。
ステップS104において、報酬決定部116は、ステップS102及びS103で決定した個数及び希少度のカプセルを、ユーザに付与する。
そして、ユーザ端末100は、ステップS101からの処理を繰り返す。
(付与されたカプセルの画面例)
図4は、図3に示した処理の流れに基づいて、ユーザに付与されたカプセルを示す画面例である。
この例では、付与条件として、クエストをクリア、すなわち、クエストにおいて敵キャラクタに勝利したことを契機として、ユーザにカプセルが付与されている。図4において、表示領域101には、付与されたカプセルの一覧が表示される。表示領域101は、カプセル102aと、カプセル102bとを含む。この例では、2つのカプセルが付与されている。なお、本実施形態の画面例では、カプセルの種類を、カプセルを表す球形の内部に表示された文字列で表すものとする。つまり、カプセル102aの種類はC1であり、カプセル102bの種類はC2である。また、本実施形態の画面例では、希少度を、☆の数で表すものとする。つまり、カプセル102aの希少度は2であり、カプセル102bの希少度は1である。希少度の数値が高いほど、希少度が高いものとする。
(開封対象のカプセルを選択する処理の流れ)
図5は、ユーザ端末100が、開封対象のカプセルを選択する処理の流れを説明するフローチャートである。
ステップS201において、オブジェクト付与部118は、ユーザによって保有されるカプセルの一覧を表示する。
次に、実行可能状態管理部117は、各開封マシンについて、ステップS202〜S204の処理を実行する。
ステップS202において、実行可能状態管理部117は、この開封マシンが、使用可能であるか否かを判断する。
ステップS202でNoの場合、ステップS203の処理が実行される。ステップS203において、実行可能状態管理部117は、開封マシンを、使用できない態様で表示する。
ステップS202でYesの場合、ステップS204の処理が実行される。ステップS204において、実行可能状態管理部117は、開封マシンを、使用可能な態様で表示する。
ステップS205において、オブジェクト付与部118は、開封マシンのうち少なくとも1つが使用可能であるか否かを判断する。
ステップS205でNoの場合、オブジェクト付与部118は、処理を終了する。
ステップS205でYesの場合、ステップS206が実行される。ステップS206において、オブジェクト付与部118は、カプセルを選択する入力操作を受け付けたか否かを判断する。カプセルを選択する入力操作は、例えば、ステップS201で表示したカプセルの一覧のうち1つに対するタップ操作であってもよいが、これに限られない。
ステップS206でNoの場合、ステップS206の処理が繰り返される。
ステップS206でYesの場合、ステップS207の処理が実行される。ステップS207において、オブジェクト付与部118は、当該カプセルを、使用可能な開封マシンの1つにセットする。
(カプセルを1つ開封する処理の流れ)
図6は、ユーザ端末100が、カプセルを1つ開封する処理の流れを説明するフローチャートである。図6に示す処理は、使用可能な開封マシンのうちの1つにカプセルがセットされている状態で、カプセルを開封する指示を示す入力操作が行われた場合に、実行される。
ステップS301において、オブジェクト付与部118は、開封マシンにセットされたカプセルに応じたオブジェクトを決定する。具体的には、オブジェクト付与部118は、セットされているカプセルの種類に関連付けられた1つ以上のオブジェクトのうち、出現確率に基づいて何れかを決定すればよい。
ステップS302において、オブジェクト付与部118は、決定したオブジェクトを、ユーザに付与する。
ステップS303において、実行可能状態管理部117は、当該カプセルがセットされていた開封マシンを、使用不能にする。そして、実行可能状態管理部117は、当該開封マシンを、使用できない態様に変更して表示する。
ステップS304において、実行可能状態管理部117は、ステップS303で使用不能にした開封マシンについて、個別使用可能条件を設定する。ステップS304の処理の詳細については、後述する。
ステップS305において、実行可能状態管理部117は、使用不能な複数の開封マシンがあるか否かを判断する。
ステップS305でYesの場合、ステップS306の処理が実行される。ステップS306において、実行可能状態管理部117は、一括使用可能条件を設定する。一括使用可能条件としては、消費アイテムの必要量が設定される。設定される必要量は、使用不能な複数の開封マシンの各々について、個別使用可能条件における消費アイテムのこの時点での必要量の合計より少ない量である。
(個別使用可能条件を設定する処理の流れ)
図7は、ステップS304における個別使用可能条件を設定する処理の詳細を説明するフローチャートである。
ステップS501において、実行可能状態管理部117は、該当する開封マシンで直前に開封されたカプセルの希少度を取得する。
ステップS502において、実行可能状態管理部117は、第1の条件として、ステップS501で取得した希少度に応じた必要時間を設定する。
ステップS503において、実行可能状態管理部117は、ステップS501で取得した希少度が、閾値以下であるか否かを判断する。
ステップS503で閾値以下であると判断された場合、ステップS504の処理が実行される。ステップS504において、実行可能状態管理部117は、第2の条件として消費アイテムの必要量を、ステップS502で設定した必要時間に応じて設定する。具体的には、必要時間が長いほど多い必要量が設定される。
ステップS503で閾値以下でない(閾値より大きい)と判断された場合、ステップS505の処理が実行される。ステップS505において、実行可能状態管理部117は、第2の条件として、消費アイテムの必要量を所定値に設定する。具体的には、所定値は、希少度が閾値の場合にステップS504で設定される必要量に等しいものとする。
(カプセルを1つ開封する画面例)
図8(A)〜(D)は、図5〜7に示した処理の流れに基づいて、カプセルを1つ開封する場合に、表示部152に出力される画面遷移例である。
図8(A)は、オブジェクト付与部118及び実行可能状態管理部117によって表示されるカプセルの開封画面の一例である。この開封画面は、保有カプセル一覧領域201と、保有数表示領域202と、4つの開封マシン203a〜203dと、カラにするボタン204と、開封ボタン205と、一括ですぐに使用ボタン206とを含んでいる。
保有カプセル一覧領域201は、ユーザによって保有されるカプセルの一覧を含む。この例では、6つのカプセル201a〜201fが保有されている。それぞれのカプセルの種類及び希少度は、図示した通りである。
保有数表示領域202は、ユーザによって保有されているカプセルの個数と、保有可能な上限数とを示している。この例では、保有可能な上限数8個のうち6個が保有されていることを表す「6/8」が示されている。
また、図8(A)における開封マシン203a〜203dは、使用可能な態様の一例を表しているものとする。使用不能な態様の一例については、後述する。
カラにするボタン204は、保有されているカプセルを一括して削除することを指示するためのUIオブジェクトの一例である。カラにするボタン204に対する入力操作が受け付けられると、保有されているカプセルが一括して削除される処理が実行される。一括して削除される処理は、例えば、消費アイテムと引き換えに実行されてもよい。一括して削除される処理の実行に必要な消費アイテムの量は、一括して削除されるカプセルの個数に応じて定められていてもよい。
開封ボタン205は、開封マシンにセットされたカプセルを開封することを指示するためのUIオブジェクトの一例である。図8(A)では、開封ボタン205は、点線の矩形で表されている。なお、ここでは、実線の矩形で表されたUIオブジェクトは、操作を受け付け可能であることを表し、点線の矩形で表されたUIオブジェクトは、操作を受け付け不能であることを表すものとするが、これに限られない。ここでは、開封マシン203a〜203dの何れにもカプセルがセットされていないため、開封ボタン205は、操作を受け付け不能である。
図8(A)において、保有カプセル一覧領域201のカプセル201aに対する入力操作が受け付けられたとする。この場合、図8(A)の画面例は、図8(B)の画面例に遷移する。
図8(B)は、開封マシンの1つにカプセルがセットされている開封画面の例である。ここで、入力操作が受け付けられたカプセル201aは、使用可能な開封マシン203a〜203dのうち1つである、開封マシン203a内に表示される。これは、カプセル201aが、開封マシン203aにセットされたことを表す。
また、図8(B)において、保有カプセル一覧領域201におけるカプセル201aの表示は、セットされていることを表す選択状態に変更される。ここでは、選択状態を表す表示は、セットされる前よりも表示色が薄くなることで表されているが、これに限られない。なお、選択状態のカプセル201aに対する入力操作が受け付けられると、カプセル201aのセットが解除されることとしてもよい。
また、カプセル201aが、開封マシン203aにセットされたことに応じて、開封ボタン205は、操作を受け付け可能な表示に変更されている。
このように、この例では、使用可能な態様の複数の開封マシンが表示されている場合、ユーザの入力操作により選択されたカプセルは、その何れかの開封マシンにセットされる。
図8(B)において、開封ボタン205に対する入力操作が受け付けられたとする。この場合、図8(B)の画面例は、図8(C)の画面例に遷移する。
図8(C)は、開封マシンにセットされたカプセルが開封から出現したオブジェクトが付与される画面例である。ここでは、オブジェクト付与部118は、開封マシン203aにセットされていたカプセル201aの種類C1に応じて、関連付けられた1つ以上のオブジェクトの中から、コイン100枚を決定したものとする。コインは、カプセルの種類に対して関連付けられた消費アイテムの一例である。また、そのようなコインの100枚という個数は、このカプセル201aの希少度2に応じて決定されたものである。
図8(C)の画面例は、図8(D)の画面例に遷移する。図8(D)への遷移は、例えば、図8(C)において画面内の任意の位置がタップされることにより行われてもよい。
図8(D)は、開封マシンの1つが使用不能になったことを表す開封画面の例である。ここでは、開封マシン203aが、使用不能であることを示す態様に変更されている。使用不能であることを示す態様は、ここでは、表示色が薄くなっていることで表されているが、これに限られない。また、使用不能な開封マシン203aは、第1の条件の表示領域207aと、すぐ使用ボタン208aとを含んでいる。
第1の条件の表示領域207aは、この開封マシン203aについて設定された第1の条件における必要時間を示している。具体的には、この開封マシン203aにおいて直近に開封されたカプセル201aの希少度2に応じて設定された必要時間として、「あと10分」が表示されている。この表示は、必要時間の経過に応じて更新される。
すぐ使用ボタン208aは、第2の条件における消費アイテムの必要量との交換を指示するためのUIオブジェクトの一例である。
また、図8(D)において、保有カプセル一覧領域201は、カプセルが1つ開封されたことに応じて更新されている。具体的には、保有カプセル一覧領域201は、まだ開封されていない5つのカプセル201b〜201fを含んでいる。また、保有数表示領域202は、保有可能上限数8個のうち、5個が保有されていることを示す「5/8」との表示に更新されている。
(カプセルを一括して開封する処理の流れ)
図9は、ユーザ端末100が、カプセルを一括して開封する処理の流れを説明するフローチャートである。図9に示す処理は、使用可能な開封マシンのうち複数にカプセルがセットされている状態で、カプセルを開封する指示を示す入力操作が行われた場合に、実行される。
ステップS401〜S405は、カプセルがセットされている各開封マシンについて実行される。なお、ステップS401〜S404の処理は、ステップS301〜S304の処理と同様であるため、詳細な説明を繰り返さない。
ステップS405において、実行可能状態管理部117は、ステップS404で該当する開封マシンについて設定した必要時間及び必要量を、割引きして更新する。割引率は、例えば、一括での開封に関わった開封マシンの個数に応じて定められていてもよい。例えば、一括での開封に関わった開封マシンの個数が多いほど、割引率が高く定められていてもよい。
各開封マシンについて、ステップS401〜S405の処理の実行が終了すると、ステップS406の処理が実行される。
ステップS406において、実行可能状態管理部117は、一括使用可能条件を設定する。ステップS406の処理は、ステップS305の処理と同様であるため、詳細な説明を繰り返さない。
(カプセルを一括して開封する画面例)
図10(A)〜(D)は、図5、9、7に示した処理の流れに基づいて、カプセルを一括して開封する場合に、表示部152に出力される画面遷移例である。
図10(A)は、開封マシンのうち2つにカプセルがセットされている開封画面例である。この開封画面は、図8(B)に示した、開封マシンのうち1つにカプセルがセットされている画面例において、さらに、保有カプセル一覧領域201のカプセル201bに対する入力操作が受け付けられた場合に表示される。
ここで、入力操作が受け付けられたカプセル201bは、使用可能な開封マシン203a〜203dのうち、カプセルがセットされていない1つである、開封マシン203b内に表示される。これは、カプセル201bが、開封マシン203bにセットされたことを表す。
このように、少なくとも1つの使用可能な開封マシンにカプセルがセットされた状態で、当該カプセルが開封される前に、他の使用可能な開封マシンに他のカプセルがセットされ得る。
これにより、保有カプセル一覧領域201におけるカプセル201bの表示は、選択状態に更新される。選択状態については、図8(B)におけるカプセル201aの選択状態と同様であるため、詳細な説明を繰り返さない。
また、カプセル201bが、開封マシン203aにセットされたことにより、開封対象として選択されているカプセルが2つになった。これに応じて、表示領域209に、一括開封の割引率が表示されている。この例では、現在選択されている2つのカプセルを一括して開封した場合、各カプセルがセットされている開封マシン203a及び203bについて設定される個別使用可能条件において、必要時間及び消費アイテムの必要量が、個別に開封される場合に比べて10%割引きされる。
図10(A)において、さらに、保有カプセル一覧領域201のカプセル201d及び201fに対する入力操作が順次受け付けられたとする。この場合、図10(A)の画面例は、図10(B)の画面例に遷移する。
図10(B)は、4つの使用可能な開封マシンの各々にカプセルがセットされている開封画面の例である。ここでは、カプセル201a、201b、201d及び201fが、開封対象として選択され、使用可能な開封マシン203a〜203dの各々の内部に表示される。これは、これらのカプセルが、4つの開封マシン203a〜203dにそれぞれセットされた状態を表す。
これに応じて、一括開封の割引率を表示する表示領域209が更新されている。この例では、現在選択されている4つのカプセルを一括して開封した場合、各カプセルがセットされている開封マシン203a〜203dについて設定される個別使用可能条件において、必要時間及び消費アイテムの必要量が、個別に開封される場合に比べて40%割引きされる。この割引率40%は、一括開封する個数が4つであるため、一括開封する個数が2つの場合(図10(A))の10%に比べて、高くなっている。
図10(B)において、開封ボタン205に対する入力操作が受け付けられたとする。この場合、図10(B)の画面例は、図10(C)の画面例に遷移する。
図10(C)は、各開封マシンにセットされた4つのカプセルから出現したオブジェクトが付与される画面例である。ここでは、オブジェクト付与部118は、開封マシン203aにセットされていたカプセル201aの種類C1に応じて、関連付けられた1つ以上のオブジェクトの中から、コイン100枚を決定したものとする。100枚という個数は、このカプセル201aの希少度2に応じて決定されたものである。また、オブジェクト付与部118は、開封マシン203bにセットされていたカプセル201bの種類C1に応じて、関連付けられた1つ以上のオブジェクトの中から、コイン90枚を決定したものとする。90枚という個数は、このカプセル201aの希少度2に応じて決定されたものである。また、オブジェクト付与部118は、開封マシン203cにセットされていたカプセル201dの種類C2に応じて、関連付けられた1つ以上のオブジェクトの中から、コイン10枚を決定したものとする。10枚という個数は、このカプセル201aの希少度1に応じて決定されたものである。また、オブジェクト付与部118は、開封マシン203dにセットされていたカプセル201fの種類C3に応じて、関連付けられた1つ以上のオブジェクトの中から、コイン990枚を決定したものとする。990枚という個数は、このカプセル201fの希少度3に応じて決定されたものである。
また、図10(C)の画面例は、一括開封によるボーナスを表す表示領域211を含んでいる。一括開封によるボーナスは、4つのカプセルを一括して開封したことによる上述の割引率が40%であることを示している。
図10(C)の画面例は、図10(D)の画面例に遷移する。図10(D)への遷移は、例えば、図10(C)において画面内の任意の位置がタップされることにより行われてもよい。
図10(D)は、4つの開封マシンが全て使用不能になったことを表す開封画面の例である。すなわち、開封マシン203a〜203dが、それぞれ、使用不能であることを示す態様に変更されている。
使用不能であることを示す態様については、図8(D)で説明した通りであるため、詳細な説明を繰り返さない。また、使用不能な各開封マシン203a〜203dは、第1の条件の表示領域207a〜207dと、すぐ使用ボタン208a〜208dとを含んでいる。
ここで、第1の条件の表示領域207aは、開封マシン203aについて設定された第1の条件における必要時間を示している。具体的には、この開封マシン203aにおいて直近に開封されたカプセル201aは、希少度2であった。また、個別にカプセルが開封された場合の希少度2に応じた必要時間が「あと10分」であったとする。この場合の例として、第1の条件の表示領域207aは、「あと10分」より40%割引きされた「あと6分」との表示を含んでいる。
また、第1の条件の表示領域207bは、開封マシン203bについて設定された第1の条件における必要時間を示している。開封マシン203bにおいて直近に開封されたカプセル201bも、開封マシン203aと同様に希少度2であった。このため、第1の条件の表示領域207bは、表示領域207aと同様に、「あと6分」との表示を含んでいる。
また、第1の条件の表示領域207cは、開封マシン203cについて設定された第1の条件における必要時間を示している。具体的には、この開封マシン203aにおいて直近に開封されたカプセル201dは、希少度1であった。また、個別にカプセルが開封された場合の希少度1に応じた必要時間が「あと5分」であったとする。この場合の例として、第1の条件の表示領域207cは、「あと5分」より40%割引きされた「あと3分」との表示を含んでいる。
また、第1の条件の表示領域207dは、開封マシン203dについて設定された第1の条件における必要時間を示している。具体的には、この開封マシン203dにおいて直近に開封されたカプセル201fは、希少度3であった。また、個別にカプセルが開封された場合の希少度3に応じた必要時間が「あと40分」であったとする。この場合の例として、第1の条件の表示領域207dは、「あと40分」より40%割引きされた「あと24分」との表示を含んでいる。
これらの第1の条件の表示領域207a〜207dの表示は、必要時間の経過に応じて更新される。なお、すぐ使用ボタン208a〜208dの詳細については、図8(D)で説明した通りであるため、詳細な説明を繰り返さない。
また、図10(D)において、保有カプセル一覧領域201は、4つのカプセルが開封されたことに応じて更新されている。具体的には、保有カプセル一覧領域201は、まだ開封されていない2つのカプセル201c及び201eを含んでいる。また、保有数表示領域202は、保有可能上限数8個のうち、2個が保有されていることを示す「2/8」との表示に更新されている。
(開封対象のカプセルを選択する処理の流れ)
図11は、ユーザ端末100が、開封マシンを使用可能にする処理の流れを説明するフローチャートである。
ステップS601において、実行可能状態管理部117は、開封マシンについて設定されている第1の条件が満たされたか否かを判断する。具体的には、実行可能状態管理部117は、第1の条件として設定されている必要時間が経過したか否かを判断する。
ステップS601でYesの場合、ステップS602の処理が実行される。ステップS602において、実行可能状態管理部117は、満たされた第1の条件に関連付けられた開封マシンを使用可能にする。
ステップS601でNoの場合、ステップS603の処理が実行される。ステップS603において、実行可能状態管理部117は、開封マシンについて設定されている第2の条件が満たされたか否かを判断する。具体的には、実行可能状態管理部117は、第2の条件として設定されている消費アイテムの必要量との交換が行われたか否かを判断する。
ステップS603でYesの場合、ステップS602の処理が実行され、該当する開封マシンが使用可能となる。
なお、ステップS601〜S603の処理は、各開封マシンについて実行される。
ステップS603でNoの場合、ステップS604の処理が実行される。ステップS604において、実行可能状態管理部117は、一括使用可能条件が満たされたか否かを判断する。具体的には、実行可能状態管理部117は、一括使用可能条件として設定されている消費アイテムの必要量との交換が行われたか否かを判断する。
ステップS604でYesの場合、ステップS605の処理が実行される。ステップS605において、実行可能状態管理部117は、使用可能でない複数の開封マシンを一括して使用可能にする。一括して使用可能とする対象となる開封マシンは、使用可能でない全ての開封マシンであってもよいし、使用可能でない開封マシンのうち一部であってもよい。
ステップS604でNoの場合、実行可能状態管理部117は、処理を終了する。
(開封マシンを使用可能にする画面例)
図12(A)〜(D)は、図11に示した処理の流れに基づいて、開封マシンを使用可能にする場合に、表示部152に出力される画面遷移例である。
図12(A)は、図8(D)において、すぐ使用ボタン208aに対する入力操作が受け付けられた場合に表示される画面例である。詳細には、図8(D)の画面例において6分が経過することにより、表示領域207aが「あと4分で使用可能」との表示に更新されたことを想定する。この状態で、すぐ使用ボタン208aに対する入力操作が受け付けられた場合に、図12(A)の画面例が表示される。
図12(A)の画面例は、表示領域301と、閉じるボタン302と、消費アイテム4個ですぐに使用ボタン303とを含む。表示領域301は、該当する開封マシン203aについての個別使用可能条件を表示する領域である。表示領域301は、第1の条件として設定された必要時間の残りが4分であること、及び、第2の条件として設定された消費アイテムの必要量が4個であることを示している。なお、この例では、必要時間t及び必要量mの関係として、m=α×tを採用し、α=1であることを想定している。つまり、この例では、図8(D)の時点では、開封マシン203aについて必要時間tが10分に設定され、必要量mが10分であった。その後、必要時間tの残りが4分になったことにより、必要量mが4個に更新されている。
閉じるボタン302は、当該画面例から、図8(D)の画面例に戻ることを指示するUIオブジェクトの一例である。閉じるボタン302に対する入力操作が受け付けられ、図8(D)の画面例に戻った後、4分が経過すると、図12(B)の画面例が表示される。図12(B)において、開封マシン203aは、使用可能な態様の表示に更新されている。
また、消費アイテム4個ですぐに使用ボタン303は、消費アイテム4個との引き換えを指示するためのUIオブジェクトの一例である。消費アイテム4個ですぐに使用ボタン303に対する入力操作が受け付けられると、ユーザに関連付けられた消費アイテムのうち4個が消費され、図12(B)の画面例が表示される。図12(B)については、前述した通りであるため、説明を繰り返さない。
図12(C)は、図10(D)において、一括ですぐに使用ボタン206に対する入力操作が受け付けられた場合に表示される画面例である。詳細には、図10(D)の画面例において4分が経過したことを想定する。すると、開封マシン203aが使用可能になるまでの残りの必要時間は2分となる。また、開封マシン203bが使用可能になるまでの残りの必要時間は2分となる。また、開封マシン203cが使用可能になるまでの残りの必要時間は8分となる。また、開封マシン203dが使用可能になるまでの残りの必要時間は20分となる。この状態で、一括ですぐ使用ボタン206に対する入力操作が受け付けられた場合に、図12(C)の画面例が表示される。
図12(C)の画面は、表示領域304と、閉じるボタン305と、消費アイテム22個ですぐに使用ボタン306とを含む。表示領域304は、使用不能な複数の開封マシンについての一括使用可能条件を表示する領域である。すなわち、表示領域304は、各開封マシン203a〜203dについて第1の条件として設定された必要時間の残りの合計が32分であること、及び、一括使用可能条件として設定された消費アイテムの必要量が22個であることを示している。なお、この例では、必要時間の残りの合計Σt及び一括使用可能条件における必要量Mの関係として、M≒β×Σtを採用し、β=0.7を想定している。つまり、この例では、図10(D)の時点では、必要時間の残りの合計Σtが48分であったため、必要量Mが33分であった。その後、前述したように4分が経過し、必要時間の残りの合計Σtが32分になったことにより、必要量Mが22個に更新されている。
閉じるボタン305は、当該画面例から、図10(D)の画面例に戻ることを指示するUIオブジェクトの一例である。閉じるボタン305に対する入力操作が受け付けられ、図10(D)の画面例に戻った後、2分が経過すると、開封マシン203a及び203bが使用可能となる。また、8分が経過すると、開封マシン203cが使用可能となる。また、24分が経過すると、開封マシン203dが使用可能となる。24分が経過するまでに、開封マシン203a〜203cに新たなカプセルがセットされていなければ、図12(D)の画面例が表示される。図12(D)では、各開封マシン203a〜203dが、使用可能な態様の表示に更新されている。
消費アイテム22個ですぐに使用ボタン306は、消費アイテム22個との引き換えを指示するためのUIオブジェクトの一例である。消費アイテム22個ですぐに使用ボタン306に対する入力操作が受け付けられると、ユーザに関連付けられた消費アイテムのうち22個が消費され、図12(D)の画面例が表示される。図12(D)については、前述した通りであるため、説明を繰り返さない。
なお、図12(A)〜(B)で説明したように、個別使用可能条件における必要時間t及び必要量mの関係として、m=α×tを採用する例について説明した。ただし、図13に示すように、必要時間tが閾値t1以上の場合には、必要時間t及び必要量mの関係として、m=m1=α×t1を採用してもよい。すなわち、必要時間tが閾値t1以上の場合には、必要量mは固定値m1に設定される。これにより、開封マシンが使用可能になるまでの必要時間が長い場合に、消費アイテムの必要量mが固定値m1以上に多くならないため、ユーザは、すぐに使用可能にするために消費アイテムと交換することに対するメリットを感じることができる。
〔変形例〕
本実施形態において、実行可能状態管理部117が、複数の管理情報を管理する例について説明した。これに限らず、実行可能状態管理部117によって管理される管理情報は、1つであってもよい。その場合であっても、本実施形態は、一括して開封するための構成及び動作、ならびに、一括して使用可能にするための構成及び動作以外については、同様に構成され、同様に動作することにより、同様の効果を奏する。
また、本実施形態において、管理情報が、「開封マシン」として表現される例について説明した。これに限らず、管理情報は、任意のカプセルの開封が可能な状態であるか待機状態であるかを表し、開封が可能な状態の管理情報に基づいてカプセルが開封されることを表す表現であれば、その他の表現で表されていてもよい。
また、本実施形態において、第1の条件が、必要時間が経過することである例について説明した。これに限らず、第1の条件は、使用不能な開封マシンを、ユーザの操作によらずに使用可能にするための条件であれば、その他の条件であってもよい。
また、本実施形態において、第2の条件及び第3の条件が、消費アイテムの必要量を消費することである例について説明した。これに限らず、第2の条件及び第3の条件の少なくとも一方は、ゲームにおいて設定されるその他の条件であってもよい。
〔本実施形態の効果〕
以上説明したように、本実施形態では、任意のカプセルの開封を可能とするための第1の条件の一例として、必要時間が経過することが設定される。このような第1の条件は、ユーザの操作によらずとも達成可能な条件である。また、このような第1の条件は、カプセルが開封されたときに設定される。そのため、ユーザは、カプセルを開封した後、ユーザの操作によらずとも必要時間さえ経過すれば、所望の時点で、次の任意のカプセルを開封して、当該カプセルに応じたオブジェクトを取得することができる。ユーザは、カプセルを開封するための何等かの条件を満たすよう、操作を行う必要がない。このように、本実施形態は、任意のカプセルを開封する手段として、直近でカプセルを開封後に設定される、ユーザの操作によらない第1の条件を達成する、という従来にない新たな手段を提供する。これにより、ゲームの興趣性を高めることができる。
また、本実施形態では、任意のカプセルの開封を可能とするための第2の条件の一例として、消費アイテムの必要量を消費することが設定される。消費アイテムの必要量は、第1の条件における必要時間の長さに応じて設定される。また、本実施形態では、任意の複数のカプセルの一括での開封を可能とするための一括使用可能条件として、第2の条件において設定される必要量の合計より少ない量の消費アイテムを消費することが設定される。このように、本実施形態は、カプセルを開封する手段を多様化することで、ゲームの興趣性を高めることができる。
〔ソフトウェアによる実現例〕
制御部210、ならびに、制御部110の各機能ブロック(特に、操作受付部111、表示制御部112、UI制御部113、アニメーション生成部114、ゲーム進行部115、報酬決定部116、実行可能状態管理部117、オブジェクト付与部118)は、集積回路(ICチップ)等に形成された論理回路(ハードウェア)によって実現してもよいし、CPU(Central Processing Unit)を用いてソフトウェアによって実現してもよい。
後者の場合、制御部210または制御部110、もしくはその両方を備えた情報処理装置は、各機能を実現するソフトウェアであるプログラムの命令を実行するCPU、上記プログラムおよび各種データがコンピュータ(またはCPU)で読み取り可能に記録されたROM(Read Only Memory)または記憶装置(これらを「記録媒体」と称する)、上記プログラムを展開するRAM(Random Access Memory)などを備えている。そして、コンピュータ(またはCPU)が上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記記録媒体としては、「一時的でない有形の媒体」、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムは、該プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して上記コンピュータに供給されてもよい。なお、本発明の一態様は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
本発明は上述した実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
〔付記事項〕
本発明の一側面に係る内容を列記すると以下のとおりである。
(項目1) ゲームプログラム(131)について説明した。本開示のある局面によると、ゲームプログラムは、プロセッサ(10、20)及びメモリ(11、21)を備えるコンピュータ(ユーザ端末100、サーバ200)により実行される。ゲームプログラムは、プロセッサに、ゲームプログラムに基づくゲームの進行に応じて、ゲームにおいて利用可能なオブジェクトを取得するための権利アイテムをユーザに付与するステップと、ユーザによって保有される権利アイテムのうち任意の権利アイテムの消費が可能な状態であるか、不能な状態から可能な状態に至るまでの待機状態であるかを表す管理情報を、メモリに記憶させて管理するステップと、管理情報が、消費が可能な状態を表す場合、権利アイテムを消費して、当該権利アイテムに基づくオブジェクトをユーザに付与するステップと、を実行させる。管理するステップは、オブジェクトを付与するステップにおいてオブジェクトが付与されると、消費が可能な状態を表す管理情報を、待機状態を表すよう更新するとともに、ユーザの操作によらずとも達成可能な第1の条件を設定するステップと、第1の条件が満たされた場合に、待機状態を表す管理情報を、消費が可能な状態を表すよう更新するステップと、を実行することを含む。
従来、ユーザに付与された権利アイテムについて、ユーザの操作に基づく何等かの条件が満たされた場合に、当該権利アイテムに応じたオブジェクトがユーザに付与されていた。本構成によれば、任意の権利アイテムの消費を可能とするための第1の条件は、ユーザの操作によらずとも達成可能な条件である。また、第1の条件は、権利アイテムが前回消費されたときに設定される。そのため、ユーザは、権利アイテムを消費した後、ユーザの操作によらずとも達成可能な第1の条件さえ満たされれば、所望の時点で、次の権利アイテムを消費して、当該権利アイテムに応じたオブジェクトを取得することができる。つまり、ユーザは、権利アイテムを消費するための何等かの条件を満たすよう、操作を行う必要がない。このように、本構成は、付与された権利アイテムに応じたオブジェクトを取得するための新たな手段を提供し、ゲームの興趣性を高めることができる。
(項目2) (項目1)において、オブジェクトを付与するステップは、ユーザによって保有される権利アイテムのうち、ユーザの操作に基づく権利アイテムを消費してもよい。これにより、ユーザは、第1の条件が満たされていれば、所望の権利アイテムに対する操作を、所望の時点で行うことにより、当該権利アイテムに応じたオブジェクトを取得することができる。
(項目3) (項目1)又は(項目2)において、第1の条件を設定するステップは、オブジェクトを付与するステップにおいてオブジェクトが付与されると、当該オブジェクトを付与するステップにおいて消費された権利アイテムに基づいて、第1の条件を設定してもよい。このように、権利アイテムの次回の消費を可能とする第1の条件を、直近に消費された権利アイテムに応じて多様化することで、ゲームの興趣性を向上させる。
(項目4) (項目3)において、プロセッサは、権利アイテムに関連付けて、当該権利アイテムに応じて取得可能なオブジェクトに関するゲームを有利に進める上での価値に基づく希少度を、メモリに記憶させてもよい。この場合、第1の条件を設定するステップは、当該オブジェクトを付与するステップにおいて消費された権利アイテムに関連付けられた希少度に基づいて、第1の条件を設定する。これにより、権利アイテムの次回の消費を可能とする第1の条件が、ユーザが直近に取得できたオブジェクトの価値に基づくものであるため、設定される第1の条件に対するユーザの納得感を得ることができる。
(項目5) (項目1)から(項目4)の何れか1項目において、管理するステップは、複数の管理情報をメモリに記憶させてもよい。この場合、オブジェクトを付与するステップは、消費が可能な状態を表す管理情報に基づいて、権利アイテムを消費して、当該権利アイテムに基づくオブジェクトをユーザに付与する。また、第1の条件を設定するステップは、オブジェクトを付与するステップにおいて消費が可能な状態を表す管理情報に基づいてオブジェクトが付与されると、当該管理情報を、待機状態を表すよう更新するとともに、当該管理情報に関連付けて第1の条件を設定する。また、更新するステップは、第1の条件が満たされると、当該第1の条件に関連付けられた管理情報を、消費が可能な状態を表すよう更新する。これにより、ユーザは、消費が可能な状態を表す1つの管理情報に基づいて権利アイテムを消費してオブジェクトを取得した後、当該管理情報に関連付けて設定された第1の条件が満たされていなくても、他の管理情報が、消費が可能な状態を表していれば、当該管理情報に基づいて、新たな権利アイテムを消費してオブジェクトを取得できる。その結果、付与された権利アイテムに応じたオブジェクトの取得が、さらに容易となる。
(項目6) (項目5)において、オブジェクトを付与するステップは、消費が可能な状態を表す複数の管理情報に基づいて、複数の権利アイテムを一括して消費して、当該複数の権利アイテムの各々に基づくオブジェクトを一括してユーザに付与してもよい。この場合、第1の条件を設定するステップは、オブジェクトを付与するステップにおいて消費が可能な状態を表す複数の管理情報に基づいてオブジェクトが一括して付与されると、当該複数の管理情報の各々を、待機状態を表すよう更新するとともに、当該管理情報に関連付ける第1の条件として、当該管理情報に基づいて個別に権利アイテムが消費された場合に設定される第1の条件に比べて達成が容易な条件を設定する。これにより、ユーザは、複数の権利アイテムを一括して消費することに対するメリットを感じることができる。
(項目7) (項目1)から(項目6)の何れか1項目において、第1の条件を設定するステップは、第1の条件として、必要時間が経過することを設定してもよい。これにより、ユーザは、設定時間の経過後に所望の時点で、保有する権利アイテムの何れかに応じたオブジェクトを取得することができる。
(項目8) (項目7)において、第1の条件を設定するステップは、第1の条件を設定するとともに、ユーザによって保有される消費アイテムの必要量を消費することを第2の条件として設定し、更新するステップは、第1の条件が満たされた場合に加えて、第2の条件が満たされた場合に、待機状態を表す管理情報を、消費が可能な状態を表すよう更新してもよい。これにより、権利アイテムの次回の消費を可能とするための条件を多様化してゲームの興趣性を高めることができる。具体的には、ユーザは、設定時間の経過を待つ代わりに、消費アイテムの必要量を消費することにより、所望の時点で、保有する権利アイテムの何れかに応じたオブジェクトを取得することができる。
(項目9) (項目8)において、第1の条件を設定するステップは、第1の条件における必要時間が長いほど、第2の条件における必要量を多く設定してもよい。これにより、権利アイテムの次回の消費を可能とするために必要となる消費アイテムの必要量が、消費アイテムを消費しない場合に待たなければいけない必要時間の長さに応じた量となる。その結果、消費アイテムの必要量に対するユーザの納得感を得ることができる。
(項目10) (項目9)において、第1の条件を設定するステップは、第1の条件における必要時間が閾値を超えると、第2の条件における必要量を変化させないようにしてもよい。これにより、権利アイテムの次回の消費を可能とするために必要となる消費アイテムの必要量は、消費アイテムを消費しない場合に待たなければいけない必要時間の長さがどんなに長くなっても上限より多くならない。その結果、ユーザは、消費アイテムを消費することに対するメリットを感じることができる。
(項目11) (項目5)において(項目8)から(項目10)の何れか1項目が適用されるとき、第1の条件を設定するステップは、第1の条件及び第2の条件を設定するとともに、待機状態を表す複数の管理情報を、消費が可能な状態を表すよう一括して更新するための第3の条件として、待機状態を表す複数の管理情報の各々を、消費が可能な状態を表すよう個別に更新するための第2の条件における必要量の合計より少ない量の消費アイテムを消費することを設定してもよい。この場合、更新するステップは、第3の条件が満たされた場合に、待機状態を表す複数の管理情報を、消費が可能な状態を示すよう一括して更新する。これにより、ユーザは、複数の管理情報を、一括して消費が可能な状態に更新するために、消費アイテムを消費することに対するメリットを感じることができる。
(項目12) (項目1)から(項目11)の何れか1項目において、管理するステップは、管理情報を表す表示オブジェクトを表示部に表示し、オブジェクトを付与するステップは、表示オブジェクトが、消費が可能な状態を表す場合に、当該表示オブジェクトに対する操作に基づいて権利アイテムを消費してもよい。これにより、ユーザは、権利アイテムの消費が可能な状態であるか待機状態であるかを認識することができ、消費が可能な状態である場合に、権利アイテムを消費してオブジェクトを取得することができる。
(項目13) ゲームプログラムを実行する方法を説明した。本開示のある局面によると、ゲームプログラムは、プロセッサ及びメモリを備えるコンピュータにより実行される。該方法は、プロセッサが(項目1)に記載の各ステップを実行する方法である。(項目13)に係る方法は、(項目1)に係るゲームプログラムと同様の作用効果を奏する。
(項目14) 情報処理装置を説明した。本開示のある局面によると、該情報処理装置は、(項目1)に係るゲームプログラムを記憶する記憶部(120)と、該ゲームプログラムを実行することにより、情報処理装置(ユーザ端末100)の動作を制御する制御部(110)とを備える。(項目14)に係る情報処理装置は、(項目1)に係るゲームプログラムと同様の作用効果を奏する。