〔実施形態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とは異なる入力装置(図示せず)から出力される信号をユーザの入力操作として特定し、受け付ける。
<各装置のハードウェア構成要素>
プロセッサ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がゲームプログラムに基づいて実行するゲーム(以下、本ゲーム)は、一例として、育成シミュレーションゲームである。該育成シミュレーションゲームは、一例として、アイドルを目指しているキャラクタを育成するアイドル育成シミュレーションゲームである。本ゲームでは、上述のキャラクタは、例えば、架空の世界でアイドルを目指して学校生活を送る男子高校生である。
ゲームシステム1は、特定のジャンルに限らず、あらゆるジャンルのゲームを実行するためのシステムであってもよい。例えば、テニス、卓球、ドッジボール、野球、サッカーおよびホッケーなどのスポーツを題材としたゲーム、パズルゲーム、クイズゲーム、RPG、アドベンチャーゲーム、シューティングゲーム、シミュレーションゲーム、育成ゲーム、ならびに、アクションゲームなどであってもよい。
また、ゲームシステム1は、特定のプレイ形態に限らず、あらゆるプレイ形態のゲームを実行するためのシステムであってもよい。例えば、単一のユーザによるシングルプレイゲーム、および、複数のユーザによるマルチプレイゲーム、また、マルチプレイゲームの中でも、複数のユーザが対戦する対戦ゲーム、および、複数のユーザが協力する協力プレイゲームなどであってもよい。
本ゲームは一例として、デッキ編成要素を含んでいてもよい。すなわち、ゲームシステム1は、ゲーム上で利用可能な、デジタルデータとしてのゲーム媒体をユーザに保有させ、これらのゲーム媒体の集合(以下、デッキ)を構成し、該デッキに基づいてゲームを進行させる。
本ゲームでは、ゲーム媒体は、ゲームにおいて、ユーザの操作にしたがって何らかの動作を主体的に行うことにより、ゲームの進行内容に影響を与える。ゲーム媒体は、一例として、デッキを構成する最小単位としてのカードという表現形態でユーザに提供される。
本ゲームでは、一例として、それぞれのカードには、該カードを分類するグループ識別子として、本ゲームに登場する複数のキャラクタのうちの1つが紐付けられている。キャラクタは、本ゲームを構成する少なくともいずれかのプレイパートにおいて、上述の動作を行う主体として表現される。本ゲームでは、カードおよびキャラクタには各種のパラメータが設定されている。ユーザは、ゲームをプレイすることを経てこれらのパラメータを強化することができる。すなわち、本ゲームは、カードまたはキャラクタを育成する育成要素を含むゲームであってもよい。
本ゲームを実行するためのゲームプログラムは、サーバ200からユーザ端末100へ基本的に無料で提供される。本ゲーム内のサービスの一部は、有料で提供される。一例として、本ゲームは、いわゆる、アイテム課金制のゲームである。
本実施形態では、一例として、本ゲーム内で利用可能なゲーム媒体の一部が、有料で提供される。本実施形態では、一例として、有料で提供されるゲーム媒体を、有償アイテムと称する。有償アイテムは、例えば、本ゲーム内でダイヤを模して表現される。本ゲームにおいて、ダイヤは、一例として、ユーザに所有させるゲーム媒体としてのカードを所定の規則に基づいて選択する処理、いわゆる「抽選」をゲームシステム1に実行させるために消費されるものである。
本実施形態では、ダイヤは、ユーザがダイヤを購入するための支払いを実施したことに伴って該ユーザに付与される。また、ダイヤは、ユーザが支払いを実施する代わりに、本ゲームをプレイして、本ゲームの進行状況を予め定められた条件に合致するように進めた場合に、プレイ報酬として該ユーザに配布されてもよい。
ゲームシステム1において、ユーザの購入行動に伴って付与されたダイヤと、ユーザの購入行動に代えて、ユーザのプレイ内容に応じて配布されたダイヤとは、区別して管理されてもよいし、区別せずにトータル個数のみが管理されてもよい。以下では、前者のダイヤを、購入ダイヤ(第1の有償アイテム)と称し、後者のダイヤを、配布ダイヤ(第2の有償アイテム)と称して必要に応じて区別する。本実施形態では、一例として、ゲームシステム1は、購入行動に伴って付与された購入ダイヤと、購入行動に代えて、プレイ報酬として配布された配布ダイヤとを区別してそれぞれ個数を管理するものとする。
<ゲームサイクル>
図2は、本ゲームのゲームサイクルの一例を説明する図である。本ゲームは、複数のプレイパートで構成される。本ゲームは、育成シミュレーションゲームであって、一例として、ストーリーパート(第2パート)、練習パート(第2パート)、実践パート(第2パート)、抽選パート、能力管理パート、および、放置パート(第1パート)の6つのプレイパートを含む。
ストーリーパートは、ユーザが、キャラクタにまつわる物語を読み進めて、ゲームを進行させるパートであり、本ゲームにおけるユーザの主たる目的となるパートである。物語は、ユーザ端末100において、静止画および動画を含む映像、音声、および、テキストなどの少なくともいずれかを含むストーリーデータとしてユーザに対して提供される。
本実施形態では、一例として、ストーリーデータは、共通ストーリーまたは個別ストーリーのいずれかの内容を含むストーリーデータとして提供される。共通ストーリーは、本ゲームの主軸の物語として展開され、本ゲームで用意されたさまざまなキャラクタが登場する、本ゲームのメインストーリーともいうべきものである。共通ストーリーは、分岐もなくすべてのユーザが一本道で読み進めるものとする。個別ストーリーは、共通ストーリーに登場する個々のキャラクタにまつわるサイドストーリー、例えば、外伝またはスピンオフ作品として展開されるものである。個別ストーリーは、ユーザのプレイ状況に応じて、分岐があったり、読み進める順番が異なったりしてもよい。
こうして、ユーザは、映像、音声および、テキストを介して、共通ストーリーを読み進めるとともに、お気に入りのキャラクタについての個別ストーリーを楽しむことができる。個別ストーリーは、1人のキャラクタに焦点を当てた物語であってもよいし、特定の複数人のキャラクタおよびそれらのキャラクタの関係性に焦点を当てた物語であってもよい。
本実施形態では、物語を読むための条件が設定されており、ユーザは、ロックされた物語を解放すべく、その条件を満たすように、以下のプレイパートをプレイする。本ゲームのゲームとしての遊戯性は、例えば、ユーザが、物語を解放するために、以下のプレイパートをいかに有利にプレイするかという点に見出される。一方、ユーザが特段のプレイ条件を満たさずとも、時間が来たら、あるいは、サーバ200から供給されたら、自動的に解放される物語があってもよい。
ユーザがストーリーパートをプレイすると、ユーザは、該パートをプレイしたことに基づいて、以後のゲーム進行、とりわけ、練習パートおよび実践パートを有利に進めるための何らかの成果を得る。成果は、一例として、練習パートおよび実践パートでプレイできるクエストの解放である。以下では、クエストを、本育成シミュレーションゲームの文脈に即して、キャラクタ達がアイドルとしてのパフォーマンスを披露する「ステージ」と称する。他の成果として、配布ダイヤ、抽選ポイント、または、抽選チケットがユーザに付与されてもよい。例えば、ユーザが、1つの物語に対応する1つのストーリーデータを読了すると、読了報酬として、所定個の配布ダイヤが該ユーザに付与されてもよい。これにより、ユーザは、解放したストーリーデータを次々に読了し、配布ダイヤを貯めて、後述する抽選パートに興じることができる。
練習パートは、カードおよびそのカードに対応するキャラクタを育成するパートである。一例として、練習パートでは、カードが編成されたデッキを用いてステージを進行させる。ユーザがプレイしたいステージを選択して該ステージを最後まで進行させると、ユーザは、該ステージをクリアしたと判定される。ユーザは、ステージをクリアしたことに基づいて、以後のゲーム進行、とりわけ、実践パートを有利に進めるための何らかの成果を得る。成果は、一例として、報酬獲得、カードまたはキャラクタのパラメータ強化、ユーザのステータス向上、および、キャラクタの個別ストーリーの解放などである。報酬は、例えば、各パートで利用可能なカード、および、カードまたはキャラクタを強化するための強化アイテムなどである。練習パートを繰り返しプレイすることにより育成されたカードおよびキャラクタは、例えば、以下の実践パートにおいて、より有利に動作する。
実践パートは、育成したカードが編成されたデッキを用いて、ステージにおいて課された課題をクリアするパートである。ユーザがプレイしたいステージを選択して該ステージをクリアすると、ユーザは、該ステージをクリアしたことに伴う成果を得ることができる。成果は、例えば、クリア報酬、および、共通ストーリーの解放である。クリア報酬は、例えば、カード、および、強化アイテムなどである。他の成果として、例えば、カードまたはキャラクタのパラメータ強化、および、ユーザのステータス向上などの成果がユーザに与えられてもよい。
本実施形態では、実践パートは、一例として、ユーザによって保有される1以上のカード(ゲーム媒体)を、対戦相手のカードと対戦させるパートであってもよい。対戦相手は、他のユーザであってもよいし、ゲームプログラムにしたがって動作するコンピュータ(COM)であってもよい。また、対戦で使用する1以上のカードは、デッキに組み入れることによって対戦で使用可能であってもよい。デッキは、練習パートで編成されるデッキと異なる構成を有していてもよいし、同じ構成を有していてもよい。本実施形態では、一例として、実践パートは、ユーザが編成したデッキの各キャラクタと、ゲームプログラム131に基づいてコンピュータが編成したデッキの各キャラクタとが、アイドルとしてのパフォーマンスの高さを競う対戦(COM戦)を含む。本実施形態では、COM戦の結果が、勝利、引き分け、または、敗北のいずれであるのかに応じてクリア判定がなされ、ユーザに与えられる成果が決定される。一例として、対戦は、該対戦で使用されるユーザのカードのパラメータが、例えば先の練習パートなどにおいて強化されていればいるほど、ユーザ側が勝利しやすいように進行してもよい。
抽選パートは、本ゲームで利用できるデジタルデータとしてのゲーム媒体を、ゲーム内価値と引き換えに、ユーザに獲得させるパートである。本実施形態では、一例として、抽選パートの進行中に、ゲームシステム1において抽選が実行される。具体的には、サーバ200は、ユーザに所有させるゲーム媒体を、複数のゲーム媒体で構成される母集団の中から所定の規則に基づいて選択することにより抽選を実行する。抽選の実行と引き換えられるゲーム内価値は、例えば、ユーザが課金により入手した仮想通貨などの有価媒体であってもよいし、プレイ報酬として無償で提供されるポイントまたは消費アイテムなどであってもよい。本実施形態では、一例として、抽選パートにおいて抽選が実行されると、当選したカードがユーザによって保有される。当選したカードは、練習パートおよび実践パートなどで利用することが可能となる。
抽選を実行するために消費される有価媒体とは、本実施形態において上述の有償アイテムのことであり、より具体的には、上述のダイヤのことを指す。また、本実施形態では、抽選を実行するために消費される消費アイテムは、一例として、抽選チケットの形態で表現される。本ゲームでは一例として、ユーザは、所定個のダイヤと引き換えるか、または、抽選チケットを所定枚数消費することにより、抽選をゲームシステム1において実行させることができる。
なお、本実施形態では、一例として、抽選に関して、購入ダイヤと配布ダイヤとは等価なものとして取り扱われる。したがって、購入ダイヤであっても配布ダイヤであっても抽選に必要な個数は同じであり、いずれのダイヤが消費されても、抽選は同様に実行される。すなわち、同じ母集団から同じ規則にしたがって、ユーザに付与するカードの選択が行われる。
また、本実施形態では、一例として、抽選チケット1枚で、1枚のカードが当選する抽選が1回実行される。さらに、本実施形態では、抽選チケットと交換可能な抽選ポイントがユーザに付与され得る。例えば、本ゲームにおいて、ユーザに付与される抽選ポイント100ptにつき、1枚の抽選チケットと交換が可能であるとする。抽選ポイントは、ログインボーナス、および、プレイ報酬などとして、ユーザに配布される。
以上のとおり、本ゲームにおいて、ユーザは、ゲームシステム1に抽選を実行させるための手段として以下の3つを有する。(1)ダイヤを購入し、入手した購入ダイヤと引き換えに抽選を実施する。(2)所定条件が満たされるようにゲームをプレイし、入手した配布ダイヤと引き換えに抽選を実施する。(3)所定条件が満たされるようにゲームをプレイして抽選ポイントを貯め、抽選ポイントと交換で手に入れた抽選チケットを消費して抽選を実施する。
ここで、「(ゲーム媒体などを)ユーザに獲得させる/保有させる/付与する」とは、一例として、ユーザに対応付けて管理されているゲーム媒体などのデジタルデータの状態を、使用不可から使用可能に遷移させることであってもよい。あるいは、デジタルデータを、ユーザ識別情報またはユーザ端末IDなどに対応付けて、ゲームシステム1に含まれるメモリ11およびメモリ21のうちの少なくともいずれかのメモリに記憶させることであってもよい。
能力管理パートは、上述の各パートで獲得された強化アイテムを消費して、カードまたはキャラクタの能力を解放したり、強化したりするパートである。ユーザは、本パートにおいてカードまたはキャラクタの能力を解放したり、強化したりすることにより、練習パートおよび実践パートをより有利に進めることが可能となる。
放置パートは、いわゆる、放置ゲームの要素を含むパートである。具体的には、ユーザが放置パートの実行を指示した後、自動的にゲームが進行し、所定期間が経過すると、その自動進行の結果がユーザに知らされる。本実施形態では、一例として、ユーザ端末100は、放置パートにおいて、実行パートと称するサブパートと、閲覧パートと称するサブパートとを実行する。実行パートにおいて、ユーザ端末100は、本ゲームに登場する複数のキャラクタのうちの少なくとも1つのキャラクタを、ユーザの第1入力操作に応じて、第1状態から第2状態へ遷移させ、該キャラクタが第2状態に遷移してから、所定の時間が経過したことに応じて、該キャラクタを第1状態に復帰させ、該キャラクタが第1状態に復帰したことに応じて、第2状態であったキャラクタに基づくコンテンツを報酬としてユーザに付与する。閲覧パートにおいて、ユーザ端末100は、ユーザに付与されたコンテンツのうち表示すべきコンテンツを指定するための第2入力操作を、ユーザから受け付け、第2入力操作を受け付けたことに応答して、指定されたコンテンツを表示部152に表示する。これにより、ユーザは、ストーリーパートで読了する物語とは別に、放置パートをプレイすることにより入手した、キャラクタに基づくコンテンツを閲覧して、キャラクタへの愛着をより一層高めながら、本ゲームを楽しむことができる。
さらに、ユーザ端末100は、実行パートにおいて、コンテンツの他にも、強化アイテム、または、抽選チケットなどを、報酬としてユーザに付与してもよい。これにより、放置パートのプレイをユーザに一層動機付けることができる。
なお、本ゲームは、ミニスケープゲーム、いわゆる、箱庭ゲームの要素を含んでいてもよい。例えば、本ゲームは、上述の5つのプレイパートの他にも、箱庭パートを含んでいてもよい。箱庭パートでは、ユーザは、上述の各パートをプレイすることにより入手したアイテム、および、カードなどの各種ゲーム媒体をマップに配置し、該マップの世界を俯瞰して楽しむことができる。また、箱庭パートのプレイ成果が、上述の他のパートにおいて有利に作用するように、該成果が設定されてもよい。
<ゲームシステム1の機能的構成>
図3は、ゲームシステム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として機能する。制御部210は、実行するゲームの性質に応じて、ユーザ端末100におけるゲームの進行を支援するために、図示しないその他の機能ブロックとしても機能することができる。
進行支援部211は、ユーザ端末100と通信し、ユーザ端末100が、本ゲームに含まれる各種のプレイパートを進行させるための支援を行う。例えば、上述の各プレイパートのいずれが実行されているのかに応じて、そのときにユーザ端末100が参照すべき情報を適宜提供する。
(ユーザ端末100の機能的構成)
制御部110は、記憶部120に格納されたゲームプログラム131を実行することにより、ユーザ端末100を統括的に制御する。例えば、制御部110は、ゲームプログラム131およびユーザの操作にしたがって、ゲームを進行させる。また、制御部110は、ゲームを進行させている間、必要に応じて、サーバ200と通信して、情報の送受信を行う。
制御部110は、ゲームプログラム131の記述に応じて、ストーリーパート進行部111、練習パート進行部112、実践パート進行部113、抽選パート進行部114、および、放置パート進行部115として機能する。
なお、制御部110は、実行するゲームの性質に応じて、ゲームを進行させるために、図示しないその他の機能ブロックとしても機能することができる。例えば、制御部110は、上述の能力管理パートを進行させる能力管理部、および、上述の箱庭パートを進行させる箱庭パート進行部として機能してもよい。
さらに、制御部110は、図示しない操作受付部、および、表示制御部などとしても機能する。操作受付部は、入力部151に対するユーザの入力操作を検知し受け付ける。例えば、操作受付部は、上述の入力操作の、入力部151における入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部は、例えば、タッチ操作、スライド操作、スワイプ操作、およびタップ操作等を特定する。表示制御部は、タッチスクリーン15の表示部152に対して、制御部110の各部によって実行された処理結果が反映されたゲーム画面を出力する。表示制御部は、制御部110の各部によって生成された映像を含むゲーム画面を表示部152に表示してもよい。また、表示制御部は、グラフィカルユーザインターフェース(以下、GUI)を、該ゲーム画面に重畳して描画してもよい。
ストーリーパート進行部111は、上述のストーリーパートを進行させる。ストーリーパート進行部111は、物語に対応するストーリーデータを再生する。ストーリーデータは、ユーザに物語を提示するために、動画、静止画、テキスト、および、音声などの各種のデータを少なくとも1以上含むデータである。ストーリーパート進行部111は、各物語の状態、例えば、解放済みか、未解放であるかを管理する。
練習パート進行部112は、上述の練習パートを進行させる。練習パート進行部112は、クエスト、本実施形態ではステージ、の進行に用いるデッキを編成し、ステージを進行させる。ユーザが、ステージを最後までプレイした場合には、練習パート進行部112は、ステージ完遂に伴う成果を決定し、該成果をゲーム情報132に反映させる。
実践パート進行部113は、上述の実践パートを進行させる。実践パート進行部113は、ステージ、本実施形態ではCOM戦、に用いるデッキを編成し、COM戦を進行させる。実践パート進行部113は、COM戦の結果に応じて成果を決定し、該成果をゲーム情報132に反映させる。
抽選パート進行部114は、上述の抽選パートを進行させる。抽選パート進行部114は、抽選の実行を指示するユーザの入力操作にしたがって、抽選実行要求をサーバ200に送信する。サーバ200によって、当選したカードが決定されると、抽選パート進行部114は、当選したカードについての通知をサーバ200から受信し、当選した該カードをユーザに保有させる。
放置パート進行部115は、上述の放置パートを進行させる。具体的には、放置パート進行部115は、ユーザによって選択されたキャラクタを第1状態から第2状態へ遷移させ、第2状態に遷移してから所定の時間が経過した後、該キャラクタに基づくコンテンツを、放置パートのプレイ報酬としてユーザに付与する。
ユーザの操作によらずに実行パートが進行している間にキャラクタが陥っている第2状態は、ユーザに対しては、例えば、キャラクタが寝ている睡眠状態という体裁で表現されてもよい。この場合、実行パートが進行していない間のキャラクタの第1状態は、例えば、覚醒状態という体裁で表現されてもよい。
本実施形態では、一例として、放置パート進行部115は、キャラクタが第2状態へ遷移してから、ユーザにコンテンツが付与されるまでの間の任意のタイミングで、該キャラクタに基づくコンテンツを生成する。
本実施形態では、コンテンツは、第2状態に遷移したキャラクタが、該第2状態であった間に体験した出来事という体裁で、該出来事を表現したデジタルデータである。具体的には、睡眠状態に遷移したキャラクタが、寝ている間に見た夢の内容を日記形式で報告するという体裁で、該夢の内容を表現したデジタルデータである。
コンテンツは、例えば、動画データ、静止画データ、音声データ、テキストデータの少なくとも1つを含むように構成されたものである。放置パート進行部115は、閲覧パートにおいて、ユーザに付与されたコンテンツを再生し、表示部152および図示しないスピーカに出力することにより、コンテンツをユーザに閲覧させる。
本実施形態では、一例として、コンテンツは、睡眠状態に遷移したキャラクタが、睡眠中に見た夢の内容について日記形式で記したという体裁で生成される「日記データ」である。日記データの生成方法およびそのデータ構造については後に詳述する。
なお、図2に示すサーバ200およびユーザ端末100の機能は一例にすぎない。サーバ200は、ユーザ端末100が備える機能の少なくとも一部を備えていてもよい。また、ユーザ端末100は、サーバ200が備える機能の少なくとも一部を備えていてもよい。さらに、ユーザ端末100およびサーバ200以外の他の装置をゲームシステム1の構成要素とし、該他の装置にゲームシステム1における処理の一部を実行させてもよい。すなわち、本実施形態においてゲームプログラムを実行するコンピュータは、ユーザ端末100、サーバ200、および他の装置の何れであってもよいし、これらの複数の装置の組み合わせにより実現されてもよい。
<発明概要>
本実施形態では、ユーザ端末100は、ゲームプログラム131を記憶するメモリ11と、ゲームプログラム131を実行することにより、ユーザ端末100の動作を制御するプロセッサ10と、表示部152とを備えている。ユーザ端末100のプロセッサ10は、ゲームの興趣性を向上させるために、ゲームプログラム131に基づいて、以下のステップを実行するように構成されている。すなわち、プロセッサ10は、ゲームプログラム131に基づくゲームに登場する複数のキャラクタのうちの少なくとも1つの第1キャラクタに対する、ユーザの第1入力操作に応じて、該第1キャラクタを第1状態から第2状態へ遷移させるステップ(S107)と、第1キャラクタが第2状態に遷移してから、所定の時間が経過したことに応じて、第1キャラクタを第1状態に復帰させるステップ(S119)と、第1キャラクタが第1状態に復帰したことに応じて、上述の第2状態であった第1キャラクタに基づくコンテンツ(日記データ)をユーザに付与するステップ(S120)と、ユーザの第2入力操作に応じて、指定されたコンテンツを表示部に表示するステップ(S204)と、を実行する。
プロセッサ10は、ゲームプログラム131に基づいて、付与するステップS120の後、表示するステップS204の前に、ユーザに付与された1または複数のコンテンツのうち表示すべきコンテンツを指定するための第2入力操作を、ユーザから受け付けるステップ(S203)を実行してもよい。
<データ構造>
(カード)
図4は、カードのデータ構造の一例を示す図である。図4は、カード1枚に相当するデータのデータ構造を示す。図4に示すデータ構造を有するカードは、ゲーム情報132として、ユーザが保有するカードの枚数分、記憶部120に記憶されている。このカードの集合体によりカードデータベース(DB)が構築される。カードDBは、ユーザが保有するカードを一元管理するためのデータベースである。カードDBでは、図4に示すデータ構造を有するカードは、1つのレコードとして取り扱われる。
カードは、一例として、カードID、キャラクタ名、希少度、属性、カードレベル、魅力、練習スキル、メインスキル、サブスキル、および、セリフ管理情報の各項目を含む。
カードIDの項目には、カードIDが格納されている。カードIDは、ユーザが保有するカードをゲームシステム1上で一意に管理するために、カードに固有に割り当てられた識別情報のことである。本実施形態では、同じ内容のカードが複数枚重複して獲得されることがある。したがって、同じ内容のカードが複数枚ある場合には、それぞれのカードを識別するために、それぞれのカードに異なるカードIDが付与される。
キャラクタ名の項目には、該カードを分類するグループ識別子として該カードに紐付けられているキャラクタの名前が格納されている。本実施形態では、カードに紐付けられるキャラクタは、本ゲームに登場する複数のキャラクタのうちの1つである。キャラクタは、練習パートおよび実践パートなどにおいて、所定の行為を実施する動作主体であり、例えば、練習パートで使用されるデッキに編成されたカードに紐付けられているキャラクタは、該練習パートにおいて、動作主体として機能する。本ゲームにおいて動作主体として登場する各キャラクタには、他のキャラクタと重複しない固有の名前が設定されている。すなわち、キャラクタ名によって、該カードに紐付けられているキャラクタを一意に識別することができる。キャラクタIDも、キャラクタを一意に識別するためにキャラクタ固有に割り当てられている。そのため、該項目には、キャラクタ名に代えてキャラクタIDが格納されてもよい。
また、本実施形態では、異なるカードに、同じキャラクタが紐付けられていてもよい。したがって、ユーザが、同じキャラクタが紐付けられているカードを複数枚保有することが起こり得、この場合、その複数枚のそれぞれのカードは、別のカードとして取り扱われる。
希少度の項目には、カードに設定された希少度が格納される。希少度は、カードの本ゲーム内での希少価値を等級で表したものである。一般に、ゲーム上、特に、練習パートおよび実践パートにおいて良好な成果をもたらすカードには、上級の希少度が設定されている。本実施形態では、希少度は、等級が高いものから順に、SSR、SR、R、Nの4段階で表される。なお、希少度は、例えば、カードの入手困難性、より具体的には、カードが当たる抽選における当選確率、ステージのクリア報酬として入手される場合のステージの難易度、または、有償入手の場合の価格などと相関があってもよい。カードの入手困難性が高いほど、カードの希少度は高く設定される。
属性の項目には、カードを属性で分類する場合に、該カードがどの属性に分類されるのかを示す情報が格納されている。本ゲームでは、一例として、赤、青、および、黄の3種類の属性が設けられている。カードは、赤、青、および、黄のいずれかの属性に分類される。なお、属性の名称は、ゲームの文脈に応じて適宜設定されるものである。例えば、アイドルが登場するゲームであれば、情熱、知性、優雅の3属性であってもよいし、魔法使いが登場するゲームであれば、火、水、雷の3属性であってもよい。
属性は、練習パートにおいて、カードを用いてゲームが進行する場にも設定されていてもよい。本ゲームにおいて場とは、デッキに編成されたカードのうち、ゲームを進行させるために使用するカードとして選択されたカードを配置する場所を指す。ユーザは、ゲームで使用したいカードを場に出すことによって、該カードを使用してゲームを進めることができる。場に設定されている属性を場属性と称する。デッキに組み入れられたカードの属性(以下、カード属性)および場属性は、例えば、ステージクリア時の成果を決定するために、練習パートの進行中において練習パート進行部112によって参照される。
また、属性は、カードのパラメータを強化するための強化アイテムにも設定されていてもよい。強化対象カードのカード属性および強化アイテムの属性は、例えば、能力管理パートの進行中において、図示しない能力管理部によって参照される。例えば、カードと同じ属性の強化アイテムを該カードの強化に用いることで、強化効率が向上する。
カードレベルの項目には、カード自体のレベルを示す値が格納される。本実施形態では、カードレベルが高いほど、実践パートにおいて良好な結果をもたらす性能が高いことを意味する。カードレベルは、例えば、練習パートのステージをクリアしたことの成果として上昇させることができる。
魅力の項目には、カードの性能の1つとしての魅力のパラメータ値が格納される。魅力のパラメータ値が高いほど、実践パートにおけるCOM戦において該カードが有利に作用する。例えば、観客動員数を競うCOM戦において、魅力が高いほど、多くの観客を動員することができ、COM戦に勝利しやすくなる。魅力は、カードレベルと相関があり、カードレベルが上がるほど、魅力のパラメータ値も高くなる。
練習スキルの項目には、練習スキルの詳細情報が格納される。練習スキルは、カードに紐付けられており、該カードが、練習パートにおけるデッキに組み入れられた場合に、練習パートにおけるステージの進行中に発動可能となるものである。
メインスキルの項目には、メインスキルの詳細情報が格納される。メインスキルは、カードに紐付けられており、該カードが、実践パートにおけるメインデッキに組み入れられた場合に、実践パートにおけるステージの進行中に発動可能となるものである。
サブスキルの項目には、サブスキルの詳細情報が格納される。サブスキルは、カードに紐付けられており、該カードが、実践パートにおけるサブデッキに組み入れられた場合に、実践パートにおけるステージの進行中に発動可能となるものである。
カードに紐付けられている上述の各スキルは、ステージの進行中、該カードに表現されているキャラクタが発動したものとして演出されてもよい。スキルが発動されると、各パートの進行に有利な効果がもたらされる。各スキルの詳細情報としては、例えば、スキルの名称、効果の内容、効果値、発動条件などが含まれる。
セリフ管理情報の項目には、セリフ管理情報が格納される。セリフ管理情報は、キャラクタに発話させるセリフを管理するための情報であり、サーバ200から供給される。なお、練習パート等において、キャラクタ同士の対話をイベントとして発生させない場合は、カードにおいて、セリフ管理情報の項目は省略されてもよい。
(キャラクタ)
図5は、キャラクタを定義するキャラクタデータのデータ構造の一例を示す図である。図5に示すデータ構造を有するキャラクタデータは、本ゲームの各ゲームパートにおいてキャラクタごとに作成され、ゲーム情報132として記憶部120に記憶される。ユーザが保有するカードに紐付けられているキャラクタの分だけキャラクタデータが記憶部120に記憶されていてもよいし、ユーザがカードを入手する前から、本ゲームに登場するすべてのキャラクタの分のキャラクタデータが記憶部120に記憶されていてもよい。
キャラクタデータは、一例として、キャラクタID、キャラクタ名、所属(カテゴリ)、ペアパラメータテーブル、ストーリーリスト、セリフデータベース(以下、DB)、および、カードIDリストの各項目を含む。
キャラクタIDの項目には、キャラクタIDが格納されている。キャラクタIDは、各ゲームパートにおいて動作主体として機能するキャラクタをゲームシステム1上で一意に管理するために、キャラクタに固有に割り当てられた識別情報のことである。キャラクタIDは、体系的にユニークなテキスト列(記号、英数字など)で構成されていることが好ましい。
キャラクタ名の項目には、キャラクタ名が格納されている。キャラクタ名は、ユーザがキャラクタを識別するために、キャラクタに固有に割り当てられた識別情報のことである。キャラクタが男子高校生アイドルである場合は、ユーザが識別しやすいように、人名またはニックネームなどと分かるような文字列で構成されていることが好ましい。
所属の項目には、キャラクタがどの集合に属するのかを示すパラメータが格納されている。ストーリーパートにおいて展開される物語の中で各キャラクタには、該キャラクタの性質または所属などのように、キャラクタのカテゴリを示すさまざまな設定がなされている。所属の項目は、複数設けられてもよい。所属の項目は、ゲームの文脈および世界観などに応じて、より具体的に定義されてもよい。例えば、キャラクタが、男子高校生である場合、所属の項目として、該キャラクタの「学年」、「部活」、「所属寮」、「派閥」、「血液型」などの、キャラクタのカテゴリを表す項目が設けられてもよい。
ペアパラメータテーブルの項目には、ペアパラメータテーブルまたは該ペアパラメータテーブルが格納されている場所を示すアクセス情報が格納されている。ペアパラメータとは、該キャラクタと、その他のキャラクタとの間の関係性を表す数値化したものである。本実施形態では、本ゲームにおいて登場するすべてのキャラクタの組み合わせごとにペアパラメータが設定されている。ペアパラメータテーブルは、図5に示すキャラクタデータによって定義されているキャラクタを基準として、その他のキャラクタとの間に設定されたペアパラメータを、その他のキャラクタごとに一覧にしたものである。
なお、ゲームシステム1は、キャラクタごとにペアパラメータテーブルを管理する代わりに、本ゲームに登場するすべてのキャラクタの組み合わせごとに設定されたペアパラメータを一元管理するためのペアパラメータデータベース(以下、DB)を記憶部(記憶部120または記憶部220)において保持していてもよい。この場合、ペアパラメータテーブルの項目には、ペアパラメータDBから、該キャラクタにおける他のキャラクタとのペアパラメータを抽出するためのクエリが格納されていてもよい。ペアパラメータテーブルおよびペアパラメータDBについては、データ構造図に基づいて後に詳述する。
ストーリーリストの項目には、ストーリーリストまたはストーリーリストにアクセスするためのアクセス情報が格納されている。ストーリーリストは、該キャラクタにまつわる個別ストーリーをまとめたリストである。本実施形態では、一例として、キャラクタにまつわる個別ストーリーは、該キャラクタとその他のキャラクタとのペアに焦点を当てた物語である。ストーリーリストについては、データ構造図に基づいて後に詳述する。
セリフデータベースの項目には、セリフDBまたはセリフDBにアクセスするためのアクセス情報が格納されている。セリフDBは、該キャラクタに紐付けられたセリフパックを一元管理するデータベースである。セリフパックは、練習パートにおいてイベントを進行させるために必要なイベントデータおよびそのメタデータなどがひとまとまりにパッケージ化された情報である。具体的には、セリフパックは、該キャラクタまたは該キャラクタとペアリングされた相手キャラクタに発話させる1以上のセリフからなるセリフ群を少なくとも含む。なお、練習パートまたは実践パート等において、対話するイベントが発生しない場合は、該セリフデータベースの項目は、キャラクタデータから省略されてもよい。
カードIDリストの項目には、カードIDリストまたはカードIDリストにアクセスするためのアクセス情報が格納されている。カードIDリストは、ユーザが保有するカードのうち、該キャラクタが紐付いているカードのカードIDをまとめたリストである。ユーザ端末100は、カードIDリストを参照することにより、ユーザが保有しているカードの中から、該キャラクタが紐付いているカードをすぐに抽出することができる。
本実施形態では、キャラクタとカードとは1対多の関係である。すなわち、1つのカードにおいて紐付けられるキャラクタは1体であるが、異なる複数のカードに対して同じキャラクタが紐付けられ得る。また、同じキャラクタでも、紐付けられているカードが異なれば、カードごとに異なる属性が設定され得る。
また、本実施形態では、キャラクタごとにも、図5に示すとおり、上述の各種項目が紐付けられており、これらのキャラクタごとの情報は、同じキャラクタが紐付けられている各カードで共有される。
換言すれば、カードは、キャラクタごとにグルーピングすることが可能であり、キャラクタは、カードを分類するためのグループ、キャラクタIDおよびキャラクタ名は、カードをグルーピングするためのグループ識別子と捉えることができる。そして、同じグループに属する各カードが利用されるとき、該グループに紐付けられた情報が、各カードに共通で参照される。具体的には、ユーザ端末100は、同じキャラクタが紐付いている各カードをデッキに組み入れて利用する際、該カードに紐付けられているキャラクタを動作させるときに、該キャラクタを定義する上述の各項目を参照する。
なお、カードは、キャラクタ以外にも、上述したとおり、希少度または属性などに基づいて分類することも可能である。さらに、カードは、キャラクタに設定されている所属などに基づいて分類することも可能である。
(ペアパラメータテーブル)
図6の(A)は、ペアパラメータテーブルのデータ構造の一例を示す図である。本ゲームでは、一例として、5人のキャラクタが物語に登場する。5人のキャラクタのキャラクタ名は、一例として、A太、B介、C彦、D男、および、F郎である。同図には、一例として、キャラクタ「A太」に紐付けられているペアパラメータテーブルを示している。同様のペアパラメータテーブルが、B介、C彦、D男、および、F郎のキャラクタごとに作成される。
ペアパラメータテーブルは、相手キャラクタ、および、ペアパラメータの各項目を含む。ペアパラメータは、上述のとおり、ペアを構成する2人のキャラクタ間の関係性を数値化したものであり、本実施形態では、一例として、友好度と調和度との2種類のペアパラメータが設定されている。
相手キャラクタの項目には、基準となるキャラクタとペアリングされた相手キャラクタのキャラクタ名が格納されている。例えば、図6に示す第1のレコードは、基準となるキャラクタ「A太」と、その相手キャラクタである「B介」との間のペアパラメータを格納するためのレコードである。
友好度の項目には、キャラクタ間の友好度を示す数値が格納される。友好度とは、ペアとなっているキャラクタ間の友好の度合いを評価する指標である。本実施形態では、数値が高いほど、ペアの友好の度合いが高い、すなわち、2人は仲が良いということを意味する。図6に示す例では、例えば、「A太」と「B介」との友好度は「25」である。友好度は、ペアごとの個別ストーリーを解放する条件として参照される。
調和度の項目には、キャラクタ間の調和度を示す数値が格納される。調和度とは、ペアとなっているキャラクタ間の連携の良さを評価する指標である。本実施形態では、100%を、ペアがとり得る最大の調和度とし、数値が高いほど、ペアの連携が良くとれている、すなわち、該ペアによってよりよいパフォーマンスが出力されるということを意味する。
例えば、実践パートのステージをプレイする際、該ステージで使用するカードのうち、特定の2枚のカードがそれぞれ示すキャラクタ間の調和度の数値に応じて、実践パートのステージにおける、該2体のキャラクタに係る、画像、動画、および音声等での演出が変化してもよい。具体的には、該2体のキャラクタ間の調和度の数値が所定値以上の場合、該2体のキャラクタが親密であることを示す画像、動画、および音声の少なくともいずれかを出力することとしてもよい。また、該2体のキャラクタ間の調和度の数値が高いほど、該演出がより豪華な演出になるようにしてもよい。また、該2体のキャラクタ間の調和度の数値が高いほど、該演出の回数、すなわち演出頻度が増加してもよい。
また例えば、該2体のキャラクタ間の調和度の数値が高いほど、実践パートのステージ進行が有利になってもよい。具体的には、該2体のキャラクタ間の調和度の数値が高いほど、実践パートのステージにおいて発動可能なスキルの効果値または効果内容の継続時間が増加してもよい。また、該2体のキャラクタ間の調和度の数値が高いほど、実践パートのステージにおいて、該2体のキャラクタの少なくとも一方のスキルの、発動可能回数および発動機会の少なくとも一方が増加してもよい。
また例えば、上述の2体のキャラクタ間の調和度の数値が高いほど、これらのキャラクタ、または該キャラクタに対応するカードに設定されている各種パラメータの値を、ゲームが有利になるように変更してもよい。具体的には、該2体のキャラクタ間の調和度の数値が高いほど、これらのキャラクタに対応するカードの魅力のパラメータ値が上昇してもよい。また、実践パートのステージが、ユーザの自陣営と、敵陣営とが対戦する対戦形式のステージである場合、自陣営の特定の2枚のカードが示すキャラクタ間の調和度と、敵陣営の特定の2枚のカードが示すキャラクタ間の調和度とを比較してもよい。そして、該比較の結果、調和度が高い方の陣営の、該特定の2枚のカードのパラメータを増加させてもよい。もしくは、該比較の結果、調和度が低い方の陣営の、該特定の2枚のカードのパラメータを低下させてもよい。
また例えば、実践パートのステージが、自陣営のターンと敵陣営のターンとを実行することで進行するゲームの場合、前述の比較の結果、調和度が高い方の陣営のターンを先に行うようにしてもよい。一例として、調和度が高い方の陣営が対戦で有利な先手を取る確率を高めるなどが想定される。または、前述の比較の結果、調和度が高い方の陣営のターンを実行する頻度を上昇させてもよい。
本実施形態では、一例として、調和度は、練習パートにおいて、ペアが練習を積むことにより高めることができ、実践パートにおいて、ペアが特定のパフォーマンスを出力するために消費される。すなわち、調和度は、ユーザが、練習パートと実践パートとを繰り返しプレイすることにより増減する数値である。
図6の(B)は、ペアパラメータDBのデータ構造の一例を示す図である。本実施形態では、ペアパラメータDBにおいて、本ゲームに登場するキャラクタの組み合わせ、すなわち、ペアを主キーとし、該ペアごとにレコードが作成される。そして、該レコードにペアパラメータが格納されている。具体的には、友好度と調和度とが格納されている。
本実施形態では、上述したとおり、5人のキャラクタが登場する。この場合、5人のキャラクタのすべての組み合わせは、10通りあるので、ペアパラメータDBは、10個のレコードを有する。ユーザ端末100の制御部110は、ペアパラメータDBから、1人のキャラクタをキーにして、ペアパラメータのレコードを抽出してもよい。例えば、「主キーにA太が含まれているレコードを抽出する」というクエリに基づいてペアパラメータDBを操作すれば、図6の(A)に示すとおり、A太についてのペアパラメータテーブルが得られる。
(ストーリーリスト)
図7は、ストーリーリストのデータ構造の一例を示す図である。同図には、一例として、キャラクタ「A太」に紐付けられているストーリーリストを示している。同様のストーリーリストが、B介、C彦、D男、および、F郎のキャラクタごとに作成される。
ストーリーリストは、相手キャラクタ、ストーリーIDおよび状態の各項目を含む。
相手キャラクタの項目には、基準となるキャラクタ(ここでは「A太」)とペアリングされた相手キャラクタのキャラクタ名が格納されている。
ストーリーIDの項目には、該ペアに紐付けられた個別ストーリーのストーリーIDが格納されている。ストーリーIDは、個別ストーリーに対応するストーリーデータをゲームシステム1において一意に識別するための識別情報である。個別ストーリーを一意に識別できる情報であれば何でもよく、例えば、該項目には、ストーリーIDに代えて、個別ストーリーごとに設定された物語のタイトル、章番号などが格納されていてもよい。あるいは、該項目には、ストーリーIDに代えて、個別ストーリーに対応するストーリーデータが格納されている場所を示すアドレス情報が格納されていてもよい。
個別ストーリーは、1つのペアにつき、複数個ユーザに提供されてもよい。同図に示す例では、例えば、A太とB介とのペアにまつわる個別ストーリーは、ストーリーID「AB001」から「AB003」までの3話分ユーザに提供されている。
状態の項目には、該個別ストーリーの状態を示すパラメータが格納されている。個別ストーリーの状態を示すパラメータは、一例として、個別ストーリーが解放済みであるか、未解放であるのかを示すフラグであってもよい。本実施形態では、個別ストーリーが「解放済みである」とは、ユーザが、該個別ストーリーのストーリーデータにユーザ端末100を介してアクセスすることが可能であって、該個別ストーリーをユーザが読むことができる状態であることを意味する。
さらに、上述の状態の項目または別に設けられた項目には、個別ストーリーの状態を示すパラメータとして、解放進捗が格納されていてもよい。解放進捗は、個別ストーリーが未解放である場合に、解放の条件をユーザがどれだけ満たしているのかを示した情報である。本実施形態では、解放進捗は、一例として、分数であり、解放に必要な友好度を示す分母と、ユーザがゲームをプレイすることによって蓄積した該ペアの現在の友好度を示す分子とで構成される。
なお、個別ストーリーは、図6の(B)に示したペアパラメータDBと同様に、ペアを主キーとするデータベースにて、ペアごとに一元管理されてもよい。
(ストーリーリスト)
図7は、ストーリーリストのデータ構造の一例を示す図である。同図には、一例として、キャラクタ「A太」に紐付けられているストーリーリストを示している。同様のストーリーリストが、B介、C彦、D男、および、F郎のキャラクタごとに作成される。
ストーリーリストは、相手キャラクタ、ストーリーIDおよび状態の各項目を含む。
相手キャラクタの項目には、基準となるキャラクタ(ここでは「A太」)とペアリングされた相手キャラクタのキャラクタ名が格納されている。
ストーリーIDの項目には、該ペアに紐付けられた個別ストーリーのストーリーIDが格納されている。ストーリーIDは、個別ストーリーに対応するストーリーデータをゲームシステム1において一意に識別するための識別情報である。個別ストーリーを一意に識別できる情報であれば何でもよく、例えば、該項目には、ストーリーIDに代えて、個別ストーリーごとに設定された物語のタイトル、章番号などが格納されていてもよい。あるいは、該項目には、ストーリーIDに代えて、個別ストーリーに対応するストーリーデータが格納されている場所を示すアドレス情報が格納されていてもよい。
個別ストーリーは、1つのペアにつき、複数個ユーザに提供されてもよい。同図に示す例では、例えば、A太とB介とのペアにまつわる個別ストーリーは、ストーリーID「AB001」から「AB003」までの3話分ユーザに提供されている。
状態の項目には、該個別ストーリーの状態を示すパラメータが格納されている。個別ストーリーの状態を示すパラメータは、一例として、個別ストーリーが解放済みであるか、未解放であるのかを示すフラグであってもよい。本実施形態では、個別ストーリーが「解放済みである」とは、ユーザが、該個別ストーリーのストーリーデータを所有していること、または、該ストーリーデータにユーザ端末100を介してアクセスする権限を有していることであって、該個別ストーリーをユーザが読むことができる状態であることを意味する。
さらに、上述の状態の項目または別に設けられた項目には、個別ストーリーの状態を示すパラメータとして、解放進捗が格納されていてもよい。解放進捗は、個別ストーリーが未解放である場合に、解放の条件をユーザがどれだけ満たしているのかを示した情報である。本実施形態では、解放進捗は、一例として、分数であり、解放に必要な友好度を示す分母と、ユーザがゲームをプレイすることによって蓄積した該ペアの現在の友好度を示す分子とで構成される。
なお、個別ストーリーは、図6の(B)に示したペアパラメータDBと同様に、ペアを主キーとするデータベースにて、ペアごとに一元管理されてもよい。
<練習パート>
(処理フロー)
図8は、練習パート進行部112によって実行される練習パートにおける処理の流れを示すフローチャートである。
ステップS301では、練習パート進行部112は、不図示のデッキ編成画面を表示部152に表示させる。デッキ編成画面は、選択されたステージで使用される1次デッキに組み入れるカードをユーザが所有するカードの中から選択する入力操作を受け付けるための画面である。
ステップS302では、練習パート進行部112は、デッキ編成画面に対して実施される上述の入力操作が操作受付部を介して受け付けられたか否か判定する。練習パート進行部112は、該入力操作を受け付けた場合、ステップS302のYESからステップS303に進み、該入力操作を受け付けていない場合は、ステップS302のNOからステップS304に進む。
ステップS303では、練習パート進行部112は、ユーザによって選択されたカードを1次デッキに組み入れて1次デッキを編成する。
さらに、本実施形態では、練習パート進行部112は、ユーザが選択したカードとは別に、所定の規則にしたがって特定したカードを1次デッキに組み入れてもよい。練習パート進行部112は、ユーザが保有するカードのうち、ユーザによって指定されなかったカードを所定の規則にしたがって特定してもよい。例えば、練習パート進行部112は、ユーザが保有するカードの中からランダムで特定してもよい。あるいは、練習パート進行部112は、ユーザが保有していないカードを所定の規則にしたがって特定してもよい。例えば、練習パート進行部112は、ユーザによって選択されたステージに予め関連付けられたカードを1次デッキに組み入れるカードとして特定してもよい。本実施形態では、練習パート進行部112は、ユーザによって選択された、ユーザが保有するカード例えば10枚と、ステージに関連付けられているカード例えば1枚とを1次デッキに編成する。
ステップS304では、練習パート進行部112は、練習パートにおけるステージの開始を指示する入力操作を受け付けてもよい。ステージの開始を指示する入力操作は、例えば、デッキ編成画面内に配置されている「開始ボタン」などのUI部品をユーザがタッチすることにより、入力されてもよい。開始ボタンがタッチされると、練習パート進行部112は、ステップS304のYESからステップS305へ進み、ステージの進行を開始する。
次に、練習パート進行部112は、ステージを進行させる。本実施形態では、一例として、1つのステージは、所定回のセットで構成される。練習パート進行部112は、1回のセットに相当するステップS305からステップS309までの各処理を所定回、例えば、10セット繰り返し進行させることにより、ステージを進行させる。本実施形態では、場はセットごとに設けられる。すなわち、練習パート進行部112は、場に出すカードとしてユーザに選択されたカードを使用して、1つのセットを進行させるという処理を10セット分繰り返すことにより、1つのステージを進行させる。ステップS305からステップS309までのループを抜ける条件は、したがって、「ステージを構成するすべてのセットが処理済みであること」である。
ステップS305では、練習パート進行部112は、1次デッキに基づいて2次デッキを編成する。より詳細には、練習パート進行部112は、1次デッキに組み入れられたカードの中から、所定の規則に基づいてカードを抽出し、抽出したカードからなる2次デッキを編成する。一例として、練習パート進行部112は、2次デッキに組み入れるカード5枚を、1次デッキの11枚のカードの中からランダムで抽出する。
ステップS306では、練習パート進行部112は、進行中の各セットの基本情報をユーザに対して開示するためのステージ進行画面を表示部152に表示する。ステージ進行画面は、ステップS305にて編成された2次デッキを含む。具体的には、練習パート進行部112は、例えば、上述のステージ進行画面に、2次デッキのカード一覧を表示させ、カード一覧の中から、ユーザが、進行中のセットで使用するカードを選択できるようにUIを提供する。すなわち、ステージ進行画面は、2次デッキの中から、進行中のセットで使用するカードを選択する入力操作をユーザから受け付けるための画面としても機能する。ステージ進行画面の具体例については、図11の(A)を参照して後に詳述する。
ステップS307では、練習パート進行部112は、ステージ進行画面に対して実施される入力操作が操作受付部を介して受け付けられたか否か判定する。練習パート進行部112は、該入力操作を受け付けた場合、ステップS307のYESからステップS308に進み、該入力操作を受け付けていない場合は、ステップS307のNOからステップS306に戻り、該入力操作が受け付けられるまで待機する。
ステップS308では、練習パート進行部112は、1つのセットに対するユーザのプレイ、つまりペアの選択、に基づいて、ユーザに付与する報酬を決定する。報酬は、一例として、カードに設定されているパラメータを強化できる強化アイテムである。
ステップS309では、練習パート進行部112は、ユーザの入力操作にしたがってユーザが2次デッキから選択したカードを場に出して、進行中のセットを終了まで進行させる。本実施形態では、練習パート進行部112は、ユーザが選択した2枚のカードを場に出す。そして、練習パート進行部112は、場に出したカードに基づいて、該セットを進行させる。本実施形態では、一例として、「セットにおいてカードを使用する」とは、進行中のセットに関連付けられている場にカードを出して、場と、該場に出されたカードとの組み合わせに応じて発生させたイベントを進行させることを指す。より具体的には、練習パート進行部112は、場に出したそれぞれのカードに紐付けられているキャラクタのペアを特定する。そして、練習パート進行部112は、場に出された2枚のカードのそれぞれに紐付いているキャラクタの2人に所定の行為を実施させる。具体的には、練習パート進行部112は、発生させたイベントを再生するためのイベントデータを処理し、キャラクタ達が上述の所定の行為を実施している演出が付いたアニメーションを表示部152に出力したり、キャラクタのセリフに対応する音声データを図示しないスピーカに出力したりする。さらに、練習パート進行部112は、ステップS308において決定された量の報酬がドロップしてユーザが獲得できる様を表すアニメーションを、併せて、表示部152に出力してもよい。
練習パート進行部112は、1つのセットにつき、ステップS305からステップS309までの各処理を実行し、これをセットごとに繰り返す。練習パート進行部112は、ステージを構成するすべてのセットについてステップS305からステップS309までの処理を実行すると、例えば、10セット進行させると、ループを抜け、ステップS310に進む。
ステップS310では、練習パート進行部112は、ステージがプレイされた成果を示す結果画面を表示部152に表示する。結果画面は、少なくとも、例えば、10セットを通じて合計で強化アイテムが何個付与されたのかを示す情報を含んでいる。
ステップS311では、練習パート進行部112は、各セットで獲得された報酬を、ユーザに付与する。具体的には、ユーザに関連付けて記憶されている強化アイテムの所持数を、上述の合計が示す個数分増分する。
(デッキ編成)
図9は、練習パートで参照されるデッキ情報のデータ構造の一例を示す図である。図9の(A)は、1次デッキのデッキ情報を示し、図9の(B)は、2次デッキのデッキ情報を示す。
図9に示すとおり、各デッキのデッキ情報は、ポジション番号、および、カードIDの各項目を含む。
ポジション番号の項目には、各デッキにおけるカードの配置場所を識別するための識別情報が格納されている。例えば、ポジション番号「1−1」は、1次デッキにおける1番目の配置場所を示しており、ここに配置されたカードは、1次デッキの1番目のカードというように識別される。なお、デッキ上の配列または配置順が、デッキを用いたゲームパートにおける進行に影響を与えない実施形態においては、ポジション番号の項目は省略されてもよい。
カードIDの項目には、各デッキに組み入れられたカードのカードIDが格納されている。同図では、説明を簡略化するために1ケタの数字が格納されているが、カードIDは、全てのカードを一意に識別するために割り振られる識別情報であるので、実際には、これよりも複雑な文字および記号の羅列であると想定される。
なお、同図には、発明の理解を助けるために、キャラクタ名の項目を設けている。これは、説明のために図示したのであって、実際のデッキ情報には項目として設けられていなくてもよい。キャラクタ名の項目には、該ポジションに配置されたカードに紐付けられているキャラクタのキャラクタ名が格納されている。
図9の(A)に示すとおり、1次デッキのデッキ情報は、少なくとも、ユーザによって選択されたカードを配置するためのポジションを有する。図示の例では、該ポジションは「1−1」から「1−10」まで10個設けられている。
練習パート進行部112が、1次デッキに入れるカードとして、ユーザによって選択されたカードとは別のカードを所定の規則に基づいて特定する場合が想定される。この場合、1次デッキのデッキ情報は、そのようにして特定されたカードを配置するためのポジションを有していてもよい。図示の例では、該ポジションは、「1−11」として1個設けられている。以下では、ユーザが選択したカードとは別に、練習パート進行部112が選択したカードを、特に区別が必要な場合には、ゲストカードと称する。一例として、1次デッキは、ユーザによって選択されたカードを配置するための10個のポジションと、練習パート進行部112が決定したゲストカードを配置するための1個のポジションとで構成される。本実施形態では、ゲストカードは、例えば、ステージごとに予め定められている。
練習パート進行部112は、ステップS103において、デッキ編成画面を介して、10枚のカードを選択する第1入力操作を受け付けると、該10枚のカードと、選択されたステージに関連付けられた1枚のゲストカードとに基づいて、図9の(A)に示すデッキ情報を生成する。
練習パート進行部112は、カードを分類するためのグループ識別子、例えば、キャラクタ名またはキャラクタIDに基づいて、カードが属するグループ、例えば、カードに紐付いているキャラクタを特定し、同じグループに属するゲーム媒体を、予め定められた上限数を超えないように、1次デッキに組み込んでもよい。例えば、図9の(A)に示すとおり、練習パート進行部112は、ゲストカードを除いて、同じキャラクタのカードが2枚を超えて組み入れられないように1次デッキを制御してもよい。これにより、様々なキャラクタのカードを1次デッキに組み入れて、どのキャラクタも万遍なく育成するようにユーザを促すことができる。結果として、ユーザは、ゲームに飽きることなく長く育成ゲームを楽しむことが可能となる。
図9の(B)に示すとおり、2次デッキのデッキ情報は、練習パート進行部112によって、1次デッキに組み入れられたカードの中から抽出されたカードを配置するためのポジションを有する。図示の例では、該ポジションは「2−1」から「2−5」まで5個設けられている。
練習パート進行部112は、セットが開始される度に、1次デッキに組み入れられた11枚のカードの中から、所定の規則に基づいて5枚(第1の所定数)のカードを抽出し、図9の(B)に示すデッキ情報を生成する。
例えば、練習パート進行部112は、ランダムに5枚のカードを抽出してもよい。練習パート進行部112は、前回のセットでどのカードが場に出されたのかに応じて5枚のカードを抽出してもよい。練習パート進行部112は、一例として、以下の規則に基づいて5枚のカードを抽出し2次デッキを編成する。
図10の(A)〜(C)は、前回のセットが進行した後、次に、練習パート進行部112が、今回のセットを進行させるために用いる2次デッキを再編するまでの工程を詳細に説明する図である。
図10の(A)は、前回のセットのステップS109において、ユーザによって選択され、場に出されたカードの一例を示す図である。上段は選択されたカードのカードID、下段は該カードに紐付けられているキャラクタのキャラクタ名を示す。図示のとおり、ユーザは、図9の(B)に示す2次デッキのカードの中から、カードID「5」および「7」の各カードを選択したとする。以下では、カードID「5」および「7」の各カードを、5番のカード、7番のカードと称する。
図10の(B)は、前回のセット終了直後の2次デッキのデッキ情報を示す図である。同図に示す例では、ポジション番号の項目の記載を省略した。上段は、2次デッキに組み入れられているカードのカードID、下段は、該カードに紐付けられているキャラクタのキャラクタ名を示す。
練習パート進行部112は、前回のセットが終了すると、一旦、前回のセットでユーザに選択され、場に出されたカードを、2次デッキから外す。図示の例では、練習パート進行部112は、5番のカードと7番のカードとを2次デッキから外す。一方、練習パート進行部112は、前回のセットでユーザに選択されなかったカードを、今回のセットにおける2次デッキに組み入れたまま維持する。
次に、練習パート進行部112は、今回のセットための2次デッキを再編成する。一例として、練習パート進行部112は、上述のカードを外したことにより空いたポジションに補充するカードを選択する。別の例では、練習パート進行部112は、前回のセットで編成された2次デッキをリセットし、2次デッキのすべてのポジションを新しく選びなおしてもよい。
一例として、練習パート進行部112は、空いたポジションに補充するカードの候補を、以下のように特定し、該カードの候補の中から、補充するカードをランダムに抽出する。
図10の(C)は、空いたポジションに補充されるカードの候補を示す図である。例えば、練習パート進行部112は、前回のセットで2次デッキに組み入れられなかったカードを候補に入れる。これにより、前回のセットで練習パート進行部112によって抽出されずに1次デッキに残留した各カードが2次デッキに組み込まれる可能性が出る。
すなわち、練習パート進行部112は、前回のセットで場に出すカードとして選択されなかったカードを2次デッキに残留させる構成、および、1次デッキにおいて2次デッキ用に抽出されなかったカードを候補に入れる構成を有する。これらの構成により、結果として、ユーザに多様なカードを使って、各種キャラクタを幅広く育成してほしいとするゲームマスター側、例えば、本ゲームのゲームプログラムを各ユーザに供給する運営団体の意図を反映させることができる。
本実施形態では、加えて、練習パート進行部112は、前回のセットでユーザに選択されたカードも候補に入れる。これにより、前回のセットでユーザが選択したカードが今回のセットにおいても連続で2次デッキに組み込まれる可能性が出る。また、カードが2次デッキに組み込まれれば、ユーザは、そのカードを自分の意思で最終的に場に出すカードとして選択することができる。ユーザは、お気に入りのカードを、該カードに関連するパラメータを育成するために何度でも選択したいと思っていると考えられる。
すなわち、練習パート進行部112は、前回のセットで場に出すカードとして選択されたカードを候補に入れる構成、および、2次デッキの中から場に出したいカードについてユーザの選択を受け付ける構成を有する。これらの構成により、お気に入りのカードを集中的に強化したいとするユーザの要望にも応えることが可能となる。
(ステージ進行画面)
図11の(A)および(B)は、ユーザ端末100の表示部152に表示されるステージ進行画面の一例を示す図である。
練習パート進行部112は、ステップS106を実行するときに、例えば、図11の(A)に示すステージ進行画面900を表示部152に表示する。練習パート進行部112は、ステップS109を実行するときに、例えば、図11の(B)示すステージ進行画面900を表示部152に表示する。
ステージ進行画面900は、ステージおよび各セットの基本情報を開示する第1の機能と、セットで使用するカードをユーザが選択するためのUI部品を提供する第2の機能と、イベントの進行状況および結果をユーザに対して提示する第3の機能とを備えるように構成される。
図11の(A)に示すとおり、第1の機能を実現するために、ステージ進行画面900は、一例として、セット情報901と、集中度ゲージ902と、成果情報903とを含む。
セット情報901は、ステージの進行状況を示す情報を含む。進行状況を示す情報は、進行中のセット(以下、現行セット)を含めて、進行が完了していないセットが残りいくつあるのかを示す情報である。「あと3セット」などとセット情報901が表示されることにより、ユーザは、未完了のセットが3セットあることを理解する。
セット情報901は、さらに、現行セット、次回セット、および、次々回セットの場属性を示す情報を含んでいてもよい。各セットにおいて「場」とは、ユーザによって選択された2枚のカードを配置するための場所のことであり、本ゲームの文脈で言えば、上述の2枚のカードのそれぞれに紐付けられた二人のキャラクタ(ペア)が、練習としてパフォーマンスを行うための練習舞台905である。
場属性を示す情報は、例えば、図示のとおり、色分けされたアイコンとして提示されてもよい。詳細には、セット情報901のうち、左の最も大きいアイコンが、現行セットの場属性を示し、中央のアイコンが、次回セットの場属性を示し、右のアイコンが次々回セットの場属性を示す。
本実施形態では、練習パート進行部112は、該セットにおける場属性と、場に配置されたカードの属性との関係性に応じて、該セットを完遂した時にユーザが得られる成果を決定してもよい。例えば、練習パート進行部112は、場属性と一致するカードが場に配置されたセットでは、一致しない場合よりもユーザにとって有利な成果が得られるように、該セットの成果の内容を補正してもよい。具体的には、練習パート進行部112は、属性が一致したセットを完遂したことの報酬である強化アイテムをより多くユーザに獲得させてもよいし、該セットに登場したペアのペアパラメータの上昇値をより多くしてもよい。また、本実施形態では、練習パート進行部112は、場属性と一致するカードが場に配置されたセットでは、一致しない場合よりもより多くのメダルをユーザに獲得させる。さらに、本実施形態では、練習パート進行部112は、場属性と一致するカードであって、推奨ペアとキャラクタが一致するカードが場に出されたセットでは、属性のみを一致させた場合よりもさらにより多くのメダルをユーザに獲得させる。
ユーザは、よりよい成果を効率よく得るために、セット情報901に示された場属性を確認し、手持ちのカードの属性と比較して最適なペアを選択することができる。結果として、練習パートの遊戯性が高まる。
集中度ゲージ902は、セットごとにイベントが進行する度に、イベントが進行したことの成果として蓄積されるパラメータの蓄積度合いを示すUI部品である。本ゲームの文脈では、該パラメータは、一例として、場に出た各キャラクタが練習に集中している度合いを示す集中度として表現される。本実施形態では、練習パート進行部112は、セットごとに場にカードを配置し、各カードのキャラクタ対に関するイベントを進行させる度に集中度を更新する。集中度が予め定められた閾値に達すると、練習パート進行部112は、次回以降の数セットを、ユーザにとって特に有利にステージを進行させるモード(いわゆるフィーバーモード)で進行させる。例えば、練習パート進行部112は、セット完遂後に得られる強化アイテムなどの報酬の量を大幅に増加させてもよい。練習パート進行部112は、フィーバーモードを終了させると、集中度のゲージをリセットし、またゼロから蓄積を再開する。なお、練習パート進行部112は、場属性と場に出されたカードの属性とが一致している場合に、より多くの集中度を蓄積してもよい。本実施形態では、練習パート進行部112は、集中度を、ステージを跨いで持ち越してもよい。練習パート進行部112は、ステージが終了した時点の集中度を、ゲーム情報132として記憶部120に記憶しておき、別のステージが開始されたときに、記憶しておいた集中度を読み出す。
成果情報903は、進行中のステージにおいて、進行済みの各セットでこれまでに獲得された報酬の数または量をユーザに提示するためのUI部品である。図示の例では、報酬は、属性が設定された強化アイテムおよびメダルであり、強化アイテムについては、設定された属性ごとに、報酬として獲得された強化アイテムの数が開示される。また、メダルについては、属性問わず、獲得されたメダルの全種類の合計が開示される。これにより、ユーザは、ステージの進行中であっても、ステージ完遂後に得られる報酬の量を事前に把握することが可能となる。
第2の機能を実現するために、ステージ進行画面900は、一例として、2次デッキ912を含む。
2次デッキ912は、1次デッキに組み入れられたカードの中から、練習パート進行部112が所定の規則に基づいて抽出したカードをユーザに提示するためのUI部品である。また、2次デッキ912は、場に出す2枚のカードをユーザが選択するためのUI部品である。2次デッキ912には、練習パート進行部112によって2次デッキとして抽出された、例えば5枚のカードが配置される。
2次デッキ912において、カードには、属性アイコン914が付与されてもよい。属性アイコン914は、カード属性を示す。ユーザは、カードに付与されている属性アイコン914を見て、そのカードのカード属性を確認することができる。
2次デッキ912において、カードには、調子アイコン915が付与されてもよい。調子アイコン915は、そのカードの調子の良さを示す。本実施形態では、「カードの調子」とは、カードの状態の良し悪しを示すパラメータである。カードの調子は、ステージで固定されていてもよいし、セットごとに変更されてもよいし、そのカードが場で使用されるまでの間同じ調子で維持されるものであってもよい。カードの調子が良いことは、カードの調子が通常の場合よりも、該カードが場に出されたときに、該カードが、ユーザにとって有利な結果または良好な成果をもたらすことができるということを意味している。
本実施形態では、練習パート進行部112は、2次デッキに組み入れられた各カードの調子を所定の規則に基づいて決定し、各カードが選択されずに2次デッキに残留している間、その調子を維持させる。練習パート進行部112は、カードが使用された後、次に、該カードを2次デッキに編成するときに、該カードの調子を所定の規則に基づいて再設定する。一例として、練習パート進行部112は、「通常」、「好調」、「絶好調」の3段階で、各カードの調子をランダムに決定する。
調子が所定の段階より上の段階にあるカード、例えば、調子が好調以上であるカード同士がペアとして選択された場合には、通常のカードを場に出した場合と比較して、より有利な結果またはより良好な成果が得られる。一例として、練習パート進行部112は、該ペアについて進行するイベントにつき、希少度の高いセリフを発現させる可能性を高めたり、ボーナス対話としてセリフをより多く発現させたりして、ペアに希少度の高い行為を実施させたりして、ユーザがよりイベントを楽しめるようにする。あるいは、練習パート進行部112は、セット完遂後に得られる各種パラメータの上昇率を高めたり、より多くのまたはより価値の高い報酬をユーザに獲得させたりして、より良好な成果をもたらしてもよい。
2次デッキ912において、ゲストカードのカードには、ゲストアイコン917が付与されてもよい。これにより、ユーザは、自分の手持ちのカード以外でデッキに組み入れられているゲストカードを判別しやすくなる。
以上のとおり、ユーザは、ステージ進行画面900に開示されたさまざまな情報、特に、セット情報901、および、2次デッキ912を確認して、現行セットの場に最適な2枚のカードを選択することができる。
2枚のカードを選択するための入力操作は、例えば、2次デッキ912に配置されている所望のカードをタップ操作することで実現される。
練習パート進行部112は、2次デッキ912に配置されている5枚のカードのうち、2枚のカードに対するタップ操作を受け付けると、選択された2枚のカードを場に出して、現行セットを進行させる。具体的には、練習パート進行部112は、選択された2枚のカードのそれぞれに紐付けられているキャラクタのペアを、練習舞台905に表示して、該ペアに関するイベントを進行させる。
続いて、練習パート進行部112は、現行セットにつきユーザに付与される報酬を視覚的に見せる演出を出力してもよい。以下では、練習パート進行部112が、内部的にユーザに獲得させる報酬を所定の規則に基づいて確定させること、また、確定したことをユーザに対して視覚的に見せることを「報酬をドロップさせる」と表現し、報酬が確定すること、また、報酬がそのように視覚的に提示されることを、「報酬がドロップする」と表現する。また、そのように取り扱われる報酬そのものを「ドロップ報酬」と表現する。
一例として、図11の(B)に示すとおり、練習パート進行部112は、イベント進行の終盤に、ステージ進行画面900において、ドロップ報酬としての強化アイテム918が、所定の行為を実施中のキャラクタ906およびキャラクタ907からドロップする様を表現したアニメーションを出力する。練習パート進行部112は、練習舞台905において演出としてドロップさせる強化アイテム918の個数を、ステップS108にて決定した個数と合わせることが好ましい。本実施形態では、さらに、練習パート進行部112は、ドロップした強化アイテム918が、成果情報903において強化アイテムの個数を表すアイコン919のところまで移動するアニメーションを付加してもよい。
これにより、ユーザは、セットで獲得できた強化アイテム数を直感的に把握することが可能となり、さらに、ドロップした強化アイテムの数多い場合には、とりわけ、多くの強化アイテム918が獲得できたことを視覚的に認知することができるので、セットを成功させたことについて、達成感、満足感をより一層得ることができる。
(画像の素材データベース)
サーバ200の記憶部220には、画像の素材データベース(以下、素材DB)が格納されている。素材DBにおいて管理されている素材データは、ストーリーパート、練習パートまたは実践パートの進行時にゲーム画面に配置される画像である。素材データとしては、例えば、キャラクタが居る所定の場所を表す背景画像(第1の素材データ)と、該所定の場所で、所定の行為を実施するキャラクタを表す前景画像(第2の素材データ)とがある。
背景画像は、例えば静止画である。背景画像の素材DBは、例えば、ID、場所名、静止画の各項目を含むデータ構造を有する。IDの項目には、背景画像を一意に識別する情報が格納されており、該情報は、静止画のファイル名などであってもよい。場所名の項目には、背景画像が表す場所の名前が格納されている。該名前は、例えば、「校舎の廊下」、「理事長室」、「寮のキッチン」、「カフェテラス」、「夕暮れの野原」など、ストーリーパートで進行する物語に登場する場所、もしくは、練習パートのステージ進行画面900(図11)または実践パートのステージ進行画面(不図示)において背景として採用される場所を指す文字列であってもよい。静止画の項目には、背景画像のデータ本体または該データ本体が格納されている場所を示すアドレスが格納されている。
前景画像は、例えばキャラクタの静止画(フレーム)の集合体、つまり、所定の行為を実施する動きを伴うキャラクタの動画である。前景画像の素材DBは、例えば、ID、キャラクタ名、行為、動画の各項目を含むデータ構造を有する。IDの項目には、前景画像を一意に識別する情報が格納されており、該情報は、動画のファイル名などであってもよい。キャラクタ名の項目には、前景画像が表すキャラクタの名前が格納されている。キャラクタ名に代えて、キャラクタIDが格納されていてもよい。行為の項目には、前景画像が表す、上述のキャラクタが実施している行為を説明する文字列が格納されている。該文字列は、例えば、「お菓子を食べる」、「びっくりする」、「飛び跳ねる」、「おしゃべりする」、「腕組みする」などであり、実践パートのステージ進行画面、または、練習パートのステージ進行画面900(図11の(B))において練習舞台905に出されたキャラクタに実施させる行為を指す言葉が格納されている。行為の項目には、言葉に代えて、ゲームシステム1が行為を一意に識別できるような識別情報が格納されていてもよい。動画の項目には、前景画像のデータ本体または該データ本体が格納されている場所を示すアドレスが格納されている。
以上のとおり、背景画像の素材DBには、ストーリーパート、練習パートおよび実践パートで使用されるすべての背景画像が格納されている。前景画像の素材DBには、すべてのキャラクタごとに、すべての行為ごとの動画が格納されている。進行支援部211は、ユーザ端末100のゲームの進行状況に応じて、適時に、背景画像の素材DBに基づいて必要な場所に対応する背景画像を読み出し、また、前景画像の素材DBに基づいて、必要なキャラクタの必要な行為に対応する前景画像を読み出し、背景画像と前景画像とをユーザ端末100に供給する。
本実施形態では、図11の(B)に示すとおり、練習パートの練習舞台905において、2人のキャラクタが左右に配置される。配置された位置が左か右かでキャラクタの向きが変わる。そこで、前景画像の素材DBにおいて、右配置用の前景画像を登録しておき、練習舞台905の左に配置するときには、練習パート進行部112が、該前景画像を左右反転させてもよい。あるいは、前景画像の素材DBにおいて、1つのキャラクタの1つの行為につき、右配置用の前景画像と左配置用の前景画像とが登録されていてもよい。
ストーリーパート、練習パートおよび実践パートの進行のために管理されている、上述の素材データは、以下で説明する放置パートにおいて報酬である日記データを生成するために流用されることが好ましい。これにより、放置パートのために態々新規に素材を生成せずとも、既存の資源を活用し、労力を抑えつつ、本ゲームに放置パートを導入することができる。
<放置パート>
(実行パートの処理フロー)
図12および図13は、放置パート進行部115が実行する放置パートのうち、実行パートの処理の流れを示すフローチャートである。
例えば、ユーザが、放置パートのトップ画面(不図示)が表示されている状態で、寝かしつけるキャラクタを選択するためのキャラクタ選択画面を呼び出す入力操作を行う。該入力操作に応答して、放置パート進行部115は、キャラクタ選択画面を表示部152に表示して、ステップS101からの一連の処理を開始する。
ステップS101では、放置パート進行部115は、キャラクタ選択画面を介して、第2状態に遷移させるキャラクタ、具体的には、寝かしつけるキャラクタ(以下、第1キャラクタ)を選択する入力操作(第3入力操作)を受け付ける。該入力操作に応答して、放置パート進行部115は、ステップS101のYESからステップS102に進む。
ステップS102では、放置パート進行部115は、上述の入力操作によって選択された、第1キャラクタを特定する。続いて、放置パート進行部115は、必要に応じて、ステップS103およびS104を実行してもよい。ステップS103およびS104は省略されてもよい。
ステップS103では、放置パート進行部115は、放置パートで利用可能な消費アイテムの一覧を表示し、利用する消費アイテムを指定する入力操作(第4入力操作)を受け付ける。
ステップS104では、放置パート進行部115は、上述の入力操作に応答して、指定された消費アイテムを消費する。消費アイテムは、例えば、アロマなど、キャラクタの快眠を助ける快眠グッズを模して表現されてもよい。消費された消費アイテムに応じて、第1キャラクタの起床後に付与される日記データの内容、すなわち、第1キャラクタが見る夢の内容が変化してもよい。例えば、第1キャラクタが好きな香りのアロマを使用すると、楽しい夢などポジティブな内容の夢を見る確率が上がってもよいし、特定のキャラクタの好きな香りのアロマを使用すると、該特定のキャラクタが夢に登場する確率が上がってもよい。
ステップS105では、放置パート進行部115は、ステップS102で特定された第1キャラクタの睡眠導入時の様子を表す導入画面を表示部152に表示する。
ステップS106では、放置パート進行部115は、導入画面に表示されている第1キャラクタに対するユーザの入力操作(第1入力操作)を受け付ける。この入力操作としては、例えば、第1キャラクタが表示されている入力部151の領域を、ユーザが指などでなでるようなスライド操作の繰り返しとすることが想定される。放置パート進行部115は、上述のスライド操作を所定回数検知すると、ステップS106のYESからステップS107に進む。
ステップS107では、放置パート進行部115は、検知したスライド操作に応答して、第1キャラクタを覚醒状態から睡眠状態に遷移させる。
ステップS108では、放置パート進行部115は、睡眠状態遷移時からの経過時間の計測を開始する。こうして、放置パート進行部115は、放置ゲームを、所定の時間が経過するまで、ユーザの入力操作を必要とせずに自動で進行させる。所定の時間は、例えば、8時間などが想定される。
ステップS109では、放置パート進行部115は、寝かされた第1キャラクタと消費された消費アイテムとを加味してコンテンツを生成する。なお、放置パート進行部115は、コンテンツを生成するステップS109を、ステップS107からステップS120までの任意のタイミングで実行してもよい。
ステップS110では、放置パート進行部115は、第1キャラクタが睡眠状態にあることを示す画面、すなわち、放置ゲームが進行中であることを示す実行画面(第2画面)を表示部152に表示する。放置パート進行部115は、実行画面に、所定の時間が経過するまでの残り時間を配置して、ユーザに知らせてもよい。
ステップS111では、放置パート進行部115は、ここで一旦放置パートを終了する指示を受け付けてもよい。放置パートを終了する指示をユーザから受け付けると、放置パート進行部115は、図13に示すステップS112において、再び放置パートを開始する指示を受け付けるまで、放置パートを終了する。放置パート進行部115は、ここで、放置パートを終了させても、経過時間の計測を継続し、バックグラウンドで放置ゲームを進行させる。ユーザは、所定の時間が経過するまで、別のパートをプレイしたり、本ゲーム自体を終了させて別のことをしていてもよい。放置パートを終了する指示が入力されないうちは、放置パート進行部115は、ステップS111のNOから、図13に示すステップS113に進み、所定の時間が経過するまで待機する。
ステップS112では、放置パート進行部115は、放置パートを開始する指示をユーザから受け付ける。放置パートを開始する指示をユーザから受け付けると、放置パート進行部115は、放置パートを開始し、ステップS112のYESからステップS113に進む。
ステップS113では、放置パート進行部115は、第1キャラクタが睡眠状態に遷移したときから計測していた経過時間が、所定の時間、例えば8時間、に到達したか否かを判定する。所定の時間が経過しないうちは、放置パート進行部115は、ステップS114に進み、所定の時間が経過すると、ステップS117に進む。
ステップS114では、放置パート進行部115は、実行画面を表示する。放置パート進行部115は、実行画面を介して、放置ゲームの進行を途中でキャンセルする指示を受け付けてもよい。
ステップS115では、実行画面中のキャンセルボタンが押下されるなどして、放置パート進行部115が、寝かしつけをキャンセルする入力操作(第5入力操作)をユーザから受け付けてもよい。該入力操作を受け付けると、放置パート進行部115は、ステップS115のYESからステップS116に進む。該入力操作を受け付けないうちは、放置パート進行部115は、ステップS111に戻り、放置パートの終了指示を待つか、あるいは、ステップS113に戻り、所定の時間の経過を待つ。
ステップS116では、放置パート進行部115は、所定の時間の満了を待たずに、第1キャラクタを睡眠状態から覚醒状態に復帰させる。この場合、放置パート進行部115は、日記データまたは強化アイテムなどの報酬をユーザに付与することを省略してもよいし、所定の時間の満了を待って覚醒状態に復帰させたときにもらえる報酬よりもゲーム内価値が低い報酬をユーザに付与してもよい。
ステップS117では、放置パート進行部115は、所定の時間が満了し、第1キャラクタを、睡眠状態から覚醒状態に復帰させることが可能であることを示す復帰直前画面を表示部152に表示する。復帰直前画面には、覚醒状態に復帰可能な第1キャラクタが配置されていてもよい。
ステップS118では、放置パート進行部115は、復帰直前画面を介して、第1キャラクタに対する入力操作を受け付ける。この入力操作としては、例えば、第1キャラクタが表示されている入力部151の領域を、ユーザが指などで軽くたたくようなタップ操作、または、ダブルタップ操作とすることが想定される。放置パート進行部115は、上述のタップ操作を所定回数検知すると、ステップS118のYESからステップS119に進む。
ステップS119では、放置パート進行部115は、検知したタップ操作に応答して、第1キャラクタを睡眠状態から覚醒状態へと復帰させる。
ステップS120では、放置パート進行部115は、第1キャラクタが、所定の時間を満了した上で覚醒状態に復帰したことに基づいて、ユーザに報酬を付与する。具体的には、放置パート進行部115は、日記データをユーザに付与する。放置パート進行部115は、ステップS109で生成した日記データを、ユーザ端末100の記憶部120に、任意のタイミングで閲覧可能に保存してもよい。このとき、該日記データに、付与された日時を関連付けておくことが好ましい。さらに、放置パート進行部115は、強化アイテムをユーザに付与してもよい。放置パート進行部115は、付与したばかりの日記データを、表示部152に表示してもよい。
別の実施形態では、ステップS121が実行されてもよい。ステップS121では、放置パート進行部115は、寝かしつけメータにおけるパラメータ値を所定の増分だけ加算する。寝かしつけメータに係る処理については、実施形態2で詳述する。
(放置キャラクタ情報)
図14は、放置キャラクタ情報のデータ構造の一例を示す図である。放置キャラクタ情報は、放置パートで使用されるキャラクタに関する情報である。例えば、放置キャラクタ情報は、放置パートにおいて、寝かしつけの対象となる各キャラクタの情報を含むテーブルである。放置キャラクタ情報は、本ゲームに登場するキャラクタのうち、放置パートで寝かしつけの対象となる各キャラクタの情報を含む。本ゲームに登場するすべてのキャラクタが、寝かしつけの対象であってもよい。
放置キャラクタ情報は、キャラクタID、キャラクタ名、状態の各項目を含んでいてもよい。キャラクタIDの項目には、キャラクタに一意に割り当てられているキャラクタIDが格納されている。キャラクタ名の項目には、キャラクタの名前が格納されている。キャラクタIDおよびキャラクタ名のいずれか一方は省略されてもよい。
状態の項目には、キャラクタの状態を示す状態情報(第1情報)が格納されている。キャラクタの状態は、放置パートの進行に影響を与える。状態情報は、「報酬」のサブ項目を含む。「報酬」のサブ項目には、キャラクタを寝かしつけた後、該キャラクタの覚醒時にドロップする報酬の属性を示す情報が格納されている。図示の例では、A太には、「赤」の状態情報が紐付けられている。該状態情報は、A太を寝かしつけると、覚醒時に、赤属性の強化アイテムがドロップすることを意味している。状態情報の「ランダム」は、赤・青・黄いずれかの属性の強化アイテムがランダムでドロップすることを意味している。
状態情報は、「調子」のサブ項目を含んでもよい。「調子」のサブ項目には、第1状態から第2状態への遷移のし易さ、または、第2状態にあるときの調子の良さを示す情報が格納されている。第2状態は、睡眠状態であってもよい。この場合、「調子」のサブ項目には、寝つき易さ、または、睡眠の質などを示す情報が格納されてもよい。図示の例では、状態情報の「よく眠れそう」は、キャラクタが良好な睡眠状態を保つことにより、良い夢を見る確率が高いことを示す。キャラクタが良い夢を見ると、ユーザにとって希少価値が高い内容を含む日記データが生成される。すなわち、「調子」の状態情報に基づいて、キャラクタを寝かしつけた場合に、希少価値が高い日記データが生成される確率が決定される。
放置パート進行部115は、キャラクタごとの「報酬」および「調子」のサブ項目を、定期的に、または、所定のトリガに基づいて、適時に変動させてもよい。
放置パート進行部115は、同図に示す放置キャラクタ情報を参照して、寝かしつけの対象となるキャラクタ一覧を生成し、該一覧を、ステップS101の前に、表示部152に表示する。
(日記データ)
図15の(A)は、日記データのデータ構造の一例を示す図である。日記データは、ステップS108とステップS120との間の任意のタイミングで、放置パート進行部115によって、生成される。日記データは、執筆者、日時、本文、コメント、背景画像、前景画像の各項目を含んでいてもよい。
執筆者の項目には、日記を記したキャラクタという体裁で、放置パートで睡眠状態に遷移させられたキャラクタの名前が格納される。
日時の項目には、執筆者が夢を見た日時という体裁で、該執筆者であるキャラクタが、放置パートにおいて睡眠状態から覚醒状態に復帰した日時が格納される。時間は、時分を正確に示す情報でなくとも、朝、昼、夜などのおおよその時間帯を示す情報であってもよい。
本文の項目には、執筆者が見た夢の内容を記した文章という体裁で、執筆者であるキャラクタに基づいて放置パート進行部115が生成した文章が格納される。コメントの項目には、執筆者が見た夢に対して述べた感想という体裁で、執筆者であるキャラクタに基づいて放置パート進行部115が生成した文章が格納される。これらの文章は、キャラクタに設定されているパーソナリティに応じて、該キャラクタが、ストーリーパートの物語の中で普段話すときの語り口調になるように放置パート進行部115が生成してもよい。
背景画像の項目には、執筆者が見た夢を表すイラストのうち、背景画像として採用される静止画の識別情報が格納される。例えば、ID、ファイル名または格納先を示すアドレスなどが格納される。
前景画像の項目には、執筆者が見た夢を表すイラストのうち、前景画像として採用される動画内のフレームを特定する情報が格納される。フレームは、例えば、キャラクタ名と、行為名または行為を識別する情報と、動画内の何番目のフレームかを特定する情報と、右配置用か左配置用かを特定する情報とによって一意に特定される。
図15の(B)は、希少度が高い日記データのデータ構造の一例を示す図である。放置パート進行部115は、執筆者とゆめの登場人物との特定の組み合わせ、ゆめの登場人物と行為との特定の組み合わせなどに応じて、執筆者が「レアな夢」を見たという体裁で、通常の日記データよりも内容が充実した希少度が高い日記データを生成してもよい。例えば、希少度が高い日記データにおいては、通常の日記データと比較して、コメントの内容が充実していてもよいし、イラストに使われる背景画像または前景画像として、再生回数が少なく、絵柄が豪華な画像が採用されてもよい。
(本文の素材データベース)
サーバ200の記憶部220には、さらに、日記データにおける本文を生成するためのテキストの素材DBが格納されている。素材DBとして、例えば、夢に登場するキャラクタの呼称を集積するキャラクタ呼称DBと、夢に出てくる場所の呼称を集積する場所呼称DBと、夢に登場するキャラクタが実施する行為の呼称を集積する行為呼称DBとの3つが記憶部220に格納されている。
キャラクタ呼称DBは、あるキャラクタが他のキャラクタを指し示す場合に用いる呼称を集積する。ストーリーパートでは、キャラクタとキャラクタとの間には様々関係性が設定されており、1人のキャラクタは、他のキャラクタから、呼び捨て、愛称、敬称など、様々な呼称で呼ばれている。ストーリーパートの物語で構築されたゲームの世界観を壊さないように、日記データの本文においてキャラクタを指し示す文字列として、ストーリーパートにおいて設定されている呼称が採用されることが好ましい。
キャラクタ呼称DBにおいて、呼称は、呼ぶ側のキャラクタのIDと、呼ばれる側のキャラクタのIDとに関連付けて格納されている。本実施形態では、執筆者が自身が登場する夢を見ることもあり得るとする。そこで、呼ぶ側のキャラクタのIDと、呼ばれる側のキャラクタのIDとが同じレコードには、該キャラクタが自分のことを指すときの一人称を格納すればよい。
場所呼称DBには、夢が展開されると想定されている場所の呼称が複数格納されている。場所の呼称は、背景画像と1対1で対応付けられて格納されてもよい。
行為呼称DBには、夢でキャラクタに実施させる行為として想定されている行為の呼称が複数格納されている。便宜上「呼称」としているが、行為を指す文字列は、本文における後述の定型部分「ていた。」が、文法上正しく後に続くように構成される。例えば、行為呼称DBには、「つまみ食いし」、「踊っ」、「トイレを探し」、「昨日の夜ごはんを聞い」などの文字列が格納されている。行為の呼称には、キャラクタごとに、当該キャラクタが当該行為を実施しているように見えるフレームを特定する情報が紐付けられている。例えば、行為の呼称「つまみ食いし」には、すべてのキャラクタ分の、動画「お菓子を食べる」の中の1フレームが紐付けられている。夢の中の行為がつまみ食いに決定された場合、放置パート進行部115は、登場キャラクタの動画「お菓子を食べる」の中の1フレームをイラストの前景画像をとして用いることができる。
図15に示した日記データの本文は、一例として、定型部分と非定型部分とで構成される。定型部分は、例えば、「AとBが、CでDていた。」のうちの、アルファベットの部分以外の部分を指す。定型部分は、すべての日記データの本文において、共通するである。非定型部分は、上述の各アルファベットの部分である。項目Aは、夢に登場する1人目のキャラクタに対応し、項目Bは、夢に登場する2人目のキャラクタに対応し、項目Cは、夢が展開されている場所に対応し、項目Dは、夢に登場する2人のキャラクタが実施している行為に対応している。
放置パート進行部115は、夢に登場する2人のキャラクタを、本ゲームに登場するキャラクタの中からランダムで決定してもよい。放置パート進行部115は、睡眠状態にあるキャラクタ(執筆者)に基づいて、夢に登場する2人のキャラクタのそれぞれの呼称をキャラクタ呼称DBから取得する。放置パート進行部115は、呼ぶ側である執筆者のキャラクタIDと、呼ばれる側となる夢に登場するキャラクタのキャラクタIDとに関連付けられた呼称をキャラクタ呼称DBから取得すればよい。放置パート進行部115は、取得した2つの呼称を、本文の項目Aおよび項目Bに埋める。
放置パート進行部115は、夢が展開される場所の呼称を場所呼称DBからランダムで取得し、項目Cを埋める。放置パート進行部115は、夢に登場する2人のキャラクタに実施させる行為の呼称を行為呼称DBからランダムで取得し、項目Dを埋める。これにより、放置パート進行部115は、睡眠状態にあるキャラクタに基づいて、本文を自動で生成することができる。
(コメントの素材データベース)
サーバ200の記憶部220には、さらに、日記データにおけるコメントを生成するためのテキストの素材DB(コメントDB)が格納されている。
コメントDBは、夢を見たキャラクタ本人(執筆者)が見た夢の内容に対して述べた感想という体裁の文章を集積している。コメントDBにおいて、該文章は、執筆者と該執筆者が見た夢の中で実施されていた行為との組み合わせごとに用意されていてもよい。
放置パート進行部115は、上述のようにして、本文の項目Dを埋める行為を決定したあと、寝かしつけられたキャラクタ(執筆者)と、決定した行為との組み合わせに対応付けられている文章をコメントDBから取得する。
(日記データの生成手順)
放置パート進行部115は、上述のように、執筆者に基づいて、本文における項目A〜Dを決定し、各素材DBから取得した各文字列を埋めて本文を完成させる。放置パート進行部115は、さらに、執筆者が選択されたときに関連付けられていた状態情報を加味して、項目A〜Dを決定してもよい。放置パート進行部115は、項目Cに基づいて特定される背景画像と、項目AおよびDに基づいて特定される左側に配置されるキャラクタの前景画像と、項目BおよびDに基づいて特定される右側に配置されるキャラクタの前景画像とを合成して、見た夢の内容を表すイラストを生成する。放置パート進行部115は、執筆者と項目Dとに基づいて特定されるコメントの文章をコメントDBから取得する。放置パート進行部115は、執筆者と、上述のように生成した本文と、上述のように取得したコメントと、上述のように合成したイラストとを含む日記データを生成する。放置パート進行部115は、執筆者が睡眠状態から覚醒状態に復帰したとき、上述の日記データに、さらに、該執筆者が覚醒状態に復帰した日時を紐付けて、日記データを完成させる。
(キャラクタ選択画面)
図16は、表示部152に表示されるキャラクタ選択画面の一例を示す図である。放置パート進行部115は、例えば、図示のキャラクタ選択画面400を、放置パートのトップ画面を表示した後、ステップS101を実行するまでの間に表示する。
キャラクタ選択画面400は、キャラクタリスト401をUI部品として含む。キャラクタリスト401は、放置パートで寝かしつけが可能なキャラクタを一覧でユーザに提示するとともに、寝かしつけるキャラクタを選択するための入力操作を受け付けるためのUI部品である。
キャラクタリスト401は、キャラクタと、該キャラクタの状態情報を示すアイコンとを含む。アイコン402は、図14に示す状態情報のうち、「報酬」のサブ項目に対応する。放置パート進行部115は、「報酬」のサブ項目において、赤、青、黄のいずれかの属性が設定されているキャラクタには、赤、青、黄のいずれかの属性を示すアイコン402を付す。アイコン403は、「調子」のサブ項目に対応する。放置パート進行部115は、「調子」のサブ項目において、「よく眠れそう」の調子が設定されているキャラクタには、良い夢を見る確率が高いことを示すアイコン403を付す。
放置パート進行部115は、例えば、キャラクタリスト401内のキャラクタに対するタップ操作を、寝かしつけるキャラクタを選択する入力操作(第3入力操作)として受け付ける。これにより、ユーザは、アイコン402およびアイコン403などに基づいて各キャラクタの状態を確認しながら、寝かしつけるキャラクタを選択することができる。
(導入画面)
図17の(A)は、表示部152に表示される導入画面の一例を示す図である。導入画面は、放置パートを開始するための指示をユーザが入力するための画面である。放置パート進行部115は、例えば、図示の導入画面500を、ステップS102を実行してからステップS106を実行するまでの間に表示する。
導入画面500は、キャラクタ501と、手アイコン502とをUI部品として含む。キャラクタ501は、ユーザによって選択されたキャラクタを示すUI部品である。手アイコン502は、キャラクタ501に対して作用を及ぼすオブジェクトを可視化したものであって、ユーザに対して、入力操作を促すためのUI部品である。ここでの入力操作とは、寝かしつけの対象として選択された上述のキャラクタを睡眠状態に遷移させるための入力操作(第1入力操作)である。放置パート進行部115は、例えば、手アイコン502をタッチした状態で、任意の方向に往復でスライド操作を繰り返す操作を第1入力操作として受け付ける。これにより、ユーザは、手アイコン502を操作してキャラクタ501に対して作用を及ぼし、キャラクタ501を睡眠状態に遷移させて放置パートの実行開始を指示することができる。
(実行画面)
図17の(B)は、表示部152に表示される実行画面の一例を示す図である。実行画面は、放置パートが実行され、ユーザの操作を必要とすることなく進行している間に、その進行状況をユーザに提示するための画面である。放置パート進行部115は、例えば、図の実行画面600を、ステップS110、および、ステップS114を実行するときに表示する。
実行画面600は、キャラクタ601と、進行状況602と、閲覧ボタン603と、キャンセルボタン604とをUI部品として含む。キャラクタ601は、第2状態に遷移中のキャラクタを示すUI部品である。キャラクタ601は、第1状態にあるキャラクタ501から第2状態に遷移したことが分かるように、キャラクタ501とは異なる表示態様で表示される。進行状況602は、第2状態から再び第1状態に復帰するまでの残り時間をユーザに提示するためのUI部品である。閲覧ボタン603は、ユーザが所有する日記を閲覧するための画面を呼び出すUI部品である。キャンセルボタン604は、所定の時間が満了するのを待たずに、放置パートの実行を取り止めるためのUI部品である。放置パート進行部115は、ステップS115において、キャンセルボタン604に対するタップ操作を、寝かしつけをキャンセルする入力操作(第5入力操作)として受け付ける。
所定の時間が満了した後、放置パート進行部115は、ステップS117にて、実行画面600を不図示の復帰直前画面に切り替えてもよい。復帰直前画面は、例えば、進行状況602が、残り時間の代わりに、キャラクタ601がいつでも覚醒状態に復帰できることを表した通知を提示することにより構成される。放置パート進行部115は、ステップS118にて、復帰直前画面を介してキャラクタ601に対する所定の入力操作を受け付けたことに応答して、キャラクタ601を睡眠状態から覚醒状態に復帰させる。
(閲覧パートの処理フロー)
図18は、放置パート進行部115が実行する放置パートのうち、閲覧パートの処理の流れを示すフローチャートである。
ステップS201では、放置パート進行部115は、コンテンツの一覧表示を指示する入力操作を受け付ける。例えば、図17の(B)に示す実行画面600の閲覧ボタン603に対するタップ操作を、該入力操作として受け付ける。
ステップS202では、放置パート進行部115は、コンテンツを一覧表示する一覧画面(第1画面)を表示部152に表示する。
ステップS203では、放置パート進行部115は、一覧画面を介して、閲覧するコンテンツを指定する入力操作(第2入力操作)を受け付ける。放置パート進行部115は、該入力操作を受け付けると、ステップS203のYESからステップS204に進む。
ステップS204では、放置パート進行部115は、第2入力操作によって指定されたコンテンツ、具体的は、日記データを表示部152に表示する。
ステップS205では、放置パート進行部115は、日記データと併せて、該日記データを他のアプリケーションで共有できるようにするための共有ボタンを同じ画面に表示してもよい。
ステップS206では、放置パート進行部115は、共有ボタンに対するユーザの入力操作を受け付ける。放置パート進行部115は、該入力操作を受け付けると、ステップS206のYESからステップS207に進む。
ステップS207では、放置パート進行部115は、ステップS204で表示部152に表示している日記データを、他のアプリケーションに共有させる。他のアプリケーションとしては、例えば、SNS(Social Networking Service)アプリケーション、電子メールアプリケーション、メモ帳アプリケーション、画像保管アプリケーションなどが想定される。SNSアプリケーションとしては、例えば、LINE(登録商標)などのメッセージ交換アプリケーション、Twitter(登録商標)などの短文投稿アプリケーション、および、Facebook(登録商標)などの情報共有アプリケーションなどが想定されている。これらのSNSアプリケーションに日記データを共有させることにより、ユーザは、SNSアプリケーションを活用して、自身が獲得した日記データを他のユーザに広く公開することができる。さらに、他のアプリケーションとしては、WiFi(登録商標)、Bluetooth(登録商標)または赤外線などを使用した無線通信アプリケーションが想定される。これにより、ユーザは、近距離通信が可能な間柄の他のユーザと、日記データを共有することができる。
(日記データベース)
図19は、日記データベース(以下、日記DB)のデータ構造の一例を示す図である。日記DBは、ユーザが所有する日記データを管理するためのものであり、ユーザがごとに生成される。日記DBは、ユーザ端末100の記憶部120およびサーバ200の記憶部220に記憶されており、ユーザ端末100とサーバ200との間で共有されている。
日記DBは、日時、執筆者、お気に入り、今月、先月、日記データの各項目を含んでいてもよい。日時の項目では、図15に示す日記データに関連付けられている日時が参照される。執筆者の項目では、図15に示す日記データに関連付けられている執筆者が参照される。
お気に入りの項目には、該日記データがユーザによってお気に入りに指定されているか否かを示すフラグが格納されている。本実施形態では、日記データは、該日記データが付与された月の翌々月の末日まで保存され、この閲覧期限を過ぎると該日記DBから抹消されるものとする。しかし、ユーザがお気に入りに指定した日記データは、例えば、最大30個まで、閲覧期限を無視して日記DBに保存できるものとする。該項目の「1」は、ユーザが、該日記データをお気に入りに指定していることを指し、「0」は、ユーザが、該日記をお気に入りに指定していないことを指す。放置パート進行部115は、閲覧期限を過ぎると、該項目が「0」の日記データを日記DBから抹消する。
今月の項目には、該日記データが今月に付与されたものであるか否かを示すフラグが格納されている。先月の項目には、該日記データが先月に付与されたものであるか否かを示すフラグが格納されている。
例えば、今月が「2019年3月」である場合、2019年3月にユーザに付与された日記データの該項目には、「1」が格納され、それ以外の年月に付与された日記データの該項目には「0」が格納される。放置パート進行部115は、現在時刻が次月、例えば、「4月」に移行すると、2019年3月にユーザに付与された日記データの今月の項目を、「1」から「0」に更新し、先月の項目を「0」から「1」に更新する。放置パート進行部115は、現在時刻が次々月、例えば、「5月」に移行すると、2019年3月にユーザに付与された日記データを、閲覧期限が到来したことに伴い、お気に入りに指定された日記データを除き、日記DBから抹消する。
日記データの項目には、日記データのデータ本体(図15)または該データ本体が格納されている場所を示すアドレスが格納されている。
放置パート進行部115は、日記DBを以上のようにして管理し、一覧画面が呼び出された場合には、常に最新の日記DBに基づいて、一覧画面を生成する。一覧画面から日記データが指定された場合には、指定された日記データを、上述のアドレスから読み出して、表示部152に表示する。
(一覧画面)
図20の(A)は、表示部152に表示される一覧画面の一例を示す図である。放置パート進行部115は、例えば、図示の一覧画面700を、ステップS202を実行するときに表示する。
一覧画面700は、タブ701〜703と、日記リスト704とをUI部品として含む。日記データは、例えば、「お気に入り」、「先月」および「今月」の3つのグループに分類される。タブ701は、お気に入りに分類されている日記データの日記リスト704を呼び出すためのUI部品である。タブ702は、先月のグループに分類されている日記データの日記リスト704を呼び出すためのUI部品である。タブ703は、今月のグループに分類されている日記データの日記リスト704を呼び出すためのUI部品である。図示の例では、今月の日記データの一覧が表示されているが、ユーザは、お気に入りに登録した日記データの日記リストに切り替えたい場合は、タブ701を、先月の日記データの日記リストに切り替えたい場合は、タブ702を、それぞれ、タップすればよい。
日記リスト704は、日記アイコン705と閲覧期限706とをUI部品として含んでいてもよい。日記アイコン705は、1つの日記データに対応するアイコンである。日記アイコン705は、執筆者、日時、および、お気に入りに登録されている日記データか否かを示すお気に入りアイコン707を含んでいてもよい。閲覧期限706は、グループ内の各日記データの閲覧期限をユーザに通知するためのUI部品である。ユーザは、日記アイコン705に含まれている情報を確認して、閲覧したい日記データを探し、所望の日記データの日記アイコン705に対して閲覧を指示する入力操作(第2入力操作)を行うことができる。放置パート進行部115は、第2入力操作を受け付けて、操作された日記アイコン705に対応する日記データを、後述する図20の(B)のように表示部152に表示する。
(日記画面)
図20の(B)は、表示部152に表示される日記画面の一例を示す図である。放置パート進行部115は、例えば、図示の日記画面800を、ステップS204を実行するときに表示する。
日記画面800は、日記データ801と、共有ボタン802と、管理ボタン803とをUI部品として含む。日記データ801は、1つの日記データをユーザに提示するためのものであり、UI部品として、日付804、執筆者805、本文806、コメント807、および、イラスト808を含む。これらのUI部品は、図15に示す日記データを構成する各項目に基づいて生成される。
共有ボタン802は、日記データを他のアプリケーションに共有させることを指示するためのUI部品である。ユーザは、共有ボタン802をタップすることにより、例えば、SNSアプリケーションに、日記画面800に表示されている日記データ801の静止画データを共有させることができる。
管理ボタン803は、日記データのお気に入りの登録と解除とを指示するためのUI部品である。ユーザは、お気に入りに登録されている日記データ801が表示されている間に、管理ボタン803をタップすることにより、該日記データ801のお気に入りの設定を解除することができる。反対に、ユーザは、お気に入りに登録されている日記データ801が表示されている間に管理ボタン803をタップして、該日記データ801をお気に入りに登録することができる。
以上のように、ユーザは、付与された日記データを、一覧画面700および日記画面800を介して、いつでも閲覧し、楽しむことができる。
〔実施形態2〕
本実施形態では、ゲームシステム1において、ユーザごとに、寝かしつけメータが管理されていてもよい。寝かしつけメータは、ユーザが、放置パートをどれだけプレイしたかを管理するためのパラメータであり、ユーザがキャラクタを所定の時間寝かしつけて日記データを取得する度に、パラメータ値が加算されるものである。放置パート進行部115は、キャラクタが所定の時間寝かしつけられる度に、ステップS121にて、寝かしつけメータのパラメータ値を加算する。蓄積されたパラメータ値は、ゲーム内価値を有する他のゲーム媒体、例えば、抽選チケットと交換が可能である。
パラメータ値と交換できる抽選チケットには、グレードに応じていくつかの種類があってもよい。交換するパラメータ値が大きいほど、グレードの高い抽選チケットと交換できるものとする。グレードが高い抽選チケットほど、希少価値がより高いカードがより当選しやすい母集団が紐付けられている。グレードが高い抽選チケットに基づいて抽選が実行された場合、グレードが低い抽選チケットと比較して希少価値が高いカードが当選しやすく、したがって、グレードが高い抽選チケットほどゲーム内価値が高い。
抽選チケットは、例えば、7段階のグレードに対応して7種類ある。希少度Nのカードからなる母集団が紐付けられた第1抽選チケット、希少度Nおよび希少度Rのカードからなる母集団が紐付けられた第2抽選チケット、希少度Rのカードからなる母集団が紐付けられた第3抽選チケット、希少度Rおよび希少度SRのカードからなる母集団が紐付けられた第4抽選チケット、希少度SRのカードからなる母集団が紐付けられた第5抽選チケット、希少度SRおよび希少度SSRのカードからなる母集団が紐付けられた第6抽選チケット、希少度SSRのカードからなる母集団が紐付けられた第7抽選チケットの7種類である。つまり、第7抽選チケットが使用されると、希少度SSRのカードが100%当選するので、第7抽選チケットは、ユーザにとって最もゲーム内価値が高い抽選チケットとなる。
例えば、寝かしつけメータは、0〜700点の値を蓄積できるものとし、100点で第1抽選チケット、200点で第2抽選チケット、以降、交換する値が100点増えるごとに1段階上のグレードの抽選チケットと交換が可能であり、700点満点で、最もグレードが高い第7抽選チケットとの効果が可能となる。値との交換により、抽選チケットが付与されると、寝かしつけメータのパラメータ値はリセットされて、0からカウントが再開される。ユーザは、希少度が高いカードが当選しにくいが、早く手に入るグレードが低めの抽選チケットを使ってたくさんの回数の抽選に興じてもよいし、希少度が高いカードが当選しやすいが、手に入りにくいグレードが高めの抽選チケットを使って、少ないチャンスで、希少度が高いカードを狙う抽選に興じてもよい。
さらに、寝かしつけメータのパラメータ値の上昇量が異なる複数のコースを設定し、ユーザに所望のコースを選択させてから、放置パートをプレイさせてもよい。複数のコースとしては、例えば、2か月程度で寝かしつけメータを700点満点にできる2か月コースと、3か月程度で寝かしつけメータを700点満点にできる3か月コースと、半年程度で寝かしつけメータを700点満点にできる半年コースとが想定されてもよい。
放置パート進行部115は、ユーザによって予め選択されたコースに応じて、寝かしつけ1回につき加算するパラメータ値を決定する。期間が長いコースほど、ゲーム内価値が高い報酬と交換できるようにすることが好ましい。例えば、3か月コースで貯められた700点と交換される報酬よりも、半年コースで貯められた700点と交換される報酬の方がゲーム内価値が高くなるように報酬を定めればよい。
〔変形例〕
放置パート進行部115は、ステップS114において、第2状態にある第1キャラクタと、該第1キャラクタが復帰したことに応じて付与される予定のコンテンツの一部とを示す第2画面を表示してもよい。具体的には、放置パート進行部115は、実行画面600において、キャラクタ601が見ている夢の内容の一部を表示してもよい。例えば、放置パート進行部115は、キャラクタ601が見ている夢に登場する2人のキャラクタのアイコンを実行画面600に表示してもよい。ユーザは、2人のキャラクタが目当てのキャラクタでない場合には、キャンセルボタン604を操作して、寝かしつけを中止し、放置パートを最初からやり直すことができる。
ステップS104で使用できる消費アイテムとして、睡眠状態を維持する所定の期間を短縮できる、いわゆる、時短アイテムがあってもよい。例えば、ステップS104で、時短アイテムが使用された場合には、通常、覚醒状態に復帰するまで8時間を要するところ、3時間に短縮されてもよい。
放置パート進行部115は、キャラクタを睡眠状態に維持する所定の時間を、複数の中からユーザに選ばせてもよい。例えば、1時間、3時間、8時間の中からユーザに選ばせる。放置パート進行部115は、選ばれた所定の時間が長いほど、ユーザに付与する報酬のゲーム内価値を高くしたり、ゲーム内価値が高い報酬がドロップする確率を上げたりしてもよい。
放置パート進行部115は、所定の時間を満了せずにキャラクタを覚醒状態に復帰させたとき、つまり、ユーザが、キャンセルボタン604を押下して放置パートを中止したとき、報酬を全く付与しなくてもよいし、中止されるまでの進捗に応じて報酬を部分的に付与してもよい。例えば、途中でキャンセルされた場合には、放置パート進行部115は、日記データは付与せず、強化アイテムだけをユーザに付与してもよいし、ユーザに付与する強化アイテムの数量を減らしてもよい。
〔ソフトウェアによる実現例〕
制御部210の制御ブロック(特に、進行支援部211)、ならびに、制御部110の制御ブロック(特に、ストーリーパート進行部111、練習パート進行部112、実践パート進行部113、抽選パート進行部114、および、放置パート進行部115)は、集積回路(ICチップ)等に形成された論理回路(ハードウェア)によって実現してもよいし、CPU(Central Processing Unit)を用いてソフトウェアによって実現してもよい。
後者の場合、制御部210または制御部110、もしくはその両方の機能を備えた情報処理装置は、各機能を実現するソフトウェアであるプログラムの命令を実行するCPU、上記プログラムおよび各種データがコンピュータ(またはCPU)で読み取り可能に記録されたROM(Read Only Memory)または記憶装置(これらを「記録媒体」と称する)、上記プログラムを展開するRAM(Random Access Memory)などを備えている。そして、コンピュータ(またはCPU)が上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記記録媒体としては、「一時的でない有形の媒体」、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムは、該プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して上記コンピュータに供給されてもよい。なお、本発明の一態様は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
〔付記事項〕
本発明の一側面に係る内容を列記すると以下のとおりである。
(項目1) ゲームプログラム(131、231)について説明した。本開示のある局面によると、ゲームプログラムは、プロセッサ(10、20)およびメモリ(11、21)を備えるコンピュータ(ユーザ端末100およびサーバ200の少なくとも一方)により実行される。ゲームプログラムは、プロセッサに、ゲームプログラムに基づくゲームに登場する複数のキャラクタのうちの少なくとも1つの第1キャラクタに対する、ユーザの第1入力操作に応じて、該第1キャラクタを第1状態から第2状態へ遷移させるステップ(S107)と、第1キャラクタが第2状態に遷移してから、所定の時間が経過したことに応じて、第1キャラクタを第1状態に復帰させるステップ(S119)と、第1キャラクタが第1状態に復帰したことに応じて、第2状態であった第1キャラクタに基づくコンテンツ(日記データ)をユーザに付与するステップ(S120)と、ユーザの第2入力操作に応じて、指定されたコンテンツを表示部に表示するステップ(S204)と、を実行させる。
(項目2) (項目1)において、遷移させるステップでは、第1入力操作に応じて、第1キャラクタを、ユーザの操作によらずに進行する、ゲーム内の第1パート(放置パート)が進行していない第1状態(覚醒状態)から、第1パートが進行している第2状態(睡眠状態)へと遷移させ、復帰させるステップでは、第1パートが進行してから、所定の時間が経過したことに応じて、該第1パートを終了させてもよい。
(項目3) (項目1)または(項目2)において、コンテンツを付与するステップでは、第1キャラクタが、第2状態であった間に体験した出来事という体裁で、該出来事を表現したコンテンツをユーザに付与してもよい。
(項目4) (項目1)から(項目3)までのいずれか1項目において、複数のキャラクタのそれぞれには該キャラクタの状態を示す第1情報(状態情報)が関連付けられており、ゲームプログラムは、プロセッサに、ユーザの第3入力操作に応じて、複数のキャラクタの中から、第2状態へ遷移させる第1キャラクタを特定するステップと、第3入力操作に応じて特定された第1キャラクタと、第1キャラクタに関連付けられている第1情報とに基づいて、ユーザに付与するコンテンツを生成するステップとを実行させてもよい。
(項目5) (項目4)において、メモリにおいて、キャラクタが居る所定の場所を表す複数の第1の素材データと、所定の行為を実施するキャラクタを表す複数の第2の素材データとが記憶されており、ゲームプログラムは、プロセッサに、第1の素材データ、および、第2の素材データの少なくともいずれか一方を用いて、第2パート(ストーリーパート、練習パート、実践パート)を進行させるステップを実行させ、コンテンツを生成するステップでは、第1キャラクタと第1情報とに基づいて選択されたメモリに記憶されている1以上の素材データを用いて、コンテンツを生成してもよい。
(項目6) (項目4)または(項目5)において、ゲームプログラムは、プロセッサに、SNSアプリケーションを介してコンテンツを公開することを指示するためのUI部品(共有ボタン)を表示するステップ(S205)を実行させてもよい。
(項目7) (項目1)から(項目6)までのいずれか1項目において、ゲームプログラムは、プロセッサに、第1キャラクタが所定の時間が満了したことに伴って第2状態から第1状態に復帰した場合に、ユーザに関連付けられたパラメータにおけるパラメータ値を加算するステップ(S121)と、パラメータが示すパラメータ値と引き換えに、引き換えるパラメータ値が大きいほど、ゲームにおいて価値が高い報酬を付与するステップとを実行させてもよい。
(項目8) (項目7)において、報酬を付与するステップは、報酬として、キャラクタが紐付けられたカードを選択する抽選処理を実施するために必要な抽選アイテム(抽選チケット)をユーザに付与するステップであって、該報酬を付与するステップでは、引き換えるパラメータ値が大きいほど、希少価値がより高いカードがより当選しやすい母集団が紐付けられた抽選アイテムを付与し、ゲームプログラムは、プロセッサに、ユーザが所有する抽選アイテムと引き換えに、該抽選アイテムに紐付けられた母集団から選択されたカードを、該ユーザに付与するステップを実行させてもよい。
(項目9) (項目7)または(項目8)において、パラメータは、パラメータ値の上昇量に応じて複数種類あり、複数種類の中の1つのパラメータがユーザに関連付けられており、加算するステップでは、ユーザに関連付けられたパラメータのパラメータ値を、該パラメータに設定されている上昇量に基づいて加算し、報酬を付与するステップでは、ユーザに関連付けられているパラメータの上昇量が小さいほど、該パラメータが示すパラメータ値と引き換えにユーザに付与する報酬の価値を高くしてもよい。
(項目10) (項目1)から(項目9)までのいずれか1項目において、コンテンツを付与するステップでは、コンテンツに、該コンテンツをユーザに付与した日付を関連付けてメモリに保存し、ゲームプログラムは、プロセッサに、メモリに保存された複数のコンテンツを、日付ごとに一覧表示する第1画面(一覧画面700)を表示するステップ(S202)と、第1画面に一覧表示されたコンテンツに対するユーザの入力操作を、該コンテンツを指定する第2入力操作として受け付けるステップ(S203)と、を実行させてもよい。
(項目11) (項目4)において、ゲームプログラムは、プロセッサに、ユーザの第4入力操作に応じて、該ユーザが所有する消費アイテムのうち、該第4入力操作によって指定された消費アイテム(快眠グッズ)を消費するステップ(S104)を実行させ、コンテンツを生成するステップでは、第1キャラクタと、該第1キャラクタに関連付けられている第1情報と、消費された消費アイテムとに基づいて、ユーザに付与するコンテンツを生成してもよい。
(項目12) (項目1)から(項目11)までのいずれか1項目において、ゲームプログラムは、プロセッサに、第2状態にある第1キャラクタと、該第1キャラクタが復帰したことに応じて付与される予定のコンテンツの一部とを示す第2画面(実行画面600)を表示するステップ(S114)と、第2画面に対する、ユーザの第5入力操作に応じて、該第1キャラクタを、所定の時間が経過する前に第1状態に復帰させるステップと、を実行させてもよい。
(項目13) ゲームプログラムを実行する方法を説明した。本開示のある局面によると、ゲームプログラムは、プロセッサおよびメモリを備えるコンピュータにより実行される。該方法は、プロセッサが(項目1)に記載の各ステップを実行する方法である。(項目13)に係る方法は、(項目1)に係るゲームプログラムと同様の作用効果を奏する。
(項目14) 情報処理装置を説明した。本開示のある局面によると、該情報処理装置は、(項目1)に係るゲームプログラムを記憶するメモリ(メモリ11、記憶部120)と、該ゲームプログラムを実行することにより、情報処理装置(ユーザ端末100)の動作を制御するプロセッサ(プロセッサ10、制御部110)とを備える。(項目14)に係る情報処理装置は、(項目1)に係るゲームプログラムと同様の作用効果を奏する。