本開示に係るシステムは、複数のユーザにゲームを提供するためのシステムである。以下、該システムについて図面を参照しつつ説明する。なお、本発明はこれらの例示に限定されるものではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が本発明に含まれることが意図される。以下の説明では、図面の説明において同一の要素には同一の符号を付し、重複する説明を繰り返さない。
<システム1の動作概要>
図1は、本実施形態に係るシステム1の概要を示す図である。システム1は、複数のユーザ端末100(コンピュータ)と、サーバ200と、ゲームプレイ端末300(外部装置、第2外部装置)と、配信端末400(外部、第1外部装置)とを含む。なお、図1では、複数のユーザ端末100の一例として、ユーザ端末100A〜100C、換言すれば、3台のユーザ端末100を記載しているが、ユーザ端末100の台数は図示の例に限定されない。また、本実施形態では、ユーザ端末100A〜Cを区別する必要が無い場合、「ユーザ端末100」と記載する。ユーザ端末100、ゲームプレイ端末300、および配信端末400は、サーバ200とネットワーク2を介して接続する。ネットワーク2は、インターネットおよび図示しない無線基地局によって構築される各種移動通信システム等で構成される。この移動通信システムとしては、例えば、所謂3G、4G移動通信システム、LTE(Long Term Evolution)、および所定のアクセスポイントによってインターネットに接続可能な無線ネットワーク(例えばWi-Fi(登録商標))等が挙げられる。
(ゲームの概要)
本実施形態では、システム1によって提供されるゲーム(以下、本ゲーム)の一例として、ゲームプレイ端末300のユーザが主としてプレイするゲームを説明する。以下、ゲームプレイ端末300のユーザを、「プレイヤ」と称する。プレイヤ(演者)は、一例として、本ゲームに登場するキャラクタを操作することにより、ゲームを進行させる。また、本ゲームにおいて、ユーザ端末100のユーザは、プレイヤによるゲームの進行を支援する役割を担う。本ゲームの詳細については後述する。なお、システム1によって提供されるゲームは、複数のユーザが参加するゲームであればよく、この例に限定されない。
(ゲームプレイ端末300)
ゲームプレイ端末300は、プレイヤによる入力操作に応じてゲームを進行させる。また、ゲームプレイ端末300は、プレイヤのゲームプレイにより生成された情報(以下、ゲーム進行情報)を、順次、サーバ200にリアルタイムで配信する。
(サーバ200)
サーバ200は、ゲームプレイ端末300からリアルタイムに受信したゲーム進行情報(第2データ)を、ユーザ端末100に送信する。また、サーバ200は、ユーザ端末100、ゲームプレイ端末300、および配信端末400の間の各種情報の送受信を仲介する。
(配信端末400)
配信端末400は、配信端末400のユーザによる入力操作に応じて、動作指図データ(第1データ)を生成し、サーバ200を介してユーザ端末100へ動作指図データを配信する。動作指図データとは、ユーザ端末100において動画を再生するためのデータであり、具体的には、動画に登場するキャラクタを動作させるためのデータである。
本実施形態では、一例として、配信端末400のユーザは、本ゲームのプレイヤである。また、一例として、ユーザ端末100にて動作指図データに基づいて再生される動画は、プレイヤがゲームで操作したキャラクタが動作する動画である。「動作」とは、キャラクタの身体の少なくとも一部を動かすことであり、発話も含む。このため、本実施形態に係る動作指図データは、例えば、キャラクタに発話させるための音声データと、キャラクタの身体を動かすためのモーションデータとを含む。
動作指図データは、一例として、本ゲームの終了後にユーザ端末100へ送信される。動作指図データ、および、該動作指図データに基づいて再生される動画の詳細については後述する。
(ユーザ端末100)
ユーザ端末100は、ゲーム進行情報をリアルタイムに受信し、該情報を用いてゲーム画面を生成して表示する。換言すれば、ユーザ端末100は、リアルタイムレンダリングにより、プレイヤがプレイしているゲームのゲーム画面を再生する。これにより、ユーザ端末100のユーザは、プレイヤがゲームをプレイしながら視認しているゲーム画面と同一のゲーム画面を、プレイヤとほぼ同じタイミングで視認することができる。
また、ユーザ端末100は、ユーザによる入力操作に応じて、プレイヤによるゲームの進行を支援するための情報を生成し、該情報を、サーバ200を介してゲームプレイ端末300へ送信する。該情報の詳細については後述する。
また、ユーザ端末100は、配信端末400から動作指図データを受信し、該動作指図データを用いて動画(映像)を生成して再生する。換言すれば、ユーザ端末100は、動作指図データをレンダリングして再生する。
<システム1のハードウェア構成>
図2は、ユーザ端末100のハードウェア構成を示す図である。図3は、サーバ200のハードウェア構成を示す図である。図4は、ゲームプレイ端末300のハードウェア構成を示す図である。図5は、配信端末400のハードウェア構成を示す図である。
(ユーザ端末100)
本実施形態では、一例として、ユーザ端末100がスマートフォンとして実現される例を説明するが、ユーザ端末100はスマートフォンに限定されない。例えば、ユーザ端末100はフィーチャーフォン、タブレット型コンピュータ、ラップトップ型コンピュータ(いわゆる、ノートパソコン)、または、デスクトップ型コンピュータなどとして実現されてもよい。また、ユーザ端末100は、ゲームプレイに適したゲーム装置であってもよい。
ユーザ端末100は図2に示すように、プロセッサ10と、メモリ11と、ストレージ12と、通信インターフェース(IF)13と、入出力IF14と、タッチスクリーン15(表示部)と、カメラ17と、測距センサ18とを備える。ユーザ端末100が備えるこれらの構成は、通信バスによって互いに電気的に接続される。なお、ユーザ端末100は、タッチスクリーン15に代えて、または、加えて、ユーザ端末100本体とは別に構成されたディスプレイ(表示部)を接続可能な入出力IF14を備えていてもよい。
また、図2に示すように、ユーザ端末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とは、有線を介して信号を送受信する。
図2に示すように、ユーザ端末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とは異なる入力装置(図示せず)から出力される信号をユーザの入力操作として特定し、受け付ける。
(サーバ200)
サーバ200は、一例として、ワークステーションまたはパーソナルコンピュータなどの汎用コンピュータであってよい。サーバ200は、プロセッサ20と、メモリ21と、ストレージ22と、通信IF23と、入出力IF24とを備える。サーバ200が備えるこれらの構成は、通信バスによって互いに電気的に接続される。
(ゲームプレイ端末300)
ゲームプレイ端末300は、一例として、パーソナルコンピュータなどの汎用コンピュータであってよい。ゲームプレイ端末300は、プロセッサ30と、メモリ31と、ストレージ32と、通信IF33と、入出力IF34とを備える。ゲームプレイ端末300が備えるこれらの構成は、通信バスによって互いに電気的に接続される。
図4に示すように、本実施形態に係るゲームプレイ端末300は、一例として、HMD(Head Mounted Display)セット1000に含まれる。つまり、HMDセット1000が、システム1に含まれていると表現することができ、また、プレイヤは、HMDセット1000を用いてゲームをプレイすると表現することもできる。なお、プレイヤがゲームをプレイするための装置は、HMDセット1000に限定されない。一例として、該装置は、プレイヤにゲームを仮想体験させることが可能な装置であればよい。また、該装置は、スマートフォン、フィーチャーフォン、タブレット型コンピュータ、ラップトップ型コンピュータ(いわゆる、ノートパソコン)、または、デスクトップ型コンピュータなどとして実現されてもよい。また、該装置は、ゲームプレイに適したゲーム装置であってもよい。
HMDセット1000は、ゲームプレイ端末300の他、HMD500、HMDセンサ510、モーションセンサ520、ディスプレイ530、コントローラ540を備える。HMD500は、モニタ51と、注視センサ52と、第1カメラ53と、第2カメラ54と、マイク55と、スピーカ56とを含む。コントローラ540は、モーションセンサ520を含み得る。
HMD500は、プレイヤの頭部に装着され、動作中に仮想空間をプレイヤに提供し得る。より具体的には、HMD500は、右目用の画像および左目用の画像をモニタ51にそれぞれ表示する。プレイヤの各目がそれぞれの画像を視認すると、プレイヤは、両目の視差に基づき当該画像を3次元画像として認識し得る。HMD500は、モニタを備える所謂ヘッドマウントディスプレイと、スマートフォンその他のモニタを有する端末を装着可能なヘッドマウント機器のいずれをも含み得る。
モニタ51は、例えば、非透過型の表示装置として実現される。ある局面において、モニタ51は、プレイヤの両目の前方に位置するようにHMD500の本体に配置されている。したがって、プレイヤは、モニタ51に表示される3次元画像を視認すると、仮想空間に没入することができる。ある局面において、仮想空間は、例えば、背景、プレイヤが操作可能なオブジェクト、プレイヤが選択可能なメニューの画像を含む。ある局面において、モニタ51は、所謂スマートフォンその他の情報表示端末が備える液晶モニタまたは有機EL(Electro Luminescence)モニタとして実現され得る。
別の局面において、モニタ51は、透過型の表示装置として実現され得る。この場合、HMD500は、図1に示されるようにプレイヤの目を覆う密閉型ではなく、メガネ型のような開放型であり得る。透過型のモニタ51は、その透過率を調整することにより、一時的に非透過型の表示装置として構成可能であってもよい。モニタ51は、仮想空間を構成する画像の一部と、現実空間とを同時に表示する構成を含んでいてもよい。例えば、モニタ51は、HMD500に搭載されたカメラで撮影した現実空間の画像を表示してもよいし、一部の透過率を高く設定することにより現実空間を視認可能にしてもよい。
ある局面において、モニタ51は、右目用の画像を表示するためのサブモニタと、左目用の画像を表示するためのサブモニタとを含み得る。別の局面において、モニタ51は、右目用の画像と左目用の画像とを一体として表示する構成であってもよい。この場合、モニタ51は、高速シャッタを含む。高速シャッタは、画像がいずれか一方の目にのみ認識されるように、右目用の画像と左目用の画像とを交互に表示可能に作動する。
ある局面において、HMD500は、図示せぬ複数の光源を含む。各光源は例えば、赤外線を発するLED(Light Emitting Diode)により実現される。HMDセンサ510は、HMD500の動きを検出するためのポジショントラッキング機能を有する。より具体的には、HMDセンサ510は、HMD500が発する複数の赤外線を読み取り、現実空間内におけるHMD500の位置および傾きを検出する。
別の局面において、HMDセンサ510は、カメラにより実現されてもよい。この場合、HMDセンサ510は、カメラから出力されるHMD500の画像情報を用いて、画像解析処理を実行することにより、HMD500の位置および傾きを検出することができる。
別の局面において、HMD500は、位置検出器として、HMDセンサ510の代わりに、あるいはHMDセンサ510に加えてセンサ(不図示)を備えてもよい。HMD500は、該センサを用いて、HMD500自身の位置および傾きを検出し得る。例えば、該センサが角速度センサ、地磁気センサ、あるいは加速度センサである場合、HMD500は、HMDセンサ510の代わりに、これらの各センサのいずれかを用いて、自身の位置および傾きを検出し得る。一例として、HMD500に備えられたセンサが角速度センサである場合、角速度センサは、現実空間におけるHMD500の3軸周りの角速度を経時的に検出する。HMD500は、各角速度に基づいて、HMD500の3軸周りの角度の時間的変化を算出し、さらに、角度の時間的変化に基づいて、HMD500の傾きを算出する。
注視センサ52は、プレイヤの右目および左目の視線が向けられる方向を検出する。つまり、注視センサ52は、プレイヤの視線を検出する。視線の方向の検出は、例えば、公知のアイトラッキング機能によって実現される。注視センサ52は、当該アイトラッキング機能を有するセンサにより実現される。ある局面において、注視センサ52は、右目用のセンサおよび左目用のセンサを含むことが好ましい。注視センサ52は、例えば、プレイヤの右目および左目に赤外光を照射するとともに、照射光に対する角膜および虹彩からの反射光を受けることにより各眼球の回転角を検出するセンサであってもよい。注視センサ52は、検出した各回転角に基づいて、プレイヤの視線を検知することができる。
第1カメラ53は、プレイヤの顔の下部を撮影する。より具体的には、第1カメラ53は、プレイヤの鼻および口などを撮影する。第2カメラ54は、プレイヤの目および眉などを撮影する。HMD500のプレイヤ側の筐体をHMD500の内側、HMD500のプレイヤとは逆側の筐体をHMD500の外側と定義する。ある局面において、第1カメラ53は、HMD500の外側に配置され、第2カメラ54は、HMD500の内側に配置され得る。第1カメラ53および第2カメラ54が生成した画像は、ゲームプレイ端末300に入力される。別の局面において、第1カメラ53と第2カメラ54とを1台のカメラとして実現し、この1台のカメラでプレイヤの顔を撮影するようにしてもよい。
マイク55は、プレイヤの発話を音声信号(電気信号)に変換してゲームプレイ端末300に出力する。スピーカ56は、音声信号を音声に変換してプレイヤに出力する。別の局面において、HMD500は、スピーカ56に替えてイヤホンを含み得る。
コントローラ540は、有線または無線によりゲームプレイ端末300に接続されている。コントローラ540は、プレイヤからゲームプレイ端末300への命令の入力を受け付ける。ある局面において、コントローラ540は、プレイヤによって把持可能に構成される。別の局面において、コントローラ540は、プレイヤの身体あるいは衣類の一部に装着可能に構成される。さらに別の局面において、コントローラ540は、ゲームプレイ端末300から送信される信号に基づいて、振動、音、光のうちの少なくともいずれかを出力するように構成されてもよい。さらに別の局面において、コントローラ540は、プレイヤから、仮想空間に配置されるオブジェクトの位置や動きを制御するための操作を受け付ける。
ある局面において、コントローラ540は、複数の光源を含む。各光源は例えば、赤外線を発するLEDにより実現される。HMDセンサ510は、ポジショントラッキング機能を有する。この場合、HMDセンサ510は、コントローラ540が発する複数の赤外線を読み取り、現実空間内におけるコントローラ540の位置および傾きを検出する。別の局面において、HMDセンサ510は、カメラにより実現されてもよい。この場合、HMDセンサ510は、カメラから出力されるコントローラ540の画像情報を用いて、画像解析処理を実行することにより、コントローラ540の位置および傾きを検出することができる。
モーションセンサ520は、ある局面において、プレイヤの手に取り付けられて、プレイヤの手の動きを検出する。例えば、モーションセンサ520は、手の回転速度、回転数等を検出する。検出された信号は、ゲームプレイ端末300に送られる。モーションセンサ520は、例えば、コントローラ540に設けられている。ある局面において、モーションセンサ520は、例えば、プレイヤに把持可能に構成されたコントローラ540に設けられている。別の局面において、現実空間における安全のため、コントローラ540は、手袋型のようにプレイヤの手に装着されることにより容易に飛んで行かないものに装着される。さらに別の局面において、プレイヤに装着されないセンサがプレイヤの手の動きを検出してもよい。例えば、プレイヤを撮影するカメラの信号が、プレイヤの動作を表わす信号として、ゲームプレイ端末300に入力されてもよい。モーションセンサ520とゲームプレイ端末300とは、一例として、無線により互いに接続される。無線の場合、通信形態は特に限られず、例えば、Bluetoothその他の公知の通信手法が用いられる。
ディスプレイ530は、モニタ51に表示されている画像と同様の画像を表示する。これにより、HMD500を装着しているプレイヤ以外のユーザにもプレイヤと同様の画像を視聴させることができる。ディスプレイ530に表示される画像は、3次元画像である必要はなく、右目用の画像や左目用の画像であってもよい。ディスプレイ530としては、例えば、液晶ディスプレイや有機ELモニタなどが挙げられる。
ゲームプレイ端末300は、HMD500の各部、コントローラ540、およびモーションセンサ520から取得した各種情報に基づいて、プレイヤの操作対象となるキャラクタを動作させ、ゲームを進行させる。ここでの「動作」には、身体の各部を動かすこと、姿勢を変えること、顔の表情を変えること、移動、発話、仮想空間に配置されたオブジェクトに触れたり、動かしたりすること、キャラクタが把持する武器、道具などを使用することなどが含まれる。すなわち、本ゲームでは、プレイヤが身体の各部を動かすことにより、キャラクタもプレイヤと同様に身体の各部を動かす。また、本ゲームでは、プレイヤが発話した内容をキャラクタが発話する。換言すれば、本ゲームにおいて、キャラクタは、プレイヤの分身としてふるまうアバターオブジェクトである。一例として、キャラクタの動作の少なくとも一部が、プレイヤによるコントローラ540に対する入力により実行されてもよい。
本実施形態では、モーションセンサ520は、一例として、プレイヤの両手、プレイヤの両足、プレイヤの腰部、および、プレイヤの頭部に取り付けられる。プレイヤの両手に取り付けられるモーションセンサ520は、上述したとおり、コントローラ540に設けられていてもよい。また、プレイヤの頭部に取り付けられるモーションセンサ520は、HMD500に設けられていてもよい。モーションセンサ520は、さらに、ユーザの両肘や両膝に取り付けられてもよい。プレイヤに取り付けるモーションセンサ520の数を増やすことにより、プレイヤの動きをより正確にキャラクタに反映させることができる。
また、プレイヤは、モーションセンサ520を身体の各部に取り付けることに代えて、1以上のモーションセンサ520が取り付けられたスーツを着用してもよい。つまり、モーションキャプチャの方法は、モーションセンサ520を用いる例に限定されない。
(配信端末400)
配信端末400は、スマートフォン、PDA(Personal Digital Assistant)、またはタブレット型コンピュータ等の携帯端末であってよい。また、配信端末400は、デスクトップパソコン等の、いわゆる据え置き型の端末であってもよい。
配信端末400は、図5に示すように、プロセッサ40と、メモリ41と、ストレージ42と、通信IF43と、入出力IF44と、タッチスクリーン45とを備える。なお、配信端末400は、タッチスクリーン45に代えて、または、加えて、配信端末400本体とは別に構成されたディスプレイ(表示部)を接続可能な入出力IF44を備えていてもよい。
コントローラ1021は、1つ以上のボタン、レバー、スティック、ホイール等の物理的な入力機構を有していてもよい。コントローラ1021は、配信端末400の操作者(本実施形態ではプレイヤ)が、該入力機構に対して入力した入力操作に基づく出力値を配信端末400へ送信する。また、コントローラ1021は、加速度センサ、および、角速度センサ等の各種センサを有していてもよく、該各種センサの出力値を配信端末400へ送信してもよい。上述の出力値は、通信IF43を介して配信端末400に受け付けられる。
配信端末400は、カメラと、測距センサ(ともに不図示)とを備えていてもよい。配信端末400が備えることに代えて、または、加えて、コントローラ1021がカメラと、測距センサとを有してしてもよい。
以上で説明したとおり、配信端末400は、該配信端末400に対して情報を入力する機構の一例として、通信IF43、入出力IF44、タッチスクリーン45を備える。入力する機構としての上述の各部は、ユーザの入力操作を受け付けるように構成された操作部と捉えることができる。
操作部がタッチスクリーン45で構成されている場合、配信端末400は、タッチスクリーン45の入力部451に対して実施されたユーザの操作をユーザの入力操作として特定し、受け付ける。あるいは、操作部が通信IF43で構成される場合、配信端末400は、コントローラ1021から送信される信号(例えば、出力値)をユーザの入力操作として特定し、受け付ける。あるいは、操作部が入出力IF44で構成される場合、配信端末400は、該入出力IF44と接続される入力装置(図示せず)から出力される信号をユーザの入力操作として特定し、受け付ける。
<各装置のハードウェア構成要素>
プロセッサ10、20、30、40はそれぞれ、ユーザ端末100、サーバ200、ゲームプレイ端末300、配信端末400の全体の動作を制御する。プロセッサ10、20、30、40は、CPU(Central Processing Unit)、MPU(Micro Processing Unit)、およびGPU(Graphics Processing Unit)を含む。プロセッサ10、20、30、40は、それぞれ、後述するストレージ12、22、32、42からプログラムを読み出す。そして、プロセッサ10、20、30、40は、それぞれ、読み出したプログラムを、後述するメモリ11、21、31、41に展開する。プロセッサ10、20、30は、展開したプログラムを実行する。
メモリ11、21、31、41は主記憶装置である。メモリ11、21、31、41は、ROM(Read Only Memory)およびRAM(Random Access Memory)等の記憶装置で構成される。メモリ11は、プロセッサ10が後述するストレージ12から読み出したプログラムおよび各種データを一時的に記憶することにより、プロセッサ10に作業領域を提供する。メモリ11は、プロセッサ10がプログラムに従って動作している間に生成した各種データも一時的に記憶する。メモリ21は、プロセッサ20が後述するストレージ22から読み出した各種プログラムおよびデータを一時的に記憶することにより、プロセッサ20に作業領域を提供する。メモリ21は、プロセッサ20がプログラムに従って動作している間に生成した各種データも一時的に記憶する。メモリ31は、プロセッサ30が後述するストレージ32から読み出した各種プログラムおよびデータを一時的に記憶することにより、プロセッサ30に作業領域を提供する。メモリ31は、プロセッサ30がプログラムに従って動作している間に生成した各種データも一時的に記憶する。メモリ41は、プロセッサ40が後述するストレージ42から読み出したプログラムおよび各種データを一時的に記憶することにより、プロセッサ40に作業領域を提供する。メモリ41は、プロセッサ40がプログラムに従って動作している間に生成した各種データも一時的に記憶する。
本実施形態において、プロセッサ10および30が実行するプログラムは、本ゲームのゲームプログラムであってもよい。本実施形態において、プロセッサ40が実行するプログラムは、動作指図データの配信を実現するための配信プログラムであってもよい。また、プロセッサ10は、さらに、動画の再生を実現するための視聴プログラムを実行してもよい。
本実施形態において、プロセッサ20が実行するプログラムは、上述のゲームプログラム、配信プログラム、視聴プログラムの少なくとも何れかであってもよい。プロセッサ20は、ユーザ端末100、ゲームプレイ端末300、および配信端末400の少なくとも何れかからの要求等に応じて、ゲームプログラム、配信プログラム、視聴プログラムの少なくとも何れかを実行する。なお、配信プログラムと視聴プログラムは、並行して実行されてもよい。
すなわち、ゲームプログラムは、ゲームをユーザ端末100、サーバ200、およびゲームプレイ端末300の協働により実現するプログラムであってもよい。配信プログラムは、動作指図データの配信を、サーバ200と配信端末400との協働により実現するプログラムであってもよい。視聴プログラムは、動画の再生を、ユーザ端末100とサーバ200との協働により実現するプログラムであってもよい。
ストレージ12、22、32、42は補助記憶装置である。ストレージ12、22、32、42は、フラッシュメモリまたはHDD(Hard Disk Drive)等の記憶装置で構成される。ストレージ12、32には、例えば、ゲームに関する各種データが格納される。ストレージ42には、動作指図データの配信に関する各種データが格納される。また、ストレージ12には、動画の再生に関する各種データが格納される。ストレージ22には、ゲーム、動作指図データの配信、および動画の再生それぞれに関する各種データのうち、少なくとも一部が格納されてもよい。
通信IF13、23、33、43は、それぞれ、ユーザ端末100、サーバ200、ゲームプレイ端末300、配信端末400における各種データの送受信を制御する。通信IF13、23、33、43は例えば、無線LAN(Local Area Network)を介する通信、有線LAN、無線LAN、または携帯電話回線網を介したインターネット通信、ならびに近距離無線通信等を用いた通信を制御する。
入出力IF14、24、34、44は、それぞれ、ユーザ端末100、サーバ200、ゲームプレイ端末300、配信端末400がデータの入力を受け付けるため、また、データを出力するためのインターフェースである。入出力IF14、24、34、44は、USB(Universal Serial Bus)等を介してデータの入出力を行ってもよい。入出力IF14、24、34、44は、物理ボタン、カメラ、マイク、スピーカ、マウス、キーボード、ディスプレイ、スティック、レバーなどを含み得る。また、入出力IF14、24、34、44は、周辺機器との間でデータを送受信するための接続部を含み得る。
タッチスクリーン15は、入力部151と表示部152(ディスプレイ)とを組み合わせた電子部品である。タッチスクリーン45は、入力部451と表示部452とを組み合わせた電子部品である。入力部151および451は、一例として、タッチセンシティブなデバイスであり、例えばタッチパッドによって構成される。表示部152および452は、例えば液晶ディスプレイ、または有機EL(Electro-Luminescence)ディスプレイ等によって構成される。
入力部151および451は、入力面に対しユーザの操作(主にタッチ操作、スライド操作、スワイプ操作、およびタップ操作等の物理的接触操作)が入力された位置を検知して、位置を示す情報を入力信号として送信する機能を備える。入力部151および451は、図示しないタッチセンシング部を備えていればよい。タッチセンシング部は、静電容量方式または抵抗膜方式等のどのような方式を採用したものであってもよい。
図示していないが、ユーザ端末100および配信端末400は、それぞれ、ユーザ端末100および配信端末400の保持姿勢を特定するための1以上のセンサを備えていてもよい。このセンサは、例えば、加速度センサ、または、角速度センサ等であってもよい。
ユーザ端末100および配信端末400がセンサを備えている場合、プロセッサ10および40は、それぞれ、センサの出力からユーザ端末100および配信端末400の保持姿勢を特定して、保持姿勢に応じた処理を行うことも可能になる。例えば、プロセッサ10および40は、それぞれ、ユーザ端末100および配信端末400が縦向きに保持されているときには、縦長の画像を表示部152および452に表示させる縦画面表示としてもよい。一方、ユーザ端末100および配信端末400が横向きに保持されているときには、横長の画像を表示部に表示させる横画面表示としてもよい。このように、プロセッサ10および40は、それぞれ、ユーザ端末100および配信端末400の保持姿勢に応じて縦画面表示と横画面表示とを切り替え可能であってもよい。
<システム1の機能的構成>
図6は、システム1に含まれるユーザ端末100、サーバ200、およびHMDセット1000の機能的構成を示すブロック図である。図7は、図6に示す配信端末400の機能的構成を示すブロック図である。
ユーザ端末100は、ユーザの入力操作を受け付ける入力装置としての機能と、ゲームの画像や音声を出力する出力装置としての機能を有する。ユーザ端末100は、プロセッサ10、メモリ11、ストレージ12、通信IF13、入出力IF14、およびタッチスクリーン15等の協働によって、制御部110および記憶部120として機能する。
サーバ200は、ユーザ端末100、HMDセット1000、および配信端末400の間の各種情報の送受信を仲介する機能を有する。サーバ200は、プロセッサ20、メモリ21、ストレージ22、通信IF23、および入出力IF24等の協働によって、制御部210および記憶部220として機能する。
HMDセット1000(ゲームプレイ端末300)は、プレイヤの入力操作を受け付ける入力装置としての機能と、ゲームの画像や音声を出力する出力装置としての機能と、ゲーム進行情報を、サーバ200を介してユーザ端末100へリアルタイムに送信する機能を有する。HMDセット1000は、ゲームプレイ端末300のプロセッサ30、メモリ31、ストレージ32、通信IF33、入出力IF34、並びに、HMD500、HMDセンサ510、モーションセンサ520、およびコントローラ540等の協働によって、制御部310および記憶部320として機能する。
配信端末400は、動作指図データを生成して、該動作指図データを、サーバ200を介してユーザ端末100へ送信する機能を有する。配信端末400は、プロセッサ40、メモリ41、ストレージ42、通信IF43、入出力IF44、およびタッチスクリーン45等の協働によって、制御部410および記憶部420として機能する。
(各装置の記憶部が格納するデータ)
記憶部120は、ゲームプログラム131(プログラム)、ゲーム情報132、および、ユーザ情報133を格納する。記憶部220は、ゲームプログラム231、ゲーム情報232、ユーザ情報233、および、ユーザリスト234を格納する。記憶部320は、ゲームプログラム331、ゲーム情報332、および、ユーザ情報333を格納する。記憶部420は、ユーザリスト421、モーションリスト422、配信プログラム423(プログラム、第2プログラム)を格納する。
ゲームプログラム131、231、331は、それぞれ、ユーザ端末100、サーバ200、HMDセット1000が実行するゲームプログラムである。ゲームプログラム131、231、331に基づいて各装置が協働して動作することにより、本ゲームが実現される。なお、ゲームプログラム131および331は、記憶部220に格納され、ユーザ端末100およびHMDセット1000にそれぞれダウンロードされる構成でもよい。なお、本実施形態では、ユーザ端末100は、ゲームプログラム131に基づいて、配信端末400から受信したデータをレンダリングし、動画を再生するものとする。換言すれば、ゲームプログラム131は、配信端末400から配信された動画指図データを用いて、動画を再生するためのプログラムでもある。該動画を再生するためのプログラムは、ゲームプログラム131と異なってもよい。この場合、記憶部120は、ゲームプログラム131とは別に、該動画を再生するためのプログラムを格納する。
ゲーム情報132、232、332は、それぞれ、ユーザ端末100、サーバ200、HMDセット1000がゲームプログラムを実行する際に参照するデータである。ユーザ情報133、233、333は、ユーザ端末100のユーザのアカウントに関するデータである。ゲーム情報232は、各ユーザ端末100のゲーム情報132、および、HMDセット1000のゲーム情報332である。ユーザ情報233は、各ユーザ端末100のユーザ情報133、および、ユーザ情報333に含まれる、プレイヤのユーザ情報である。ユーザ情報333は、各ユーザ端末100のユーザ情報133、および、プレイヤのユーザ情報である。
ユーザリスト234およびユーザリスト421は、ゲームに参加したユーザのリストである。ユーザリスト234およびユーザリスト421は、プレイヤによる直近のゲームプレイにおいて参加したユーザのリストの他、該ゲームプレイ以前の各ゲームプレイにおいて参加したユーザのリストを含んでいてもよい。モーションリスト422は、予め作成されている複数のモーションデータのリストである。モーションリスト422は、例えば、各モーションを識別する情報(例えば、モーション名)のそれぞれに、モーションデータが対応付けられたリストである。配信プログラム423は、ユーザ端末100にて動画を再生するための動作指図データの、ユーザ端末100への配信を実現するためのプログラムである。
(サーバ200の機能的構成)
制御部210は、記憶部220に格納されたゲームプログラム231を実行することにより、サーバ200を統括的に制御する。例えば制御部210は、ユーザ端末100、HMDセット1000、および配信端末400の間の各種情報の送受信を仲介する。
制御部210は、ゲームプログラム231の記述に応じて、通信仲介部211、ログ生成部212、リスト生成部213として機能する。制御部210は、ゲームプレイおよび動作指図データの配信に係る各種情報の送受信の仲介、並びに、ゲームの進行の支援のために、図示しないその他の機能ブロックとしても機能することができる。
通信仲介部211は、ユーザ端末100、HMDセット1000、および配信端末400の間の各種情報の送受信を仲介する。例えば、通信仲介部211は、HMDセット1000から受信したゲーム進行情報をユーザ端末100へ送信する。ゲーム進行情報は、プレイヤによって操作されるキャラクタの動き、該キャラクタのパラメータ、該キャラクタが所持しているアイテムや武器、敵キャラクタなどの情報などを示すデータが含まれる。サーバ200は、ゲーム進行情報を、ゲームに参加している全てのユーザのユーザ端末100へ送信する。換言すれば、サーバ200は、共通のゲーム進行情報をゲームに参加している全てのユーザのユーザ端末100へ送信する。これにより、ゲームに参加している全てのユーザのユーザ端末100それぞれにおいて、HMDセット1000と同様にゲームが進行する。
また、例えば、通信仲介部211は、ユーザ端末100のいずれかから受信した、プレイヤによるゲームの進行を支援するための情報を、その他のユーザ端末100、および、HMDセット1000へ送信する。該情報は、一例として、プレイヤがゲームを有利に進行するためのアイテムであって、プレイヤ(キャラクタ)に提供されるアイテムを示すアイテム情報であってもよい。アイテム情報は、アイテムを提供したユーザを示す情報(ユーザ名、ユーザIDなど)を含む。また、通信仲介部211は、配信端末400からユーザ端末100への動作指図データの配信を仲介してもよい。
ログ生成部212は、HMDセット1000から受信するゲーム進行情報に基づいて、ゲーム進行のログを生成する。リスト生成部213は、ゲームプレイの終了後にユーザリスト234を生成する。詳細については後述するが、ユーザリスト234における各ユーザには、そのユーザが行ったプレイヤへの支援の内容を示すタグが関連付けられている。リスト生成部213は、ログ生成部212が生成したゲーム進行のログに基づいて、タグを生成し、該当するユーザに関連付ける。なお、リスト生成部213は、ゲームの運営者などがパーソナルコンピュータなどの端末装置を用いて入力した、各ユーザが行ったプレイヤへの支援の内容を、タグとして、該当するユーザに関連付けてもよい。これにより、各ユーザが行った支援の内容がより詳細なものとなる。なお、ユーザ端末100は、ユーザがゲームに参加する際、ユーザの操作に基づいて、ユーザを示す情報をサーバ200へ送信する。例えば、ユーザ端末100は、ユーザが入力したユーザIDをサーバ200へ送信する。つまり、サーバ200は、ゲームに参加している全てのユーザについて、各ユーザを示す情報を保持している。リスト生成部213は、該情報を用いて、ユーザリスト234を生成すればよい。
(HMDセット1000の機能的構成)
制御部310は、記憶部320に格納されたゲームプログラム331を実行することにより、HMDセット1000を統括的に制御する。例えば、制御部310は、ゲームプログラム331、および、プレイヤの操作に従って、ゲームを進行させる。また、制御部310は、ゲームを進行させている間、必要に応じて、サーバ200と通信して、情報の送受信を行う。制御部310は、情報の送受信を、サーバ200を介さずにユーザ端末100と直接行ってもよい。
制御部310は、ゲームプログラム331の記述に応じて、操作受付部311、表示制御部312、UI制御部313、アニメーション生成部314、ゲーム進行部315、仮想空間制御部316、および反応処理部317として機能する。制御部310は、実行されるゲームの性質に応じて、該ゲームに登場するキャラクタの制御などのために、図示しないその他の機能ブロックとしても機能することができる。
操作受付部311は、プレイヤの入力操作を検知し、受け付ける。操作受付部311は、HMD500、モーションセンサ520、コントローラ540などから入力された信号を受け付け、いかなる入力操作がなされたかを判別し、その結果を制御部310の各要素に出力する。
UI制御部313は、モニタ51、ディスプレイ530などに表示させるユーザインターフェース(以下、UI)画像を制御する。UI画像は、プレイヤが、ゲームの進行上必要な入力をHMDセット1000に対して行うためのツール、または、ゲームの進行中に出力される情報をHMDセット1000から得るためのツールである。UI画像は、これには限定されないが、例えば、アイコン、ボタン、リスト、メニュー画面などである。
アニメーション生成部314は、各種オブジェクトの制御態様に基づいて、各種オブジェクトのモーションを示すアニメーションを生成する。例えば、アニメーション生成部314は、オブジェクト(例えば、プレイヤのアバターオブジェクト)がまるでそこにいるかのように動いたり、口を動かしたり、表情を変えたりする様子を表現したアニメーション等を生成してもよい。
ゲーム進行部315は、ゲームプログラム331、プレイヤによる入力操作、および、該入力操作に応じたアバターオブジェクトの動作などに基づいて、ゲームを進行する。例えば、ゲーム進行部315は、アバターオブジェクトが所定の動作を行った場合に、所定のゲーム処理を行う。また、例えば、ゲーム進行部315は、ユーザ端末100におけるユーザの操作を表す情報を受信し、当該ユーザの操作に基づいてゲーム処理を行ってもよい。また、ゲーム進行部315は、ゲームの進行に従ってゲーム進行情報を生成し、サーバ200へ送信する。該ゲーム進行情報は、サーバ200を介してユーザ端末100へ送信される。これにより、HMDセット1000におけるゲームの進行が、ユーザ端末100において共有される。換言すれば、HMDセット1000におけるゲームの進行と、ユーザ端末100におけるゲームの進行とが同期する。
仮想空間制御部316は、ゲームの進行に応じて、プレイヤに提供される仮想空間に関する各種の制御を行う。一例として、仮想空間制御部316は、各種オブジェクトを生成し、仮想空間に配置する。また、仮想空間制御部316は、仮想カメラを仮想空間に配置する。また、仮想空間制御部316は、ゲームの進行に応じて、仮想空間に配置した各種オブジェクトを動作させる。また、仮想空間制御部316は、ゲームの進行に応じて、仮想空間に配置した仮想カメラの位置、傾きを制御する。
表示制御部312は、モニタ51、ディスプレイ530に対して、上述の各要素によって実行された処理結果が反映されたゲーム画面を出力する。表示制御部312は、仮想空間に配置された仮想カメラからの視界に基づく画像を、ゲーム画面として、モニタ51、ディスプレイ530に表示してもよい。また、表示制御部312は、アニメーション生成部314によって生成されたアニメーションを該ゲーム画面に含めてもよい。また、表示制御部312は、UI制御部313によって制御される上述のUI画像を、該ゲーム画面に重畳して描画してもよい。
反応処理部317は、ユーザ端末100のユーザによる、プレイヤのゲームプレイに対する反応についてフィードバックを受け付けて、これを、プレイヤに対して出力する。本実施形態では、例えば、ユーザ端末100は、ユーザの入力操作に基づいて、アバターオブジェクトに宛てたコメント(メッセージ)を作成することができる。反応処理部317は、該コメントのコメントデータを受け付けて、これを出力する。反応処理部317は、ユーザのコメントに対応するテキストデータを、モニタ51、ディスプレイ530に表示してもよいし、ユーザのコメントに対応する音声データを、図示しないスピーカから出力してもよい。前者の場合、反応処理部317は、上記テキストデータに対応する画像(すなわち、コメントの内容を含む画像)を、ゲーム画面に重畳して描画してもよい。
(ユーザ端末100の機能的構成)
制御部110は、記憶部120に格納されたゲームプログラム131を実行することにより、ユーザ端末100を統括的に制御する。例えば、制御部110は、ゲームプログラム131、および、ユーザの操作に従って、ゲームを進行させる。また、制御部110は、ゲームを進行させている間、必要に応じて、サーバ200と通信して、情報の送受信を行う。制御部110は、情報の送受信を、サーバ200を介さずにHMDセット1000と直接行ってもよい。
制御部110は、ゲームプログラム131の記述に応じて、操作受付部111、表示制御部112、UI制御部113、アニメーション生成部114、ゲーム進行部115、仮想空間制御部116、および動画再生部117として機能する。制御部110は、実行されるゲームの性質に応じて、ゲームの進行のために、図示しないその他の機能ブロックとしても機能することができる。
操作受付部111は、入力部151に対するユーザの入力操作を検知し受け付ける。操作受付部111は、タッチスクリーン15およびその他の入出力IF14を介したコンソールに対してユーザが及ぼした作用から、いかなる入力操作がなされたかを判別し、その結果を制御部110の各要素に出力する。
例えば、操作受付部111は、入力部151に対する入力操作を受け付け、該入力操作の入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部111は、入力操作の種類として、例えばタッチ操作、スライド操作、スワイプ操作、およびタップ操作等を特定する。また、操作受付部111は、連続して検知されていた入力が途切れると、タッチスクリーン15から接触入力が解除されたことを検知する。
UI制御部113は、ユーザの入力操作、および、受信したゲーム進行情報の少なくとも何れかに応じて、UIを構築するために表示部152に表示させるUI画像を制御する。UI画像は、ユーザが、ゲームの進行上必要な入力をユーザ端末100に対して行うためのツール、または、ゲームの進行中に出力される情報をユーザ端末100から得るためのツールである。UI画像は、これには限定されないが、例えば、アイコン、ボタン、リスト、メニュー画面などである。
アニメーション生成部114は、各種オブジェクトの制御態様に基づいて、各種オブジェクトのモーションを示すアニメーションを生成する。
ゲーム進行部115は、ゲームプログラム131、受信したゲーム進行情報、および、ユーザによる入力操作などに基づいて、ゲームを進行する。ゲーム進行部115は、ユーザによる入力操作により、所定のゲーム処理を行った場合、該ゲーム処理に関する情報を、サーバ200を介してHMDセット1000へ送信する。これにより、該所定のゲーム処理が、HMDセット1000において共有される。換言すれば、HMDセット1000におけるゲームの進行と、ユーザ端末100におけるゲームの進行とが同期する。所定のゲーム処理とは、例えば、アバターオブジェクトにアイテムを提供する処理であり、この例の場合、ゲーム処理に関する情報は、上述したアイテム情報である。
仮想空間制御部116は、ゲームの進行に応じて、ユーザに提供される仮想空間に関する各種の制御を行う。一例として、仮想空間制御部116は、各種オブジェクトを生成し、仮想空間に配置する。また、仮想空間制御部116は、仮想カメラを仮想空間に配置する。また、仮想空間制御部116は、ゲームの進行、具体的には、受信したゲーム進行情報に応じて、仮想空間に配置した各種オブジェクトを動作させる。また、仮想空間制御部316は、ゲームの進行、具体的には、受信したゲーム進行情報に応じて、仮想空間に配置した仮想カメラの位置、傾きを制御する。
表示制御部112は、表示部152に対して、上述の各要素によって実行された処理結果が反映されたゲーム画面を出力する。表示制御部112は、ユーザに提供される仮想空間に配置された仮想カメラからの視界に基づく画像を、ゲーム画面として、表示部152に表示してもよい。また、表示制御部112は、アニメーション生成部114によって生成されたアニメーションを該ゲーム画面に含めてもよい。また、表示制御部112は、UI制御部113によって制御される上述のUI画像を、該ゲーム画面に重畳して描画してもよい。いずれにしても、表示部152に表示されるゲーム画面は、他のユーザ端末100、および、HMDセット1000にて表示されるゲーム画面と同様のゲーム画面である。
動画再生部117は、配信端末400から受信した動作指図データを解析(レンダリング)し、動画を再生する。
(配信端末400の機能的構成)
制御部410は、記憶部420に格納されたプログラム(不図示)を実行することにより、配信端末400を統括的に制御する。例えば、制御部410は、該プログラム、および、配信端末400のユーザ(本実施形態ではプレイヤ)の操作に従って、動作指図データを生成し、ユーザ端末100に配信する。また、制御部410は、必要に応じて、サーバ200と通信して、情報の送受信を行う。制御部410は、情報の送受信を、サーバ200を介さずにユーザ端末100と直接行ってもよい。
制御部410は、プログラムの記述に応じて、通信制御部411、表示制御部412、操作受付部413、音声受付部414、モーション特定部415、および動作指図データ生成部416として機能する。制御部410は、動作指図データの生成および配信のために、図示しないその他の機能ブロックとしても機能することができる。
通信制御部411は、サーバ200、または、サーバ200を介したユーザ端末100との情報の送受信を制御する。通信制御部411は、一例として、サーバ200からユーザリスト421を受信する。また、通信制御部411は、一例として、動作指図データをユーザ端末100へ送信する。
表示制御部412は、表示部452に対して、各要素によって実行された処理結果が反映された各種画面を出力する。表示制御部412は、一例として、受信したユーザリスト234を含む画面を表示する。また、表示制御部412は、一例として、配信する動作指図データに含まれる、アバターオブジェクトを動作させるためのモーションデータを、プレイヤに選択させるためのモーションリスト422を含む画面を表示する。
操作受付部413は、入力部151に対するプレイヤの入力操作を検知し受け付ける。操作受付部111は、タッチスクリーン45およびその他の入出力IF44を介したコンソールに対してプレイヤが及ぼした作用から、いかなる入力操作がなされたかを判別し、その結果を制御部410の各要素に出力する。
例えば、操作受付部413は、入力部451に対する入力操作を受け付け、該入力操作の入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部413は、入力操作の種類として、例えばタッチ操作、スライド操作、スワイプ操作、およびタップ操作等を特定する。また、操作受付部413は、連続して検知されていた入力が途切れると、タッチスクリーン45から接触入力が解除されたことを検知する。
音声受付部414は、配信端末400の周囲で発生した音声を受け付け、該音声の音声データを生成する。音声受付部414は、一例として、プレイヤが発話した音声を受け付け、該音声の音声データを生成する。
モーション特定部415は、プレイヤの入力操作に応じて、モーションリスト422から、プレイヤが選択したモーションデータを特定する。
動作指図データ生成部416は、動作指図データを生成する。一例として、動作指図データ生成部416は、生成された音声データと、特定されたモーションデータとを含む動作指図データを生成する。
なお、図6に示すHMDセット1000、サーバ200、およびユーザ端末100の機能、並びに、図7に示す配信端末400の機能は一例にすぎない。HMDセット1000、サーバ200、ユーザ端末100、および配信端末400の各装置は、他の装置が備える機能の少なくとも一部を備えていてもよい。さらに、HMDセット1000、サーバ200、ユーザ端末100、および配信端末400以外のさらに別の装置をシステム1の構成要素とし、該別の装置にシステム1における処理の一部を実行させてもよい。すなわち、本実施形態においてゲームプログラムを実行するコンピュータは、HMDセット1000、サーバ200、ユーザ端末100、および配信端末400、並びに、それ以外の別の装置の何れであってもよいし、これらの複数の装置の組み合わせにより実現されてもよい。
<仮想空間の制御処理>
図8は、プレイヤに提供される仮想空間、および、ユーザ端末100のユーザに提供される仮想空間の制御処理の流れの一例を示すフローチャートである。図9は、ある実施の形態に従う、プレイヤに提供される仮想空間600A、および、プレイヤが視認する視界画像を示す図である。図10は、ある実施の形態に従う、ユーザ端末100のユーザに提供される仮想空間600B、および、ユーザが視認する視界画像を示す図である。なお以降、仮想空間600Aおよび600Bを区別する必要が無い場合、「仮想空間600」と記載する。
ステップS1において、プロセッサ30は、仮想空間制御部316として、図9に示す仮想空間600Aを規定する。プロセッサ30は、仮想空間データ(不図示)を用いて、仮想空間600Aを規定する。仮想空間データは、ゲームプレイ端末300に記憶されていてもよいし、プロセッサ30が、ゲームプログラム331に基づいて生成してもよいし、プロセッサ30が、サーバ200などの外部の装置から取得してもよい。
仮想空間600は、一例として、中心として定義された点の360度方向の全体を覆う全天球状の構造を有する。図9および図10では、説明を複雑にしないために、仮想空間600のうちの上半分の天球が例示されている。
ステップS2において、プロセッサ30は、仮想空間制御部316として、仮想空間600Aに、アバターオブジェクト610(キャラクタ)を配置する。アバターオブジェクト610は、プレイヤに関連付けられたアバターオブジェクトであり、プレイヤの入力操作に従って動作する。
ステップS3において、プロセッサ30は、仮想空間制御部316として、仮想空間600Aに、その他のオブジェクトを配置する。図9の例では、プロセッサ30は、オブジェクト631〜634を配置する。その他のオブジェクトは、例えば、ゲームプログラム331に従って動作するキャラクタオブジェクト(いわゆるノンプレイヤキャラクタ、NPC)、仮想手などの操作オブジェクト、ゲームの進行に従って配置される動物、植物、人工物、自然物などを模したオブジェクトなどを含み得る。
ステップS4において、プロセッサ30は、仮想空間制御部316として、仮想空間600Aに仮想カメラ620Aを配置する。プロセッサ30は、一例として、仮想カメラ620Aを、アバターオブジェクト610の頭部の位置に配置する。
ステップS5において、プロセッサ30は、視界画像650をモニタ51およびディスプレイ530に表示する。プロセッサ30は、仮想カメラ620Aの初期の位置と傾きとに応じて、仮想空間600Aにおける仮想カメラ620Aからの視界である視界領域640Aを定義する。そして、プロセッサ30は、視界領域640Aに対応する視界画像650を定義する。プロセッサ30は、視界画像650をモニタ51およびディスプレイ530に出力することによって、視界画像650をHMD500およびディスプレイ530に表示させる。
図9の例において、図9(A)に示すように、オブジェクト634の一部が視界領域640Aに含まれているため、視界画像650は、図9(B)に示すようにオブジェクト634の一部を含む。
ステップS6において、プロセッサ30は、初期配置情報を、サーバ200を介してユーザ端末100へ送信する。初期配置情報とは、仮想空間600Aにおける各種オブジェクトの初期の配置位置を示す情報である。図9の例において、初期配置情報は、アバターオブジェクト610、および、オブジェクト631〜634の初期の配置位置の情報を含む。初期配置情報は、ゲーム進行情報の1つであると表現することもできる。
ステップS7において、プロセッサ30は、仮想空間制御部316として、HMD500の動きに応じて仮想カメラ620Aを制御する。具体的には、プロセッサ30は、HMD500の動き、すなわち、プレイヤの頭部の姿勢に応じて、仮想カメラ620Aの向きおよび傾きを制御する。後述のように、プロセッサ30は、プレイヤが頭部を動かす(頭部の姿勢を変更する)と、この動きに合わせて、アバターオブジェクト610の頭部を動かす。プロセッサ30は、例えば、アバターオブジェクト610の視線の方向と、仮想カメラ620Aの視線の方向とが一致するように、仮想カメラ620Aの向きおよび傾きを制御する。ステップS8において、プロセッサ30は、仮想カメラ620Aの向きおよび傾きが変更されたことに応じて、視界画像650を更新する。
ステップS9において、プロセッサ30は、仮想空間制御部316として、プレイヤの動きに応じて、アバターオブジェクト610を動かす。一例として、プロセッサ30は、プレイヤが現実空間で移動したことに応じて、仮想空間600Aでアバターオブジェクト610を移動させる。また、プロセッサ30は、プレイヤが現実空間で頭部を動かしたことに応じて、仮想空間600Aでアバターオブジェクト610の頭部を動かす。
ステップS10において、プロセッサ30は、仮想空間制御部316として、仮想カメラ620Aを、アバターオブジェクト610に追随するように移動させる。つまり、仮想カメラ620Aは、アバターオブジェクト610が移動しても、常にアバターオブジェクト610の頭部の位置にある。
プロセッサ30は、仮想カメラ620Aの移動に応じて、視界画像650を更新する。つまり、プロセッサ30は、プレイヤの頭部の姿勢と、仮想空間600Aにおける仮想カメラ620Aの位置とに応じて、視界領域640Aを更新する。その結果、視界画像650が更新される。
ステップS11において、プロセッサ30は、アバターオブジェクト610の動作指図データを、サーバ200を介してユーザ端末100へ送信する。ここでの動作指図データは、仮想体験中(例えば、ゲームプレイ中)において、プレイヤの動作を取り込んだモーションデータ、プレイヤが発話した音声の音声データ、コントローラ540に対する入力操作の内容を示す操作データの少なくとも何れかを含む。プレイヤがゲームをプレイしている場合、動作指図データは、例えば、ゲーム進行情報としてユーザ端末100へ送信される。
ステップS7〜S11の処理は、プレイヤがゲームをプレイしている間、継続して繰り返し実行される。
ステップS21において、ユーザ3のユーザ端末100のプロセッサ10は、仮想空間制御部116として、図10に示す仮想空間600Bを規定する。プロセッサ10は、仮想空間データ(不図示)を用いて、仮想空間600Bを規定する。仮想空間データは、ユーザ端末100に記憶されていてもよいし、プロセッサ10が、ゲームプログラム131に基づいて生成してもよいし、プロセッサ10が、サーバ200などの外部の装置から取得してもよい。
ステップS22において、プロセッサ10は、初期配置情報を受信する。ステップS23において、プロセッサ10は、仮想空間制御部116として、初期配置情報に応じて各種オブジェクトを仮想空間600Bに配置する。図10の例の場合、各種オブジェクトは、アバターオブジェクト610、および、オブジェクト631〜634である。
ステップS24において、プロセッサ10は、仮想空間制御部116として、仮想空間600Bに仮想カメラ620Bを配置する。プロセッサ10は、一例として、仮想カメラ620Bを、図10(A)に示す位置に配置する。
ステップS25において、プロセッサ10は、視界画像660を表示部152に表示する。プロセッサ10は、仮想カメラ620Bの初期の位置と傾きとに応じて、仮想空間600Bにおける仮想カメラ620Bからの視界である視界領域640Bを定義する。そして、プロセッサ10は、視界領域640Bに対応する視界画像660を定義する。プロセッサ10は、視界画像660を表示部152に出力することによって、視界画像660を表示部152に表示させる。
図10の例において、図10(A)に示すように、アバターオブジェクト610およびオブジェクト631が視界領域640Bに含まれているため、視界画像660は、図10(B)に示すようにアバターオブジェクト610およびオブジェクト631を含む。
ステップS26において、プロセッサ10は、動作指図データを受信する。ステップS27において、プロセッサ10は、仮想空間制御部116として、動作指図データに応じて、仮想空間600Bでアバターオブジェクト610を動かす。換言すれば、プロセッサ10は、リアルタイムレンダリングにより、アバターオブジェクト610が動作している映像を再生する。
ステップS28において、プロセッサ10は、仮想空間制御部116として、操作受付部111として受け付けたユーザの操作に応じて仮想カメラ620Bを制御する。ステップS29において、プロセッサ10は、仮想カメラ620Bの仮想空間600Bにおける位置、仮想カメラ620Bの向きおよび傾きが変更されたことに応じて、視界画像660を更新する。なお、ステップS28において、プロセッサ10は、アバターオブジェクト610の動き、例えば、アバターオブジェクト610の移動や、向きの変更に応じて仮想カメラ620Bを自動的に制御してもよい。例えば、プロセッサ10は、常にアバターオブジェクト610を正面から撮影するように自動的に仮想カメラ620Bを移動させたり、向きおよび傾きを変更したりしてもよい。また、一例として、プロセッサ10は、アバターオブジェクト610の動きに応じて、常にアバターオブジェクト610を後方から撮影するように自動的に仮想カメラ620Bを移動させたり、向きおよび傾きを変更したりしてもよい。
このように、仮想空間600Aにおいて、アバターオブジェクト610は、プレイヤの動きに応じて動作する。この動作を示す動作指図データは、ユーザ端末100に送信される。仮想空間600Bにおいて、アバターオブジェクト610は、受信した動作指図データに応じて動作する。これにより、仮想空間600Aと仮想空間600Bとにおいて、アバターオブジェクト610は同様の動作を行う。換言すれば、ユーザ3は、ユーザ端末100を用いて、プレイヤの動作に応じたアバターオブジェクト610の動作を視認することができる。
<ゲーム概要>
図11は、ユーザ端末100において表示される視界画像の他の例を示す図である。具体的には、プレイヤがプレイしている、システム1が実行するゲーム(本ゲーム)のゲーム画面の一例を示す図である。
本ゲームは、一例として、銃、ナイフなどの武器を操作するアバターオブジェクト610と、NPCである複数の敵オブジェクト671とを仮想空間600に登場させ、アバターオブジェクト610に敵オブジェクト671との対戦を行わせるゲームである。アバターオブジェクト610の体力、使用可能なマガジンの数、銃の残弾数、敵オブジェクト671の残数等の各種ゲームパラメータは、ゲームの進行に応じて更新される。
本ゲームには、複数のステージが用意されており、プレイヤは、各ステージに関連付けられている所定の達成条件を成立させることにより、当該ステージをクリアすることができる。所定の達成条件としては、例えば、出現する敵オブジェクト671をすべて倒すことや、出現する敵オブジェクト671のうちボスオブジェクトを倒すこと、所定のアイテムを獲得すること、所定位置に到達することなどにより成立する条件を含むものであってもよい。該達成条件は、ゲームプログラム131内で定義されている。なお、本ゲームでは、ゲームの内容に即し、達成条件が成立された場合にプレイヤはステージをクリア、換言すれば、アバターオブジェクト610の敵オブジェクト671への勝利(アバターオブジェクト610と敵オブジェクト671との間の勝敗)が決定される。これに対し、例えば、システム1で実行されるゲームがレースゲーム等である場合、ゴールに到達するという条件が成立した場合に、アバターオブジェクト610の順位が決定される。
本ゲームでは、HMDセット1000及び複数のユーザ端末100の間で仮想空間を共有するために、ゲーム進行情報が、所定時間毎に複数のユーザ端末100にライブ配信される。この結果、ゲームを視聴中のユーザ端末100のタッチスクリーン15には、ユーザ端末100に対応する仮想カメラ620Bによって規定される視界領域の視界画像が表示される。また、視界画像の右上段および左上段には、アバターオブジェクト610の体力、使用可能なマガジンの数、銃の残弾数、敵オブジェクト671の残数等を表すパラメータ画像が重畳的に表示される。この視界画像は、ゲーム画面と表現することもできる。
ゲーム進行情報は、上述したとおり、プレイヤの動作を取り込んだモーションデータ、プレイヤが発話した音声の音声データ、コントローラ540に対する入力操作の内容を示す操作データを含む。これらのデータはすなわち、アバターオブジェクト610の位置、姿勢、向きなどを特定するための情報、敵オブジェクト671の位置、姿勢、向きなどを特定する情報、その他オブジェクト(例えば、障害物オブジェクト672、673)の位置などを特定する情報である。プロセッサ10は、ゲーム進行情報を解析(レンダリング)することにより、各オブジェクトの位置、姿勢、向きなどを特定する。
ゲーム情報132は、アバターオブジェクト610、敵オブジェクト671、障害物オブジェクト672、673等の各種オブジェクトのデータを含む。プロセッサ10は、該データと、ゲーム進行情報の解析結果とを用いて、各オブジェクトの位置、姿勢、向きなどを更新する。これにより、ゲームが進行し、仮想空間600Bにおける各オブジェクトは、仮想空間600Aにおける各オブジェクトと同様に動く。具体的には、仮想空間600Bにおいて、アバターオブジェクト610を含む各オブジェクトは、ユーザ端末100に対するユーザからの操作の有無に関わらず、ゲーム進行情報に基づいて動作する。
ユーザ端末100のタッチスクリーン15においては、一例として、UI画像701および702が、視界画像に重畳して表示される。UI画像701は、アバターオブジェクト610を支援するためのアイテム投入操作をユーザ3から受け付けるUI画像711を、タッチスクリーン15に表示するための操作を受け付けるUI画像である。UI画像702は、アバターオブジェクト610(換言すれば、プレイヤ4)に対するコメントを入力し、送信するための操作をユーザ3から受け付けるUI画像(後述)を、タッチスクリーン15に表示するための操作を受け付けるUI画像である。UI画像701および702が受け付ける操作は、例えば、UI画像701および702をタップする操作であってもよい。
UI画像701がタップされると、UI画像711が、視界画像に重畳して表示される。UI画像711は、例えば、マガジンのアイコンが描かれたUI画像711A、救急箱のアイコンが描かれたUI画像711B、三角コーンのアイコンが描かれたUI画像711C、バリケードのアイコンが描かれたUI画像711Dを含む。アイテム投入操作は、例えば、いずれかのUI画像をタップする操作に相当する。
一例として、UI画像711Aがタップされると、アバターオブジェクト610が使用する銃の残弾数が増加する。UI画像711Bがタップされると、アバターオブジェクト610の体力が回復する。UI画像711Cおよび711Dがタップされると、敵オブジェクト671の移動を妨害する障害物オブジェクト672、673が仮想空間に配置される。障害物オブジェクト672、673は、一方が他方に比べて、敵オブジェクト671の移動をより妨害するものであってもよい。
プロセッサ10は、アイテム投入操作が行われたことを示すアイテム投入情報を、サーバ200へ送信する。アイテム投入情報には、アイテム投入操作により指定されたアイテムの種別を特定するための情報が少なくとも含まれる。アイテム投入情報には、アイテムが配置される位置を示す情報など、アイテムに関するその他の情報が含まれていてもよい。アイテム投入情報は、サーバ200を介して、他のユーザ端末100、および、HMDセット1000へ送信される。
図12は、ユーザ端末100において表示される視界画像の他の例を示す図である。具体的には、本ゲームのゲーム画面の一例を示す図であり、ゲームプレイ中のプレイヤとユーザ端末100とのコミュニケーションについて説明するための図である。
図12(A)の例において、ユーザ端末100は、アバターオブジェクト610に発話691を実行させている。具体的には、ユーザ端末100は、ゲーム進行情報に含まれる音声データに従って、アバターオブジェクト610に発話691を実行させている。発話691の内容は、プレイヤ4が発話した「弾が無いよー!」というものである。すなわち、発話691の内容は、マガジンが0、銃に装填した銃弾が1となったことにより、敵オブジェクト671を攻撃する手段を失いそうであることを各ユーザに伝えるものである。
なお、図12(A)では、アバターオブジェクト610の発話を視覚的に示すため吹き出しを用いているが、実際は、ユーザ端末100のスピーカから音声が出力される。なお、音声出力とともに、図12(A)に示す吹き出し(すなわち、音声の内容のテキストを含む吹き出し)が視界画像中に表示されてもよい。これは、後述する発話692でも同様である。
UI画像702に対するタップ操作を受け付けると、ユーザ端末100は、図12(B)に示すように、UI画像705および706(メッセージUI)を視界画像に重畳して表示する。UI画像705は、アバターオブジェクト610(換言すれば、プレイヤ)に対するコメントを表示するUI画像である。UI画像706は、入力されたコメントを送信するためコメント送信操作をユーザ3から受け付けるUI画像である。
ユーザ端末100は、一例として、UI画像705へのタップ操作を受け付けると、キーボードを模したUI画像(不図示、以下、単に「キーボード」と記載)をタッチスクリーン15に表示させる。ユーザ端末100は、キーボードに対するユーザの入力操作に応じたテキストを、UI画像705に表示させる。図12(B)の例では、「マガジン送るね」というテキストがUI画像705に表示されている。
ユーザ端末100は、テキスト入力後に、一例として、UI画像706へのタップ操作を受け付けると、入力した内容(テキストの内容)を示す情報と、ユーザを示す情報とを含むコメント情報をサーバ200へ送信する。コメント情報は、サーバ200を介して、他のユーザ端末100、および、HMDセット1000へ送信される。
UI画像703Aは、コメントを送信したユーザのユーザ名を示すUI画像であり、UI画像704Aは、該ユーザが送信したコメントの内容を示すUI画像である。図12(B)の例では、ユーザ名が「BBBBB」であるユーザが、自身のユーザ端末100を用い、「危ない!」という内容のコメント情報を送信したことにより、UI画像703AおよびUI画像704Aが表示されている。UI画像703AおよびUI画像704Aは、本ゲームに参加しているすべてのユーザ端末100のタッチスクリーン15、および、HMD500のモニタ51に表示される。なお、UI画像703Aおよび704Aは、1つのUI画像であってもよい。すなわち、1つのUI画像にユーザ名とコメントの内容とが含まれていてもよい。
図12(C)の例では、図12に示すユーザ端末100のユーザである、「AAAAA」というユーザ名のユーザが、上述したとおりコメントを入力し、送信したことにより、タッチスクリーン15にUI画像703Bおよび704Bが表示されている。UI画像703Bにはユーザ名「AAAAA」が含まれており、UI画像704Bには、図12(B)の例において入力された「マガジン送るね!」とのコメントが含まれている。
また、図12(C)の例は、ユーザ「AAAAA」がさらに、UI画像701へのタップ操作を入力し、UI画像711をタッチスクリーン15に表示させ、UI画像711Aへのタップ操作を入力した後の視界画像611である。つまり、ユーザ「AAAAA」のユーザ端末100から、他のユーザ端末100およびHMDセット1000に、マガジンを示すアイテム投入情報が送信された結果、ユーザ端末100およびHMDセット1000は、演出オブジェクト674(後述)を仮想空間600に配置している。一例として、ユーザ端末100およびHMDセット1000は、アイテム投入情報にて示された経過時間が経過した後に、演出オブジェクト674に関する演出を実行し、アイテムオブジェクトの効果を発動させる処理を実行する。
図12(D)の例では、アイテムオブジェクトの効果を発動させる処理の実行により、マガジンの数が0から1に増加している。この結果、プレイヤは、ユーザ「AAAAA」に対して、「ありがとう!」と発話し、該発話の音声データが、各ユーザ端末100に送信される。これにより、各ユーザ端末100は、アバターオブジェクト610の発話692として、「ありがとう!」という音声を出力する。
以上のように、本ゲームにおいては、プレイヤの発話に基づくアバターオブジェクト610の発話音声の出力と、各ユーザによるコメントの入力とにより、ユーザとアバターオブジェクト610とのコミュニケーションが実現される。
(ゲームプレイ端末300におけるゲーム進行処理)
図13は、ゲームプレイ端末300で実行されるゲーム進行処理の流れの一例を示すフローチャートである。
ステップS31において、プロセッサ30は、ゲーム進行部315として、ゲームプログラム331とプレイヤの動きとに基づいてゲームを進行させる。ステップS32において、プロセッサ30は、ゲーム進行情報を生成し、ユーザ端末100へ配信する。具体的には、プロセッサ30は、生成したゲーム進行情報を、サーバ200を介して、各ユーザ端末100へ送信する。
ステップS33において、プロセッサ30は、アイテム投入情報を受信すると(S33でYES)、ステップS34において、アイテム投入情報に基づいて、アイテムオブジェクトを仮想空間600Aに配置する。一例として、プロセッサ30は、アイテムオブジェクトの配置の前に、演出オブジェクト674を仮想空間600Aに配置する(図11(C)参照)。演出オブジェクト674は、例えば、プレゼント箱を模したオブジェクトであってもよい。プロセッサ30は、一例として、アイテム投入情報にて示された経過時間が経過した後に、演出オブジェクト674に関する演出を実行してもよい。該演出は、例えば、プレゼント箱の蓋が開くアニメーションであってもよい。プロセッサ30は、該アニメーションの実行の後、アイテムオブジェクトの効果を発動させる処理を実行する。例えば、図11(D)の例では、障害物オブジェクト673を配置する。
プロセッサ30は、アニメーションの実行の後、タップ操作されたUI画像に対応するアイテムオブジェクトを仮想空間600Aに配置してもよい。例えば、UI画像711Aに対してタップ操作が行われた場合、プロセッサ30は、アニメーションの実行の後、マガジンを示すマガジンオブジェクトを仮想空間600Aに配置する。また、UI画像711Bに対してタップ操作が行われた場合、プロセッサ30は、アニメーションの実行の後、救急箱を示す救急箱オブジェクトを仮想空間600Aに配置する。プロセッサ30は、例えば、マガジンオブジェクトまたは救急箱オブジェクトの位置に、アバターオブジェクト610が移動した場合に、マガジンオブジェクトまたは救急箱オブジェクトの効果を発動させる処理を実行してもよい。
プロセッサ30は、ゲームが終了するまで、ステップS31〜S34の処理を継続し、繰り返す。ゲームが終了した場合、例えば、プレイヤがゲームを終了するための所定の入力操作を入力した場合(ステップS35でYES)、図13に示す処理は終了する。
(ユーザ端末100におけるゲーム進行処理)
図14は、ユーザ端末100で実行されるゲーム進行処理の流れの一例を示すフローチャートである。
ステップS41において、プロセッサ10は、ゲーム進行情報を受信する。ステップS42において、プロセッサ10は、ゲーム進行部115として、ゲーム進行情報に基づいてゲームを進行させる。
ステップS43において、プロセッサ10が、ユーザ3によるアイテム投入操作を受け付けると(ステップS43にてYES)、ステップS44において、プロセッサ10は、仮想通貨を消費し、演出オブジェクト674を仮想空間600Bに配置する。ここで、仮想通貨は、ゲームへの参加の前、あるいは、ゲームへの参加中に、ユーザ3がプロセッサ10に対し所定の操作を行うことにより購入(本ゲームに対して課金)されるものであってもよいし、所定の条件を満たした場合にユーザ3に付与されるものであってもよい。所定の条件とは、本ゲームにおけるクエストのクリア等、本ゲームへの参加が必要なものであってもよいし、アンケートに答える等、本ゲームへの参加が不要なものであってもよい。仮想通貨の金額(仮想通貨の所有量)は、一例として、ゲーム情報132としてユーザ端末100に記憶される。
ステップS45において、プロセッサ10は、アイテム投入情報をサーバ200へ送信する。アイテム投入情報は、サーバ200を介してゲームプレイ端末300へ送信される。
プロセッサ10は、演出オブジェクト674の配置後、所定時間が経過すると、アイテムオブジェクトを仮想空間600Aに配置する。図11の例では、障害物オブジェクト673を配置する。つまり、ユーザ3が、UI画像711Cへのタップ操作を入力することにより、所定量の仮想通貨が消費され、障害物オブジェクト673が配置される。
プロセッサ10は、ゲームが終了するまで、ステップS41〜S45の処理を継続し、繰り返す。ゲームが終了した場合、例えば、プレイヤがゲームを終了するための所定の入力操作を行った場合や、ユーザ3が、ゲームから途中退席するための所定の入力操作を行った場合(ステップS46でYES)、図14に示す処理は終了する。
(サーバ200におけるゲーム進行処理)
図15は、サーバ200で実行されるゲーム進行処理の流れの一例を示すフローチャートである。
ステップS51において、プロセッサ20は、ゲーム進行情報をゲームプレイ端末300から受信する。ステップS52において、プロセッサ20は、ログ生成部212として、ゲーム進行のログ(以下、プレイログ)を更新する。なお、プレイログは、一例として、ゲームプレイ端末300から初期配置情報を受信したとき、プロセッサ20が生成する。
ステップS53において、プロセッサ20は、受信したゲーム進行情報を、各ユーザ端末100へ送信する。
ステップS54において、アイテム投入情報をいずれかのユーザ端末100から受信した場合(ステップS54にてYES)、ステップS55において、プロセッサ20は、ログ生成部212としてプレイログを更新する。ステップS56において、プロセッサ20は、受信したアイテム投入情報をゲームプレイ端末300へ送信する。
プロセッサ20は、ゲームが終了するまで、ステップS51〜S56の処理を継続し、繰り返す。ゲームが終了した場合、例えば、ゲームプレイ端末300から、ゲームが終了したことを示す情報を受信した場合(ステップS57でYES)、ステップS58において、プロセッサ20は、リスト生成部213として、プレイログからゲームに参加したユーザのリスト(ユーザリスト234)を生成する。プロセッサ20は、生成したユーザリスト234を、サーバ200に記憶する。
図16は、ユーザリスト234の一具体例を示す図である。「ユーザ」のカラムには、ゲームに参加した各ユーザを示す情報(例えば、ユーザ名)が格納されている。「タグ」のカラムには、各ユーザがプレイヤに対して行った支援に基づいて生成された情報(タグ)が格納されている。図16の例において、「タグ」のカラムに格納されたタグのうち、鍵括弧を有さないものは、プロセッサ20が自動生成した情報であり、鍵括弧を有するものは、ゲームの運営者が手動で入力した情報である。
図16の例において、ユーザ「AAAAA」には、マガジン、10F、ボス、「マガジンのプレゼントによりボスに勝利」という情報が対応付けられている。これは、例えば、10Fというステージでのボス戦において、ユーザ「AAAAA」がマガジンを投入し、その投入されたマガジンの銃弾でアバターオブジェクト610がボスに勝利したことを示している。
また、ユーザ「BBBBB」には、救急箱、3F、ザコ、「ゲームオーバー寸前で回復」という情報が対応付けられている、これは、例えば、3Fというステージのザコ敵との戦闘において、ユーザ「BBBBB」が救急箱を投入し、その結果、アバターオブジェクト610の体力が0になる(ゲームオーバーになる)寸前で体力が回復したことを示している。
また、ユーザ「CCCCC」には、バリケード、5F、ザコ、「バリケードでゾンビを二人足止め」という情報が対応付けられている。これは、例えば、5Fというステージのザコ敵との戦闘において、ユーザ「CCCCC」がバリケード(図11における障害物オブジェクト672)を投入し、その結果、二人のザコ敵の足止めに成功したことを示している。
図16の例では、各ユーザ3のユーザ名に対し、行った支援が1つ対応付けられているが、支援を複数回行なったユーザ3のユーザ名には、複数回の支援それぞれのタグが対応付けられる。ユーザリスト234において、該それぞれのタグは区別されていることが好ましい。これにより、ゲーム終了後に、配信端末400を用いてユーザリスト421を参照するプレイヤが、各支援の内容を正確に把握できる。
<動作指図データの配信>
(配信端末400における配信処理)
図17は、配信端末400で実行される配信処理の流れの一例を示すフローチャートである。図18は、配信端末400に表示される画面の一具体例を示す図である。図19は、配信端末に表示される画面の他の具体例を示す図である。
ステップS61において、プロセッサ40は、操作受付部413として、ゲームに参加したユーザのリスト(ユーザリスト234)を表示するための第1操作を受け付ける。図18(A)に示すダウンロード画面721は、ユーザリスト234をサーバ200からダウンロードし、表示部452に表示させるための画面である。ダウンロード画面721は、一例として、図17に示す配信処理を実行するアプリケーションの起動操作を、配信端末400に入力した直後に表示される画面である。
ダウンロード画面721は、一例として、UI画像722および723を含む。UI画像722は、ユーザリスト234をダウンロードするための操作、すなわち、上記第1操作を受け付ける。第1操作は、例えば、UI画像722をタップする操作であってもよい。UI画像723は、アプリケーションを終了するための操作を受け付ける。該操作は、例えば、UI画像723をタップする操作であってもよい。
UI画像722に対するタップ操作を受け付けると、ステップS62において、プロセッサ40は、通信制御部411として、ユーザリスト234をサーバ200から取得(受信)する。ステップS63において、プロセッサ40は、表示制御部412として、ユーザリスト234を表示部452に表示させる。具体的には、プロセッサ40は、ユーザリスト234に基づいて生成されたユーザリスト画面を、表示部452に表示させる。ユーザリスト画面は、一例として、図18(B)に示すユーザリスト画面731であってもよい。ユーザリスト画面731は、ユーザリスト234における各レコードに対応するレコード画像からなる。図18(B)の例では、レコード画像として、レコード画像732A〜732Cを記載しているが、レコード画像の数は3つに限定されない。図18(B)の例において、ユーザリスト234におけるレコードの数が3より多い(すなわち、ゲームに参加したユーザの人数が3人より多い)場合、プレイヤは、例えば画面をスクロールする操作(例えば、ドラッグ操作やフリック操作)をタッチスクリーン45に入力することにより、他のレコード画像を表示部452に表示させることができる。
一例として、レコード画像732A〜732Cは、それぞれ、ユーザ名733A〜733C、タグ情報734A〜734C、および、アイコン735A〜735Cを含む。以降、レコード画像732A〜732C、ユーザ名733A〜733C、タグ情報734A〜734C、および、アイコン735A〜735Cについて、区別する必要が無い場合、それぞれ、「レコード画像732」、「ユーザ名733」、「タグ情報734」、「アイコン735」と記載する。
ユーザ名733は、ユーザリスト234において、「ユーザ」のカラムに格納されている、ゲームに参加した各ユーザを示す情報である。タグ情報734は、ユーザリスト234において、ゲームに参加した各ユーザを示す情報のそれぞれに対応付けられているタグを示す情報である。例えば、レコード画像732Aは、ユーザ名733Aとして、「AAAAA」を含む。このため、レコード画像732Aは、タグ情報734Aとして、ユーザリスト234において「AAAAA」に対応付けられている、『マガジン、10F、ボス、「マガジンのプレゼントによりボスに勝利」』を含む。アイコン735は、例えば、ユーザが事前に設定した画像である。
なお、プロセッサ40は、受信したユーザリストを配信端末400に記憶してもよい(図7のユーザリスト421)。ダウンロード画面721は、ユーザリスト421を表示部452に表示するためのUI画像(不図示)を含んでいてもよい。この例において、該UI画像がタップされた場合、プロセッサ40は、ユーザリスト234のダウンロードを行わず、ユーザリスト421を読み出し、該ユーザリスト421からユーザリスト画面を生成し、表示部452に表示させる。
ステップS64において、プロセッサ40は、操作受付部413として、ユーザリスト画面731に含まれるユーザの何れかを選択するための第2操作を受け付ける。第2操作は、一例として、ユーザリスト画面731におけるレコード画像732の何れかをタップする操作であってもよい。図18(B)の例では、プレイヤは、レコード画像732Aへのタップ操作を入力している。すなわち、プレイヤは、動作指図データを配信するユーザとしてユーザ「AAAAA」を選択している。
レコード画像732に対するタップ操作を受け付けると、ステップS65において、プロセッサ40は、表示制御部412として、モーションリスト422を表示部452に表示させる。具体的には、プロセッサ40は、モーションリスト422に基づいて生成されたモーションリスト画面を、表示部452に表示させる。モーションリスト画面は、一例として、図19に示すモーションリスト画面741であってもよい。モーションリスト画面741は、モーションリスト422における各レコードに対応するレコード画像からなる。図19の例では、レコード画像として、レコード画像742A〜742Cを記載しているが、レコード画像の数は3つに限定されない。図19の例において、モーションリスト422におけるレコードの数が4より多い場合、プレイヤは、例えば画面をスクロールする操作(例えば、ドラッグ操作やフリック操作)をタッチスクリーン45に入力することにより、他のレコード画像を表示部452に表示させることができる。
一例として、レコード画像742A〜742Cは、それぞれ、モーション名743A〜743C、モーション画像744A〜744C、および、UI画像745A〜745Cを含む。以降、レコード画像742A〜742C、モーション名743A〜743C、モーション画像744A〜744C、および、UI画像745A〜745Cについて、区別する必要が無い場合、それぞれ、「レコード画像7432」、「モーション名743」、「モーション画像744」、「UI画像745」と記載する。
モーション名743は、モーションリスト422に格納されているモーションを識別する情報である。モーション画像744は、モーションリスト422において、各モーション名に対応付けられているモーションデータから生成される画像である。プロセッサ40は、一例として、各モーションデータにおける最初の姿勢をとるアバターオブジェクト610の画像を、モーション画像744とてレコード画像742に含める。モーション画像744は、プレイヤによる所定の操作(例えば、モーション画像744に対するタップ操作)を受け付けるUI画像であってもよい。プロセッサ40は、該所定の操作を受け付けた場合、モーションデータに基づいてアバターオブジェクト610が動作するモーション動画を再生してもよい。プロセッサ40は、モーション動画が終了すると、自動的にモーションリスト画面741を再表示してもよい。
なお、レコード画像742は、モーション画像744に代えて、例えば、「モーション再生」とのテキストを含むUI画像を含んでもよい。
ステップS66において、プロセッサ40は、操作受付部413として、モーションを選択する第3操作を受け付ける。第3操作は、一例として、UI画像745へのタップ操作であってもよい。つまり、UI画像745は、各レコード画像742に対応するモーションデータを選択する操作を受け付ける。第3操作を受け付けたことにより、プロセッサ40は、モーション特定部415として、プレイヤが選択したモーションデータを特定する。
ステップS67において、プロセッサ40は、表示制御部412および音声受付部414として、アバターオブジェクト610が、選択されたモーションデータに基づき動作するモーション動画を再生しながら、プレイヤの音声入力を受け付ける。
図20は、プレイヤ4による音声入力の一具体例を示す図である。図20に示すように、プレイヤ4は、モーション動画810Aを再生しながら、発話音声820Aを入力している。この発話音声820Aは、ユーザ名が「AAAAA」であるユーザ3(以下、ユーザ3A)宛の発話音声である。つまり、図20の例において、プレイヤ4は、ステップS64にて、ユーザ3A(第1ユーザ)を選択し、該ユーザ3A宛の動作指図データを作成している。なお、ユーザ3Aが使用するユーザ端末100は、ユーザ端末100Aであるとする。
発話音声820Aは、ユーザ3A宛の発話音声であるため、該ユーザ3Aがアバターオブジェクト610(換言すれば、プレイヤ4)に対して行った支援の内容に基づく発話音声となっている。具体的には、ユーザ3Aは、10Fというステージでのボス戦において、マガジンを投入し、その投入されたマガジンの銃弾でアバターオブジェクト610がボスに勝利している。このため、発話音声820Aは、「ボス戦でマガジンをプレゼントしてくれてありがとう!タイミングも完璧だったね!AAAAAさんのおかげでクリアできたよ!」という内容である。このように、発話音声は、ユーザ3がゲームにおいて行った支援の内容と、ユーザ3への感謝とを含むものであることが好ましい。
ある局面において、プレイヤ4は、音声入力を開始する前、すなわち、第3操作を配信端末400へ入力する前に、ユーザ3宛の発話内容を作成する。別の局面において、ユーザ3宛の発話内容は、プロセッサ40が自動生成してもよい。また、プロセッサ40は、第2操作によって選択されたユーザ3に対応付けられたタグを、モーション動画810Aに重畳して表示させてもよい。
プロセッサ40は、受け付けた音声を音声データに変換する。ステップS68において、プロセッサ40は、動作指図データ生成部416として、該音声データと、選択されたモーションのモーションデータとを含む動作指図データを生成する。
ステップS69において、プロセッサ40は、通信制御部411として、生成した動作指図データを選択されたユーザ3(図20の例ではユーザ3A)のユーザ端末100(第1コンピュータ)に配信する。図21は、配信端末400に表示される画面のさらなる別の具体例を示す図である。プロセッサ40は、ステップS68の実行後、表示制御部412として、配信画面を表示部452に表示させる。配信画面は、一例として、図21(A)に示す配信画面751であってもよい。配信画面751は、UI画像752、および、モーション画像753Aを含む。また、配信画面751は、図21(A)に示すように、動作指図データの配信先のユーザを示す情報を含むものであってもよい。
UI画像752は、動作指図データを選択されたユーザ3へ配信するための操作を受け付ける。該操作は、例えば、UI画像752へのタップ操作であってもよい。モーション画像753Aは、生成した動作指図データに基づく動画、すなわち、ユーザ3A用に生成した動作指図データに基づく動画を再生するための操作を受け付けるUI画像である。該操作は、例えば、モーション画像753Aへのタップ操作であってもよい。なお、生成した動画を再生するための操作を受け付けるUI画像は、モーション画像753Aに限定されない。例えば、「動画再生」とのテキストを含むUI画像であってもよい。プロセッサ40は、動画が終了すると、自動的に配信画面751を再表示してもよい。
配信画面751は、音声入力の受け付けに戻るための操作を受け付けるUI画像をさらに含むことが好ましい。該操作は、例えば、該UI画像へのタップ操作であってもよい。配信画面751が該UI画像を含むことにより、プレイヤ4は、例えば、発話する内容を間違えた場合など、音声入力に失敗した場合に、再度音声入力を行うことができる。なお、該UI画像は、モーションデータの選択に戻るための操作を受け付けるUI画像であってもよい。
UI画像752に対するタップ操作を受け付けると、プロセッサ40は、ユーザ3Aを示す情報とともに、動作指図データをサーバ200へ送信する。サーバ200は、ユーザ3Aを示す情報に基づいて、動作指図データの送信先のユーザ端末100を特定し、該動作指図データを特定したユーザ端末100(すなわち、ユーザ端末100A)へ送信する。
プロセッサ40は、動作指図データの送信が終了した場合、一例として、図21(B)に示す配信完了画面761を表示部452に表示させてもよい。配信完了画面761は、一例として、UI画像762および763を含む。また、配信完了画面761は、図21(B)に示すように、動作指図データの送信が完了したことを示すテキストを含むものであってもよい。
UI画像762は、別のユーザ3宛の動作指図データの作成を開始するための操作を受け付ける。該操作は、例えば、UI画像762をタップする操作であってもよい。プロセッサ40は、該タップ操作を受け付けると、ユーザリスト画面を、表示部452に再度表示させる。すなわち、該タップ操作を受け付けた場合、配信処理は、ステップS63に戻る。このとき、プロセッサ40は、配信端末400に記憶したユーザリスト421に基づいて、ユーザリスト画面を生成し、表示部452に表示させてもよい。UI画像763は、アプリケーションを終了するための操作を受け付ける。該操作は、例えば、UI画像763をタップする操作であってもよい。該操作を受け付けると、配信処理は終了する。
図20、図21を参照して説明した例では、図21(C)に示すように、配信端末400は、ユーザ3A(ユーザ名が「AAAAA」のユーザ3)宛の動画の動作指図データを、ユーザ端末100Aのみに送信する。
図22は、プレイヤ4による音声入力の他の具体例を示す図である。図22に示すように、プレイヤ4は、モーション動画810Bを再生しながら、発話音声820Bを入力している。この発話音声820Bは、ユーザ名が「BBBBB」であるユーザ3(以下、ユーザ3B)宛の発話音声である。つまり、図22の例において、プレイヤ4は、ステップS64にて、ユーザ3Bに対応するレコード画像732Bへのタップ操作を入力し、ユーザ3B宛の動作指図データを作成している。なお、ユーザ3Bが使用するユーザ端末100は、ユーザ端末100Bであるとする。
発話音声820Bは、ユーザ3B宛の発話音声であるため、該ユーザ3Bがアバターオブジェクト610(換言すれば、プレイヤ4)に対して行った支援の内容に基づく発話音声となっている。具体的には、ユーザ3Bは、3Fというステージのザコ敵との戦闘において、ユーザ「BBBBB」が救急箱を投入し、その結果、アバターオブジェクト610の体力が0になる(ゲームオーバーになる)寸前で体力が回復している。このため、発話音声820Bは、「BBBBBさんがプレゼントしてくれた救急箱のおかげで、3Fでゲームオーバーにならずにすんだよ。本当にありがとう!」という内容である。
図23は、配信端末400に表示される画面のさらなる別の具体例を示す図である。図23(A)に示す配信画面751は、UI画像752、および、モーション画像753Bを含む。モーション画像753Bは、タップ操作を受け付けると、ユーザ3B用に生成した動作指図データに基づく動画を再生する。
UI画像752に対するタップ操作を受け付けると、プロセッサ40は、ユーザ3Bを示す情報とともに、動作指図データをサーバ200へ送信する。サーバ200は、ユーザ3Bを示す情報に基づいて、動作指図データの送信先のユーザ端末100を特定し、該動作指図データを特定したユーザ端末100(すなわち、ユーザ端末100B)へ送信する。
図22、図23を参照して説明した例では、図23(C)に示すように、配信端末400は、ユーザ3B(ユーザ名が「BBBBB」のユーザ3)宛の動画の動作指図データを、ユーザ端末100Bのみに送信する。
以上のように、動作指図データに含まれる音声データに基づく音声の内容は、ユーザ3が直近のゲームへの参加において、プレイヤ4に対して行った支援の内容に基づくものとなる。該支援の内容はユーザ3ごとに異なるため、音声の内容は、ユーザ3ごとに異なる内容となる。つまり、ゲームの終了後、ゲームに参加したユーザ3の少なくとも一部のユーザ端末100には、それぞれ異なる内容の音声を含む動作指図データが送信される。
また、図22の例におけるアバターオブジェクト610のモーションは、図20の例におけるモーションと異なる。つまり、プレイヤ4は、ユーザ3B宛の動作指図データ生成において、ユーザ3A宛の動作指図データ生成時と異なるモーションデータを選択している。具体的には、プレイヤ4は、ステップS66において、レコード画像742Bに対応するモーションデータを選択する、UI画像745Bへのタップ操作を入力している。このように、プレイヤ4は、動作指図データに含まれるモーションデータを、ユーザ3毎に異ならせることができる。
そして、ユーザ3毎に異なる内容の音声データと、ユーザ3毎に選択されたモーションデータとを含む、ユーザ3毎の動作指図データは、各ユーザ3のユーザ端末100のみに送信される。換言すれば、ユーザ端末100毎にユニーク(一意)の動作指図データが、選択されたユーザ3のユーザ端末100の各々に送信される。
図24は、ゲームプレイ端末300からユーザ端末100へのゲーム進行情報の送信の概要を示す図である。ユーザ端末100における動画再生のための動作指図データが、ユーザ端末100毎にユニークである一方、図24に示すように、ゲーム実行中に、ゲームに参加している全てのユーザ3のユーザ端末100に送信されるゲーム進行情報は、各ユーザ端末100の間で共通である。すなわち、ゲーム進行情報に含まれる動作指図データもまた、各ユーザ端末100の間で共通である。このように、動画再生のための動作指図データと、ゲームを進行させるための動作指図データとは、ユーザ端末100間での同異、および、送信先といった観点で異なるデータであると言える。
(ユーザ端末100における動画再生処理)
図25は、ユーザ端末100で実行される動画再生処理の流れの一例を示すフローチャートである。
ステップS71において、プロセッサ10は、動画再生部117として、動作指図データを受信する。ステップS72において、プロセッサ10は、動画再生部117として、動作指図データの受信をユーザ3へ通知する。プロセッサ10は、一例として、通知画像の表示部152への表示、スピーカ(不図示)からの通知音声の再生、LED(light-emitting diode)などで構成される点灯部(不図示)の点灯または点滅の少なくともいずれかにより、動作指図データの受信をユーザ3へ通知する。
ステップS73において、プロセッサ10は、操作受付部111として、動画を再生するための第1再生操作を受け付ける。第1再生操作は、一例として、通知画像をタップする操作であってもよい。ステップS74において、プロセッサ10は、動画再生部117として、動作指図データをレンダリングし、動画を再生する。プロセッサ10は、一例として、本ゲームをプレイするためのアプリケーションを起動し、動画を再生してもよいし、該アプリケーションとは別の、動画再生用のアプリケーションを起動し、動画を再生してもよい。以降、該動画を、「ありがとう動画」と記載する。
図26は、ありがとう動画の再生の一具体例を示す図である。具体的には、ユーザ3Aのユーザ端末100における、ありがとう動画の再生の一例を示す図である。該ユーザ端末100において再生されたありがとう動画910Aにおいて、アバターオブジェクト610は、或るモーションを実行しながら、音声920Aを発話している。換言すれば、プロセッサ10は、或るモーションを実行するアバターオブジェクト610を含むありがとう動画910Aを再生しながら、音声920Aをスピーカ(不図示)から出力させている。
ありがとう動画910Aにおけるモーションは、ユーザ3A宛の動作指図データの生成において、プレイヤ4が選択したモーションデータに基づくものであり、音声920Aは、該動作指図データの生成において、プレイヤ4が入力した発話音声820Aから生成された音声データに基づくものである。つまり、音声920Aは、ユーザ3Aがゲームにおいて行った支援の内容と、該支援に対する感謝とを含む音声である。このように、ユーザ3Aは、第1再生操作の入力により、自身がゲームにおいて行った支援の内容と、該支援に対する感謝とを、アバターオブジェクト610が発話するありがとう動画を視聴することができる。
ユーザ端末100は、一例として、ありがとう動画910Aの再生が終了した後、少なくとも1つのUI画像をタッチスクリーン15に表示させてもよい。該UI画像は、例えば、ありがとう動画910Aをもう一度再生するための操作を受け付けるUI画像であってもよいし、別の画面に遷移するための操作を受け付けるUI画像であってもよいし、アプリケーションを終了するための操作を受け付けるUI画像であってもよい。
また、ユーザ端末100は、一例として、ありがとう動画910Aの再生中に、少なくとも1つのUI画像をタッチスクリーン15に表示させてもよい。該UI画像は、例えば、再生中のありがとう動画910Aを一時的に停止させたり、終了させたり、再生する場面を変更させたりする操作をそれぞれ受け付ける、複数のUI画像であってもよい。
なお、ありがとう動画910Aの再生中、および、ありがとう動画910Aの再生が狩猟した後に表示されるこれらのUI画像には、アバターオブジェクト610に対する返答を行うためのUI画像は含まれない。すなわち、本実施形態に係るありがとう動画910Aにおいては、アバターオブジェクト610に対する返答を行うための手段が備えられていない。
図27は、ありがとう動画の再生の他の具体例を示す図である。具体的には、ユーザ3Bのユーザ端末100における、ありがとう動画の再生の例を示す図である。該ユーザ端末100において再生されたありがとう動画910Bにおいて、アバターオブジェクト610は、或るモーションを実行しながら、音声920Bを発話している。換言すれば、プロセッサ10は、或るモーションを実行するアバターオブジェクト610を含むありがとう動画910Bを再生しながら、音声920Bをスピーカ(不図示)から出力させている。
ありがとう動画910Bにおけるモーションは、ユーザ3B宛の動作指図データの生成において、プレイヤ4が選択したモーションデータに基づくものであり、音声920Bは、該動作指図データの生成において、プレイヤ4が入力した発話音声820Bから生成された音声データに基づくものである。このため、図27の例において、アバターオブジェクト610が行っているモーションは、図26の例のモーションとは異なる。また、音声920Bは、ユーザ3Bがゲームにおいて行った支援の内容と、該支援に対する感謝とを含む音声である。このため、図27の例において、音声920Bの内容は、図26の例に
おける音声920Aの内容とは異なる。
このように、ゲームの終了後に、ゲームに参加したユーザ3の少なくとも一部のユーザ端末100が受信するありがとう動画は、ユーザ3毎にアバターオブジェクト610の発話内容が異なる動画である。
なお、プロセッサ10は、次回のゲームへの参加を促す内容を含むUI画像930を、動画910に重畳させて表示させてもよい。UI画像930は、動作指図データとともに配信されてもよいし、ゲーム情報132として、ユーザ端末100が記憶していてもよい。
<位置情報ゲームの概要>
本実施形態に係るシステム1は、上述の本ゲーム以外に、位置情報ゲームを提供する。当該位置情報ゲームでは、センタータワーCTW、ポータルPTL、およびライブ配信タワーLTWのオブジェクトが表示されている地図画像が、タッチスクリーン15に表示される。当該ポータルPTLのオブジェクトへのタップ操作が行なわれると、当該ポータルPTLに関連付けられているゲームが実行される。また、当該ライブ配信タワーLTWのオブジェクトへのタップ操作が行なわれると、当該ライブ配信タワーLTWに関連付けられているライブ配信コンテンツを視聴するライブ視聴処理が実行される。
図28に示すように、地図画像は、複数のHEXに区分されている。当該複数のHEX各々は六角形をなし、当該六角形の頂点から中心までの距離は、例えば1kmに設定されている。また、当該複数のHEX各々の配置を特定するための配置情報は、ゲームプログラムのダウンロード時やアップデート時にサーバ200から取得され、メモリ11に記憶される。
センタータワーCTWは、当該複数のHEX各々の中心位置に配置される。ポータルPTLおよびライブ配信タワーLTWは、当該複数のHEX各々の任意の位置に配置される。ポータルPTLは各HEX内に複数配置され、ライブ配信タワーLTWは各HEXに1つ配置される。
位置情報ゲームを開始する操作が行なわれると、ユーザ端末100に備えられている不図示の位置登録システムにより、当該ユーザ端末100の現在位置PSTの情報(例えば、住所情報、緯度経度情報など)が取得され、当該現在位置PSTを含む所定領域(例えば、当該現在位置PSTを中心とする半径50kmの領域)の地図データが、他のサービス提供装置から取得される。また、当該所定領域に配置されているポータルPTLの位置情報およびポータルIDと、当該所定領域に配置されているライブ配信タワーLTWの位置情報および配信タワーIDとが、サーバ200から取得される。
なお、ポータルIDは、例えば、当該IDがポータルPTLのIDであることを示すID種別情報と、当該ポータルPTLが属するHEXの識別番号と、当該ポータルPTLの識別番号とにより規定される。また、配信タワーIDは、例えば、当該IDがライブ配信タワーLTWのIDであることを示すID種別情報と、当該ライブ配信タワーLTWが属するHEXの識別番号と、当該ライブ配信タワーLTWの識別番号とにより規定される。
タッチスクリーン15には、当該現在位置PSTの周辺を斜め上空から眺めた視点で模式化した地図画像が、当該地図データに基づいて表示される(図30(A)参照)。当該地図画像に現れるHEXの中心位置には、メモリ11に記憶されているHEXの配置情報に基づいて、センタータワーCTWを表すオブジェクトが表示される。また、当該HEXの所定の位置には、サーバ200から取得したポータルPTLの位置情報およびポータルIDとライブ配信タワーLTWの位置情報および配信タワーIDとに基づいて、ポータルPTLを表すオブジェクトとライブ配信タワーLTWを表すオブジェクトとが表示される。ただし、ライブ配信タワーLTWのオブジェクトについては、ライブ視聴処理が行われていないもの、つまりライブ配信コンテンツが視聴されていないものが表示される。
なお、以降の説明では、センタータワーCTWを表すオブジェクトを単に「センタータワーCTW」と呼び、ポータルPTLを表すオブジェクトを単に「ポータルPTL」と呼び、ライブ配信タワーLTWを表すオブジェクトを単に「ライブ配信タワーLTW」と呼ぶ。
当該地図画像においては、「タップ済み」のセンタータワーCTWが配置されているHEXがハイライト表示され、当該現在位置PSTを表す現在位置画像と当該現在位置PSTを中心とするサークルCCL(所定範囲)を表すサークル画像とが表示される。ここで、サークルCCLの広さは、センタータワーCTWが当該サークルCCL内に含まれる状態では、当該センタータワーCTWが配置されているHEX内にユーザ端末100が位置する広さ(例えば半径500mの広さ)に設定される。このため、当該HEXの外側にユーザ端末100が存在する状態では、当該HEXのセンタータワーCTWが当該サークルCCLに含まれることはなく、また、他のHEXのセンタータワーCTWが当該サークルCCLに含まれることもない。
なお、タッチスクリーン15上の地図画像は、タッチスクリーン15に対するスクロール操作(フリック操作またはスワイプ操作)を受け付けることによりスクロールされる。また、ユーザ端末100が移動すれば、当該現在位置画像が中心に表示されるように、地図画像がスクロールされる。
メモリ11には、図29に示すテーブルTBL1が記憶される。図29によれば、地図画像上の複数のHEX各々に対して、当該HEXに配置されているセンタータワーCTW、ライブ配信タワーLTW、および複数のポータルPTLの各々の設定が関連付けられる。ここでテーブルTBL1におけるセンタータワーCTW、ライブ配信タワーLTW、および複数のポータルPTLの各々の設定状態は、ユーザ端末100毎に異なり得る。また、テーブルTBL1はサーバ200により管理し、位置情報ゲームの開始時に当該サーバ200からメモリ11に取り込むようにしてもよい。
このうち、センタータワーCTWの設定は、当該センタータワーCTWに対するタップ操作が行われていないときに「タップ無し」を示し、当該センタータワーCTWに対するタップ操作が行われているときに「タップ済み」を示す。センタータワーCTWに対するタップ操作は、ユーザ端末100の現在位置PSTを中心とするサークルCCL内に当該センタータワーCTWが含まれる場合に許容される(有効に受け付けられる)。このため、例えば、HEX1のセンタータワーCTWが当該サークルCCL内に含まれる位置にユーザ端末100が移動すると、当該センタータワーCTWに対するタップ操作が許容される。当該センタータワーCTWの設定は、当該タップ操作に応じて「タップ済み」に変更される。
ライブ配信タワーLTWの設定としては、表示設定および視聴設定が設けられる。当該表示設定は、ライブ視聴処理が実行されていないライブ配信タワーLTWについて「可」に設定され、当該ライブ視聴処理が実行されたライブ配信タワーLTWについて「不可」に設定される。ライブ配信タワーLTWは、当該表示設定が「可」を示す場合に地図画像上に表示され、当該表示設定が「不可」を示す場合に非表示とされる。
当該視聴設定は、センタータワーCTWが「タップ済み」のHEXに配置されたライブ配信タワーLTWのうち、ライブ視聴処理が実行されていないライブ配信タワーLTWについて「未」に設定され、ライブ視聴処理が実行されたライブ配信タワーLTWについて「済」に設定される。また、当該視聴設定は、センタータワーCTWが「タップ無し」のHEXに配置されているライブ配信タワーLTWについて、「--」に設定される。
例えば、HEX1のセンタータワーCTWに対するタップ操作は行なわれたものの、当該HEX1のライブ配信タワーLTWについてライブ視聴処理が実行されていなければ、表示設定は「可」に設定され、視聴設定は「未」に設定される。その後、当該ライブ配信タワーLTWについてライブ視聴処理が実行されると、当該視聴設定は「済」に変更され、当該表示設定は「不可」に変更される。
即ち、初期状態においては、ライブ配信タワーLTWの表示設定は「可」に設定され、視聴設定は「--」に設定される。当該ライブ配信タワーLTWが属するHEXのセンタータワーCTWがタップされると、当該ライブ配信タワーLTWの視聴設定は「未」に更新される。また、当該ライブ配信タワーLTWがタップされると、表示設定は「不可」に更新され、視聴設定は「済」に更新される。
この結果、センタータワーCTWがタップされていない段階においても、当該センタータワーCTWが属するHEX内のライブ配信タワーLTWは、ポータルPTLと同様に表示される。当該ライブ配信タワーLTWからのライブ配信は、当該センタータワーCTWに対するタップ操作により視聴可能となる。視聴が終了すると、ポータルPTLと異なり、当該ライブ配信タワーLTWは非表示となる。
ポータルPTLの設定としては、クールタイムの残り時間、レアリティ、遠方プレイ済フラグが設けられる。あるHEXのセンタータワーCTWに対するタップ操作が行なわれると、当該HEXに配置されている全てのポータルPTLに対して、クールタイムの残り時間、レアリティ、遠方プレイ済フラグが設定される。具体的には、クールタイムの残り時間は0分に設定され、レアリティの種類は銀、金、虹のいずれかに設定され、遠方プレイ済フラグはリセットされる。これによって、当該全てのポータルPTLに対するタップ操作が許容される(有効に受け付け可能となる)。即ち、当該全てのポータルPTLが開放される。タップ操作が許容されたポータルPTLは、タップ操作が許容されていないポータルPTLとは異なる態様で、地図画像上に表示される。例えば、タップ操作が許容されていないポータルPTLは、所定のポータル画像のみが表示されるのに対し、タップ操作が許容されたポータルPTLは、所定のポータル画像の周りが輝いている態様で表示される。
クールタイムは、当該ゲームが終了した後に当該ポータルPTLに対するタップ操作が許容されない時間、つまりタップ操作が再度許容可能となるまでの残り時間を表すパラメータである。当該クールタイムは、当該ゲームの終了に応じて所定時間(例えば120分)に設定され、残り時間のカウントダウンが開始される。当該ポータルPTLが配置されているHEX内にユーザ端末100が存在する場合、当該ポータルPTLに対するタップ操作は、当該クールタイムの残り時間が0分となったときに再度許容される。
レアリティは、例えば、ポータルPTLに対するタップ操作により実行されるゲームをクリアすることにより付与される投げ銭アイテムの価値を規定するパラメータであり、銀→金→虹の順で高くなる。当該レアリティは、クールタイムの残り時間が0分になったときに例えば乱数抽選により当該ポータルPTLに再設定される。なお、ポータルPTLの表示態様は、レアリティに応じて異ならせる(例えば、ポータル画像の大きさが異なる)ようにしてもよい。
遠方プレイ済みフラグは、タップ操作が行なわれたセンタータワーCTWが属するHEXの外側にユーザ端末100が存在する状態で、当該HEX内のポータルPTLのうちクールタイムが経過しているポータルPTL(クールタイムの残り時間が0分を示すポータルPTL)に対するタップ操作を許容するか否かを特定可能にするためのフラグである。
あるHEX内のセンタータワーCTWに対するタップ操作が行なわれると、当該HEX内の全てのポータルPTLに関連付けられている遠方プレイ済みフラグがリセットされる(即ち、遠方プレイ済みフラグが0になる)。当該遠方プレイ済みフラグは、ユーザ端末100が当該HEXの内側に存在する状態で、当該HEX内のポータルPTLのうちクールタイムが経過しているポータルPTLに対するタップ操作が行なわれる毎に、全てリセットされる。クールタイムの残り時間が0分のポータルPTLに対するタップ操作は、遠方プレイ済みフラグがリセットされていることを条件として許容される。
一方、ユーザ端末100が当該HEXの外側に移動した後に、当該HEX内のポータルPTLに対するタップ操作が行なわれた場合には、当該ポータルPTLの遠方プレイ済みフラグがセットされていないことを条件として、当該タップ操作に応じてゲームが実行可能となるとともに、当該ポータルPTLの遠方プレイ済みフラグがセットされる。これにより、当該ポータルPTLのクールタイムが経過した後であっても、当該ポータルPTLが属するHEXの外側にユーザ端末100が存在する限り、遠方プレイ済フラグがセットされているため、当該ポータルPTLに対するタップ操作が許容されることはない。
遠方プレイ済みフラグについて、例えば、ユーザが大阪に旅行し、大阪に配置されているHEXのうちユーザ端末100が存在するHEXのセンタータワーCTWをタップすると、当該HEX内の全てのポータルPTLに関連付けられている遠方プレイ済みフラグがリセットされる。当該遠方プレイ済みフラグは、当該ユーザが当該HEXの内側にいる状態で、当該HEX内のクールタイムが経過しているポータルPTLをタップしたときにも、全てリセットされる。この結果、ユーザが当該HEXの内側にいれば、当該HEX内のポータルPTLに対するタップ操作は、当該ポータルPTLのクールタイムが経過する毎に許容される。
その後に当該ユーザが東京に移動し、ユーザ端末100が大阪の上記のHEX内に存在しない状態において、当該HEX内のいずれかのポータルPTLをタップすると、当該ポータルPTLの遠方プレイ済みフラグがセットされる。遠方プレイ済みフラグがセットされているポータルPTLに対するタップ操作は、ユーザ端末100が当該ポータルPTLが属するHEXの外側にいる場合には許容されない。この結果、ユーザが当該HEXの外側にいる限り、当該HEX内のポータルPTLに対するタップ操作は1回しか許容されない。
テーブルTBL1に設定されているポータルPTLのうち、クールタイムの残り時間が0分で、遠方プレイフラグがリセットされているポータルPTLに対するタップ操作が行われると、当該ポータルPTLに関連付けられているゲーム(例えばシューティングゲーム)が実行される。当該ゲームは、所定の達成条件(例えば、撃ち落とした敵キャラクタの数が所定数に到達するといった条件)が成立することにより、クリアとなるゲームである。当該ゲームがクリアとなると、当該ポータルPTLのレアリティに応じた投げ銭アイテムが、報酬としてユーザに付与される。当該投げ銭アイテムの価値は、当該レアリティが高いほど高くなる。
具体的には、当該レアリティが銀または金であれば、当該ポータルPTLが属するHEXが配置されている地域に関係しないアイテムであって銀または金に応じたアイテムが、投げ銭アイテムとして付与される。
一方、当該レアリティが虹であれば、ご当地アイテムが投げ銭アイテムとして付与される。当該HEXが複数の地域に跨る場合があるため、ご当地がいずれの地域であるかは、当該HEXの中心位置に基づいて特定される。例えば、当該中心位置が東京都墨田区であれば、スカイツリーを模したアイテムが投げ銭アイテムとして付与され、当該中心位置が大阪市浪速区であれば通天閣を模したアイテムが投げ銭アイテムとして付与される。
地図画像上のライブ配信タワーLTWに対するタップ操作が行われたときは、当該ライブ配信タワーLTWが配置されているHEXが、テーブルTBL1上で特定される。当該HEXに関連付けられているライブ配信タワーLTWの視聴設定が「未」であれば、ライブ視聴処理が実行される。具体的には、ゲームプレイ端末300からライブ配信される動作指図データ等のゲーム進行情報がサーバ200を介して受信され、当該ゲーム進行情報に基づくコンテンツ(例えば、図11および図12を参照して説明した本ゲームの映像)がタッチスクリーン15に表示される。また、当該コンテンツを視聴するユーザには、ポータルチケットが付与される。当該ポータルチケットは、クールタイムが経過していないポータルPTLや、遠方プレイ済フラグがセットされているポータルPTLへのタップ操作を許容するためのアイテムである。さらに、当該コンテンツの視聴中において、ユーザは、ゲームをクリアすることにより付与された投げ銭アイテムや、課金により付与された投げ銭アイテムを配信者に対して投入することができる。
クールタイムが経過していないポータルPTL、または遠方プレイ済みフラグがセットされているポータルPTLがタップされたときは、図30(D)に示すチケット消費問合せ画面がタッチスクリーン15に重畳して表示される。図30(D)によれば、当該チケット消費問合せ画面には、「ポータルチケットを消費してゲームを実行しますか?」の文字列と、「実行」ボタンと、「キャンセル」ボタンとが表示される。ここで「実行」ボタンがタップされると、ユーザが所有するポータルチケットの消費に伴って、ゲームが開始される。即ち、クールタイムが経過していない場合や、遠方プレイ済みフラグがセットされている場合でも、当該ポータルチケットを消費することにより、当該ポータルPTLに対するタップ操作が許容される。
なお、ポータルチケットが足りない場合には、課金により当該ポータルPTLに対するタップ操作を許容するようにしてもよい。具体的には、課金によりポータルチケットを購入可能とし、当該ポータルチケットを消費することにより、当該タップ操作を許容するようにしてもよく、課金により仮想通貨を購入可能とし、当該仮想通貨を消費することにより、当該タップ操作を許容するようにしてもよい。
図30(A)に示すように、タッチスクリーン15上の地図画像には、一覧アイコンICNを含む各種アイコンが重畳して表示される。当該一覧アイコンICNがタップされると、センタータワーCTWの設定が「タップ済み」を示すHEXがテーブルTBL1上で特定され、当該HEXの見出しが列挙された一覧画面がタッチスクリーン15に重畳して表示される(図30(B)参照)。
当該一覧画面に列挙されている見出しのいずれかをタップする操作、即ちHEX選択操作が行われると、当該HEX選択操作により選択されたHEX内の所定位置(例えば、センタータワーCTWが配置されている当該HEXの中心位置)が特定される。タッチスクリーン15上の地図画像は、当該所定位置の周辺を斜め上空から眺めた地図画像に更新される(図30(C)参照)。
更新後の地図画像においても、センタータワーCTWと、ポータルPTLと、表示設定が「可」を示すライブ配信タワーLTWとが表示される。また、当該HEX内のセンタータワーCTWは「タップ済み」であるため、ポータルPTLおよびライブ配信タワーLTWの各々に対するタップ操作は受け付け可能となる。ただし、当該HEXがユーザ端末100の現在位置PSTよりも遠方(例えば、現在位置PSTが表示されない位置)のHEXである場合、現在位置画像と当該現在位置PSTを中心とするサークル画像とが地図画像に現れることはない。
(動作について)
図31および図32は、位置情報ゲームを行うための位置情報ゲーム処理の一例を説明するためのフローチャートである。位置情報ゲーム処理は、位置情報ゲームを開始する操作を受付けたときにプロセッサ10により実行される。
なお、図31および図32に示すフローチャートの一部の処理はサーバ200において実行し、処理結果をユーザ端末100に送信するようにしてもよい。また、ユーザ端末100とゲームプレイ端末300との間での情報の送受信は、サーバ200を介して実行されるものであるが、これに限らず、サーバ200を介することなく実行されるものであってもよい。
図31を参照して、ステップS81では、当該ユーザ端末100の現在位置PSTを示す位置情報を位置登録システムから取得し、当該位置情報を図示しないレジスタに記憶する。ステップS82では、当該レジスタに記憶された位置情報により特定される位置を含む所定領域の地図データを他のサービス提供装置から取得するとともに、当該所定領域に配置されているポータルPTLの位置情報およびポータルIDと、当該所定領域に配置されているライブ配信タワーLTWの位置情報および配信タワーIDとをサーバ200から取得する。
ステップS82では、当該位置の周辺を斜め上空から眺めた地図画像を当該地図データに基づいてタッチスクリーン15に表示する。また、メモリ11に記憶されているHEXの配置情報に基づいて、当該地図画像に現れるHEXの中心位置にセンタータワーCTWを表示する。さらに、サーバ200から取得したポータルPTLの位置情報およびポータルIDに基づいて、当該ポータルPTLを当該HEXの所定位置に表示し、サーバ200から取得したライブ配信タワーLTWの位置情報および配信タワーIDに基づいて、当該ライブ配信タワーLTWを当該HEXの所定位置に表示する。また、ライブ配信タワーLTWについては、図29に示すテーブルTBL1において表示設定が「可」を示すもの(ライブ視聴処理が行われていないもの)を表示する。
レジスタに記憶されている位置情報が現在位置PSTを示す場合、ステップS82では、現在位置画像と、当該現在位置PSTを中心とするサークル画像とを当該地図画像に表示する(図30(A)参照)。また、ステップS82では、「タップ済み」のセンタータワーCTWが配置されているHEXをハイライト表示し、一覧アイコンICNを含む各種アイコンを当該地図画像に重畳する。
ステップS83では、当該地図画像上のセンタータワーCTWに対するタップ操作が行われたか否かを、タッチスクリーン15からの操作入力に基づいて判定する。当該タップ操作が行われたと判定されたときは、ステップS84に進む。ステップS84では、当該タップ操作の対象であるセンタータワーCTWの位置が当該サークルCCL内であり、当該センタータワーCTWの設定が「タップ無し」であるか否かを、メモリ11に記憶されているHEXの配置情報およびユーザ端末100の現在位置PSTと、テーブルTBL1の設定とに基づいて判定する。
当該センタータワーCTWの位置が当該サークルCCL内であり、当該センタータワーCTWの設定が「タップ無し」であると判定されたときは、ステップS85に進む。ステップS85では、当該センタータワーCTWの設定を、「タップ無し」から「タップ済み」に変更する。また、当該センタータワーCTWが配置されているHEX内のライブ配信タワーLTWを配信タワーIDに基づいて特定し、当該ライブ配信タワーLTWの視聴設定をテーブルTBL1上で「--」から「未」に変更する。さらに、当該HEX内の全てのポータルPTLをポータルIDに基づいて特定し、当該全てのポータルPTLについて、レアリティを銀、金、虹のいずれかに設定し、クールタイムの残り時間を0分に設定し、遠方プレイ済フラグをリセットする。
この結果、当該HEX内のライブ配信タワーLTWおよびポータルPTLの各々に対するタップ操作が許容される。ポータルPTLについては、ユーザ端末100の現在位置PSTを中心とするサークルCCL内に配置されているポータルPTLであるか否かにかかわらず、当該HEX内の全てのポータルPTLに対するタップ操作が許容される。即ち、当該HEX内の全てのポータルPTLが開放される。ステップS85の処理が完了すると、ステップS83に戻る。
なお、ステップS84において、当該タップ操作の対象であるセンタータワーCTWの位置が当該サークルCCL内であり、当該センタータワーCTWの設定が「タップ無し」であると判定されなかったときは、ステップS85の処理を実行することなく、ステップS83に戻る。
ステップS83において、センタータワーCTWに対するタップ操作が行われたと判定されなかったときは、ステップS86に進み、いずれかのポータルPTLに対するタップ操作が行われたか否かを、タッチスクリーン15からの操作入力に基づいて判定する。当該タップ操作が行われたと判定されたときは、ステップS87に進む。
ステップS87では、ステップS82で取得した当該ポータルPTLのポータルPTLIDに基づいて当該ポータルPTLが配置されているHEXを特定し、当該HEX内のセンタータワーCTWが「タップ済み」であるか否かを、テーブルTBL1の設定に基づいて判定する。当該センタータワーCTWが「タップ済み」であると判定されたときは、ステップS88でポータル対応処理(後述)を実行し、その後にリターンする。
一方、ステップS86において、ポータルPTLに対するタップ操作が行われたと判定されなかったとき、または、ステップS87において、当該センタータワーCTWが「タップ済み」であると判定されなかったときは、ステップS89に進み、一覧アイコンICNに対するタップ操作が行われたか否かを、タッチスクリーン15に対する操作入力に基づいて判定する。当該タップ操作が行われたと判定されたときは、ステップS90に進む。
ステップS90では、センタータワーCTWの設定が「タップ済み」であるHEXをテーブルTBL1上で特定し、当該HEXの見出しが列挙された一覧画面をタッチスクリーン15に重畳して表示する(図30(B)参照)。図30(B)によれば、当該HEXの見出しが当該一覧画面の中央に縦方向に並んで表示され、「キャンセル」ボタンが当該一覧画面の右下段に表示される。
ステップS91では、当該一覧画面に列挙されている見出しのいずれかをタップするHEX選択操作が行われたか否かを、タッチスクリーン15に対する操作入力に基づいて判定する。当該HEX選択操作が行われたと判定されなかったときは、ステップS92に進み、当該一覧画面上の「キャンセル」ボタンがタップされたか否かを、タッチスクリーン15に対する操作入力に基づいて判定する。当該「キャンセル」ボタンがタップされたと判定されなかったときは、ステップS91に戻る。
一方、ステップS91においてHEX選択操作が行われたと判定されたときは、ステップS93に進む。ステップS93では、当該HEX選択操作により選択された見出しに対応するHEXを特定し、当該HEX内の所定位置を示す位置情報を上記レジスタに記憶する。また、ステップS93では、当該一覧画面を非表示とする。ステップS93の処理が完了すると、ステップS82に戻る。
この結果、タッチスクリーン15上の地図画像は、選択されたHEX(所定位置)の周辺を斜め上空から眺めた地図画像に更新される(図30(C)参照)。更新後の地図画像にも、センタータワーCTWと、ポータルPTLと、ライブ視聴処理が行われていないライブ配信タワーLTWとが表示される。また、当該HEX内のセンタータワーCTWは「タップ済み」であるため、ポータルPTLへのタップ操作は、ステップS86およびS87により受け付け可能となり、ライブ配信タワーLTWへのタップ操作は、ステップS97およびS98により受け付け可能となる。
なお、HEX選択操作により地図画像が更新された場合においても、図30(A)と同様に、一覧アイコンICNを含む各種アイコンが当該地図画像に重畳される。ただし、当該HEXがユーザ端末100の現在位置PSTよりも遠方のHEXである場合、現在位置画像と当該現在位置PSTを中心とするサークル画像とが当該地図画像に現れることはない。
ステップS92において「キャンセル」ボタンがタップされたと判定されたときは、ステップS94に進む。ステップS94では、当該一覧画像を非表示とし、その後にステップS83に戻る。
ステップS89において、一覧アイコンICNに対するタップ操作が行われたと判定されなかったときは、ステップS95に進み、スクロール操作が行われたか否かを、タッチスクリーン15に対する操作入力に基づいて判定する。当該スクロール操作が行われたと判定されたときは、ステップS96に進み、レジスタ上の位置情報を更新することなく、タッチスクリーン15に表示されている地図画像をスクロールする。スクロール操作に応じたステップS96の処理が完了すると、ステップS83に戻る。なお、スクロールされた地図画像にもセンタータワーCTWと、ポータルPTLと、ライブ視聴処理が行われていないライブ配信タワーLTWとが表示され、これらのポータルPTL等へのタップ操作が受け付け可能となる。
当該スクロール操作が行われたと判定されなかったときは、ステップS97に進み、ライブ配信タワーLTWに対するタップ操作が行われたか否かをタッチスクリーン15からの操作入力に基づいて判定する。当該タップ操作が行われたと判定されたときはステップS98に進む。ステップS98では、ステップS82で取得した当該ライブ配信タワーLTWの配信タワーIDに基づいて当該ライブ配信タワーLTWが配置されているHEXを特定し、当該HEX内のセンタータワーCTWが「タップ済み」であるか否かをテーブルTBL1に基づいて判定する。
当該センタータワーCTWが「タップ済み」であると判定されると、ステップS99においてライブ視聴処理を実行する。この結果、ゲームプレイ端末300からライブ配信されたデータに基づくコンテンツがタッチスクリーン15に表示される。当該ライブ視聴処理では、当該コンテンツを視聴するユーザに対してポータルチケットを付与する。また、コンテンツの視聴中、ユーザは、後述するステップS116で付与された投げ銭アイテムや、課金により付与された投げ銭アイテムを配信者に対して投入することができる。
ライブ視聴処理が完了すると、ステップS100に進み、テーブルTBL1における当該ライブ配信タワーLTWの表示設定を「不可」に変更し、視聴設定を「済」に変更する。ステップS100の処理が完了すると、ステップS82に戻る。この結果、タッチスクリーン15の表示は、当該レジスタに記憶された位置情報により特定される位置の周辺を斜め上空から眺めた地図画像に更新される。ただし、当該地図画像上では、当該ライブ配信タワーLTWは非表示とされる。
ステップS97において、ライブ配信タワーLTWに対するタップ操作が行われたと判定されなかったとき、または、ステップS98において、当該センタータワーCTWが「タップ済み」であると判定されなかったときは、ステップS101でその他の処理を実行し、その後にリターンする。
ステップS88に示すポータル対応処理は、図32に示すサブルーチンに従って実行される。まずステップS111で、タップされたポータルPTLに設定されているクールタイムの残り時間は0分であるか否かを、テーブルTBL1に基づいて判定する。当該残り時間は、センタータワーCTWへのタップ操作されたとき、並びにゲームが実行された後に再設定されたクールタイムが経過したときに0分を示す。このような状態で当該ポータルPTLがタップされると、ステップS111からステップS112に進む。
ステップS112では、当該ポータルPTLのポータルIDに基づいて当該ポータルPTLが配置されているHEXを特定し、ユーザ端末100の現在位置PSTが当該HEXの内側であるか否かをメモリ11に記憶されているHEXの配置情報とユーザ端末100の現在位置PSTとに基づいて判定する。
当該現在位置PSTが当該HEXの内側であると判定されたときは、ステップS113に進み、当該現在位置PSTが当該HEXの内側であると判定されなかったときは、ステップS118に進む。
この結果、あるポータルPTLへのタップ操作に応じてゲーム処理が実行された後において、当該ポータルPTLが属するHEX内にユーザ端末100が存在するときには、当該ポータルPTLのクールタイムが経過することにより当該ポータルPTLへの再度のタップ操作が許容される。例えば、HEX1に配置されているポータル2へのタップ操作に応じてゲーム処理が実行された後においてユーザ端末100がHEX1内に存在するときにされた当該ポータル2への再度のタップ操作は、当該ポータル2のクールタイムが経過していることにより、許容される。
一方、ポータルPTLへのタップ操作に応じてゲーム処理が実行された後において、当該ポータルPTLが属するHEX内にユーザ端末100が存在しないときには、当該ポータルPTLのクールタイムが経過することによっては、当該ポータルPTLへの再度のタップ操作は許容されない。例えば、HEX1に配置されているポータル2へのタップ操作に応じてゲーム処理が実行された後においてユーザ端末100がHEX1の外側に移動しているときにされた当該ポータル2への再度のタップ操作は、当該ポータル2のクールタイムが経過していることのみによっては許容されず、後述するステップS118へ移行される。
ステップS113では、テーブルTBL1において当該HEX内のポータルPTLに関連付けられている遠方プレイ済みフラグを全てリセットする。例えば、ユーザ端末100がHEX1内に存在する場合は、当該HEX1内のポータル1、2、…の各々に関連付けられている遠方プレイ済みフラグをリセットする。ステップS113の処理が完了すると、ステップS114に進む。
一方、ステップS118では、タップ操作が行なわれたポータルPTLに関連付けられている遠方プレイ済みフラグがリセットされているか否かをテーブルTBL1に基づいて判定する。当該遠方プレイ済みフラグがリセットされていると判定されたときは、ステップS119で当該遠方プレイ済みフラグをセットし、その後にステップS114に進む。この結果、例えばHEX1に配置されているセンタータワーCTWがタップされた後に、ユーザ端末100が当該HEX1の外側に移動し、当該HEX1の内側に戻っていない状況でも、当該HEX1内に配置されているポータル1、2、…に設定されているクールタイムが0分であれば、遠方プレイ済みフラグがリセットされていることを条件として当該ポータル1、2、…へのタップ操作が1回だけ許容される。
ステップS114では、当該ポータルPTLに関連付けられているゲームを当該ポータルPTLのポータルIDに基づいて特定し、当該ゲームを実行する。当該ゲームは、所定の達成条件が成立することによりクリアとなる。当該ゲームが終了するとステップS115に進み、当該ゲームがクリアされたか否かをステップS114の処理結果に基づいて判定する。当該ゲームがクリアされたと判定されると、ステップS116に進む。
ステップS116では、当該ポータルPTLに設定されているレアリティをテーブルTBL1から特定し、当該レアリティが高いほど価値の高い投げ銭アイテムを、報酬としてユーザに付与する。付与対象の投げ銭アイテムには、ライブ配信(指定場所)に応じたカテゴリにかかわらずライブ配信中において一律に投入(消費)可能な投げ銭アイテムの他に、図33(C)に示す特定カテゴリ(公園、神社、寺等)のライブ配信中に投入(消費)可能な専用投げ銭アイテム(公園に対する「噴水」、神社に対する「鳥居」、寺に対する「鐘」等)が含まれている。これについては後述する。
ステップS116の処理が完了すると、ステップS117に進む。また、ステップS115において当該ゲームがクリアされたと判定されなかったときは、ステップS116の処理を実行することなく、ステップS117に進む。ステップS117では、当該ゲームを実行する契機となったタップ操作の対象であるポータルPTLをテーブルTBL1上で特定し、当該ポータルPTLのクールタイムを所定時間に再設定する。ステップS117の処理が完了すると、リターンする。
ステップS111において、タップされたポータルPTLに設定されているクールタイムの残り時間は0分であると判定されなかったとき、または、ステップS118において、当該ポータルPTLに関連付けられている遠方プレイ済みフラグがリセットされていると判定されなかったときは、ステップS120に進み、図30(D)に示すチケット消費問合せ画面をタッチスクリーン15に重畳して表示する。図30(D)によれば、当該チケット消費問合せ画面には、「ポータルチケットを消費してゲームを実行しますか?」の文字列と、「実行」ボタンと、「キャンセル」ボタンとが表示される。
ステップS121では、「実行」ボタンがタップされたか否かをタッチスクリーン15に対する操作入力に基づいて判定する。当該「実行」ボタンがタップされたと判定されなかったときは、ステップS123に進み、「キャンセル」ボタンがタップされたか否かをタッチスクリーン15に対する操作入力に基づいて判定する。当該「キャンセル」ボタンがタップされたと判定されなかったときは、ステップS121に戻る。
ステップS121において「実行」ボタンがタップされたと判定されたときは、ステップS122に進み、ユーザが所有するポータルチケットを消費する。ステップS122の処理が完了すると、ステップS114に移行する。このため、当該ポータルPTLに対するタップ操作は、クールタイムの残り時間が0分でない場合や、遠方プレイ済みフラグがセットされている場合でも、当該ポータルチケットを消費することにより、当該ポータルPTLに対するタップ操作が許容される。一方、ステップS123において「キャンセル」ボタンがタップされたと判定されたときは、リターンする。
なお、ユーザがポータルチケットを所有していないときは、ステップS120〜S123の処理を実行することなく、リターンする。ただし、ポータルチケットを所有していない場合には、課金によりポータルチケットまたは仮想通貨を購入可能とし、当該ポータルチケットまたは当該仮想通貨を消費することにより、当該ポータルに対するタップ操作を許容するようにしてもよい。
ライブ配信には、前述したようにライブ配信タワーLTWへのタップ操作により視聴可能となるライブ配信のみならず、所定のライブ視聴アイコンへのタップ操作(ライブ視聴操作)により視聴可能となるライブ配信が設けられている。図33〜図35では、所定のライブ視聴アイコンへのタップ操作により視聴可能となるライブ配信について説明する。
図33(A)は、ライブ配信の予定を複数のユーザ端末100に通知するライブ予定通知処理の一例を示すフローチャートである。図33(A)を参照して、ゲームプレイ端末300のプロセッサ30は、ステップS130において、例えば配信者によりライブ配信予定(ライブ視聴の指定場所を含む)が入力されたか否か判定する。ゲームプレイ端末300を所持する配信者がコントローラ540等を操作してライブ配信予定(ライブ視聴の指定場所を含む)を入力した段階で、ステップS131に進む。ライブ配信予定は、少なくとも、ライブ配信の開始日時およびライブを視聴するための指定場所を含んでいる。ステップS131では、入力されたライブの指定場所が属するカテゴリと、当該カテゴリのライブ配信専用の投げ銭アイテムとして定められている専用投げ銭アイテムとを特定する処理を行う。
「カテゴリ」とは、ライブを視聴するための指定場所がどの範疇に属するかを分類した枠組みである。例えば、ライブ視聴の指定場所が「代々木公園」であればカテゴリとして「公園」、「明治神宮」であればカテゴリとして「神社」、「清水寺」であればカテゴリとして「寺」となる。このカテゴリは、例えば地図データを提供する他のサービス提供装置で管理されている。他のサービス提供装置のアプリケーションプログラムでは、例えば、「公園」、「神社」、「寺」、「球場」、「ショッピングモール」等のカテゴリを入力すれば、当該カテゴリに属する場所がマップ上に表示される。他のサービス提供装置のアプリケーションプログラムと、ゲームプレイ端末300およびユーザ端末100各々のアプリケーションプログラムとは、API(Application Programming Interface)を介して連携している。ゲームプレイ端末300およびユーザ端末100は、各々、当該他のサービス提供装置のAPIを利用して、入力されたライブ視聴の指定場所がどのカテゴリに属するかのカテゴライズを行うことができる。ステップS131では、例えば、配信者により京都清水寺が指定場所として指定された場合、指定場所が属するカテゴリとして「寺」を特定する。
本実施形態におけるライブ配信は、指定場所へ実際に出向くことにより視聴可能となることに加えて、指定場所と同じカテゴリに属する場所へ出向くことによっても視聴可能となる。よって、例えば、配信者により京都清水寺が指定場所として指定された場合には、京都清水寺のみならず、当該京都清水寺が属するカテゴリである寺が特定され、地図上に配置されているいずれかの寺に出向くことにより、当該ライブ配信を視聴可能となる。
また、「専用投げ銭アイテム」とは、配信者により指定された指定場所が属する特定のカテゴリのライブ配信中に投入(消費)できる当該カテゴリ専用の投げ銭アイテムである。専用投げ銭アイテムの種類は、カテゴリに応じて予め定められている。専用投げ銭アイテムの種類としては、例えば、カテゴリ「公園」に対して「噴水」、カテゴリ「神社」に対して「鳥居」、カテゴリ「寺」に対して「鐘」、カテゴリ「球場」に対して「ボール」、カテゴリ「ショッピングモール」に対して「ポイントカード」などが予め定められている。なお、カテゴリに応じて定められている専用投げ銭アイテムの種類は、1つのカテゴリに対して1種類に限らず、1つのカテゴリに対して複数種類定められているものであってもよい。ステップS131では、例えば、配信者により京都清水寺が指定場所として指定された場合、カテゴリ「寺」に対する「鐘」が専用投げ銭アイテムの種類として特定される。
ステップS132においては、入力されたライブ配信予定(指定場所を含む)と、特定されたカテゴリと、特定された専用投げ銭アイテムの種類とを特定可能な情報を、サーバ200を介してユーザ端末100へ送信する。なお、ゲームプレイ端末300からユーザ端末100へ送信する情報については、サーバ200を経由することなく、ゲームプレイ端末300からユーザ端末100へ直接送信するものであってもよい。
ユーザ端末100のプロセッサ10は、ステップS134によりライブ配信予定と、特定されたカテゴリと、特定された専用投げ銭アイテムの種類とを特定可能な情報を受信したか否か判定する。ステップS134において受信していないと判定された場合にはリターンするが、受信したと判定された場合にはステップS135に移行する。ライブ配信予定等を特定可能な情報は、例えば、ユーザが働きかけなくても能動的に取得して通知するプッシュ方式のプッシュ通知により通知される。
ステップS135においては、受信した情報に基づくライブ配信予定をタッチスクリーン15にポップアップ通知し、その後ステップS136に進む。具体的には、ユーザ端末100のタッチスクリーン15の所定領域(例えばステータスバー)にプッシュ通知の受信に対応する画像が表示される。プッシュ通知の受信に対応する画像をタップ操作することにより、ゲームプログラム(ゲームプログラムが起動していない場合には当該ゲームプログラムを起動)によりユーザ端末100のタッチスクリーン15にポップアップ通知が表示される。図33(B)は、ポップアップ通知の表示画面例を示している。
図33(B)では、ユーザ端末100のタッチスクリーン15に、「[お知らせ]2019年3月24日午後2時より京都の清水寺に集合してください!ライブ配信します。遠方の方はお近くのお寺で視聴してください。」といったメッセージが表示されている。さらに、メッセージの下に、「視聴予約」のアイコンが表示されており、このアイコンをユーザがタップ操作することにより、ポップアップ通知されたライブの視聴を予約できる。
ステップS136では、視聴予約の操作を行ったか否かを、「視聴予約」のアイコンに対する入力操作に基づいて判定する。視聴予約の操作を行っていないと判定された場合にはリターンする。一方、ユーザが「視聴予約」のアイコンをタップ操作した場合には、ステップS136で視聴予約の操作が行われたと判定し、ステップS137に移行する。ステップS137では、受信した情報に基づき、視聴予約されたライブ配信予定と、特定されたカテゴリと、特定された専用投げ銭アイテムの種類とをメモリ11にテーブルの形で記憶した後、リターンする。図33(C)は、メモリ11に記憶されたテーブルTBL2の一例である。テーブルTBL2では、ライブ配信の開始日時、ライブ視聴の指定場所、カテゴリ、および専用投げ銭アイテムの種類が記憶されている。ユーザ端末100においては、ライブ配信が開始されるまでに受信したライブ配信予定等に基づきテーブルTBL2を生成し、生成されたテーブルTBL2に基づいてライブ配信予定の一覧(専用投げ銭アイテムの種類を含む)を表示部152に表示可能となる。
図34は、ユーザの場所に応じて視聴可能となるライブ配信を視聴するためのライブ視聴処理の流れの一例を示すフローチャートである。図34を参照し、ユーザ端末100のプロセッサ10は、ステップS145において、ライブ視聴操作が行われたか否かを、タッチスクリーン15に対する入力操作に基づいて判定する。ライブ視聴操作が行われていないと判定された場合にはリターンする。ユーザがタッチスクリーン15を操作してライブ視聴操作を行えば、ステップS145においてライブ視聴操作が行われたと判定され、ステップS146に進み、前述のステップS137で記憶されたライブの予約リストをタッチスクリーン15に表示する。具体的には、メモリ11にテーブルTBL2として記憶されている予約済みのライブの発信日時、ライブ視聴の指定場所およびカテゴリをリスト表示する。ステップS146の処理が完了すると、ステップS147に進み、予約リストへのタップ操作が行われたか否かを判定する。タップ操作が行われていないと判定された場合にはステップS148に進み、キャンセル操作が行われたか否かを判定し、キャンセル操作が行われていないと判定した場合にはステップS146に戻る。ステップS147〜S148の処理を繰り返し実行し、キャンセル操作が行われたと判定された時点でリターンするが、予約リストへのタップ操作が行われたと判定された場合にステップS149に進む。
ステップS149では、タップされた予約ライブの指定場所およびカテゴリをテーブルTBL2から特定する。例えば、2019年3月14日午後5時から開始されるライブ視聴の指定場所が代々木公園の予約ライブがタップされた場合には、図33(C)のテーブルTBL2を参照して、指定場所として「代々木公園」、カテゴリとして「公園」が特定される。ステップS150においては、当該ユーザ端末100の現在位置を示す位置情報を位置登録システムから取得する。また、ステップS151においては、ステップS149で特定したカテゴリに属する場所を、他のサービス提供装置のAPIを利用することにより、当該ユーザ端末100の現在位置近辺から特定する。例えば、タップされた予約ライブの指定場所のカテゴリが「公園」で、当該ユーザ端末100の現在位置が大阪市西区靭本町1丁目−B−Cである場合、カテゴリ「公園」に属する場所のうち現在位置から最も距離が近い場所を特定する。その結果、例えば現在位置である大阪市西区靭本町1丁目−B−C近辺の公園である「靭公園」「花乃井公園」「江戸堀公園」「西船場公園」等のうち、現在位置から最も直線距離が近い場所(ここでは「靱公園」とする)が特定される。
ステップS151の処理が完了すると、ステップS152に進む。ステップS152では、ユーザ端末100の現在位置がライブ視聴の指定場所(例えば代々木公園内の所定位置)から所定範囲内(例えば30m圏内)であるか否か判定する。所定範囲内であると判定された場合にはステップS166に進む。なお、代々木公園内の所定位置は、他のサービス提供装置上において代々木公園に対応付けられている位置(例えば中央位置)であってもよく、また他のサービス提供装置上において代々木公園の外縁位置であってもよい。ステップS152において所定範囲内ではないと判定された場合には、ステップS153に進み、ユーザ端末100の現在位置がステップS151で特定された場所(例えば、靭公園)から所定範囲内(例えば30m圏内)であるか否か判定する。所定範囲内であると判定した場合にはステップS166に進む。なお、所定範囲内は30mに限らず、例えば、50mまたは100mであってもよい。また、所定範囲は、ステップS152とステップS153とで異なる距離が定められているものであってもよい。
一方、ステップS153において、所定範囲内ではないと判定した場合にはステップS154に進み、所定範囲外である旨をタッチスクリーン15に表示する。所定範囲外である旨としては、例えば、タッチスクリーン15に「公園にもう少し近づいてください!」といったメッセージを表示するものであってもよい。また、ステップS147において予約リストへのタッチ操作が行われたときには、ステップS149〜S151において特定された結果に基づいて、タッチスクリーン15に現在位置や特定された公園を含む地図画像を表示し、現在位置から所定範囲内に相当するサークル画像を表示し、当該サークル画像の外に公園が表示されることにより所定範囲外である旨を表示するようにしてもよい。
ステップS154の処理の後、ステップS155に進み、所定の終了操作があったか否かを、タッチスクリーン15に対する入力操作に基づいて判定する。所定の終了操作があったと判定された場合には、リターンする。一方、所定の終了操作がないと判定した場合には、ステップS150に戻り、ステップS150〜ステップS155の処理を繰り返し実行する。ステップS150〜ステップS155の処理が繰り返し実行されている間に、ユーザがライブ視聴の指定場所またはステップS151で特定された場所から所定範囲内に進入した場合には、ステップS152またはステップS153で所定範囲内であると判定され、ステップS166に進む。
次に図35を参照してライブ配信される際の処理の流れの一例を説明する。ステップS166では、ストレージ12に記憶されている仮想空間データに基づいて仮想空間600Bを規定する。また、ステップS166では、仮想カメラ620Bを当該仮想空間600Bの予め定められた初期位置に配置する。
ステップS167では、ゲームプレイ端末300から配信されたゲーム進行情報を受信する。ステップS168では、当該ゲーム進行情報に基づいて、アバターオブジェクト610を含むオブジェクトを仮想空間600Bに配置・動作させるとともに、各種ゲームパラメータ値を更新する。
ゲーム進行情報は、ゲームプレイ端末300から所定時間(1/60秒)毎に送信される。このため、ステップS168においては、受信したゲーム進行情報に基づき、仮想空間600B内のオブジェクトを当該所定時間毎に更新し、各種ゲームパラメータ値を当該所定時間毎に更新する。なお、仮想空間600Bに配置されるオブジェクトには、ユーザにより投入された投げ銭アイテムのオブジェクトも含まれる。
ステップS169では、現在の仮想カメラ620Bの位置および向きに応じた視界領域640Bを規定し、当該視界領域640Bに対応する視界画像660を生成する。また、ステップS169では、上記の各種ゲームパラメータ値を表すパラメータ画像を当該視界画像660の上段に重畳するとともに、アイテム投入操作をユーザから受け付けるためのUI画像を当該視界画像660の下段に重畳し、タッチスクリーン15に表示する。このUI画像は、ライブの視聴制御を行う契機となった場所が属するカテゴリに応じた専用投げ銭アイテム(図33(C)参照)を投入するためのアイコンを含んでいる。
本実施形態では、ステップS116で付与された無償の投げ銭アイテムのアイコン(指定場所が属するカテゴリに応じた専用投げ銭アイテムのアイコンを含む)と、仮想通貨を消費することにより投入可能な有償の投げ銭アイテムのアイコン(指定場所が属するカテゴリに応じた専用投げ銭アイテムのアイコンを含む)とが、UI画像に描かれる。有償の投げ銭アイテムには、当該投げ銭アイテムを投入する際に消費される仮想通貨の量と、当該仮想通貨の消費量に応じたポイント量とが関連付けられている。
ここで、ポイントとは、ユーザおよび配信者に付与されるポイントであって、投げ銭アイテムが投入されることにより、当該投げ銭アイテムに関連付けられているポイントがユーザおよび配信者に付与される。ユーザおよび配信者は、付与されたポイントの量に応じて例えば、他のユーザ間あるいは他の配信者間における格付け(ランキング)等がなされる。このため、より多くのポイントを獲得しようとする動機を働かせることができる。有償の投げ銭アイテムに関連付けられているポイント量は、無償の投げ銭アイテムに関連付けられているポイント量よりも多い。また、有償の投げ銭アイテムに関連付けられているポイント量は、当該有償の投げ銭アイテムの投入に必要な仮想通貨の消費量が増大するほど増大する。また、指定場所が属するカテゴリに応じた専用投げ銭アイテムに関連付けられているポイント量は、カテゴリにかかわらずライブ配信中において一律に投入可能な投げ銭アイテムに関連付けられているポイント量よりも多い。このため、専用投げ銭アイテムを獲得しようとする動機および専用投げ銭アイテムを投入(消費)しようとする動機を働かせることができる。
ステップS170では、有償の投げ銭アイテムのアイコンであってカテゴリに応じた専用投げ銭アイテムのアイコンを含む複数種類のアイコンに対するタップ操作が行われたか否かを、タッチスクリーン15に対する入力操作に基づいて判定する。当該タップ操作が行われたと判定されたときは、ステップS171に進み、ユーザが所有する仮想通貨のうちから、当該タップ操作の対象である投げ銭アイテムに関連付けられている消費量に相当する仮想通貨を消費する。ステップS171の処理が完了すると、ステップS173に進む。
有償の投げ銭アイテムのアイコンに対するタップ操作が行われたと判定されなかったときは、ステップS172に進み、無償の投げ銭アイテムのアイコンであってカテゴリに応じた専用投げ銭アイテムをユーザが獲得している場合には当該専用投げ銭アイテムのアイコンを含む複数種類のアイコンに対するタップ操作が行われたか否かを、タッチスクリーン15に対する入力操作に基づいて判定する。当該タップ操作が行なわれたと判定されたときは、ステップS173に進む。
ステップS173では、アイテム投入情報をゲームプレイ端末300に対して送信する。アイテム投入情報には、当該タップ操作の対象である投げ銭アイテムの種類を特定するための情報と、当該投げ銭アイテムに関連付けられたポイント量と、当該アイテム投入操作を行ったユーザのユーザIDを特定するための情報とが含まれる。ステップS173の処理が完了したとき、またはステップS172において無償アイテム投入操作が行なわれたと判定されなかったときは、ステップS174に進む。
ステップS174では、ユーザによって視聴終了操作が行われたか否かを、タッチスクリーン15に対する入力操作に基づいて判定する。視聴終了操作が行われたと判定されなかったときは、ステップS167に戻る。これにより、ゲームプレイ端末300からゲーム進行情報を受信する毎に、オブジェクトの動きや配置などを制御する処理が繰返し実行される。一方、視聴終了操作が行われたと判定されたときは、ステップS175に進み、視聴完了条件が成立したことによりポータルチケット(特典)を付与する処理が行われ、ユーザ端末100のメモリ15にポータルチケットが加算記憶される。ステップS175の処理が完了したとき、リターンする。ステップS175における視聴完了条件とは、ゲームプレイ端末300から配信されてくる1つのライブ配信について、所定の割合(例えば90%)以上視聴していることにより成立する条件である。ステップS175においては、ライブ視聴の指定場所(例えば代々木公園)にまでユーザが実際に出向いた場合には、指定場所と同じカテゴリに属する場所(例えば公園)に出向いた場合に比べて、多くのポータルチケットを付与してもよい。
一方、ゲームプレイ端末300は、図35の右側に示すフローチャートに従って予定していたライブ配信を実行する。ステップS180では、ゲームプログラムに基づいて当該ライブ配信を進行させる。具体的には、アバターオブジェクト610を含むオブジェクト(後述するステップS183で投入されたアイテムオブジェクトを含む)について仮想空間600A内における配置・移動・変更等の更新を行うとともに、各種ゲームパラメータを初期設定または更新等する。また、ライブ配信されるコンテンツは、例えば、図11や図12等で示したライブ配信ゲームなどであってもよい。
ステップS181では、ユーザ端末100からアイテム投入情報を受信したか否かを、通信IF13からの入力に基づいて判定する。当該アイテム投入情報を受信したと判定されたときは、ステップS182に進む。ステップS182では、当該アイテム投入情報に含まれるポイント量を特定し、当該ポイント量をアバターオブジェクト610に付与する。ステップS183では、当該アイテム投入情報に含まれる投げ銭アイテムの種類を特定し、当該種類に対応するアイテムオブジェクトを仮想空間600A内に投入して配置する。
ステップS183の処理が完了したとき、またはステップS181で当該アイテム投入情報を受信したと判定されなかったときは、ステップS184に進む。ステップS184では、ステップS180において更新された仮想空間600A内のオブジェクト(ステップS183の処理によって投入されたアイテムオブジェクトを含む)と各種ゲームパラメータ値とに基づいてゲーム進行情報を生成し、当該ゲーム進行情報データを複数のユーザ端末100に配信する。ステップS184の処理が完了すると、リターンする。これにより、配信するライブ映像を、指定場所から所定範囲内に存在するユーザ端末100のみならず、指定場所と同じカテゴリに属する場所から所定範囲内に存在するユーザ端末100において視聴可能となる。
<本実施形態の効果>
本実施形態によれば、ライブ視聴条件にかかわる指定場所が遠方の場合に、ユーザがその指定場所にまで出向かなくても、ユーザの近隣であってライブ視聴の指定場所が属するカテゴリと同じカテゴリの場所に出向くことにより、ライブの視聴が可能となり、ライブ視聴に伴うユーザの負担を軽減できるとともに、ゲームの好趣を高めることができる。
また、ユーザは、ライブ配信を視聴することによりポータルチケットを獲得できるため、ライブ配信の視聴に対するインセンティブを付与できる。また、ライブ視聴の指定場所にまでユーザが出向いた場合には、ライブ指定場所が属するカテゴリと同じカテゴリの場所に出向いた場合に比べて、多くのポータルチケットを獲得できるようにすれば、指定場所にまでユーザが出向くインセンティブも維持できる。
また、ライブ配信中に投入できるアイテムとして表示される投げ銭アイテムには、カテゴリにかかわらず一律に表示される投げ銭アイテムに加えて、ライブの指定場所が属するカテゴリに応じた種類の専用投げ銭アイテムが含まれる。このため、ライブ配信中に投入できるアイテムの幅が広がるため、ゲームの好趣を高めることができる。また、専用投げ銭アイテムは、ポータルに関連付けられているゲームをクリアすることによっても獲得可能となる。このため、ポータルに関連付けられているゲームの実行→ライブ配信において専用投げ銭アイテムの投入→ポイントやポータルチケット獲得→ランキング上昇→ポータルに関連付けられているゲームの実行…といったゲームサイクルをユーザに提供可能となる。
本実施形態によれば、複数のHEXに区分されている地図画像のうち、ユーザ端末100の現在位置PSTに応じた地図画像が、タッチスクリーン15に表示される。ポータルPTLへのタップ操作は、当該複数のHEXのうち、現在位置PSTを中心とするサークルCCL内に中心位置(センタータワーCTW)が存在する特定のHEX内に配置されているポータルPTLを対象として許容される。許容されたポータルPTLに対するタップ操作が行われると、当該ポータルPTLに関連付けられたゲームが実行される。
この結果、ユーザに対してHEXの中心位置がサークルCCL内に含まれる程度の移動を促すことができ、かつ、当該移動によって、当該HEX内に配置されているポータルPTLであれば、サークルCCL内に含まれていないポータルPTLであっても、これらのポータルPTLに応じたゲームが実行可能となる。つまり、適度な移動をユーザに促すとともに、適度な移動により実際に移動していないポータルPTLに応じたゲームが実行可能となるため、ゲームの好趣を高めることができる。
また、本実施形態によれば、特定のHEX内に配置されているポータルPTLがユーザ端末100を中心とするサークルCCL内に配置されているか否かにかかわらず、当該ポータルPTLへのタップ操作が許容される。
このため、あるHEXに配置されているポータルPTLに対するタップ操作は、当該HEXの中心位置が当該サークルCCL内に含まれる位置にユーザ端末100が移動することにより、許容される。これによって、当該タップ操作が可能となるためのユーザの行動基準が単純明快になり、ゲームの好趣が向上する。
また、本実施形態によれば、複数のHEX各々の中心位置には、センタータワーCTWが配置されており、特定のHEX内のセンタータワーCTWに対してタップ操作を行うことにより、当該特定のHEX内に配置されているポータルPTLへのタップ操作が許容される。この結果、当該ポータルPTLに関連付けられているゲームを実行するには、ユーザは、地図画像をタッチスクリーン15に表示させ、いずれかのHEXのセンタータワーCTWが当該サークルCCL内に存在する状況になったときに、当該センタータワーCTWをタップする必要がある。これによって、地図画像を頻繁に確認するためのユーザ操作が促され、位置情報ゲームがダウンロードされたまま放置される懸念を軽減することができる。
HEX内のポータルPTLを開放する契機となるタップ操作の対象であるセンタータワーCTWは、当該HEXの端ではなく中心に配置される。このため、他のHEX内のポータルPTLを開放するためには、ユーザは当該他のHEXのセンタータワーCTWがサーブルCCL内に含まれる位置に移動する必要がある。これによって、ユーザに適度な移動を促すことができる。
さらに、本実施形態によれば、HEXの一覧画面に表示されている見出しのうちのいずれかの見出しをタップするHEX選択操作が行われると、ユーザ端末100の現在位置PSTにかかわらず、当該見出しに対応するHEXが現れている地図画像がタッチスクリーン15に表示される。タップ操作が許容されているポータルPTLがどのポータルPTLであるかは、テーブルTBL1により管理されている。ユーザ端末100の現在位置PSTを中心とするサークルCCL内に中心位置が存在していないHEX内のポータルPTLであっても、テーブルTBL1からタップ操作が許容されていることが特定されるポータルPTLへのタップ操作を受け付けることにより、当該ポータルPTLに関連付けられているゲームが実行される。
これによって、あるHEXの中心位置が当該サークルCCLに含まれる位置まで移動することにより、当該HEX内のポータルPTLへのタップ操作が許容されれば、ユーザ端末100が当該HEXから離れた後でも、当該ポータルPTLに対するタップ操作により、当該ゲームを実行することができる。また、当該ゲームをクリアすることにより、ライブ配信の配信者に対して投入可能な投げ銭アイテムを入手できる。即ち、センタータワーCTWが一旦タップ操作されたHEXについては、当該HEX内にユーザ端末が存在しないときであっても、当該HEX内のポータルPTLに応じたゲームを実行でき、投げ銭アイテムを入手することができる。この結果、様々な地域を訪問した際に取り敢えずセンタータワーCTWをタップしておき、訪問先から戻った後にゆっくりゲームを楽しもうという動機付けを働かせることができる。
また、本実施形態によれば、あるHEX内のポータルPTLへのタップ操作を許容することによりゲーム処理が実行された後において、ユーザ端末100の現在位置PSTに応じて再許容条件(当該HEX内にユーザ端末100が存在するという条件)が成立しているときには、クールタイムが経過することにより当該ポータルPTLへの再度のタップ操作が許容される。一方、ユーザ端末100の現在位置PSTに応じて再許容条件が成立していないときには、クールタイムが経過することによっては当該ポータルPTLへの再度のタップ操作は許容されない。これによって、ユーザ端末100が当該HEX内に存在し続ける場合、クールタイムが経過する毎にタップ操作が許容され、ゲームを繰り返し楽しむことができる。また、ユーザ端末100が当該HEX内に存在しないときにまで時間経過のみによりゲームを繰り返し実行できないようにすることにより、ユーザに移動を促すことができる。
さらに、本実施形態によれば、ゲーム処理が実行された後において当該再許容条件が成立していないことにより、当該ポータルPTLへの再度のタップ操作が許容されないときであっても、ユーザが所有するポータルチケットを消費することにより、当該ポータルPTLへの再度のタップ操作が許容可能とされる。これによって、ユーザ端末100が当該ポータルPTLが配置されているHEXから離れた後でも、当該ポータルチケットを消費することにより、当該ゲームを楽しむことができる。
また、本実施形態によれば、当該ポータルチケットは、ライブ配信によるコンテンツをユーザが視聴することにより、当該ユーザに付与される。この結果、当該コンテンツを視聴して当該ポータルチケットを入手することにより、再度のタップ操作が許容されていないポータルPTLに関連付けられているゲームを実行可能にしようという動機付けをユーザに働かせることができる。
さらに、本実施形態によれば、ポータルPTLに関連付けられたゲームがクリアされることにより、複数種類の投げ銭アイテムのうち当該ポータルPTLが配置されているHEXに応じた種類の投げ銭アイテムがユーザに付与される。これによって、様々な地域を訪れて様々な投げ銭アイテムを入手しようという動機付けをユーザに働かせることができる。
<変形例>
以上説明した実施形態の変形例などを以下に列挙する。
(1) 上記実施形態においては、ユーザ端末100の現在位置PSTを中心とするサークルCCL内にセンタータワーCTWが含まれる状態で当該センタータワーCTWをタップすることにより、当該センタータワーCTWが属するHEX内の全てのポータルPTLを開放するようにしている。しかし、センタータワーCTWへのタップ操作により、センタータワーCTWに応じたゲーム処理が実行され、当該ゲームをクリアすることにより、当該センタータワーCTWが属するHEX内の全てのポータルPTLを開放するようにしてもよい。つまり、センタータワーCTWは、HEX内の全てのポータルPTLを開放する契機となることに加えて、ポータルPTLと同様にゲーム処理を実行するものであってもよい。また、HEX内にセンタータワーCTWが設けられているものに限らず、当該サークルCCL内に当該複数のポータルPTLのうちのいずれかのポータルPTLまたは特定のポータルPTLが含まれる状態で当該ポータルPTLをタップすることにより、当該ポータルPTLが属するHEX内の全てのポータルPTLを開放するようにしてもよい。
(2) 上記実施形態においては、複数のHEX各々の位置および形状は固定的である。しかし、当該位置または形状は、時期(例えば季節)によって異ならせるようにしてもよく、さらには隣り合うHEXの間に隙間を設けるようにしてもよい。同様に、当該複数のHEX各々に配置されるライブ配信タワーLTWおよびポータルPTLの位置や数も、時期(例えば季節)によって異ならせるようにしてもよい。
(3) 上記実施形態においては、ライブ配信タワーLTWおよびポータルPTLは、センタータワーCTWに対するタップ操作が行われる前の段階でも、地図画像上に現れている。しかし、ライブ配信タワーLTWおよびポータルPTLは、センタータワーCTWに対するタップ操作が行われることにより、地図画像上に出現させるようにしてもよい。この場合、ライブ配信タワーLTWおよびポータルPTLは、当該タップ操作時に乱数抽選によって特定した位置に配置するようにしてもよい。
(4) 上記実施形態においては、現在の地図を表す地図画像をタッチスクリーン15に表示するようにしているが、例えば地図更新操作を受け付けることにより、別の時代の地図を表す地図画像をタッチスクリーン15に表示するようにしてもよい。これにより、表示する地図画像のバリエーションを豊富にすることができる。
(5) 上記実施形態においては、ポータルPTLの位置情報およびポータルIDとライブ配信タワーLTWの位置情報および配信タワーIDとをサーバ200から取得し、地図データを他のサービス提供装置から取得するようにしている。しかし、地図データについてもサーバ200から取得するようにしてもよい。
(6) 上記実施形態においては、ライブ配信タワーLTWに対するタップ操作は、当該ライブ配信タワーLTWが配置されているHEX内のセンタータワーCTWに対してタップ操作を行うことにより、許容される。しかし、当該ライブ配信タワーLTWに対するタップ操作は、当該センタータワーCTWがタップされたか否かにかかわらず許容するようにしてもよい。
(7) 上記実施形態においては、あるHEX内のポータルPTLに関連付けられている遠方プレイ済みフラグは、ユーザ端末100が当該HEX内のいずれかのポータルPTLに対してタップ操作を行うことにより、リセットされる。しかし、ユーザ端末100があるHEX内に入れば、当該HEX内のいずれかのポータルPTLに対してタップ操作が行われたか否かにかかわらず、当該HEX内のポータルPTLに関連付けられている遠方プレイフラグをリセットするようにしてもよい。
(8) 上記実施形態においては、ユーザがあるHEX内のセンタータワーCTWをタップして当該HEXの外に移動した場合(例えば、大阪に配置されているHEX内のセンタータワーCTWをタップして東京に移動した場合)、当該HEX内のポータルPTLに対してタップ操作が行われたか否かにかかわらず、当該HEX内のいずれのポータルPTLについても、1回に限りタップ操作が許容される。しかし、当該HEX内のポータルPTLのうち、ユーザ端末100が当該HEX内にいる状態でタップ操作が行われたポータルPTLについては、ユーザ端末100が当該HEXの外に移動した後のタップ操作を許容しないようにしてもよい。即ち、ユーザ端末100が当該HEXの外側に存在する状態でタップ操作を許容するポータルPTLは、当該HEX内のポータルPTLのうち1回もゲームが実行されていないポータルPTLに限るようにしてもよい。
(9) 上記実施形態においては、ユーザ端末100の現在位置PSTを中心とするサークルCCLの広さは固定的である。しかし、課金操作を受け付けることにより当該サークルCCLの広さを拡大するようにしてもよい。例えば、サークル拡大アイコンを当該サークルCCLが表示されている地図画像上に表示し、当該サークル拡大アイコンがタップされたときに、課金をしてもよいか否かを確認した上でサークルCCLの広さを2倍(例えば、半径1キロの広さ)にするようにしてもよい。また、拡大された後のサークルの広さは、2以上のHEXのセンタータワーが包含される広さとなるようにしてもよい。
(10) 上記実施形態においては、ゲームをクリアすると、当該ゲームを実行する契機となったポータルPTLのレアリティに応じた投げ銭アイテムをユーザに付与するようにしている。しかし、これに加えて、ゲームをクリアすることによりユーザの経験値をアップさせ、当該経験値が所定値に達することにより当該ユーザが属するHEX内のポータルPTLのランクをアップさせるようにしてもよい。ランクアップの効果は、より高いレアリティを当該ポータルPTLに設定し、当該ポータルPTLのクールタイムを0分に設定する旨の効果としてもよい。
また、ゲームが実行されることに応じて更新条件が成立することにより、ユーザに関連付けられているランクを更新し、当該更新条件を成立させたゲームを実行する契機となったポータルPTLが配置されているHEX内のポータルPTLについては、クールタイムが経過しているか否かにかかわらずクールタイムを0として、タップ操作を許容可能とするようにしてもよい。また、この場合、さらに遠方プレイ済フラグについてもリセットしてもよい。
(11) 上記実施形態においては、ポータルPTLへのタップ操作に応じてゲーム処理が実行された後において、当該ポータルPTLが属するHEXの内側にユーザ端末100が存在しないことにより、当該ポータルPTLに対する再度のタップ操作が許容されていないときでも、ユーザが所有するポータルチケットを消費することにより、当該再度のタップ操作が許容される。ここで、ポータルPTLおよびポータルチケットの各々に複数のレアリティのうちのいずれかを設定し、再度のタップ操作が許容されていないときに、タップ操作の対象となるポータルPTLとレアリティが一致するポータルチケットを消費することにより、当該ポータルPTLへの再度のタップ操作を許容するようにしてもよい。これによって、より多くのライブ配信タワーLTWをタップして様々なレアリティのポータルチケットを入手しようという動機付けが働く。
(12) 上記実施形態においては、ライブ配信タワーLTWへのタップ操作に応じて実行されるライブ視聴処理では、当該ライブ配信タワーLTWが配置されているHEXの位置にかかわらず、ユーザが所有するいずれの投げ銭アイテムも配信者に対して投入することができる。しかし、当該ライブ配信タワーLTWが配置されているHEXの位置に応じた種類の投げ銭アイテム(例えば、当該HEXが東京都墨田区に配置されている場合には、東京スカイツリーを模したアイテム)は、当該HEXが配置されている地域(例えば東京都墨田区)でライブ配信を視聴する視聴者に対しては投入可能とする一方、当該HEXが配置されている地域と異なる地域(例えば大阪市浪速区)でライブ配信を視聴する視聴者に対しては投入できないようにしてもよい。これによって、まず当該HEX内のポータルPTLに応じたゲームを実行してご当地アイテムを入手し、その後に当該HEX内のライブ配信タワーLTWをタップしようという一連の操作をユーザに促すことができる。
(13) 上記実施形態においては、ゲームをクリアすることにより付与されたご当地アイテム等の投げ銭アイテムを投入可能なコンテンツとして、ライブ視聴処理により視聴可能となるライブ配信コンテンツを想定している。しかし、当該投げ銭アイテムを投入可能なコンテンツは、これに限るものではない。即ち、アバターオブジェクト610が登場するライブ配信コンテンツであれば、種類は問わず、図11および図12を参照して説明したゲームや、ユーザがアバターオブジェクト610と対戦するゲームや、ユーザにより操作されるオブジェクトをアバターオブジェクト610とともに仮想空間に配置して進めるゲームにおいても、当該投げ銭アイテムを投入可能とするようにしてもよい。
(14) 上記実施形態においては、ポータルPTLのレアリティは、センタータワーCTWが「タップ済み」のHEXの数に関係なく、乱数抽選により銀、金、虹のいずれかに設定される。しかし、当該HEXの数が増えるほど虹が設定される確率を高くするなど、当該HEXの数に応じて異なる態様で当該レアリティを設定するようにしてもよい。
(15) 上記実施形態においては、ゲームを実行する契機となったタップ操作の対象であるポータルPTLに再設定するクールタイムの長さは、固定的である。しかし、ゲームを開始する直前に当該ポータルPTLに設定されていたレアリティに応じて、当該クールタイムの長さを異ならせるようにしてもよい。例えば、当該レアリティが虹であれば、当該クールタイムを150分に設定し、当該レアリティが金であれば、当該クールタイムを120分に設定し、当該レアリティが銀であれば、当該クールタイムを90分に設定するようにしてもよい。
(16) 上記実施形態においては、ユーザがゲームをクリアすることにより、投げ銭アイテムを当該ユーザに付与するようにしている。しかし、投げ銭アイテムの替わりに、または投げ銭アイテムとともに、有償の投げ銭アイテムを購入可能な仮想通貨をユーザに付与するようにしてもよい。このとき、当該仮想通貨の量は、当該ゲームの実行契機となったタップ操作の対象であるポータルPTLのレアリティに応じて異ならせるようにしてもよい。また、当該仮想通貨は、ユーザにより課金操作により購入できるようにしてもよい。
(17) 上記実施形態においては、ポータルPTLのクールタイムは、当該ポータルPTLに関連付けられているゲームをクリアしたか否かにかかわらず、再設定される。しかし、当該クールタイムは、当該ゲームをクリアすることを条件として、再設定するようにし、当該ゲームをクリアできなかったときには設定されないようにしてもよい。
(18) 上記実施形態においては、複数のHEX各々に配置されるライブ配信タワーLTWは1つであるが、当該ライブ配信タワーLTWは、当該複数のHEX各々に複数配置するようにしてもよい。
(19) 上記実施形態においては、「タップ済み」のセンタータワーCTWが配置されているHEXをハイライト表示により報知するようにしている。しかし、HEXの配置状態が視認できるように、当該HEXの輪郭を表す線を表示することにより、「タップ済み」のセンタータワーCTWが配置されているHEXであることを報知するようにしてもよい。この場合、「タップ済み」のセンタータワーCTWが配置されているHEXのハイライト表示は、必ずしも必要ではない。
(20) 上記実施形態においては、ポータルPTLにどのようなゲームを関連付けるかが当該ポータルPTLのレアリティによって規定されることはない。しかし、当該ポータルPTLに関連付けられるゲームを当該ポータルPTLのレアリティにより規定するようにしてもよい。即ち、レアイティが銀のポータルPTLには簡単なゲームを関連付け、レアイティが虹のポータルPTLには難しいゲームを関連付けるなどのように、ポータルPTLに関連付けられているゲームのクリアレベル(難易度)をレアリティに応じて異ならせるようにしてもよい。
(21) 上記実施形態においては、ポータルPTLが地域によって偏在しないようにポータルPTLの数を調整することを想定していない。しかし、複数のHEX各々に所定数以上のポータルPTLを配置するようにしてもよい。この場合、レアリティの高いポータルPTL即ちレアリティが虹のポータルPTLを、当該複数のHEX各々に必ず設定するようにしてもよい。さらに、ポータルPTLのレアリティを再設定する場合には、当該ポータルPTLが配置されているHEX内にレアイティが虹のポータルPTLが必ず存在するように、当該再設定を行うようにしてもよい。
(22) 上記実施形態においては、ポータルPTLのレアリティは、当該ポータルPTLに設定されているクールタイムの残り時間が0分となったときに再設定される。しかし、当該レアリティは、当該ポータルPTLに関連付けられているゲームが実行されたときに再設定するようにしてもよい。
(23) 上記実施形態においては、タッチスクリーン15に表示されている一覧アイコンICNがタップされると、センタータワーCTWの設定が「タップ済み」を示すHEXがテーブルTBL1上で特定され、図30(B)に示すように当該HEXの見出しが列挙された一覧画面がタッチスクリーン15に重畳して表示される。ここで、当該HEXの見出しには、地名(市町村など)および日時などの訪問履歴や、タップ操作の履歴(タップしたポータルPTLまたはライブ配信タワーの数など)を含めるようにしてもよい。
(24) 上記実施形態においては、ライブ視聴処理においてコンテンツを視聴するユーザに対して、ポータルチケットを付与するとともに、ゲームをクリアすることにより付与された投げ銭アイテムや、課金により付与された投げ銭アイテムを配信者に対して投入可能としている。ここで、ユーザが投げ銭アイテムを投入したときの方が、投入しなかったときよりも多くのポータルチケットを当該ユーザに付与したり、レアリティが高いポータルチケットを当該ユーザに付与したりしてもよい。また、課金により投げ銭アイテムを投入したときの方が、ゲームをクリアすることにより付与された投げ銭アイテムを投入したときよりも多くのポータルチケットを付与したり、レアリティが高いポータルチケットを付与したりしてもよい。
(25) 上記実施形態においては、地図画像におけるポータルPTLの表示態様は、当該ポータルPTLに対するタップ操作が許容されているか否かによって異ならせるとともに、当該ポータルPTLのレアリティに応じて異ならせるようにしている。これに加えて、またはこれに替えて、ポータルPTLの表示態様は、クールタイムの残り時間、当該ポータルに関連付けられているゲームの種類、当該ゲームをクリアすることにより付与される投げ銭アイテムの種類に応じて異ならせるようにしてもよい。
(26) 上記実施形態においては、サーバ200から取得したポータルPTLの位置情報およびポータルIDに基づいて、当該ポータルPTLをHEXの所定位置に表示し、サーバ200から取得したライブ配信タワーLTWの位置情報および配信タワーIDに基づいて、当該ライブ配信タワーLTWをHEXの所定位置に表示するようにしている。しかし、ポータルPTLおよびライブ配信タワーのうちの少なくとも一方については、HEX内のランダムな位置(乱数抽選により決定された位置)に配置するようにしてもよい。
(27) 上記実施形態においては、ライブ配信タワーLTWがタップされることにより、ライブ配信によるコンテンツを視聴する処理が実行される。しかし、ライブ配信に替えて録画済のコンテンツを視聴する処理を実行するようにしてもよい。
(28) 上記実施形態においては、ライブ視聴処理が終了すると、ライブ配信タワーLTWは非表示となり、ライブ配信によるコンテンツを視聴することはできなくなる。しかし、ライブ配信タワーLTWについてもクールタイムを設定し、当該クールタイムが経過することにより当該コンテンツを再度視聴可能とするようにしてもよい。
(29) 上記実施形態においては、ユーザ端末100がライブ配信時刻にライブ視聴の指定場所および当該指定場所と同じカテゴリの場所に存在することにより、当該ライブ配信を視聴できる。しかし、ライブ配信時刻よりも以前の段階において、ライブ指定場所あるいは当該指定場所と同じカテゴリの場所に出向いてユーザ端末100を存在させていることにより、ライブ配信されるときのユーザ端末の位置にかかわらず当該ライブ配信を視聴できるようにしてもよい。例えば、ユーザが、ライブ配信時刻よりも前にライブの指定場所あるいは指定場所と同じカテゴリの場所に行き、ライブ視聴操作を行って(ステップS145でYES)予約リストを表示し(ステップS146)、視聴予約したいライブをタップし(ステップS147でYES)、タップしたライブの指定場所とユーザ端末100の現在位置とが所定範囲内であること(ステップS152でYES)、または、タップしたライブのカテゴリとユーザ端末100の現在位置とが所定範囲内であること(ステップS153でYES)を条件として、視聴予約を行う。視聴予約されると、当該視聴予約対象のライブ配信は、その後のユーザ端末100の位置にかかわらず、視聴可能となる。これにより、ユーザ端末100がリアルタイムで指定場所あるいは指定場所と同じカテゴリに存在していないときであっても、一旦指定場所あるいは指定場所と同じカテゴリに出向いて存在させることによりライブ配信時刻前において既に許可条件が成立しているときには、ライブ配信時刻になれば当該ユーザ端末100の位置にかかわらず、予約したライブを視聴可能となる。
(30) 上記実施形態においては、ユーザ端末100の位置に応じて許可条件が成立することにより行われる所定の制御として、ライブ配信の視聴制御を例に挙げたが、ライブ配信の視聴制御に限るものではない。例えば、所定の制御としては、例えば、許可条件が成立していることにより実行可能となる所定のクエストを行う制御であってもよく、許可条件が成立していることにより実行可能となる所定のゲームを行う制御であってもよく、許可条件が成立していることにより実行可能となる所定の対戦を行う制御であってもよい。
(31) 上記実施形態においては、ユーザ端末100がゲームプレイ端末300からのライブ配信予定を受信してタッチスクリーン15に表示し(ステップS134、S135、図33(B))、ユーザが視聴予約したライブ配信予定をユーザ端末100において記憶する(ステップS136、S137)例を示したが、これに限らず、視聴予約せずともユーザ端末100がゲームプレイ端末300から受信したライブ配信予定を全て記憶するようにしてもよい。また、ユーザの操作に応じて、記憶した全てのライブ配信予定をタッチスクリーン15において一覧表示されるようにしてもよい。さらに、ライブの内容(例えば、ストーリーパート、対戦ゲームパート等)もテーブルTBL2に記憶し、ライブ配信日時、カテゴリまたはライブの内容等をキーワードとしてライブ配信予定を検索してその検索結果を一覧表示できるようにしてもよい。
さらには、ユーザが視聴予約しなくても、ユーザの操作に応じて、その都度ゲームプレイ端末300に問い合わせてライブ配信番組表をタッチスクリーン115に一覧表示できるようにしてもよい。また、ユーザからの入力操作に応じて、所定時間(例えば1時間)以内に配信予定のライブを一覧表示できるようにしてもよい。
(32) 上記実施形態における専用投げ銭アイテムは、1つのカテゴリにおいてのみ投入可能である例について説明した。しかし、専用投げ銭アイテムは、特定のカテゴリに属する場所に出向くことにより視聴可能となるライブ配信中においてのみ投入して配信者に付与できるアイテムであればこれに限らず、例えば、特定のカテゴリとして2つ以上のカテゴリが定められているものであってもよい。例えば、鐘は、寺以外に教会でも投入可能にし、噴水は、公園以外に地下街でも投入可能にしてもよい。
(33) 上記実施形態においては、ゲームプレイ端末300が他のサービス提供装置のAPIを利用することにより、ライブ視聴の指定場所が属するカテゴリを特定するようにしている。しかし、ユーザ端末100が他のサービス提供装置のAPIを利用することにより、当該カテゴリを特定するようにしてもよい。この場合、図33(A)に示すステップS131の処理は実行する必要はなく、ステップS132ではライブ配信予定をユーザ端末100に送信するようにしてもよい。また、専用投げ銭アイテムについては、ユーザ端末100において特定されたカテゴリに対応するものをユーザ端末100において特定するようにしてもよい。
<付記>
以上の各実施形態で説明した事項を、以下に付記する。
(付記1):
本開示に示す一実施形態のある局面によれば、プロセッサ、メモリ、入力部、および表示部を備える情報端末装置(ユーザ端末100)において実行されるゲームプログラムであって、前記ゲームプログラムは、前記プロセッサに、前記情報端末装置の位置を取得する第1ステップ(S150)と、前記第1ステップにより取得された位置に応じて許可条件が成立することにより(S152またはS153でYES)、所定の制御を行う第2ステップ(S166〜S168)とを実行させ、前記許可条件は、前記第1ステップにより取得された位置が、実空間において属するカテゴリが定められている複数種類の場所のうち所定の場所(ライブ視聴の指定場所)に対応する位置から所定範囲内(例えば30mの範囲内)にあることにより成立する第1許可条件(S152でYESと判定される条件)と、前記第1ステップにより取得された位置が、前記所定の場所(ライブ視聴の指定場所)とは異なり、前記複数種類の場所のうち前記所定の場所と同じカテゴリ(例えば、代々木公園に対する「公園」、図33(C))に属する場所に対応する位置から所定範囲内にあることにより成立する第2許可条件(S153でYESと判定される条件)とを含む。
(付記2):
(付記1)において、前記所定の制御は、配信者によって操作されるメインキャラクタが配置されている仮想空間内における映像を含むコンテンツを視聴可能とするための視聴用情報を情報端末装置において受信して、当該コンテンツをユーザに視聴させるための視聴制御(S166〜S168)である。
(付記3):
(付記2)において、前記ゲームプログラムは、前記プロセッサに、前記所定の場所を特定可能とするための情報を受信して当該所定の場所を前記コンテンツが視聴可能となるまでに報知する第3ステップ(S134、S135)を実行させる。
(付記4):
(付記2)または(付記3)において、前記コンテンツはライブ配信によるコンテンツである。
(付記5):
(付記2)〜(付記4)のいずれかにおいて、前記ゲームプログラムは、前記プロセッサに、前記視聴制御中において、複数種類のアイテムのうちのいずれかを前記配信者に付与可能とする第4ステップ(S169〜S173)を実行させ、前記配信者に付与可能となるアイテムは、前記視聴制御を行う契機となった場所が属するカテゴリに応じたアイテム(S169、図33(C))を含む。
(付記6):
(付記2)〜(付記5)のいずかにおいて、前記ゲームプログラムは、前記プロセッサに、所定のゲーム処理を実行する第5ステップ(S114)と、前記ゲーム処理中において所定の達成条件が成立することにより(S115でYES)、複数種類のアイテムのいずれかをユーザに関連付ける第6ステップ(S116)とを実行させ、前記第6ステップによりユーザに関連付けられるアイテムは、前記第1ステップにより取得された位置が、特定のカテゴリに属する場所に対応する位置から所定範囲内にあることを条件として行われる視聴制御中においてのみ前記配信者に付与可能となるアイテム(図33(C)の「公園」「神社」「鳥居」)を含む。
(付記7):
(付記1)〜(付記5)のいずかにおいて、前記ゲームプログラムは、前記プロセッサに、前記所定の制御が行われたことによりユーザに特典(ポータルチケット)を付与する第7ステップ(S175)を実行させる。
(付記8):
本開示に示す一実施形態のある局面によれば、プロセッサ、メモリ、入力部、および報知部を備える情報端末装置(ユーザ端末100)において位置情報を利用して実行されるゲーム方法であって、前記ゲーム方法は、前記情報端末装置が、前記情報端末装置の位置を取得する第1ステップ(S150)と、前記第1ステップにより取得された位置に応じて許可条件が成立することにより(S152またはS153でYES)、所定の制御を行う第2ステップ(S166〜S168)とを実行させ、前記許可条件は、前記第1ステップにより取得された位置が、実空間において属するカテゴリが定められている複数種類の場所のうち所定の場所(ライブ視聴の指定場所)に対応する位置から所定範囲内(例えば30mの範囲内)にあることにより成立する第1許可条件(S152でYESと判定される条件)と、前記第1ステップにより取得された位置が、前記所定の場所(ライブ視聴の指定場所)とは異なり、前記複数種類の場所のうち前記所定の場所と同じカテゴリ(例えば、代々木公園に対する「公園」、図33(C))に属する場所に対応する位置から所定範囲内にあることにより成立する第2許可条件(S153でYESと判定する条件)とを含む。
(付記9):
本開示に示す一実施形態のある局面によれば、位置情報取得部を備える情報端末装置(ユーザ端末100)であって、ゲームプログラムを記憶する記憶部と、前記ゲームプログラムを実行することにより、前記情報端末装置の動作を制御する制御部とを備え、前記制御部は、前記情報端末装置の位置を取得する第1ステップ(S150)と、前記第1ステップにより取得された位置に応じて許可条件が成立することにより(S152またはS153でYES)、所定の制御を行う第2ステップ(S166〜S168)とを実行させ、前記許可条件は、前記第1ステップにより取得された位置が、実空間において属するカテゴリが定められている複数種類の場所のうち所定の場所(ライブ視聴の指定場所)に対応する位置から所定範囲内(例えば30mの範囲内)にあることにより成立する第1許可条件(S152でYESと判定する条件)と、前記第1ステップにより取得された位置が、前記所定の場所(ライブ視聴の指定場所)とは異なり、前記複数種類の場所のうち前記所定の場所と同じカテゴリ(例えば、代々木公園に対する「公園」、図33(C))に属する場所に対応する位置から所定範囲内にあることにより成立する第2許可条件(S153でYESと判定する条件)とを含む。
〔ソフトウェアによる実現例〕
ユーザ端末100、サーバ200、ゲームプレイ端末300(HMDセット1000)、および配信端末400の制御ブロック(特に制御部110、210、310、410)は、集積回路(ICチップ)等に形成された論理回路(ハードウェア)によって実現してもよいし、ソフトウェアによって実現してもよい。
後者の場合、ユーザ端末100、サーバ200、ゲームプレイ端末300(HMDセット1000)、および配信端末400は、各機能を実現するソフトウェアであるプログラムの命令を実行するコンピュータを備えている。このコンピュータは、例えば1つ以上のプロセッサを備えていると共に、上記プログラムを記憶したコンピュータ読み取り可能な記録媒体を備えている。そして、上記コンピュータにおいて、上記プロセッサが上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記プロセッサとしては、例えばCPU(Central Processing Unit)を用いることができる。上記記録媒体としては、「一時的でない有形の媒体」、例えば、ROM(Read Only Memory)等の他、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムを展開するRAM(Random Access Memory)などをさらに備えていてもよい。また、上記プログラムは、該プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して上記コンピュータに供給されてもよい。なお、本発明の一態様は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。