本開示に係るゲームシステムは、複数のユーザにゲームを提供するためのシステムである。以下、ゲームシステムについて図面を参照しつつ説明する。なお、本発明はこれらの例示に限定されるものではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が本発明に含まれることが意図される。以下の説明では、図面の説明において同一の要素には同一の符号を付し、重複する説明を繰り返さない。
<ゲームシステム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とは異なる入力装置(図示せず)から出力される信号をユーザの入力操作として特定し、受け付ける。
<各装置のハードウェア構成要素>
プロセッサ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とサーバ200との協働により実現されるゲームは、一例として、ユーザ端末100において起動されたブラウザ上で実行されるゲームであってもよい。あるいは、該プログラムは、該ゲームを複数のユーザ端末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は、ユーザによる対価の支払い又は対価の支払いに応じて得られるゲームアイテムの消費に基づくゲーム処理を含むゲームを実行するためのシステムである。
ゲームシステム1によって実行されるゲーム(以下、本ゲーム)は、特定のジャンルに限らず、あらゆるジャンルのゲームであってよい。例えば、テニス、卓球、ドッジボール、野球、サッカーおよびホッケーなどのスポーツを題材としたゲーム、パズルゲーム、クイズゲーム、RPG、アドベンチャーゲーム、シューティングゲーム、シミュレーションゲーム、育成ゲーム、ならびに、アクションゲームなどであってもよい。
また、本ゲームは、特定のプレイ形態に限らず、あらゆるプレイ形態のゲームであってもよい。例えば、単一のユーザによるシングルプレイゲーム、および、複数のユーザによるマルチプレイゲーム、また、マルチプレイゲームの中でも、複数のユーザが対戦する対戦ゲーム、および、複数のユーザが協力する協力プレイゲームなどであってもよい。
<ゲームシステム1の機能的構成>
図2は、ゲームシステム1に含まれるサーバ200およびユーザ端末100の機能的構成を示すブロック図である。サーバ200およびユーザ端末100のそれぞれは、図示しない、一般的なコンピュータとして機能する場合に必要な機能的構成、および、ゲームにおける公知の機能を実現するために必要な機能的構成を含み得る。
ユーザ端末100は、ユーザの入力操作を受け付ける入力装置としての機能と、ゲームの画像や音声を出力する出力装置としての機能を有する。ユーザ端末100は、プロセッサ10、メモリ11、ストレージ12、通信IF13、および入出力IF14等の協働によって、制御部110および記憶部120として機能する。
サーバ200は、各ユーザ端末100と通信して、ユーザ端末100がゲームを進行させるのを支援する機能を有する。ゲームがマルチプレイゲームである場合には、サーバ200は、ゲームに参加する各ユーザ端末100と通信して、ユーザ端末100同士のやりとりを仲介する機能を有していてもよい。サーバ200は、プロセッサ20、メモリ21、ストレージ22、通信IF23、および入出力IF24等の協働によって、制御部210および記憶部220として機能する。
記憶部120および記憶部220は、ゲームプログラム、ゲーム情報132およびユーザ情報133を格納する。ゲームプログラム131は、ユーザ端末100が実行するゲームプログラムである。ゲームプログラム231は、サーバ200が実行するゲームプログラムである。ゲーム情報132は、制御部110および制御部210がゲームプログラムを実行する際に参照するデータである。ユーザ情報133は、ユーザのアカウントに関するデータである。記憶部220において、ゲーム情報132およびユーザ情報133は、ユーザ端末100ごとに格納されている。
(サーバ200の機能的構成)
制御部210は、記憶部220に格納されたゲームプログラム231を実行することにより、サーバ200を統括的に制御する。例えば、制御部210は、ユーザ端末100に各種データおよびプログラム等を送信する。制御部210は、ゲーム情報もしくはユーザ情報の一部または全部をユーザ端末100から受信する。ゲームがマルチプレイゲームである場合には、制御部210は、ユーザ端末100からマルチプレイの同期の要求を受信して、同期のためのデータをユーザ端末100に送信してもよい。
制御部210は、ゲームプログラム231の記述に応じて、進行支援部211、販売処理部212、及び抽選支援部213として機能する。制御部210は、実行するゲームの性質に応じて、ユーザ端末100におけるゲームの進行を支援するために、図示しないその他の機能ブロックとしても機能することができる。
進行支援部211は、ユーザ端末100と通信し、ユーザ端末100が、本ゲームを進行させるための支援を行う。例えば、進行支援部211は、ユーザ端末100におけるゲームの進行状況に応じて、そのときにユーザ端末100が参照すべき情報を適宜提供する。
販売処理部212は、ゲームアイテムをユーザに販売するための処理を実行する。販売処理部212は、ユーザ端末100からの要求に応じて課金処理を実行し、要求されたゲームアイテムをユーザに保有させるための付与処理を実行する。一例として、ゲームアイテムは、ゲーム内における仮想通貨である。なお、仮想通貨は、本発明における「対価の支払いに応じて得られるゲームアイテム」の一例に相当する。
この場合、販売処理部212は、要求された数の仮想通貨に対応する金額を、要求元のユーザ端末100の所有者であるユーザに対して請求するための課金処理を実行する。販売処理部212は、課金処理を、外部の課金サーバ(図示せず)に対して要求し、課金サーバから、決済完了の通知を受領する。そして、販売処理部212は、決済完了の通知を受領後、仮想通貨をユーザに保有させるための付与処理として、購入された数量の仮想通貨を表す情報を、ユーザ端末100に送信する。なお、本実施形態では、ユーザによって保有される仮想通貨は、ユーザ端末100においてユーザに関連付けて記憶されるものとして説明する。
また、販売処理部212は、対価の支払いに基づくゲーム処理を実行するための課金処理を実行する。販売処理部212は、ユーザ端末100からの要求に応じて課金処理を実行後、該当するゲーム処理が実行可能となったことをユーザ端末100に通知する。一例として、ゲーム処理は、抽選処理である。
この場合、販売処理部212は、要求された抽選処理に対応する金額を、要求元のユーザ端末100の所有者であるユーザに対して請求するための課金処理を、課金サーバに対して要求する。販売処理部212は、課金サーバから決済完了の通知を受領すると、抽選処理が実行可能となったことをユーザ端末100に通知する。
抽選支援部213は、ユーザ端末100からの抽選要求にしたがって、ゲームにおいて利用可能なゲーム媒体のうち、ユーザに付与するためのゲーム媒体を決定する選択処理を実行する。選択処理は、所定の規則に基づいて行われる。本実施形態では、所定の規則とは、各ゲーム媒体に設定された抽選確率であるものとする。以降、抽選確率に基づく選択処理を、抽選処理とも記載する。ただし、選択処理は、抽選処理に限らず、他の規則に基づくものであってもよい。また、抽選支援部213は、決定したゲーム媒体を表す情報を、ユーザ端末100に送信する。送信されたゲーム媒体は、ユーザによって保有されるものとして、ユーザ端末100においてユーザに関連付けて記憶される。
また、ユーザ端末100からの抽選要求の内容が、複数回の抽選を示す場合がある。この場合、抽選支援部213は、複数回の抽選を実行することにより、複数のゲーム媒体を決定すればよい。
(ユーザ端末100の機能的構成)
制御部110は、記憶部120に格納されたゲームプログラム131を実行することにより、ユーザ端末100を統括的に制御する。例えば、制御部110は、ゲームプログラム131およびユーザの操作にしたがって、ゲームを進行させる。また、制御部110は、ゲームを進行させている間、必要に応じて、サーバ200と通信して、情報の送受信を行う。
制御部110は、ゲームプログラム131の記述に応じて、ゲーム進行部111、購入処理部112、抽選部113、及び割引管理部114として機能する。
なお、制御部110は、実行するゲームの性質に応じて、ゲームを進行させるために、図示しないその他の機能ブロックとしても機能することができる。
また、制御部110は、図示しない操作受付部、および、表示制御部などとしても機能する。操作受付部は、入力部151に対するユーザの入力操作を検知し受け付ける。例えば、操作受付部は、上述の入力操作の、入力部151における入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部は、例えば、タッチ操作、スライド操作、スワイプ操作、およびタップ操作等を特定する。表示制御部は、タッチスクリーン15の表示部152に対して、制御部110の各部によって実行された処理結果が反映されたゲーム画面を出力する。表示制御部は、制御部110の各部によって生成された映像を含むゲーム画面を表示部152に表示してもよい。また、表示制御部は、グラフィカルユーザインターフェース(以下、GUI)を、該ゲーム画面に重畳して描画してもよい。
なお、以降、操作受付部によって入力部151に対する入力操作が検知され受け付けられることを、単に、入力操作が受け付けられる、とも記載する。また、他の機能ブロックが、各種のゲーム画面を表示制御部によって表示部152に出力することを、単に、表示する、とも記載する。
また、本実施形態では、任意のゲームデータをユーザに付与する、ユーザが保有する、ユーザが取得するとは、ユーザ端末100の記憶部120に、ユーザに関連付けて記憶させることであるとして説明する。ただし、付与する、保有する、取得するとは、ユーザに関連付けて記憶部120及び220の少なくとも一方に記憶させることであってもよい。ユーザによって保有されるゲームデータが記憶部120及び220の何れかに記憶される場合、当該保有されるゲームデータに関する情報は、必要に応じてユーザ端末100及びサーバ200間で送受信されるものとする。
ゲーム進行部111は、ゲームの進行に係る各種処理を行う。例えば、ゲーム進行部111は、ユーザに付与されたゲーム媒体を用いて、ユーザ操作に応じてゲームを進行させる。
購入処理部112は、仮想通貨の購入を指示する入力操作が受け付けられると、指示された数量の仮想通貨の購入要求を、サーバ200に送信する。また、購入処理部112は、指示された数量に対応する金額の課金処理を完了したサーバ200から通知された仮想通貨を、ユーザに付与する。
抽選部113は、抽選処理の実行を指示する入力操作が受け付けられると、当該抽選処理に応じた金額の課金処理を、サーバ200に要求する。また、抽選部113は、課金処理が完了して抽選処理が実行可能となると、サーバ200に対して、抽選処理を要求する。また、抽選部113は、抽選処理により決定されたゲーム媒体を、ユーザに付与する。ここで、抽選処理に応じた金額とは、例えば、抽選処理の回数、抽選され得るゲーム媒体の構成、抽選処理で用いられる抽選確率テーブル等に応じて定められていてもよい。
割引管理部114は、第1処理が第1条件で実行されたタイミングを特定し、特定したタイミングの翌日以降において第2処理が実行される場合に第2条件を適用可能とする。具体的には、割引管理部114は、第1処理が第1条件で実行されたタイミングを含む日を、第1日として特定してもよい。また、特定したタイミングの翌日以降のうち、第1日の翌日において、第2処理に第2条件を適用可能としてもよい。以降、第1日の翌日を、第2日とも記載する。ここで、特定したタイミングを表す情報は、記憶部120に記憶される。以降、特定したタイミングを表す情報を、特定のタイミングを表す情報とも記載する。例えば、特定のタイミングを表す情報は、当該タイミングを含む第1日の日付と、適用された第1条件とをそれぞれ表す情報を含んでいてもよい。
なお、第2日は、第1日が開始してから24時間後に開始するものとする。ここで、第1日及び第2日は、日付が変更となる時刻から開始してもよいし、その他の所定の時刻から開始してもよい。例えば、第1日及び第2日は、日付が変更となる夜中の0時から開始してもよいし、早朝3時から開始してもよい。なお、第1日及び第2日のそれぞれの長さは、厳密に24時間の長さでなくてもよい。
また、本実施形態では、第2条件が適用されるのは、特定したタイミングの翌日以降に実行される所定回数までの第2処理であるものとする。例えば、第2条件が適用されるのは、第2日において実行される第2処理のうち、ユーザによって選択された所定回数までの第2処理であってもよい。また、例えば、第2条件が適用されるのは、第2日において実行される1回目から所定回数目までの第2処理であってもよい。本実施形態では、所定回数は「1回」であるものとして説明する。なお、第2条件は、第1処理が第1条件で実行されたタイミングの翌日が開始するまでは、第2処理が実行される場合に適用されない。例えば、第2条件は、第1日が終了するまでの間、第2処理が実行される場合に適用されない。
ここで、第1処理とは、対価の支払い又は仮想通貨の消費に基づくゲーム処理である。本実施形態では、第1処理として、抽選処理を適用する。本実施形態における抽選処理は、対価の支払いに基づくゲーム処理である。また、第1条件とは、第1処理を実行する際に適用される条件であり、後述の第2条件との間で、ユーザにとっての良さが比較可能な条件である。第1条件の詳細については後述する。
また、第2処理とは、対価の支払い又は仮想通貨の消費に基づくゲーム処理である。例えば、第2処理は、第1処理と同一カテゴリのゲーム処理であってもよい。本実施形態では、第2処理として、第1処理と同一の抽選処理を適用する。
また、第2条件とは、第1条件よりもユーザにとって有利な条件である。本実施形態では、第2条件は、対価の支払い金額の割引率が第1条件よりも高い条件であるとする。つまり、この場合、第1条件及び第2条件は、どちらも、対価の支払い金額の割引率に関する条件である。具体的には、第1条件が、「第1割引率で割り引く」との条件である場合、第2条件は、「第1割引率より高い第2割引率で割り引く」との条件であるとする。なお、第1割引率が「0%」である場合、第1条件は、「0%で割り引く」、すなわち、「割引なし」との条件を表す。この場合、第2条件は、「0%」より大きい割引率での割引であればよい。
また、割引管理部114は、第2日に第2条件で第2処理が実行されると、第2条件及び第2処理を新たな第1条件及び新たな第1処理とみなすことにより、第2日を新たな第1日として特定する。この場合、割引管理部114は、新たな第1日の翌日以降の新たな第2日において新たな第2処理が実行される場合に、新たな第2条件を適用可能とする。ここで、新たな第2条件は、新たな第1条件(すなわち、前回の第2条件)よりもユーザにとって有利な条件である。
換言すると、割引管理部114は、対価の支払いに基づく抽選処理を実行させた連続日数が多くなるほど、ユーザにとってより有利な第2条件での抽選処理を実行可能とする。例えば、割引管理部114は、前日の第1条件よりユーザにとって良い第2条件を設定するために、連続日数に応じた第2条件を記憶部120に記憶していてもよい。また、この場合、割引管理部114は、第1日を特定する度に、連続日数のカウントを増加させてもよい。連続日数の初期値は0である。
なお、割引管理部114は、新たな第1条件が所定条件である場合、新たな第1日の翌日以降の新たな第2日において新たな第2処理が実行される場合に、第1日と同じ第1条件を適用可能とする。所定条件とは、ユーザにとっての良さとしての上限を表す条件であってもよい。本実施形態では、所定条件とは、割引率の上限であるとする。換言すると、対価の支払いに基づく抽選処理が連日実行される場合、連続日数が閾値以上となると、割引率は前日から変化しない。
なお、図2に示すサーバ200およびユーザ端末100の機能は一例にすぎない。サーバ200は、ユーザ端末100が備える機能の少なくとも一部を備えていてもよい。また、ユーザ端末100は、サーバ200が備える機能の少なくとも一部を備えていてもよい。さらに、ユーザ端末100およびサーバ200以外の他の装置をゲームシステム1の構成要素とし、該他の装置にゲームシステム1における処理の一部を実行させてもよい。すなわち、本実施形態においてゲームプログラムを実行するコンピュータは、ユーザ端末100、サーバ200、および他の装置の何れであってもよいし、これらの複数の装置の組み合わせにより実現されてもよい。
<処理概要>
本実施形態においてゲームシステム1が実行する処理の概要について説明する。ユーザ端末100において、まず、抽選部113は、ユーザによる対価の支払いまたは支払いにより得られるゲームアイテムの消費に基づく第1処理を実行するための第1操作をユーザから受け付ける。次に、抽選部113は、第1操作に応答して、第1処理を第1条件で実行する。次に、割引管理部114は、第1条件で第1処理が実行されたタイミングを特定する。次に、割引管理部114は、第1条件で第1処理が実行されたことに応答して、対価の支払いまたは支払いにより得られるゲームアイテムの消費に基づく第2処理を、第1条件よりもユーザにとって有利な第2条件で、上述したタイミングの翌日以降に実行可能とする。次に、抽選部113は、第2処理を第2条件で実行するための第2操作を、ユーザから受け付ける。次に、抽選部113は、第2操作に応答して、第2処理を第2条件で実行する。
<処理フロー>
図3は、本実施形態においてゲームシステム1が実行する処理の詳細な流れを示すフローチャートである。なお、以下に説明する各ステップは、ユーザ端末100によって実行されるものとして説明するが、その少なくとも一部がサーバ200によって実行されてもよい。また、以下に説明する処理の開始時には、記憶部120には、連続日数のカウントとして初期値である「0」が記憶されているものとする。
ステップS101において、割引管理部114は、本日が、特定のタイミングの翌日以降であるか否かを判断する。具体的には、割引管理部114は、本日が第1日の翌日であるか否かを判断する。例えば、記憶部120に、特定のタイミングを表す情報が記憶されていれば、割引管理部114は、本日が、当該特定のタイミングを表す情報によって示される第1日の翌日であるか否かを判断すればよい。また、記憶部120に、特定のタイミングを表す情報が記憶されていなければ、割引管理部114は、本日が、特定のタイミングの翌日以降でないと判断すればよい。
ステップS101でYesの場合については後述する。ステップS101でNoの場合、次のステップS102の処理が実行される。
ステップS102において、抽選部113は、抽選画面を表示する。このとき、抽選画面には、抽選処理を行うための定価の金額が含まれる。
ステップS103において、抽選部113は、抽選処理を指示するユーザ操作が受け付けられたか否かを判断する。当該ユーザ操作は、上述した第1操作の一例である。つまり、本ステップでは、第1操作を受け付ける本発明の第1ステップが実行されたか否かが判断される。ステップS103でNoの場合、ステップS101からの処理が実行される。ステップS103でYesの場合、次のステップS104の処理が実行される。
ステップS104において、抽選部113は、定価の課金処理を、サーバ200に要求することにより実行する。抽選部113は、サーバ200から、当該課金処理が完了したことを通知される。
ステップS105において、抽選部113は、抽選処理を、サーバ200に要求することにより実行する。抽選部113は、サーバ200から、抽選処理で決定されたゲーム媒体を通知されると、当該ゲーム媒体をユーザに付与する。定価での課金処理は、上述した第1条件の一例であり、抽選処理は、上述した第1処理の一例である。つまり、本ステップでは、第1操作に応答して第1処理を第1条件で実行する第2ステップが実行される。
ステップS106において、割引管理部114は、第1条件で抽選処理が実行されたタイミングを特定する。具体的には、割引管理部114は、当該タイミング含む日を、第1日として特定する。つまり、本ステップでは、本発明における第3ステップが実行される。具体的には、割引管理部114は、特定のタイミングを表す情報として、第1日を表す情報(例えば、日付)と、適用された第1条件(第1日に適用された割引率)とを表す情報を、記憶部120に記憶させる。また、割引管理部114は、抽選処理を実行させた連続日数のカウントを1つ増加させる。
ステップS107において、割引管理部114は、第1日に適用された割引率が、上限値に達しているか否かを判断する。当該判断処理は、記憶部120に記憶された特定のタイミングを表す情報に含まれる第1条件を参照することにより、実行可能である。ステップS107でNoの場合、次のステップS108の処理が実行され、Yesの場合、次のステップS109の処理が実行される。
ステップS108において、割引管理部114は、第2日の割引率として、第1日より高い割引率を設定する。一方、ステップS109において、割引管理部114は、第2日の割引率として、第1日と同一の割引率を設定する。
なお、ステップS108及びS109において、第2日の割引率は、記憶部120に記憶された第1日の割引率が参照されることにより、それより高い値又は同一の値として算出されてもよい。また、第2日の割引率は、記憶部120に記憶された、連続日数に応じた割引率を表す情報が参照されることにより、現在の連続日数のカウントに応じた割引率が設定されてもよい。
また、ステップS108及びS109において、抽選部113は、設定した第2日の割引率を表す情報を、抽選結果とともに表示してもよい。これにより、ユーザは、課金処理によって抽選処理を実行させたことに対する報酬として、第2日の割引率を認識できる。
ステップS108又はS109の実行後、ステップS101からの処理が実行される。
ここで、ステップS108又はS109の実行後、第1日の間にステップS101が実行される場合は、ステップS101でNoとなり、ステップS102からの処理が実行される。第1日の翌日になると、ステップS101でYesとなり、次のステップS110の処理が実行される。
ステップS110において、抽選部113は、抽選画面を表示する。抽選画面には、ステップS108又はS109で設定された第2日の割引率が適用された割引価格が含まれる。
ステップS111において、抽選部113は、割引価格での抽選処理を指示するユーザ操作が受け付けられたか否かを判断する。当該ユーザ操作は、上述した第2操作の一例である。このように、第2操作は、現在の時が第1日の時刻の範囲に含まれる場合には、受け付けられず、現在の時が第1日の時刻の範囲以降である場合(一例として、ここでは、第2日の時刻の範囲に含まれる場合)には、受け付け可能である。つまり、本ステップでは、第2操作を受け付ける本発明の第4ステップが実行されたか否かが判断される。ステップS111でNoの場合については後述する。ステップS111でYesの場合、次のステップS112の処理が実行される。
ステップS112において、抽選部113は、第2日の割引率による割引価格の課金処理を、サーバ200に要求することにより実行する。抽選部113は、サーバ200から、課金サーバによる当該課金処理が完了したことを通知される。
ステップS113において、抽選部113は、抽選処理を、サーバ200に要求することにより実行する。抽選部113は、サーバ200から、抽選処理で決定されたゲーム媒体を通知されると、当該ゲーム媒体をユーザに付与する。割引価格での課金処理は、上述した第2条件の一例であり、抽選処理は、上述した第2処理の一例である。つまり、本ステップでは、第2操作に応答して第2処理を第2条件で実行する第5ステップが実行される。
ステップS113の実行後、ステップS106(第3ステップ)からの処理が実行される。換言すると、ゲームシステム1は、ステップS113(第5ステップ)が実行されたことに応答して、ステップS106(第3ステップ)からS109、ステップS101からS113(第5ステップ)までの各ステップを再度実行させる。
再度実行されるステップS106において、それまでの第2処理は「新たな第1処理」とみなされ、それまでの第1条件は「新たな第1条件」とみなされる。したがって、再度実行されるステップS106において、「新たなタイミング」が特定される。また、特定された「新たなタイミング」を含む新たな第1日は、それまでの第2日である。これにより、記憶部120における「特定のタイミングを表す情報」は、新たな第1日及び新たな第1条件をそれぞれ表す情報を含むよう更新される。
また、ステップS108で、第2日の割引率として第1日より高い割引率が設定された場合には、再度実行されるステップS111(第4ステップ)では、新たな第1条件よりもユーザにとって有利な新たな第2条件で、新たな第2処理を実行するための第2操作が、新たな第2日に受け付けられる。また、再度実行されるステップ114(第5ステップ)では、新たな第2日に新たな抽選処理が新たな第2条件で実行される。
また、ステップS109で、第2日の割引率として第1日と同一の割引率が設定された場合には、再度実行されるステップS111(第4ステップ)では、新たな第2処理を第1条件で実行するための第3操作が、新たな第2日に受け付けられる。また、再度実行されるステップS113(第5ステップ)では、新たな第2日に新たな抽選処理が第1条件で実行される。
なお、本フローチャートによれば、第2日と判定された日付において一旦ステップS112及びS113が実行されると、その後ステップS106が実行されることにより第1日及び第2日の表す日付が更新される。つまり、第2日と判定された日付において第2日の割引率が適用されるのは、当該日付において第2処理が1回目に実行される場合に限られる。当該日付において第2処理が2回目以降に実行される際には、定価が適用される。そして、当該日付のさらに翌日において第2処理が1回目に実行される場合に、新たな第2日の割引率が適用されることになる。
一方、ステップS111でNoの場合、次のステップS114が実行される。ステップS114において、割引管理部114は、特定されたタイミングの翌日開始以降の所定時点が終了したか否かを判断する。具体的には、割引管理部114は、第2日が終了したか否かを判断すればよい。ステップS114でNoの場合、ステップS101からの処理が実行される。ステップS114でYesの場合、次のステップS115の処理が実行される。
ステップS115において、割引管理部114は、連続日数のカウントを初期値にリセットする。そして、ステップS101からの処理が実行される。
このように、第2日が終了するまでに第2操作又は第3操作が受け付けられなかった場合には、ステップS111(第4ステップ)及びステップS113(第5ステップ)が実行される代わりに、第2日の翌日以降において、ステップS103(第1ステップ)からステップS113(第5ステップ)までの各ステップが実行される。
<具体例>
(連続日数に応じた翌日の割引率の具体例)
図4は、連続日数に応じた翌日の割引率の具体例である。当該翌日の割引率を表す情報は、例えば、記憶部120に記憶されている。図4に示すように、連続日数が1日では、翌日の割引率として10%が、2日では20%が、3日では30%が、4日では40%が、5日以上では50%が設定されている。このように、連続日数が多いほど、翌日の割引率として高い値が設定されている。なお、この例の場合、割引率の上限は50%である。
(適用割引率の具体例)
図5は、連続する複数日においてそれぞれ実行されたゲーム処理に応じて、適用された割引率の具体例を示す図である。ここでは、図4に示した割引率が設定されていることを想定している。また、ここでは、抽選処理を1回実行させる(以降、1回抽選と記載する)場合は、対価として定価500円を支払う必要があり、5回実行させる(以降、5回抽選と記載する)場合は、対価として定価2500円を支払う必要があるものとする。
(1日目)
図5において、1日目に、1回抽選が実行されたことが示されている。ここでは、1日目は、第2日ではないと判断されたとする(ステップS101でNo)。このため、割引率0%が設定される(ステップS102)。そして、1回抽選を指示するユーザ操作に応じて(ステップS103でYes)、定価500円の課金処理が実行され(ステップS104)、1回抽選が実行される(ステップS105)。これにより、1日目が「第1日」として特定される。また、抽選処理の連続日数は「1日」に更新される(ステップS106)。図4が参照されることにより、報酬として、1日目より高い「翌日10%割引」が表示される(ステップS108)。
(2日目)
図5において、2日目に、5回抽選が実行されことが示されている。2日目は第2日であり(ステップS101でYes)、「10%割引」が適用される。5回抽選を指示するユーザ操作に応じて(ステップS111でYes)、定価の10%割引価格である2250円の課金処理が実行され(ステップS112)、5回抽選が実行される(ステップS113)。そして、2日目が、新たな第1日として特定される。また、抽選処理の連続日数は「2日」に更新される(ステップS106)。そして、図4が参照されることにより、報酬として、2日目より高い「翌日20%割引」が表示される。
(3日目)
図5において、3日目に、1回抽選が実行されことが示されている。3日目は新たな第2日であり、「20%割引」が適用される。1回抽選を指示するユーザ操作に応じて、定価の20%割引価格である400円の課金処理が実行され、1回抽選が実行される。そして、3日目が、新たな第1日として特定される。また、抽選処理の連続日数は「3日」に更新される。図4が参照されることにより、報酬として、3日目より高い「翌日30%割引」が表示される。
(4日目)
図5において、4日目に、抽選処理が実行されなかったことが示されている。4日目が終了するまでに、抽選処理を指示するユーザ操作が受け付けられなかったため(ステップS114でYes)、抽選処理の連続日数が初期値にリセットされる(ステップS115)。
(5日目)
図5において、5日目に、5回抽選が実行されことが示されている。特定のタイミングを表す情報が3日目を示したままであるため、5日目は、第2日でないと判断される。このため、1日目と同様に、割引率0%が設定され、定価2500円の課金処理に応じて5回抽選が実行される。5日目の報酬については、1日目と同様であるため、説明を繰り返さない。
<画面例>
図6~図9は、図5に示した具体例において表示部152に表示されるゲーム画面の一例を示す図である。ここでは、1日目が12月1日であるものとしている。
図6は、1日目においてステップS102で表示される抽選画面の一例である。図6において、抽選画面G1は、抽選ボタンG101及びG102と、連続日数情報G103と、詳細ボタンG104とを含む。抽選ボタンG101及びG102は、それぞれ、1回抽選及び5回抽選の実行を指示するユーザ操作を受け付けるUIオブジェクトの一例である。抽選ボタンG101内には、1回抽選を実行させるために支払う必要がある対価として定価「500円」が表示されている。抽選ボタンG102内には、5回抽選を実行させるために支払う必要がある対価として定価「2500円」が表示されている。連続日数情報G103は、この時点で、抽選処理の連続日数のカウントが0であることを示している。詳細ボタンG104は、連続日数に応じた割引率を表示する指示を受け付けるUIオブジェクトの一例である。詳細ボタンG104に対するユーザ操作が受け付けられると、例えば、図4に示した情報が表示される。
図7は、1日目においてステップS108で表示される抽選結果画面の一例である。図7に示す抽選結果画面G2は、図6において抽選ボタンG101に対するユーザ操作が受け付けられたことに応答して表示される。抽選結果画面G2は、当選情報G201と、報酬情報G202と、連続日数情報G203と、詳細ボタンG104とを含む。
当選情報G201は、1回抽選が実行された結果を表している。ここでは、抽選処理によりユーザに付与されたゲーム媒体が「ゲームアイテムA」であることが示されている。連続日数情報G203は、抽選処理を実行した連続日数が「1日」となったことを表している。報酬情報G202は、連続日数が1日となったことによる報酬を表している。ここでは、翌日である12月2日に抽選処理を実行させるために支払う必要がある対価が、定価より10%割引になることが示されている。報酬情報G202の表示は、翌日ゲームにログインすることに対するユーザの動機付けを向上させる。
図8は、2日目においてステップS110で表示される抽選画面の一例である。図8において、抽選画面G3は、抽選ボタンG301及びG302と、割引情報G303と、連続日数情報G203と、詳細ボタンG104とを含む。抽選ボタンG301及びG302は、図6に示した抽選ボタンG101及びG102に対して、内部に表示される価格が異なる。抽選ボタンG301内には、割引価格「450円」が表示されている。抽選ボタンG302内には、割引価格「2250円」が表示されている。
割引情報G303は、抽選ボタンG301及びG302内に表示されている割引価格が、割引率10%が適用された価格であることを示している。割引情報G303及び連続日数情報G203の表示により、ユーザは、本日であれば、10%の割引価格で抽選処理を実行できるとのメリットを認識することができる。これにより、抽選処理を本日実行することに対するユーザの動機付けが向上する。
図9は、2日目においてステップS108で表示される抽選結果画面の一例である。図7に示す抽選結果画面G4は、図8において抽選ボタンG302に対するユーザ操作が受け付けられたことに応答して表示される。抽選結果画面G4は、当選情報G401と、報酬情報G402と、連続日数情報G403と、詳細ボタンG104とを含む。
当選情報G401は、5回抽選が実行された結果を表している。ここでは、5回抽選によりユーザに付与されたゲーム媒体が「ゲームアイテムA、P、B,C,M」であることが示されている。連続日数情報G403は、抽選処理を実行した連続日数が「2日」となったことを表している。報酬情報G402は、連続日数が2日となったことによる報酬を表している。ここでは、翌日である12月3日に抽選処理を実行させるために支払う必要がある対価が定価より20%割引になることが示されている。報酬情報G402の表示は、翌日ゲームにログインすることに対するユーザの動機付けを向上させる。
〔変形例1〕
本実施形態において、第1処理及び第2処理として、それぞれ、対価の支払いに基づくゲーム処理に加えて、仮想通貨の消費に基づくゲーム処理を適用するよう変形した変形例1について説明する。対価の支払いに基づくゲーム処理の一例は、仮想通貨購入処理である。また、仮想通貨の消費に基づくゲーム処理の一例は、抽選処理、コンテンツ引換処理である。なお、変形例1では、上述した抽選処理を実行させるために、対価の支払いの代わりに、仮想通貨の消費が必要であるものとする。また、コンテンツ引換処理とは、ゲームにおいて利用可能なコンテンツのうちユーザによって指定されたコンテンツを、仮想通貨の消費と引き換えにユーザに付与する処理であるとする。また、仮想通貨購入処理は、ユーザによって指定された数量の仮想通貨に対応する金額の課金処理により、当該数量の仮想通貨をユーザに付与する処理である。
変形例1では、第2条件は、仮想通貨の消費量の割引率が前記第1条件よりも高いとの条件を含む。換言すると、第2条件としての「割引率」は、対価の支払い額にも、仮想通貨の消費量にも適用される。
変形例1に係るゲームシステム1の動作は、図3に示したフローチャート及びその説明において、課金処理、価格等を、仮想通貨の消費処理、消費量等と必要に応じて適宜読み替え、ステップS102~S105における抽選処理を第1処理と読み替え、ステップS110~S113における抽選処理を第2処理と読み替えることにより、同様に説明される。
図10は、変形例1において、連続する複数日にそれぞれ実行されたゲーム処理に応じて適用された割引率の具体例を示す図である。ここでは、1回抽選には仮想通貨10個を、5回抽選には仮想通貨50個を、それぞれ消費する必要があるものとする。また、コンテンツAとの引換には仮想通貨20個を、コンテンツBとの引換には仮想通貨10個を、それぞれ消費する必要があるものとする。また、仮想通貨50個の購入には対価として900円を、仮想通貨500個の購入には対価として9000円を、それぞれ支払う必要があるものとする。
(1日目)
図10において、1日目に、割引率0%(割引無し)の仮想通貨10個が消費されることにより、1回抽選が実行されたことが示されている。これにより、第1処理を実行させた連続日数が「1日」となり、報酬として「翌日10%割引」が表示される。なお、割引の対象となるゲーム処理は、抽選処理、コンテンツ引換処理、仮想通貨購入処理の何れかである。
(2日目)
図10において、2日目に、割引率10%の仮想通貨18個が消費されることにより、コンテンツAとの引換が実行されたことが示されている。これにより、第1処理を実行させた連続日数は「2日」となり、報酬として「翌日20%割引」が表示される。
(3日目)
図10において、3日目に、割引率20%の割引価格である7200円の課金処理が実行されることにより、仮想通貨500個の購入処理が実行されたことが示されている。これにより、第1処理を実行させた連続日数は「3日」となり、報酬として「翌日30%割引」が表示される。
(4日目)
図10において、4日目に、割引率30%の仮想通貨7個が消費されることにより、コンテンツBとの引換が実行されたことが示されている。これにより、第1処理を実行させた連続日数は「4日」となり、報酬として「翌日40%割引」が表示される。
(5日目)
図10において、5日目に、割引率40%の仮想通貨30個が消費されることにより、5回抽選が実行されたことが示されている。これにより、第1処理を実行させた連続日数が「5日」となり、報酬として「翌日50%割引」が表示される。
このように、翌日(第2日)に、当日(第1日)より大きい割引率を適用して(第2条件で)実行させる第2処理は、当日(第1日)に実行された第1処理と必ずしも同一カテゴリのゲーム処理でなくてもよい。
図11は、変形例1において3日目に表示される仮想通貨購入画面の一例を示す図である。図11に示す仮想通貨購入画面G5は、購入ボタンG501及びG502と、割引情報G503と、チェックボックスG504と、連続日数情報G505と、詳細ボタンG104とを含む。
購入ボタンG501及びG502は、それぞれ、仮想通貨50個及び500個の購入を指示する操作を受け付けるUIオブジェクトの一例である。購入ボタンG501内には、割引価格「720円」が表示されている。購入ボタンG502内には、割引価格「7200円」が表示されている。
割引情報G503は、購入ボタンG501及びG502内に表示されている割引価格が、割引率20%が適用された価格であることを示している。連続日数情報G505は、対価の支払い又は仮想通貨の消費を実行した連続日数が「2日」となったことを表している。割引情報G503及び連続日数情報G505の表示により、ユーザは、本日であれば、20%の割引価格で仮想通貨を購入できるとのメリットを認識することができる。これにより、仮想通貨を本日購入することに対するユーザの動機付けが向上する。
また、割引情報G503は、本日の割引率20%は、第2処理である抽選処理、コンテンツ引換処理、仮想通貨購入処理の何れかに適用可能であることを示している。これにより、ユーザは、本日の割引率20%を、仮想通貨の購入において適用する代わりに、抽選処理又はコンテンツ引換処理において適用することも可能であることを認識できる。
チェックボックスG504は、仮想通貨購入において本日の割引率20%を適用するか否かをユーザに選択させるUIオブジェクトの一例である。この例では、チェックボックスG504がチェックされた状態であるため、購入ボタンG501及びG502内に表示される価格には、割引率20%が適用されている。チェックボックスG504がチェックされていない状態の場合、購入ボタンG501及びG502内に表示される価格は、定価となる。
このように、第2処理として複数のゲーム処理が適用されている場合、各第2処理を実行させる際に、割引率(第2条件)を適用するか否かがユーザ操作により選択可能となってもよい。なお、図11において、本日の割引率を適用した第2処理の当日の実行回数が所定回数に到達している場合は、割引情報G503及びチェックボックスG504は表示されなくてよい。また、購入ボタンG501及びG502内に表示される価格は、定価となる。
変形例1は、翌日の割引を報酬としてユーザに獲得させる手段を多様化することができる。また、翌日の割引を適用可能なゲーム処理の種類(カテゴリ)が多様化するため、翌日にゲームにログインすることに対するユーザの動機付けがさらに向上する。
〔変形例2〕
変形例1をさらに変形した変形例2について説明する。変形例2では、第1処理として、仮想通貨の消費に基づくゲーム処理(抽選処理及びコンテンツ引換処理)を適用し、対価の支払いに基づくゲーム処理(仮想通貨購入処理)を適用しない。
変形例2に係るゲームシステム1の動作は、変形例1に係るゲームシステム1の動作に対して、図3のステップS113後の動作の詳細が異なる。変形例2に係るゲームシステム1は、ステップS113で実行した第2処理が仮想通貨の消費に基づくゲーム処理である場合には、ステップS106からの処理を実行する。仮想通貨の消費に基づくゲーム処理でない場合には、ステップS101からの処理を実行する。
図12は、変形例2において、連続する複数日にそれぞれ実行されたゲーム処理に応じて適用された割引率の具体例を示す図である。図12は、図10に対して、3日目の報酬と、4日目及び5日の適用割引率等が異なる。
(3日目)
図12において、3日目に、割引率20%の割引価格である7200円の課金処理が実行されることにより、通貨500個の購入処理が実行されたことが示されている。ここで、仮想通貨購入処理は、第2処理の1つであるため、3日目の割引率20%が適用されている。一方、仮想通貨購入処理は、第1処理ではないため、3日目は、第1処理を実行した第1日として特定されない。また、連続日数は初期値にリセットされる。このため、報酬としての翌日割引は無しとなっている。
(4日目)
図12において、4日目では、3日目の報酬が無かったため割引率0%が適用される。すなわち、定価の仮想通貨10個が消費されることにより、コンテンツBとの引換が実行されたことが示されている。これにより、第1処理を実行させた連続日数は「1日」となり、報酬として「翌日10%割引」が表示される。
(5日目)
図12において、5日目に、割引率10%の通貨40個が消費されることにより、5回抽選が実行されたことが示されている。これにより、第1処理を実行させた連続日数が「2日」となり、報酬として「翌日20%割引」が表示される。
このように、変形例2では、変形例1における1日目~5日目と同様のゲーム処理が実行された場合であっても、4日目及び5日目に適用される割引率及び報酬が異なる。変形例2において、3日目に、仮想通貨を購入するだけでなく、購入した仮想通貨を消費するゲーム処理が実行されれば、4日目及び5日目に適用される割引率は、変形例1と同様となる。その結果、変形例2は、ユーザに対して、連日、仮想通貨を消費するよう促すことができる。
〔その他の変形例〕
本実施形態において、第2条件として、抽選処理において特定のゲーム媒体が選択される確率(ここでは、抽選確率)が第1条件よりも高い条件を適用してもよい。この場合、抽選処理を実行させるために必要となる支払い金額または仮想通貨の消費量は、第2条件が適用された場合と第1条件が適用された場合とで同一であるものとする。例えば、ゲーム媒体Aの抽選確率が1%(第1条件)で抽選処理(第1処理)が実行された第1日の翌日である第2日には、ゲーム媒体Aの抽選確率が5%(第2条件)で抽選処理(第2処理)が実行可能であってもよい。また、この場合、連続日数が多いほど高い抽選確率が定められていてもよい。
また、本実施形態において、第2条件として、抽選処理においてユーザに付与されるゲーム媒体が第1条件よりも多い条件を適用してもよい。この場合、抽選処理を実行させるために必要となる支払い金額または仮想通貨の消費量は、第2条件が適用された場合と第1条件が適用された場合とで同一であるものとする。例えば、5000円の支払いにより5回抽選が実行された第1日の翌日である第2日には、同じ5000円の支払いにより6回抽選が実行可能であってもよい。
また、本実施形態において、第2条件は、第1日に第2処理が実行された場合に適用されたであろう条件よりもユーザにとってより良い条件であってもよい。例えば、第2処理が抽選処理であり、第1処理が仮想通貨購入処理であるとする。この場合、第2条件は、第1日に抽選処理が行われた場合に適用されたであろう特定のゲーム媒体の抽選確率よりも高い抽選確率を適用するとの条件であってもよい。また、この場合、第2条件は、「当該第2条件(第2日の抽選確率)で第2処理(抽選処理)が実行されること」が、「第1条件(第1日の割引率)で第1処理(仮想通貨購入処理)が実行されること」よりも、ユーザにとってより満足度が高くなるような条件であるとも言える。
また、本実施形態において、第1処理が実行されたことに応答して、当該第1処理が実行された日を第1日として第2日に第2条件で第2処理を実行可能とする権利を表す情報を、ユーザに付与してもよい。例えば、当該権利を表す情報の一例として、翌日割引チケット等の形態があげられる。この場合、図3のステップS108又はS109において、当該ステップの処理に加えて、翌日割引チケットがユーザに付与されてもよい。また、図3のステップS112において、当該ステップの処理に加えて、割引チケットが消費されてもよい。これにより、ユーザは、第2日において第2処理に第2条件が適用される権利を保有していることを、容易に認識することができる。
また、本実施形態において、第2日において実行される全ての第2処理について、第2条件を適用可能としてもよい。これにより、第2日にゲームにログインすることに対するユーザの動機付けがさらに向上する。
また、本実施形態において、第2条件で第2処理を実行させるための第2操作は、必ずしも第2日に受け付けられなくてもよい。例えば、第1日が特定された後、当該第1日のうちに、翌日の第2日に第2条件で第2処理を実行させることを予約する操作が、第2操作として受け付けられてもよい。この場合、予約した第2処理を第2条件で実行するために、第2日にゲームにログインすることに対するユーザの動機付けが向上する。
また、本実施形態において、第2日は、第1日の翌日以降であれば、翌日でなくてもよい。例えば、第2日は、第1日の2日後であってもよい。この場合、1日おきにゲームにログインすることに対するユーザの動機付けが向上する。
また、本実施形態において、第2処理を実行する際に第2条件を適用可能であるか否かの判断処理は、第1処理が第1条件で実行されたタイミングからの経過時間に基づいて行われてもよい。この場合、例えば、ステップS106において、記憶部120に記憶される特定のタイミングを表す情報には、第1日を表す情報の代わりに、当該タイミングの時刻を表す情報が含まれることとしてもよい。つまり、この場合、第1日を特定する処理は不要である。また、ステップS101における判断処理は、特定のタイミングを表す情報が示す時刻からの経過時間が所定の長さを超えたか否かに基づいて実行可能である。また、第1処理が第1条件で実行されたことに応答して経過時間の計時を開始することにより、記憶部120に、当該タイミングからの経過時間が随時カウントされることとしてもよい。これにより、必ずしも当該タイミングを表す時刻の情報を保持せずとも、カウントされていく経過時間が所定の長さを超えたか否かに基づいて、ステップS101における判断処理を実行することができる。所定の長さとは、例えば、24時間であってもよいし、24時間以外の長さであってもよい。また、この場合、ステップS114において、特定のタイミングの翌日開始以降の所定時点が終了(第2日が終了)したか否かの判断処理は、当該タイミングの時刻からの経過時間が所定の長さの2倍を超えたか否かに基づいて実行可能である。
〔ソフトウェアによる実現例〕
制御部210の制御ブロック(特に、進行支援部211、販売処理部212、及び抽選支援部213)、ならびに、制御部110の制御ブロック(特に、ゲーム進行部111、購入処理部112、抽選部113、及び割引管理部114)は、集積回路(ICチップ)等に形成された論理回路(ハードウェア)によって実現してもよいし、CPU(Central Processing Unit)を用いてソフトウェアによって実現してもよい。
後者の場合、制御部210または制御部110、もしくはその両方を備えた情報処理装置は、各機能を実現するソフトウェアであるプログラムの命令を実行するCPU、上記プログラムおよび各種データがコンピュータ(またはCPU)で読み取り可能に記録されたROM(Read Only Memory)または記憶装置(これらを「記録媒体」と称する)、上記プログラムを展開するRAM(Random Access Memory)などを備えている。そして、コンピュータ(またはCPU)が上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記記録媒体としては、「一時的でない有形の媒体」、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムは、該プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して上記コンピュータに供給されてもよい。なお、本発明の一態様は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
〔付記事項〕
本発明の一側面に係る内容を列記すると以下のとおりである。
(項目1) プロセッサ(10、20)及びメモリ(11、21)を備えるコンピュータ(ユーザ端末100及びサーバ200の少なくとも何れか一方)により実行されるゲームプログラム(131)について説明した。本開示のある局面によると、ゲームプログラムは、プロセッサに、ユーザによる対価の支払いまたは支払いにより得られるゲームアイテムの消費に基づく第1処理を実行するための第1操作をユーザから受け付ける第1ステップと、第1操作に応答して、第1処理を第1条件で実行する第2ステップと、第1条件で第1処理が実行されたタイミングを特定する第3ステップと、第1条件で第1処理が実行されたことに応答して、対価の支払いまたは支払いにより得られるゲームアイテムの消費に基づく第2処理を、第1条件よりもユーザにとって有利な第2条件で実行するための第2操作を、前記タイミングの翌日以降にユーザから受け付ける第4ステップと、第2操作に応答して、第2処理を第2条件で実行する第5ステップと、を実行させる。上記の構成によれば、第1条件で第1処理が実行されたタイミングの翌日以降にゲームにログインすることに対するユーザの動機付けが向上する。
(項目2) (項目1)において、第3ステップは、上述したタイミングを含む日を第1日として特定し、第4ステップは、現在の時が第1日の時刻の範囲に含まれる場合は第2操作を受け付けず、現在の時が第1日の時刻の範囲以降である場合に、第2操作を受け付けてもよい。これにより、第1日の翌日以降にゲームにログインすることに対するユーザの動機付けが向上する。
(項目3) (項目1)又は(項目2)において、ゲームプログラムは、プロセッサに、5ステップが実行されたことに応答して、第3ステップから第5ステップまでの各ステップを再度実行させ、再度実行される第3ステップにおいて、第2条件及び第2処理を新たな第1条件及び新たな第1処理とみなして新たなタイミングを特定し、再度実行される第4ステップにおいて、新たな第1条件よりもユーザにとって有利な新たな第2条件で新たな第2処理を実行するための第2操作を、新たなタイミングの翌日以降に受け付け、再度実行される第5ステップにおいて、新たな第2処理を新たな第2条件で実行してもよい。これにより、翌日以降にゲームにログインする度に、さらにその翌日以降にゲームにログインすることに対するユーザの動機付けが向上する。
(項目4) (項目3)において、再度実行される第4ステップにおいて、新たな第1条件が所定条件である場合に、新たな第2処理を第1条件で実行するための第3操作を前記新たなタイミングの翌日以降に受け付け、再度実行される第5ステップにおいて、第3操作に応答して、新たな第2処理を第1条件で実行してもよい。これにより、第2条件が有利になり過ぎることがなく、ゲームの興趣性が維持される。
(項目5) (項目1)から(項目4)の何れか1項目において、ゲームプログラムは、プロセッサに、 第1ステップから第3ステップまでの各ステップの実行後、前記タイミングの翌日開始以降の所定時点までに第2操作が受け付けられなかった場合に、第4ステップ及び第5ステップを実行させる代わりに、翌日以降において、第1ステップから第5ステップまでの各ステップを実行させてもよい。これにより、翌日以降におけるゲームのログインを繰り返すことに対するユーザの動機付けが向上する。
(項目6) (項目1)から(項目5)の何れか1項目において、第1ステップから第4ステップまでの各ステップにおいて、第1処理として、ゲームアイテムの消費に基づく処理を適用してもよい。これにより、継続してゲームアイテムを消費することに対するユーザの動機付けが向上する。
(項目7) (項目1)から(項目6)の何れか1項目において、第4ステップ及び第5ステップにおいて、第2処理として、第1処理と同一のカテゴリの処理を適用してもよい。これにより、継続して同一カテゴリの処理を実行させることに対するユーザの動機付けが向上する。
(項目8) (項目1)から(項目7)の何れか1項目において、第4ステップ及び第5ステップにおいて、第2条件として、ゲームアイテムの消費量の割引率が第1条件よりも高い条件を適用してもよい。これにより、継続してゲームアイテムを消費することに対するユーザの動機付けが向上する。
(項目9) (項目1)から(項目7)の何れか1項目において、第4ステップ及び第5ステップにおいて、第2条件として、対価の支払い額の割引率が第1条件よりも高い条件を適用してもよい。これにより、継続して対価を支払うことに対するユーザの動機付けが向上する。
(項目10) (項目1)から(項目9)の何れか1項目において、第4ステップ及び第5ステップにおいて、第2処理が、複数のゲーム媒体の中から少なくとも1つのゲーム媒体を選択してユーザに付与する処理である場合、第2条件として、特定のゲーム媒体が選択される確率が第1条件よりも高い条件を適用してもよい。これにより、継続して抽選処理を実行したユーザは、特定のゲーム媒体が付与される期待値が大きくなるというメリットを享受することができる。
(項目11) (項目1)から(項目10)の何れか1項目において、第4ステップ及び第5ステップにおいて、第2処理が、複数のゲーム媒体の中から少なくとも1つのゲーム媒体を選択してユーザに付与する処理である場合、第2条件として、ユーザに付与されるゲーム媒体が第1条件よりも多い条件を適用してもよい。これにより、継続して抽選処理を実行したユーザは、特定のゲーム媒体が付与される数が多くなるというメリットを享受することができる。
(項目12) (項目1)から(項目11)の何れか1項目において、第4ステップにおいて、第2操作を、上述したタイミングの翌日に受け付けてもよい。これにより、連日ゲームにログインすることに対するユーザの動機付けが向上する。
(項目13) ゲームプログラムを実行する方法を説明した。本開示のある局面によると、ゲームプログラムは、プロセッサおよびメモリを備えるコンピュータにより実行される。該方法は、プロセッサが(項目1)に記載のゲームプログラムにおける各ステップを実行する方法である。(項目13)に係る方法は、(項目1)に係るゲームプログラムと同様の作用効果を奏する。
(項目14) 情報処理装置を説明した。本開示のある局面によると、該情報処理装置は、(項目1)に係るゲームプログラムを記憶する記憶部(120)と、該ゲームプログラムを実行することにより、情報処理装置(ユーザ端末100)の動作を制御する制御部(110)とを備える。(項目14)に係る情報処理装置は、(項目1)に係るゲームプログラムと同様の作用効果を奏する。