〔実施形態〕
本開示に係るゲームシステムは、複数のユーザにゲームを提供するためのシステムである。以下、ゲームシステムについて図面を参照しつつ説明する。なお、本発明はこれらの例示に限定されるものではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が本発明に含まれることが意図される。以下の説明では、図面の説明において同一の要素には同一の符号を付し、重複する説明を繰り返さない。
<ゲームシステム1の概要>
ゲームシステム1は、第1イベントを実行することを含むゲームを実行するシステムである。本実施形態では、第1イベントは、ゲームの第1パートで実行されるものとする。ただし、第1イベントは、ゲームの第1パートで実行されるものに限られない。また、ゲームシステム1によって実行されるゲームは、第1イベントを実行することを含むゲームであればよく、必ずしも第1パートを含むものに限られない。
第1パートは、複数のキャラクタによって構成されるグループを用いて進行するパートである。本実施形態では、第1パートは、第1イベントを構成する要素の選択、第1パートで用いられるグループの編成、グループからの2以上のメインキャラクタの選択、第1イベントの実行、及び、第1パートの進行結果の提示を含んで構成される。ただし、第1パートは、少なくとも第1イベントの実行を含んでいればよく、上述した構成に限られない。ここでは、第1イベントが、グループによる特別な内容の演奏会(以降、ライブと記載する)である例について説明する。演奏会としては、後述するミュージックビデオの画像や映像が挙げられる。特別な内容とは、グループから選択された2以上のキャラクタに応じた内容である。従って、特別な内容の演奏会の一例としては、グループから選択された2以上のキャラクタの友好関係に応じたミュージックビデオの画像や映像が挙げられる。また、第1イベントで用いられるグループの編成は、デッキの編成である例について説明する。つまり、ユーザは、自身が所有する、キャラクタに見立てた仮想のカードの中から、複数のカードを選択して、第1イベントで用いられるデッキを編成する。また、第1イベントを構成する要素が、ライブで上演される曲を表すミュージックビデオである例について説明する。また、第1パートが、ミュージックビデオとして再生される曲のリズムに合わせて操作を行う音楽ゲームである例について説明する。この場合、第1パートは、ライブを構成する曲の選択、ライブを行うグループの編成、グループから2以上のメインキャラクタの選択、ライブの実行、及び、音楽ゲームの結果の提示を含んで構成される。ただし、第1イベントは、特別な内容のライブに限られない。また、第1イベントを構成する要素は、ミュージックビデオに限られない。また、第1パートは、音楽ゲームに限られない。
また、ゲームシステム1によって実行されるゲームは、第2パートを含んでいてもよい。第2パートは、ゲームにおいて利用可能な複数のキャラクタのうち2以上のキャラクタの組み合わせについて、第2イベントを実行することにより、当該2以上のキャラクタ間の第1パラメータを更新するパートである。第1パラメータについては後述する。第2イベントは、2以上のキャラクタ間の第1パラメータを更新するためのイベントを表す。例えば、第2イベントは、ライブの準備を行うイベント、キャラクタ間の友好度を深めるイベント等であってもよい。ただし、第2イベントは、これらの例に限られない。
本実施形態では、第2パートは、2以上のキャラクタの選択、第2イベントの実行、第1パラメータの更新、及び、第2パートの進行結果の提示を含んで構成される。ただし、第2パートは、少なくとも第2イベントの実行及び第1パラメータの更新を含んでいればよく、上述した構成に限られない。なお、ゲームシステム1によって実行されるゲームは、必ずしも第2パートを含んでいなくてもよい。
<ゲームシステム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が備えるこれらの構成は、通信バスによって互いに電気的に接続される。また、図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の協働により実現するためのゲームプログラムであってもよい。また、各種データとは、ユーザ情報およびゲーム情報などのゲームに関するデータ、ならびに、ユーザ端末100とサーバ200との間または複数のユーザ端末100間で送受信する指示または通知を含んでいる。
ストレージ12および22は補助記憶装置である。ストレージ12および22は、フラッシュメモリまたはHDD(Hard Disk Drive)等の記憶装置で構成される。ストレージ12およびストレージ22には、ゲームに関する各種データが格納される。
通信IF13は、ユーザ端末100における各種データの送受信を制御する。通信IF23は、サーバ200における各種データの送受信を制御する。通信IF13および23は例えば、無線LAN(Local Area Network)を介する通信、有線LAN、無線LAN、または携帯電話回線網を介したインターネット通信、ならびに近距離無線通信等を用いた通信を制御する。
入出力IF14は、ユーザ端末100がデータの入力を受け付けるためのインターフェースであり、またユーザ端末100がデータを出力するためのインターフェースである。入出力IF14は、USB(Universal Serial Bus)等を介してデータの入出力を行ってもよい。入出力IF14は、例えば、ユーザ端末100の物理ボタン、カメラ、マイク、または、スピーカ等を含み得る。サーバ200の入出力IF24は、サーバ200がデータの入力を受け付けるためのインターフェースであり、またサーバ200がデータを出力するためのインターフェースである。入出力IF24は、例えば、マウスまたはキーボード等の情報入力機器である入力部と、画像を表示出力する機器である表示部とを含み得る。
ユーザ端末100のタッチスクリーン15は、入力部151と表示部152とを組み合わせた電子部品である。入力部151は、例えばタッチセンシティブなデバイスであり、例えばタッチパッドによって構成される。表示部152は、例えば液晶ディスプレイ、または有機EL(Electro-Luminescence)ディスプレイ等によって構成される。
入力部151は、入力面に対しユーザの操作(主にタッチ操作、スライド操作、スワイプ操作、およびタップ操作等の物理的接触操作)が入力された位置を検知して、位置を示す情報を入力信号として送信する機能を備える。入力部151は、図示しないタッチセンシング部を備えていればよい。タッチセンシング部は、静電容量方式または抵抗膜方式等のどのような方式を採用したものであってもよい。
図示していないが、ユーザ端末100は、該ユーザ端末100の保持姿勢を特定するための1以上のセンサを備えていてもよい。このセンサは、例えば、加速度センサ、または、角速度センサ等であってもよい。ユーザ端末100がセンサを備えている場合、プロセッサ10は、センサの出力からユーザ端末100の保持姿勢を特定して、保持姿勢に応じた処理を行うことも可能になる。例えば、プロセッサ10は、ユーザ端末100が縦向きに保持されているときには、縦長の画像を表示部152に表示させる縦画面表示としてもよい。一方、ユーザ端末100が横向きに保持されているときには、横長の画像を表示部に表示させる横画面表示としてもよい。このように、プロセッサ10は、ユーザ端末100の保持姿勢に応じて縦画面表示と横画面表示とを切り替え可能であってもよい。
カメラ17は、イメージセンサ等を含み、レンズから入射する入射光を電気信号に変換することで撮影画像を生成する。
測距センサ18は、測定対象物までの距離を測定するセンサである。測距センサ18は、例えば、パルス変換した光を発する光源と、光を受ける受光素子とを含む。測距センサ18は、光源からの発光タイミングと、該光源から発せられた光が測定対象物にあたって反射されて生じる反射光の受光タイミングとにより、測定対象物までの距離を測定する。測距センサ18は、指向性を有する光を発する光源を有することとしてもよい。
ここで、ユーザ端末100が、カメラ17と測距センサ18とを用いて、ユーザ端末100の近傍の物体1010を検出した検出結果を、ユーザの入力操作として受け付ける例をさらに説明する。カメラ17および測距センサ18は、例えば、ユーザ端末100の筐体の側面に設けられてもよい。カメラ17の近傍に測距センサ18が設けられてもよい。カメラ17としては、例えば赤外線カメラを用いることができる。この場合、赤外線を照射する照明装置および可視光を遮断するフィルタ等が、カメラ17に設けられてもよい。これにより、屋外か屋内かにかかわらず、カメラ17の撮影画像に基づく物体の検出精度をいっそう向上させることができる。
プロセッサ10は、カメラ17の撮影画像に対して、例えば以下の(1)〜(5)に示す処理のうち1つ以上の処理を行ってもよい。(1)プロセッサ10は、カメラ17の撮影画像に対し画像認識処理を行うことで、該撮影画像にユーザの手が含まれているか否かを特定する。プロセッサ10は、上述の画像認識処理において採用する解析技術として、例えばパターンマッチング等の技術を用いてよい。(2)また、プロセッサ10は、ユーザの手の形状から、ユーザのジェスチャを検出する。プロセッサ10は、例えば、撮影画像から検出されるユーザの手の形状から、ユーザの指の本数(伸びている指の本数)を特定する。プロセッサ10はさらに、特定した指の本数から、ユーザが行ったジェスチャを特定する。例えば、プロセッサ10は、指の本数が5本である場合、ユーザが「パー」のジェスチャを行ったと判定する。また、プロセッサ10は、指の本数が0本である(指が検出されなかった)場合、ユーザが「グー」のジェスチャを行ったと判定する。また、プロセッサ10は、指の本数が2本である場合、ユーザが「チョキ」のジェスチャを行ったと判定する。(3)プロセッサ10は、カメラ17の撮影画像に対し、画像認識処理を行うことにより、ユーザの指が人差し指のみ立てた状態であるか、ユーザの指がはじくような動きをしたかを検出する。(4)プロセッサ10は、カメラ17の撮影画像の画像認識結果、および、測距センサ18の出力値等の少なくともいずれか1つに基づいて、ユーザ端末100の近傍の物体1010(ユーザの手など)とユーザ端末100との距離を検出する。例えば、プロセッサ10は、カメラ17の撮影画像から特定されるユーザの手の形状の大小により、ユーザの手がユーザ端末100の近傍(例えば所定値未満の距離)にあるのか、遠く(例えば所定値以上の距離)にあるのかを検出する。なお、撮影画像が動画の場合、プロセッサ10は、ユーザの手がユーザ端末100に接近しているのか遠ざかっているのかを検出してもよい。(5)カメラ17の撮影画像の画像認識結果等に基づいて、ユーザの手が検出されている状態で、ユーザ端末100とユーザの手との距離が変化していることが判明した場合、プロセッサ10は、ユーザが手をカメラ17の撮影方向において振っていると認識する。カメラ17の撮影範囲よりも指向性が強い測距センサ18において、物体が検出されたりされなかったりする場合に、プロセッサ10は、ユーザが手をカメラの撮影方向に直交する方向に振っていると認識する。
このように、プロセッサ10は、カメラ17の撮影画像に対する画像認識により、ユーザが手を握りこんでいるか否か(「グー」のジェスチャであるか、それ以外のジェスチャ(例えば「パー」)であるか)を検出する。また、プロセッサ10は、ユーザの手の形状とともに、ユーザがこの手をどのように移動させているかを検出する。また、プロセッサ10は、ユーザがこの手をユーザ端末100に対して接近させているのか遠ざけているのかを検出する。このような操作は、例えば、マウスまたはタッチパネルなどのポインティングデバイスを用いた操作に対応させることができる。ユーザ端末100は、例えば、ユーザの手の移動に応じて、タッチスクリーン15においてポインタを移動させ、ユーザのジェスチャ「グー」を検出する。この場合、ユーザ端末100は、ユーザが選択操作を継続中であると認識する。選択操作の継続とは、例えば、マウスがクリックされて押し込まれた状態が維持されること、または、タッチパネルに対してタッチダウン操作がなされた後タッチされた状態が維持されることに対応する。また、ユーザ端末100は、ユーザのジェスチャ「グー」が検出されている状態で、さらにユーザが手を移動させると、このような一連のジェスチャを、スワイプ操作(またはドラッグ操作)に対応する操作として認識することもできる。また、ユーザ端末100は、カメラ17の撮影画像によるユーザの手の検出結果に基づいて、ユーザが指をはじくようなジェスチャを検出した場合に、当該ジェスチャを、マウスのクリックまたはタッチパネルへのタップ操作に対応する操作として認識してもよい。
<ゲームシステム1の機能的構成>
図2は、ゲームシステム1に含まれるサーバ200およびユーザ端末100の機能的構成を示すブロック図である。サーバ200およびユーザ端末100のそれぞれは、図示しない、一般的なコンピュータとして機能する場合に必要な機能的構成、および、ゲームにおける公知の機能を実現するために必要な機能的構成を含み得る。
ユーザ端末100は、ユーザの入力操作を受け付ける入力装置としての機能と、ゲームの画像や音声を出力する出力装置としての機能を有する。ユーザ端末100は、プロセッサ10、メモリ11、ストレージ12、通信IF13、および入出力IF14等の協働によって、制御部110および記憶部130として機能する。
サーバ200は、各ユーザ端末100と通信して、ユーザ端末100がゲームを進行させるのを支援する機能を有する。例えば、有価データの販売、サービスの提供などを実行する。ゲームがマルチプレイゲームである場合には、サーバ200は、ゲームに参加する各ユーザ端末100と通信して、ユーザ端末100同士のやりとりを仲介する機能を有していてもよい。サーバ200は、プロセッサ20、メモリ21、ストレージ22、通信IF23、および入出力IF24等の協働によって、制御部210および記憶部230として機能する。
記憶部130および記憶部230は、ゲームプログラム131、ゲーム情報132およびユーザ情報133を格納する。ゲームプログラム131は、ユーザ端末100およびサーバ200で実行するゲームプログラムである。ゲーム情報132は、制御部110および制御部210がゲームプログラム131を実行する際に参照するデータである。ユーザ情報133は、ユーザのアカウントに関するデータである。記憶部230において、ゲーム情報132およびユーザ情報133は、ユーザ端末100ごとに格納されている。
(サーバ200の機能的構成)
制御部210は、記憶部230に格納されたゲームプログラム131を実行することにより、サーバ200を統括的に制御する。例えば、制御部210は、ユーザ端末100に各種データおよびプログラム等を送信する。制御部210は、ゲーム情報もしくはユーザ情報の一部または全部をユーザ端末100から受信する。ゲームがマルチプレイゲームである場合には、制御部210は、ユーザ端末100からマルチプレイの同期の要求を受信して、同期のためのデータをユーザ端末100に送信してもよい。
制御部210は、ゲームプログラム131の記述に応じて、送受信部211、サーバ処理部213、及びデータ管理部212として機能する。制御部210は、実行するゲームの性質に応じて、ユーザ端末100におけるゲームの進行を支援するために、図示しないその他の機能ブロックとしても機能することができる。
送受信部211は、各種データを送受信する。例えば、送受信部211は、ユーザ端末100からの各種データおよびプログラムの送信要求、マルチプレイの同期の要求、および同期のためのデータ等を受信し、サーバ処理部213に送る。また例えば、送受信部211は、サーバ処理部213からの指示に従って、ユーザ端末100に各種データおよびプログラムを送信する。
サーバ処理部213は、ゲームを提供するために必要な演算処理を行う。サーバ処理部213は、ユーザ端末100からの要求等に応じて、ゲームプログラム221に記述された演算処理を実行する。また例えば、サーバ処理部213は、ゲームの進行に係る各種判定処理を行う。
例えば、サーバ処理部213は、データ管理部212にゲーム情報122またはユーザ情報123の追加、更新、または削除を指示する。また例えば、サーバ処理部213は送受信部211に、各種データまたはプログラムの送信を指示する。
データ管理部212は、記憶部230に格納されている各種データをサーバ処理部213の指示に従って管理する。例えば、データ管理部212は、サーバ処理部213からの指示に応じてゲーム情報122またはユーザ情報123を、追加、更新、または削除する。
また例えば、データ管理部212は、サーバ処理部213からの指示に従って、ゲーム情報222およびユーザ情報223の少なくとも一方を記憶部230から読み出し、送受信部211を介しユーザ端末100に送信する。
また例えば、データ管理部212は、サーバ処理部213からの指示に従って、ゲームプログラム121のうち、ユーザ端末100で実行する分のプログラムを記憶部230から読み出し、送受信部211を介しユーザ端末100に送信する。
(ユーザ端末100の機能的構成)
制御部110は、記憶部130に格納されたゲームプログラム131を実行することにより、ユーザ端末100を統括的に制御する。例えば、制御部110は、ゲームプログラム131およびユーザの操作にしたがって、ゲームを進行させる。また、制御部110は、ゲームを進行させている間、必要に応じて、サーバ200と通信して、情報の送受信を行う。
制御部110は、ゲームプログラム131の記述に応じて、操作受付部111、表示制御部112、ユーザインタフェース(以下、UIと記載する)制御部113、アニメーション生成部114、要素選択部115、グループ編成部116、第1パート進行部117、及び第2パート進行部118として機能する。制御部110は、実行するゲームの性質に応じて、ゲームを進行させるために、図示しないその他の機能ブロックとしても機能することができる。
操作受付部111は、入力部151に対するユーザの入力操作を検知し受け付ける。操作受付部111は、タッチスクリーン15およびその他の入出力IF14を介したコンソールに対してユーザが及ぼした作用から、いかなる入力操作がなされたかを判別し、その結果を制御部110の各要素に出力する。
例えば、操作受付部111は、入力部151に対する入力操作を受け付け、該入力操作の入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部111は、入力操作の種類として、例えばタッチ操作、スライド操作、スワイプ操作、およびタップ操作等を特定する。また、操作受付部111は、連続して検知されていた入力が途切れると、タッチスクリーン15から接触入力が解除されたことを検知する。
UI制御部113は、UIを構築するために表示部152に表示させるUIオブジェクトを制御する。UIオブジェクトは、ユーザが、ゲームの進行上必要な入力をユーザ端末100に対して行うためのツール、または、ゲームの進行中に出力される情報をユーザ端末100から得るためのツールである。UIオブジェクトは、これには限定されないが、例えば、アイコン、ボタン、リスト、メニュー画面などである。
アニメーション生成部114は、各種オブジェクトの制御態様に基づいて、各種オブジェクトのモーションを示すアニメーションを生成する。
表示制御部112は、タッチスクリーン15の表示部152に対して、上述の各要素によって実行された処理結果が反映されたゲーム画面を出力する。表示制御部112は、アニメーション生成部114によって生成されたアニメーションを含むゲーム画面を表示部152に表示してもよい。また、表示制御部112は、上述のUIオブジェクトを、該ゲーム画面に重畳して描画してもよい。
なお、図2に示すサーバ200およびユーザ端末100の機能は一例にすぎない。サーバ200は、ユーザ端末100が備える機能の少なくとも一部を備えていてもよい。また、ユーザ端末100は、サーバ200が備える機能の少なくとも一部を備えていてもよい。さらに、ユーザ端末100およびサーバ200以外の他の装置をゲームシステム1の構成要素とし、該他の装置にゲームシステム1における処理の一部を実行させてもよい。すなわち、本実施形態においてゲームプログラムを実行するコンピュータは、ユーザ端末100、サーバ200、および他の装置の何れであってもよいし、これらの複数の装置の組み合わせにより実現されてもよい。
(記憶部130に格納され得る情報の詳細)
記憶部130は、ユーザ情報133の一部として次の情報を格納し得る。なお、これらの情報は、制御部110の機能ブロックの少なくとも何れかによって生成または更新されて格納される。また、これらの情報は、制御部110の機能ブロックの少なくとも何れかによって読みだされて利用される。
(1)ユーザに付与された各キャラクタに関する情報:ゲームシステム1において利用可能な複数のキャラクタのうち、ユーザに付与された各キャラクタに関する情報である。例えば、1つ以上のキャラクタが、ゲームの初期状態においてユーザに付与されていてもよい。また、追加のキャラクタが、ゲームの進行に応じて、ユーザに付与されるようにしてもよい。各キャラクタに関する情報は、第1パートにおいて用いられる各種パラメータを含む。各種パラメータは、ゲームの進行により更新され得る。また、各キャラクタに関する情報は、キャラクタの属性を表す情報を含む。属性は、例えば、キャラクタの外観に関わる属性であってもよい。属性は、ゲームの進行又はユーザの設定により変更され得る。
(2)第1パラメータ:ユーザに付与されたキャラクタのうち任意の2つのキャラクタ間の関係性を表す情報である。関係性とは、例えば、2つのキャラクタ間の友好の程度であってもよい。第1パラメータは、2つのキャラクタの組み合わせに関連付けて記憶されていてもよい。あるいは、上述した各キャラクタに関する情報に、当該キャラクタと他のキャラクタとの間の第1パラメータが含まれていてもよい。第1パラメータは、ゲームの進行により更新され得る。
(3)第2パラメータ:ユーザ端末100を利用するユーザに関わる情報である。第2パラメータは、ゲームの進行により更新され得る。第2パラメータは、例えば、ユーザの経験値を表すものであってもよい。
(4)グループに関する情報:第1パートで用いられるグループを構成するメンバを表す情報である。また、グループに関する情報は、メンバのうちの2以上のメインキャラクタに関する情報、及び、各メインキャラクタの役割に関する情報も含む。グループに関する情報は、ユーザの設定により更新され得る。
(5)要素に関する情報:第1イベントを構成し得る要素としてゲームシステム1において利用可能な要素のうち、ユーザに付与された要素に関する情報である。例えば、1つ以上の要素が、ゲームの初期状態においてユーザに付与されていてもよい。また、追加の要素が、ゲームの進行に応じて、ユーザに付与されるようにしてもよい。本実施形態では、前述したように、第1イベントを構成し得る要素とは、ライブで上演される曲を表すミュージックビデオである。ミュージックビデオは、音声及び画像を含んでいてもよい。また、ミュージックビデオは、複数のレイヤによって構成されていてもよい。
また、要素に関する情報は、当該要素の種類に関する情報を含んでいる。要素の種類は、後述の演出の内容に反映される。また、要素に関する情報は、当該要素に対して定められたキャラクタの組み合わせに関する情報を含んでいる。キャラクタの組み合わせに関する情報は、後述の演出の内容に反映される。
(6)演出に関する情報:演出は、第1パートの進行を盛り上げるための工夫であり、第1パートにおいて実行される。本実施形態では、演出は、2以上のメインキャラクタの関係性を表す映像として実現される。例えば、演出に関する情報は、ミュージックビデオに挿入し得る画像を表す情報からなっていてもよい。また、演出は、例えば、第1演出と、第2演出とを含んでいてもよい。第1演出は、キャラクタの組み合わせ毎に定まる内容である。第2演出は、キャラクタの組み合わせに加えて、各キャラクタの属性に応じて定まる内容である。さらに、第2演出は、キャラクタの役割に応じて定まる内容であってもよい。属性の一例としては、例えば、外観に関わる属性があるが、これに限られない。ミュージックビデオが複数のレイヤによって構成される場合、第1演出を表す情報は、キャラクタの組み合わせ毎に、それらのキャラクタを同一シーンに含むレイヤ画像として表されていてもよい。また、第1演出を表す情報は、キャラクタ毎に用意されたレイヤ画像の組み合わせとして表されていてもよい。また、第2演出を表す情報は、キャラクタ毎に用意された、その属性及び役割に応じたレイヤ画像の組み合わせとして表されていてもよい。また、第1演出を表す情報又は第2演出を表す情報は、さらに音声情報を含んでいてもよい。
なお、前述した第1イベントは、特別な内容として、少なくとも第2演出を含むものであってもよい。また、本実施形態では、第1パートにおいて、第1イベント以外のイベントが実行される場合がある。そのようなイベントを、以降、通常イベントとも記載する。通常イベントは、特別な内容を含まない。例えば、通常イベントは、第2演出を含まず、第1演出を含むものであってもよい。
(グループ編成部116の詳細)
グループ編成部116は、ゲームシステム1において利用可能な複数のキャラクタを用いて、第1パートで用いられるグループを構成する。具体的には、グループ編成部116は、第1パートにおいてライブを上演するグループのメンバを編成する。グループを編成可能なキャラクタは、ゲームシステム1において利用可能な複数のキャラクタのうち、ユーザに対して付与されたキャラクタであってもよい。
また、グループ編成部116は、第1パートで用いられるグループを構成するキャラクタの中から、2以上のキャラクタを選択する。以降、グループから選択された2以上のキャラクタを、それぞれメインキャラクタとも記載する。具体的には、グループ編成部116は、第1パートにおいてライブを上演するグループのメンバの中から、第1イベントのために、中心となる2以上のメインキャラクタを選択する。以降、選択されるメインキャラクタは2つであるものとして説明するが、3つ以上であってもよい。また、以降、2つのメインキャラクタの各々を区別する必要がある場合には、第1メインキャラクタ及び第2メインキャラクタとも記載する。
グループ編成部116は、上述のようにして選択した2つのメインキャラクタ各々に、役割を割り当ててもよい。役割としては、例えば、主従関係が挙げられる。例えば、グループ編成部116は、メインキャラクタの一方に第1の役割を割り当て、他方に第2の役割を割り当ててもよい。第1の役割としては、例えば、主従関係の主、第2の役割としては、主従関係の従が挙げられる。第1の役割及び第2の役割は、第1パート進行部117によって実行される第1イベントにおける演出に反映される。
(第1パート進行部117の詳細)
第1パート進行部117は、グループを用いて第1パートを進行する。第1パートを進行する上で、第1パート進行部117は、グループを構成する各キャラクタが有する各種パラメータを参照する。具体的には、第1パート進行部117は、第1パートにおいて、グループによるライブとしてミュージックビデオを再生する。そして、第1パート進行部117は、ミュージックビデオに含まれる曲のリズムに合わせて操作を受け付けたか否かを、上述した各種パラメータを参照しながら判定することにより、音楽ゲームを進行する。
また、第1パート進行部117は、第1パートにおいて、メインキャラクタ間の関係性を表す演出を実行する。具体的には、第1パート進行部117は、グループによるライブとして、ミュージックビデオに、メインキャラクタの関係性を表す演出となる映像を含めて、当該ミュージックビデオを再生する。例えば、上述した第1演出及び第2演出の一方または両方が、後述する各種の条件に応じてミュージックビデオに含められる。第1演出及び第2演出を含むミュージックビデオによるライブは、前述した第1イベントの一例である。また、第1演出を含み第2演出を含まないミュージックビデオによるライブは、前述した通常イベントの一例である。第1パート進行部117は、第1演出として、選択された2つのメインキャラクタを同一シーンに含むレイヤ画像を、ミュージックビデオの所定時点に挿入してもよい。また、第1パート進行部117は、第1演出として、選択された2つのメインキャラクタの各々のレイヤ画像を、ミュージックビデオの所定時点に挿入してもよい。また、第1パート進行部117は、第2演出として、選択された2つのメインキャラクタ各々の属性に基づくレイヤ画像を、ミュージックビデオの互いに異なるレイヤに、各々の役割に基づき時間差で挿入してもよい。なお、2つのメインキャラクタ各々の属性に基づくレイヤ画像は、役割に基づき時間差で挿入された後、同時に表示される期間が設けられることが望ましい。第1演出及び第2演出の詳細については後述する。
このように、第1パートにおいて、メインキャラクタ間の関係性を楽しむ機会が、第1演出又は第2演出として、ユーザに提供される。そして、ユーザは、第1演出により、メインキャラクタ間の関係性を楽しむことができる。また、ユーザは、それぞれに属性が反映されたメインキャラクタが、役割に基づき時間差で登場するという第2演出により、メインキャラクタ間の関係性を楽しむことができる。
また、第1パート進行部117は、メインキャラクタ間の関係性を表す第1パラメータが第1条件を満たす場合に、第1パートにおいて、メインキャラクタに応じた内容の第1イベントを実行する。ここで、第1条件とは、第1パラメータに関する条件であり、例えば、第1パラメータが閾値以上であることであってもよい。以降、第1パラメータが第1条件を満たすことを、単に、第1条件を満たす、とも記載する。
このように、第1イベントの実行に、キャラクタ間の関係性である第1パラメータが関わることで、ゲームの興趣性が向上する。
なお、第1パート進行部117は、第1イベントを実行する条件として、第1条件に加えて、第2条件を適用してもよい。第2条件とは、編成されたグループを構成する複数のキャラクタが所定の組み合わせであるとの条件を表し、例えば、後述の要素選択部115により選択された要素に対して定められた組み合わせであるとの条件を表す。
第2条件が満たされない場合について説明する。この場合、第1パート進行部117は、第1イベントを実行しない。この場合、例えば、第1パート進行部117は、前述の通常イベントを実行してもよい。
また、第2条件が満たされるが、第1条件が満たされない場合について説明する。この場合、第1パート進行部117は、第1イベントを実行しない。この場合、例えば、第1パート進行部117は、第1パートにおいてライブを開始しなくてもよい。換言すると、例えば、第1パート進行部117は、第1イベント及び通常イベントの何れも実行しなくてもよい。
これにより、第1パートで第1イベントが実行されるよう(すなわち、第1イベントで第2演出を観賞できるよう)、所定の組み合わせのキャラクタでグループのメンバを構成することに対するユーザの動機付けが向上する。
さらに、第1パート進行部117は、第1イベントを実行する条件として、第1条件及び第2条件に加えて、第3条件を適用してもよい。第3条件とは、選択された要素が所定の種類であるとの条件を表す。
例えば、ゲームシステム1において利用可能なミュージックビデオが、種類A又は種類Bの何れかに分類されているとする。この場合、第1パート進行部117は、選択されたミュージックビデオが種類Aであり(第3条件)、かつ、編成されたグループのメンバが、そのミュージックビデオに対して定められた組み合わせであり(第2条件)、かつ、2つのメインキャラクタ間の第1パラメータが第1条件を満たす場合に、第1イベントを実行してもよい。
第3条件が満たされない場合について説明する。この場合、第1パート進行部117は、第1イベントを実行しない。この場合、例えば、第1パート進行部117は、前述の通常イベントを実行してもよい。
これにより、第1パートで第1イベントが実行されるよう(すなわち、第1イベントで第2演出を観賞できるよう)、所定の要素に対して定められた所定の組み合わせのキャラクタでグループのメンバを構成することに対するユーザの動機付けが向上する。
(要素選択部115の詳細)
要素選択部115は、第1イベントを構成し得る1つ以上の要素から何れかの要素を選択する。例えば、第1イベントを構成し得る1つ以上の要素は、ゲームシステム1において利用可能な1つ以上の要素のうち、ユーザに付与された要素であってもよい。また、要素の選択肢数は、ユーザに関わる第2パラメータに応じて変化してもよい。第2パラメータについては後述する。なお、本実施形態では、第1イベントを構成し得る要素は、前述のミュージックビデオである。
(第2パート進行部118の詳細)
第2パート進行部118は、第2パートでパラメータを更新する対象となる2以上のキャラクタを選択する。以降、選択された2以上のキャラクタを、育成キャラクタとも記載する。以降、選択される育成キャラクタは2つであるものとして説明するが、3つ以上であってもよい。
また、第2パート進行部118は、2つの育成キャラクタの組み合わせについて、第2イベントを実行する。また、第2パート進行部118は、第2イベントの実行に応じて、2つの育成キャラクタ間の第1パラメータを更新する。例えば、第2パート進行部118は、第2イベントの実行により、当該育成キャラクタ間の第1パラメータを、より大きくなるよう更新してもよい。
また、第2パート進行部118は、第2イベントの実行に応じて、ユーザに関わる第2パラメータを更新させてもよい。例えば、第2パート進行部118は、第2イベントの実行により、第2パラメータを、より大きくなるよう更新してもよい。この場合、第2パラメータが大きいほど、要素の選択肢数が多くなるものとする。例えば、第2パラメータが所定値を超えるごとに、選択肢となる要素がユーザに追加して付与されてもよい。
これにより、ユーザは、第1パートで、第1イベントのバリエーションを楽しむことができる。
<ゲームシステム1の画面例>
(要素選択画面の具体例)
図3は、要素選択部115によって生成される要素選択画面の具体例である。要素選択画面は、第1パートにおいて表示される画面の一例であり、第1パートにおいて実行される第1イベントを構成し得るミュージックビデオを選択するための画面である。なお、図3では、ミュージックビデオを、MVと記載している。図3において、要素選択画面は、要素オブジェクト301a〜301cと、次ボタン302とを含む。次ボタン302は、グループ編成画面の表示に進むためのUIオブジェクトである。
要素オブジェクト301a〜301cは、要素の選択肢を表す。なお、図3では、要素の選択肢数が3つである例を示しているが、要素の選択肢数は3つに限定されない。また、要素選択画面において同時に表示可能な要素の数より、要素の選択肢数が多い場合、要素選択画面は、さらに、スクロールバー(図示せず)を含んでいてもよい。その場合、当該スクロールバーに対する入力操作に応じて、それまで表示されていなかった他の要素を表す要素オブジェクトが表示される。なお、要素の選択肢数は、前述したように、第2パラメータに応じて変化する。図3の例では、要素オブジェクト301aは、ミュージックビデオMV1を表し、要素オブジェクト301bは、ミュージックビデオMV2を表し、要素オブジェクト301cは、ミュージックビデオMV3を表している。
また、例えば、要素選択部115は、要素オブジェクト301a〜301cの何れかに対する入力操作に応じて、該当する要素を選択する。なお、本実施形態では、選択される要素の数は、1つであるものとするが、2つ以上であってもよい。
(グループ編成画面の詳細)
図4は、グループ編成部116によって生成されるグループ編成画面の具体例である。グループ編成画面は、第1パートにおいて表示される画面の一例であり、第1パートにおいてライブを上演するグループを編成するための画面である。図4において、グループ編成画面は、第1メインキャラクタ枠401aと、第2メインキャラクタ枠401bと、3つのサブキャラクタ枠401c〜401eと、パラメータ表示領域402とを含む。以降、第1メインキャラクタ枠401aと、第2メインキャラクタ枠401bと、3つのサブキャラクタ枠401c〜401eとをまとめて、キャラクタ枠401a〜401eとも記載する。この具体例では、グループを構成するメンバ数は5人である。また、サブキャラクタとは、メインキャラクタでないメンバのことである。また、第1メインキャラクタ枠401aは、第1の役割が割り当てられた第1メインキャラクタを設定するためのUIオブジェクトである。また、第2メインキャラクタ枠401bは、第2の役割が割り当てられた第2メインキャラクタを設定するためのUIオブジェクトである。サブキャラクタ枠401c〜401eは、サブキャラクタを設定するためのUIオブジェクトである。
例えば、グループ編成部116は、第1メインキャラクタ枠401aに対する入力操作に応じて、ユーザに対して付与されたキャラクタの一覧画面(図示せず)を表示してもよい。なお、「表示する」とは、表示制御部112を用いて表示部152に表示させることをいうものとする。そして、グループ編成部116は、一覧画面から何れかのキャラクタが入力操作により選択されると、当該一覧画面を閉じ、選択されたキャラクタを第1メインキャラクタ枠401aに表示してもよい。なお、「入力操作」とは、操作受付部111により受け付けられた入力部151に対する操作をいうものとする。入力操作は、例えば、タッチスクリーン15に対するタップ操作であってもよいが、これに限られない。これにより、ユーザに付与されたキャラクタの中から、第1の役割が割り当てられた第1メインキャラクタが選択される。第2メインキャラクタ枠401b及びサブキャラクタ枠401c〜401eについても同様にして、ユーザに付与されたキャラクタの中から選択されたキャラクタが表示される。これにより、グループ編成画面においてグループのメンバが編成される。
また、グループ編成部116は、キャラクタ枠401a〜401eの何れかについて入力操作によりキャラクタが選択されると、当該キャラクタに関するパラメータを、パラメータ表示領域402に表示する。
また、図4に示したグループ編成画面は、さらに、入れ替えボタン403と、おまかせ編成ボタン404と、開始ボタン405とを含む。
入れ替えボタン403は、2つのメインキャラクタに割り当てられた役割を入れ替えるためのUIオブジェクトである。グループ編成部116は、入れ替えボタン403に対する入力操作に応じて、メインキャラクタの役割を入れ替える。すなわち、グループ編成部116は、第1メインキャラクタ枠401a及び第2メインキャラクタ枠401bにキャラクタがそれぞれ表示されている状態で、入れ替えボタン403に対する入力操作を受け付ける。そして、グループ編成部116は、当該入力操作に応じて、第1メインキャラクタ枠401aに表示された第1メインキャラクタと、第2メインキャラクタ枠401bに表示された第2メインキャラクタとを入れ替える。これにより、第1メインキャラクタとして選択されていたキャラクタが、第2メインキャラクタとして選択され、第2メインキャラクタとして選択されていたキャラクタが、第1メインキャラクタとして選択される。
おまかせ編成ボタン404は、グループのメンバを自動で編成するためのUIオブジェクトである。グループ編成部116は、おまかせ編成ボタン404に対する入力操作に応じて、ユーザに対して付与されたキャラクタの中から、グループのメンバを選択する。すなわち、グループ編成部116は、ユーザに対して付与されたキャラクタの中からグループのメンバを選択する。例えば、グループ編成部116は、おまかせ編成ボタン404に対する入力操作に応じて、第1パートを進行するのに有利となる構成のグループのメンバを選択してもよい。そのような有利となる構成のグループのメンバは、各キャラクタが有する各種パラメータを考慮して選択されてもよい。
開始ボタン405は、編成されたグループのメンバによって第1パートにおいてライブを開始するためのUIオブジェクトである。換言すると、開始ボタン405は、第1イベントの実行を開始するためのUIオブジェクトである。ただし、開始ボタン405に対する操作に応じて、通常イベントが開始される場合もある。開始ボタン405に対する入力操作は、第1パート進行部117によって検出される。
このように、グループ編成画面に入れ替えボタン403が含まれることにより、グループ編成を行いながら、役割を容易に入れ替えることができるというメリットがある。また、グループ編成画面におまかせ編成ボタン404が含まれることにより、初級ユーザであってもグループの編成を容易に行うことができるというメリットがある。
(第1イベント画面の具体例)
図5(A)は、第1パートにおいて実行される第1イベント画面の具体例である。図5(A)に示すように、第1イベント画面は、第1パートにおいて表示される画面の一例であり、演出領域501と、第1パート進行領域502とを含む。演出領域501は、第1イベントを構成し得る要素の一例であるミュージックビデオが第1演出及び第2演出の少なくとも一方を含んで再生される領域である。
図5(A)における第1パート進行領域502は、演出領域で再生中のミュージックビデオにおける曲のリズムに合わせて、タイミング指標503が移動表示される領域である。タイミング指標503は、例えば、画面の右方向から左方向に移動表示されるUIオブジェクトである。複数のタイミング指標503が、順次、移動表示されてもよい。第1パート進行部117は、第1パート進行領域502内の所定領域504にタイミング指標503が重なったときに、当該タイミング指標503に対して入力操作が受け付けられたか否かを判定する。このとき、第1パート進行部117は、編成されたグループを構成する各キャラクタが有する各種パラメータも参照しながら判定を行うことにより、音楽ゲームを進行する。これにより、ユーザは、演出領域で再生される第1演出又は第2演出によりメインキャラクタ間の関係性を楽しみながら、音楽ゲームをさらに楽しむことができる。
(結果画面の具体例)
図5(B)は、第1パートの進行結果を示す結果画面の具体例であり、第1パート進行領域502において進行された音楽ゲームの結果を表す画面である。この結果画面は、選択されていた要素(例えば、ミュージックビデオ)を表す情報が表示される表示領域505と、スコアを表す情報が表示される表示領域506とを含んでいる。また、第1パート進行部117は、音楽ゲームの結果に基づいて、グループを構成する各キャラクタの各種パラメータの少なくとも一部を更新してもよい。この場合、結果を表す画面は、更新されたパラメータに関する情報をさらに含んでいてもよい。
(第1演出及び第2演出の実現例)
図6〜図9は、演出領域501における第1演出及び第2演出の実現例を説明する図である。
まず、図6(A)及び(B)を用いて、ミュージックビデオのレイヤ構成及びレイヤに配置されるレイヤ画像について説明する。図6(A)及び(B)において、矢印601〜603は、ミュージックビデオを構成するレイヤの再生時間tの経過を表している。また、時間t0〜t6は、ミュージックビデオの再生期間中の所定時点を表している。なお、時間t0〜t6は、再生期間中にこの順に到来する時点であるものとする。また、この例では、ミュージックビデオは、3枚のレイヤ(前レイヤ、中レイヤ、後レイヤ)によって構成される。以降、矢印601〜603と記載する代わりに、前レイヤ601、中レイヤ602、後レイヤ603とも記載する。またこれらのレイヤをまとめて、レイヤ601〜603とも記載する。また、各レイヤ601〜603各々の矢印の近傍に描画された線分611〜615は、当該レイヤにおいて、当該線分が示す範囲の期間に挿入されるレイヤ画像を表している。以降、線分611〜615と記載する代わりに、レイヤ画像611〜615とも記載する。なお、レイヤ画像611〜615が挿入される期間以外の各レイヤ601〜603には、他のレイヤ画像(図示せず)が挿入されていてもよい。また、この具体例では、後レイヤ603の上に中レイヤ602が重畳され、中レイヤ602の上に前レイヤ601が重畳されて、表示部152に表示される。なお、各レイヤ601〜603に表示されるレイヤ画像は、透明度が設定された画素からなり、画素の透明度に応じて、当該画素と、当該画素より後ろのレイヤの画素とが合成されて表示部152に表示されるものとする。なお、複数のレイヤを統合して表示部152に表示する技術としては、公知の技術を採用可能である。
図6(A)は、第1演出が含まれるミュージックビデオを模式的に表している。換言すると、図6(A)は、上述した第2条件及び第3条件の少なくとも何れかが満たされない場合に再生されるミュージックビデオの一例である。
図6(A)において、レイヤ画像611〜615は、レイヤ601〜603の何れかに挿入される。なお、レイヤ画像611〜615の各々は、必ずしも1枚の静止画像でなくてもよく、それぞれが、複数の静止画像を含む動画像であってもよい。
レイヤ画像611は、ミュージックビデオのタイトル、歌詞、装飾等を含む。レイヤ画像611は、時間t0〜t6の間、前レイヤ601に配置される。
レイヤ画像612は、ミュージックビデオに共通の背景を含む。レイヤ画像617は、時間t0〜t6の間、後レイヤ603に配置される。
図6(A)において、レイヤ画像613〜616は、第1演出を構成する。レイヤ画像613は、第1メインキャラクタを含むレイヤ画像である。レイヤ画像614は、第2メインキャラクタを含むレイヤ画像である。レイヤ画像615は、2つのメインキャラクタを同一シーンに含むレイヤ画像である。レイヤ画像613は、時間t1〜t2までの期間に、中レイヤ602に挿入される。レイヤ画像614は、時間t2〜t3までの期間に、中レイヤ602に挿入される。レイヤ画像615は、時間t3〜t4までの期間に、中レイヤ602に挿入される。このように、第1演出では、2つのメインキャラクタが、重複しない期間で順次登場するか、または、同時に登場する。
このような第1演出により、ユーザは、メインキャラクタの組み合わせを楽しむことができる。
図6(B)は、第1演出及び第2演出が含まれるミュージックビデオを模式的に表している。図6(B)は、上述した第1条件、第2条件、第3条件が全て満たされる場合に再生されるミュージックビデオの一例である。
図6(B)において、レイヤ画像611〜612については、上述した通りである。ただし、レイヤ画像611は、時間t0〜t6までの期間ではなく、時間t0〜t4までの期間、前レイヤ601に配置される。また、レイヤ画像612は、時間t0〜t6までの期間ではなく、時間t0〜t4までの期間、後レイヤ603に配置される。また、レイヤ画像613〜615が、第1演出を構成する点については、上述した通りであるため、詳細な説明を繰り返さない。
レイヤ画像616〜617は、第2演出を構成する。レイヤ画像616は、第1の役割が割り当てられた第1メインキャラクタを、設定されている属性に応じた外観で含むレイヤ画像である。レイヤ画像617は、第2の役割が割り当てられた第2メインキャラクタを、設定されている属性に応じた外観で含むレイヤ画像である。レイヤ画像616は、再生時間t4からt6までの期間に、後レイヤ603に挿入される。レイヤ画像617は、時間t5からt6までの期間に、前レイヤ601に挿入される。このように、第2演出では、2つのメインキャラクタの属性に応じたレイヤ画像は、役割に基づき時間差で挿入が開始されるとともに、同時に挿入が終了する。これにより、まず第1の役割が割り当てられた第1メインキャラクタが登場し、その後、当該第1メインキャラクタが登場中の場面に、第2の役割が割り当てられた第2メインキャラクタが追加で登場する、という第2演出が実現される。なお、図6(B)では、第2演出中において、ミュージックビデオのタイトル、歌詞、装飾等が表示されない例について説明した。これに限らず、第2演出中に、ミュージックビデオのタイトル、歌詞、装飾等が表示されても構わない。その場合、例えば、レイヤ画像617は、前レイヤ601の代わりに中レイヤ602に挿入されてもよい。また、この場合、レイヤ画像611は、第2演出中も前レイヤ601に引き続き挿入されていてもよい。
このような第2演出により、ユーザは、2つのメインキャラクタ間において、それぞれの属性及び役割の少なくとも一方が反映された関係性を楽しむことができる。また、ユーザにとって、2つのメインキャラクタの属性及び役割の少なくとも一方が反映された第2演出の価値が、第1演出よりも高くなると考えられる。したがって、ユーザは、第2演出を観賞するために、第1条件〜第3条件を満たすよう、ゲームを進行することに対する動機付けが増す。例えば、あるミュージックビデオに対して所定の組み合わせのメンバでグループを構成することができるよう、それらの全てのキャラクタを取得することに対するユーザの動機付けが増す。また、所望のキャラクタ間の第1パラメータが、第1条件を満たすよう、第2パートをプレイすることに対するユーザの動機付けが増す。
図7(A)、(B)は、図6(B)において用いられるレイヤ画像611、612の一例である。例えば、図7(A)に示すレイヤ画像611は、ミュージックビデオのタイトル、歌詞等を含んでいる。なお、レイヤ画像611は、図示の静止画像に続く複数の静止画像からなる動画像であってもよく、各静止画像は、例えば、曲の流れに沿って区切られた歌詞を含んでいてもよい。
また、図7(B)に示すレイヤ画像612は、共通の背景を含んでいる。なお、レイヤ画像612は、図示の静止画像に続く複数の静止画像からなる動画像であってもよい。
図8(A)〜(E)は、図6(A)又は(B)において用いられるレイヤ画像613〜617の一例である。例えば、図8(A)は、レイヤ画像613を表し、第1メインキャラクタを含んでいる。また、レイヤ画像613に含まれる第1メインキャラクタには、その属性は反映されていない。ここでは、キャラクタに設定される属性は、キャラクタの外観(例えば、服)を表すものとする。つまり、レイヤ画像611に含まれる第1メインキャラクタは、設定されている属性に関わらず、初期設定の服を着ているものとする。なお、レイヤ画像613は、図示の静止画像に続く複数の静止画像からなる動画像であってもよい。
図8(B)は、レイヤ画像614を表し、第2メインキャラクタを含んでいる。また、レイヤ画像612に含まれる第2メインキャラクタには、その属性は反映されていない。つまり、レイヤ画像614に含まれる第2メインキャラクタは、設定されている属性に関わらず、初期設定の服を着ているものとする。なお、レイヤ画像614は、図示の静止画像に続く複数の静止画像からなる動画像であってもよい。
図8(C)は、レイヤ画像615を表し、第1メインキャラクタ及び第2メインキャラクタを同一シーンに含んでいる。また、レイヤ画像615に含まれる第1メインキャラクタ及び第2メインキャラクタには、その属性は反映されていない。なお、レイヤ画像615は、図示の静止画像に続く複数の静止画像からなる動画像であってもよい。
図8(D)は、レイヤ画像616を表し、第1メインキャラクタを左上半分の三角形の領域に含んでいる。また、レイヤ画像616に含まれる第1メインキャラクタには、その属性が反映されている。具体的には、レイヤ画像616に含まれる第1メインキャラクタは、その属性に従い、図8(A)とは異なる服を着ている。なお、レイヤ画像616は、図示の静止画像に続く複数の静止画像からなる動画像であってもよい。
図8(E)は、レイヤ画像617を表し、第2メインキャラクタを右下半分の領域に含んでいる。また、レイヤ画像617に含まれる第2メインキャラクタには、その属性が反映されている。具体的には、レイヤ画像617に含まれる第2メインキャラクタは、その属性に従い、図8(B)とは異なる服を着ている。また、レイヤ画像617の左上半分の領域は、透明画素である。なお、レイヤ画像617は、図示の静止画像に続く複数の静止画像からなる動画像であってもよい。
図9(A)〜(F)は、図6(B)に示したタイミングチャートに沿って、図7〜図8に示したレイヤ画像が順次挿入された場合に、ミュージックビデオが第1イベント画面において再生される様子を表している。
図9(A)は、図6(B)のt0における画面例である。図9(A)に示すように、t0では、後レイヤ603にレイヤ画像612が配置され、前レイヤ601にレイヤ画像611が配置されることにより、共通の背景上にタイトル、歌詞等が重畳された画面が表示される。
図9(B)は、図6(B)のt1における画面例である。図9(B)に示すように、中レイヤ602にレイヤ画像613が配置されることにより、共通の背景上に第1メインキャラクタが初期設定の服で登場し、その上に歌詞が重畳される。
図9(C)は、図6(B)のt2における画面例である。図9(C)に示すように、中レイヤ602にレイヤ画像614が配置されることにより、共通の背景上に、第1メインキャラクタの代わりに第2メインキャラクタが初期設定の服で登場し、その上に、図9(B)に続く歌詞が重畳される。
図9(D)は、図6(B)のt3における画面例である。図9(D)に示すように、中レイヤ602にレイヤ画像615が配置されることにより、共通の背景上に、第2メインキャラクタの代わりに、第1メインキャラクタ及び第2メインキャラクタが、初期設定の服で同一シーンに登場する。
図9(E)は、図6(B)のt4における画面例である。図9(E)に示すように、後レイヤ603にレイヤ画像616が配置されることにより、共通の背景の代わりに、第1メインキャラクタが、属性を反映した服を着て登場する。
図9(F)は、図6(B)のt5における画面例である。図9(F)に示すように、中レイヤ602にレイヤ画像617が配置されることにより、第1メインキャラクタが登場中のシーンに、第2メインキャラクタが、その属性を反映した服を着て登場する。そして、この具体例では、第1メインキャラクタ及び第2メインキャラクタの役割は、第2演出における登場の順序に反映されている。
なお、レイヤ画像616において第1メインキャラクタが配置されている領域は、レイヤ画像617において透明画素領域であるため、重畳された場合に2つのメインキャラクタが同時に表示される。これにより、後から登場する第2の役割が割り当てられたメインキャラクタの表示が、最初に登場した第1の役割が割り当てられたメインキャラクタの表示を覆ってしまうことがなく、より効果的な第2演出が実現される。
なお、図6〜図9を用いて説明した第1演出及び第2演出の具体例は、一例である。また、ミュージックビデオは、必ずしも複数のレイヤによって構成されていなくてもよい。その場合、第1演出は、2つのメインキャラクタの組み合わせに応じた内容であればよく、上述した以外の手法により実現されてもよい。また、第2演出は、2つのメインキャラクタの組み合わせに加えて、それぞれの役割及び属性に応じた内容であればよく、上述した以外の手法により実現されてもよい。
(第2パート画面の具体例)
図10(A)は、第2パートで育成対象とする2つの育成キャラクタを選択する育成キャラクタ選択画面の具体例である。図10において、育成キャラクタ選択画面は、キャラクタオブジェクト801a〜801eと、表示領域802と、開始ボタン803とを含む。
キャラクタオブジェクト801a〜801eは、ユーザに対して付与されたキャラクタの一覧を表す。この例では、5つのキャラクタがユーザに対して付与されている。また、育成キャラクタ選択画面において同時に表示可能な育成キャラクタの数より、ユーザに付与されたキャラクタ数が多い場合、育成キャラクタ選択画面は、さらに、スクロールバー(図示せず)を含んでいてもよい。その場合、当該スクロールバーに対する入力操作に応じて、それまで表示されていなかった他のキャラクタを表すキャラクタオブジェクトが表示される。
キャラクタオブジェクト801a〜801eの各々は、入力操作が受け付けられると、対応するキャラクタが育成キャラクタとして選択される。同時に選択可能な育成キャラクタの数は、この例では2つである。
表示領域802は、選択された2つの育成キャラクタ間の第1パラメータを表示する領域である。この表示領域806により、ユーザは、キャラクタ間の第1パラメータを確認しながら、第1パラメータを上昇させる対象となる2つの育成キャラクタを選択することが可能となる。
開始ボタン803は、選択された2つの育成キャラクタについて第2イベントを開始するためのUIオブジェクトである。
第2パート進行部118は、キャラクタオブジェクト801a〜801eに対する入力操作によって選択された2つの育成キャラクタについて、開始ボタン803に対する入力操作に応じて、第2イベントを開始する。
ここで、第2パート進行部118は、第2イベントを開始する際に、第2イベントの内容を選択させる第2イベント選択画面(図示せず)を表示してもよい。この場合、第2パート進行部118は、選択された内容の第2イベントを開始する。例えば、そのような第2イベント選択画面は、第2イベントが仮想的に実行されるステージの内容、第2イベントで用いられるアイテム等が選択可能に構成されていてもよい。ステージの内容の具体例としては、例えば、「お菓子を食べるステージ」が挙げられるが、これに限られない。また、この場合、アイテムの具体例としては、「差し入れのお菓子」が挙げられるが、これに限られない。
なお、図10(A)に示した育成キャラクタの選択画面は、必ずしも第2パートにおいて表示される必要はない。育成キャラクタの選択は、例えば、第1パート、第2パート以外のパートで実行されてもよい。
図10(B)は、第2イベントの実行画面の具体例を示す図である。この具体例では、第2パート進行部118は、第2イベントとして、「お菓子を食べるステージにおいて、育成キャラクタが差し入れのお菓子を食べる様子」を表す映像を再生している。
図10(C)は、第2イベントの結果画面の具体例を示す図である。この具体例では、結果画面は、第1パラメータの表示領域804と、第2パラメータの表示領域805とを含む。第2パート進行部118は、第2イベントの実行が終了すると、第1パラメータの表示領域804に、2つの育成キャラクタ間の第1パラメータについて、第2イベントの実行前の値と、実行後の値とを表示する。また、第2パート進行部118は、第2パラメータの表示領域805に、ユーザに関わる第2パラメータについて、第2イベントの実行前の値と、実行後の値とを表示する。この例では、第1パラメータ及び第2パラメータの更新は、それぞれ、値を上昇させることである。
なお、第2パート進行部118は、第2イベントの内容(例えば、ステージ、アイテム等)に応じて、第1パラメータ及び第2パラメータの少なくとも一方の変化幅を異ならせてもよい。
このように、ユーザは、第2パートをプレイすることにより、第1パートで第1イベントが実行されるための第1条件(すなわち、第2演出を観賞するための第1条件)を満たすよう、育成キャラクタ間の第1パラメータを更新することができる。また、ユーザは、第2パートをプレイすることにより、第1イベントを構成し得る要素の選択肢数を増やすため、自身に関わる第2パラメータを更新することができる。
<ゲームシステム1の処理フロー>
図11〜図12は、ユーザ端末100が、ゲームプログラム131に基づいて実行する処理の流れを示すフローチャートである。
図11は、ユーザ端末100が第1パートにおいて実行する動作を示すフローチャートである。
ステップS901において、要素選択部115は、第1イベントを構成し得る要素(例えば、ミュージックビデオ)を選択する。例えば、要素選択部115は、図3に示した要素選択画面に対する入力操作に応じて、第1イベントを構成し得る要素を選択すればよい。
ステップS902〜S905において、グループ編成部116は、ユーザに付与された複数のキャラクタを用いて、グループを編成する。
具体的には、ステップS902において、グループ編成部116は、ユーザに付与された複数のキャラクタの中から、2つのメインキャラクタを選択し、各々に役割を割り当てる。例えば、グループ編成部116は、図4に示したグループ編成画面における第1メインキャラクタ枠401aに対する入力操作に応じて、第1の役割が割り当てられた第1メインキャラクタを選択すればよい。また、グループ編成部116は、第2メインキャラクタ枠401bに対する入力操作に応じて、第2の役割が割り当てられた第2メインキャラクタを選択すればよい。
ステップS903において、グループ編成部116は、ユーザに付与された複数のキャラクタの中から、各サブキャラクタを選択する。例えば、グループ編成部116は、グループ編成画面のサブキャラクタ枠401c〜401eに対する入力操作に応じて、各サブキャラクタを選択すればよい。
なお、グループ編成部116は、グループ編成画面のおまかせ編成ボタン404に対する入力操作に応じて、ステップS902及びS903を実行してもよい。この場合、グループ編成部116は、ユーザに付与されているキャラクタの中から、第1パートを進行させる上で有利な編成となるよう、2つのメインキャラクタ及び各キャラクタを選択すればよい。そのような選択処理は、例えば、各キャラクタのパラメータ、キャラクタ間の第1パラメータ等に基づいて実行されてもよい。
ステップS904において、グループ編成部116は、2つのメインキャラクタの役割を入れ替える入力操作を受け付けたか否かを判断する。例えば、グループ編成部116は、グループ編成画面の入れ替えボタン403に対する入力操作を受け付けたか否かを判断すればよい。受け付けた場合、ステップS905において、グループ編成部116は、2つのメインキャラクタの役割を入れ替える。受け付けなかった場合、ステップS905の処理は行われない。
なお、ステップS902〜S905の処理は、必ずしもこの順で行われなくてもよい。
ステップS906において、第1パート進行部117は、第1イベントの実行を開始する入力操作を受け付けたか否かを判断する。例えば、第1パート進行部117は、グループ編成画面の開始ボタン405に対する入力操作を受け付けたか否かを判断すればよい。受け付けない場合、ステップS902からS905の処理の少なくとも1つが繰り返されてもよい。受け付けた場合、ステップS907が実行される。
なお、ステップS902〜S906の流れからわかるように、グループ編成画面に入れ替えボタン403及び開始ボタン405が含まれることで、第1イベントの開始直前まで、グループの編成を変更したり、メインキャラクタ及びその役割を入れ替えたりすることが、ユーザにとって容易である、というメリットがある。
ステップS907において、第1パート進行部117は、ステップS901で選択された要素(例えば、ミュージックビデオ)が、所定種類であるか否か(第3条件を満たすか否か)を判断する。所定種類でない場合は、後述のステップS911が実行される。所定種類である場合、次のステップS908が実行される。
ステップS908において、第1パート進行部117は、選択されたグループのメンバが、選択された要素に対して定められた組み合わせであるか否か(第2条件を満たすか否か)を判断する。定められた組み合わせでない場合、後述のステップS911が実行される。定められた組み合わせである場合、次のステップS909が実行される。
ステップS909において、第1パート進行部117は、選択された2つのメイキャラクタ間の第1パラメータが、第1条件を満たすか否かを判断する。ここで、第1条件を満たさない場合、第1パート進行部117は、第1イベントを実行しない。この場合、ステップS902からS905の少なくとも1つの処理が繰り返されてもよく、続いて、ステップS906からの処理が繰り返されてもよい。第1の条件を満たすと判断された場合、次のステップS910が実行される。
ステップS910において、第1パート進行部117は、第1イベントを実行して、第1パートを進行する。例えば、第1パート進行部117は、選択されたミュージックビデオに、第1演出及び第2演出を含める。ステップS910において、第1パート進行部117は、少なくとも第2演出を含めればよく、必ずしも第1演出を含めなくてもよい。そして、第1パート進行部117は、ミュージックビデオを再生しながら、音楽ゲームを進行する。
一方、ステップS907において選択された要素が所定種類でなかった場合、又は、ステップS908において、グループを構成する複数のキャラクタが、選択された要素に対して定められた組み合わせでなかった場合について説明する。この場合、次のステップS911が実行される。
ステップS911において、第1パート進行部117は、第1イベントを実行せずに、通常イベントを実行する。例えば、第1パート進行部117は、選択された要素に対応するミュージックビデオに、第1演出を含める。なお、第1パート進行部117は、第2演出を少なくとも含めなければよく、必ずしも第1演出を含めなくてもよい。そして、第1パート進行部117は、ミュージックビデオを再生しながら、音楽ゲームを進行する。
ステップS912では、第1パート進行部117は、ステップS910又はS911における第1パートの進行結果として、音楽ゲームの結果画面を表示する。
なお、以上の動作の説明において、ステップS901の要素選択処理、及び、S902〜S905のグループ編成処理の少なくとも一方は、必ずしも第1パートで行われる必要はなく、第1パート以外のパートで実行されてもよい。
なお、上述した第1パートの動作の説明において、ステップS909で第1条件が満たされない場合には、第1イベント及び通常イベントの何れも実行されず、S902からS905の少なくとも1つの処理が繰り返されてもよいものとして説明した。これに限らず、ステップS909で第1条件が満たされない場合に、ステップS911が実行されてもよい。例えば、第1パート進行部117は、2つのメインキャラクタ間の第1パラメータが第1条件を満たさない場合に、通常イベントを実行してもよい。
また、上述した第1パートの動作の説明において、ステップS907で第3条件が満たされない場合、又は、ステップS908で第2条件が満たされない場合には、第1イベントの代わりに通常イベントが実行されるものとして説明した。これに限らず、ステップS907で第3条件が満たされない場合、又は、ステップS908で第2条件が満たされない場合に、第1イベント及び通常イベントの何れも実行されなくてもよい。この場合に、S902からS905の少なくとも1つの処理が繰り返されてもよい。
図12は、ユーザ端末100が第2パートにおいて実行する動作を示すフローチャートである。
ステップS1001において、第2パート進行部118は、ユーザに付与されたキャラクタの中から、2つの育成キャラクタを選択する。例えば、第2パート進行部118は、図10(A)に示した育成キャラクタ選択画面のキャラクタオブジェクト801a〜801eに対する入力操作に応じて、2つの育成キャラクタを選択すればよい。
ステップS1002において、第2パート進行部118は、第2パートを開始する入力操作を受け付けたか否かを判断する。例えば、第2パート進行部118は、育成キャラクタ選択画面の開始ボタン803に対する入力操作を受け付けたか否かを判断すればよい。受け付けない場合、ステップS1001から処理が繰り返されてもよい。受け付けた場合、ステップS1003が実行される。
ステップS1003において、第2パート進行部118は、2つの育成キャラクタについて、第2イベントを実行する。
ステップS1004において、第2パート進行部118は、2つの育成キャラクタ間の第1パラメータを更新する。
ステップS1005において、第2パート進行部118は、ユーザに関わる第2パラメータを更新する。
なお、ステップS1004、ステップS1005の処理は、必ずしもこの順序で行われなくてもよい。
ステップS1006において、第2パート進行部118は、第2パートの結果として、更新された第1パラメータ及び第2パラメータに関する情報を表示する。
なお、以上の動作の説明において、ステップS1001の育成キャラクタ選択処理は、必ずしも第2パートで行われる必要はなく、第2パート以外のパートで実行されてもよい。
〔変形例〕
本実施形態において、第1パート進行部117は、少なくとも第1パラメータが第1条件を満たすか否かに基づいて、第1イベントを実行するものとして説明した。ただし、第1パート進行部117は、必ずしも第1パラメータが第1条件を満たすか否かを考慮せずに、第1イベントを実行してもよい。例えば、第1パート進行部117は、編成されたグループメンバによるライブとして、選択されたミュージックビデオに、選択されたメインキャラクタの関係性を表す演出(例えば、第1演出及び第2演出の一方又は両方)を含めて、当該ミュージックビデオを再生してもよい。
この場合、ユーザ端末100は、第2パート進行部118を有していなくてもよい。すなわち、ゲームプログラム131に基づくゲームは、必ずしも第2パートを含んでいなくてもよい。このように変形した場合も、ユーザは、選択したメインキャラクタ間の関係性を、その関係性を表す演出により、楽しむことができる。
また、本実施形態において、第1パート進行部117は、ユーザによって保有されるプレイ権アイテムと引き換えに、第1パートを進行するようにしてもよい。プレイ権アイテムは、例えば、第1パートを1回プレイする単位で管理される。この場合、ユーザは、1つ以上のプレイ権アイテムを保有することが可能である。例えば、第1パート進行部117は、ユーザが保有するプレイ権アイテムを1つ消費する処理を行ってから、図11のステップS901からの処理を実行してもよい。また、第1パート進行部117は、ユーザがプレイ権アイテムを保有していなければ、ステップS901からの処理を実行せずに、動作を終了してもよい。
また、この場合、第2パート進行部118は、第2イベントの実行に応じて、第1パラメータ及び第2パラメータを更新することに加えて、ユーザにプレイ権データを付与してもよい。
このように変形することにより、第2パートをプレイすることに対するユーザの動機付けをさらに高めることができる。
〔ソフトウェアによる実現例〕
制御部210の制御ブロック(特に、送受信部211、データ管理部212及びサーバ処理部213)、ならびに、制御部110の制御ブロック(特に、操作受付部111、表示制御部112、UI制御部113、アニメーション生成部114、要素選択部115、グループ編成部116、第1パート進行部117及び第2パート進行部118)は、集積回路(ICチップ)等に形成された論理回路(ハードウェア)によって実現してもよいし、CPU(Central Processing Unit)を用いてソフトウェアによって実現してもよい。
後者の場合、制御部210または制御部110、もしくはその両方を備えた情報処理装置は、各機能を実現するソフトウェアであるプログラムの命令を実行するCPU、上記プログラムおよび各種データがコンピュータ(またはCPU)で読み取り可能に記録されたROM(Read Only Memory)または記憶装置(これらを「記録媒体」と称する)、上記プログラムを展開するRAM(Random Access Memory)などを備えている。そして、コンピュータ(またはCPU)が上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記記録媒体としては、「一時的でない有形の媒体」、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムは、該プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して上記コンピュータに供給されてもよい。なお、本発明の一態様は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
〔付記事項〕
本発明の一側面に係る内容を列記すると以下のとおりである。
(項目1) ゲームプログラム(131)について説明した。本開示のある局面によると、ゲームプログラムは、プロセッサ(10、20)、メモリ(11、21)、操作部(入力部151など)および表示部(152)を備えるコンピュータ(ユーザ端末100、サーバ200)により実行される。ゲームプログラムは、プロセッサに、ゲームプログラムに基づくゲームにおいて利用可能な複数のキャラクタを用いてキャラクタのグループを構成するステップと、グループを用いてゲームを進行するステップと、を実行させる。ゲームを進行するステップは、ゲームにおいて、グループに含まれる少なくとも2以上のキャラクタ間の関係性を表す演出を実行する。
上記構成によれば、ゲームを進行させながら、ゲームの進行に関わるグループに含まれる少なくとも2以上のキャラクタ間の関係性を楽しむ機会を、ユーザに提供できる。
(項目2) (項目1)において、キャラクタには、ゲームの進行に関わるパラメータが設定されていてもよい。また、ゲームプログラムは、プロセッサに、グループから2以上のキャラクタを選択するステップを更に実行させてもよい。この場合、ゲームを進行するステップは、グループを構成する複数のキャラクタに設定されたパラメータに基づいてゲームを進行し、選択された2以上のキャラクタに基づいて演出を実行する。これにより、ユーザは、グループを構成する複数のキャラクタのパラメータに応じて進行するゲームの展開を楽しみながら、グループから選択された2以上のキャラクタ間の関係性を楽しむことができる。
(項目3) (項目1)又は(項目2)において、キャラクタは、属性を有していてもよい。この場合、演出は、少なくとも2以上のキャラクタに応じて定まる第1演出と、少なくとも2以上のキャラクタに加え少なくとも2以上のキャラクタの属性に応じて定まる第2演出を含んでいてもよい。これにより、ユーザは、第1演出によって、2以上のキャラクタに応じた内容でキャラクタ間の関係性を楽しむだけでなく、各キャラクタの属性に応じて定まる内容で、キャラクタ間の関係性を楽しむことができる。
(項目4) (項目3)において、属性は、キャラクタの外観を示していてもよい。この場合、第2演出は、少なくとも2以上のキャラクタのそれぞれが、属性に応じた外観で、時間差で登場する演出であってもよい。これにより、ユーザは、少なくとも2以上のキャラクタの登場順序によって表されるキャラクタ間の関係性を楽しむことができる。
(項目5) (項目4)において、第2演出は、複数のレイヤで構成される映像に含まれていてもよい。この場合、少なくとも2以上のキャラクタは、互いに異なるレイヤに配置されていてもよい。これにより、少なくとも2以上のキャラクタを時間差で登場させることが容易となる。
(項目6) (項目1)から(項目5)の何れか1項目において、演出は、少なくとも2以上のキャラクタの組み合わせに基づいていてもよい。これにより、ユーザは、少なくとも2以上のキャラクタの組み合わせによる演出を楽しむことができる。
(項目7) (項目6)において、選択するステップは、少なくとも2以上のキャラクタ各々に役割を割り当ててもよい。この場合、演出は、少なくとも2以上のキャラクタ各々の役割に基づいていてもよい。これにより、ユーザは、少なくとも2以上のキャラクタの役割に基づく演出を楽しむことができる。
(項目8) (項目1)から(項目7)の何れか1項目において、コンピュータは、さらに音声出力部を備えていてもよい。また、演出は、複数のキャラクタに含まれる少なくとも2以上のキャラクタ間の関係性を表す映像に含まれ、映像は、画像及び音声を含んで構成されていてもよい。この場合、ゲームを進行するステップは、映像を、表示部及び音声出力部に出力させる。これにより、ユーザは、これにより、ユーザは、少なくとも2以上のキャラクタの関係性を、画像及び音声により楽しむことができる。
(項目9) ゲームプログラムを実行する方法を説明した。本開示のある局面によると、ゲームプログラムは、プロセッサ、メモリ、操作部および表示部を備えるコンピュータにより実行される。該方法は、プロセッサが(項目1)に記載の各ステップを実行する方法である。(項目9)に係る方法は、(項目1)に係るゲームプログラムと同様の作用効果を奏する。
(項目10) 情報処理装置を説明した。本開示のある局面によると、該情報処理装置は、(項目1)に係るゲームプログラムを記憶する記憶部(120)と、該ゲームプログラムを実行することにより、情報処理装置(ユーザ端末100)の動作を制御する制御部(110)とを備える。(項目10)に係る情報処理装置は、(項目1)に係るゲームプログラムと同様の作用効果を奏する。